Universität Ulm | 89069 Ulm | Germany Fakultät für
Ingenieurwissenschaften
und Informatik
Institut für Datenbanken
und Informationssysteme
Systematische Analyse von
Vorgehensmodellen zur Unterstützung
wissensintensiver Prozesse
Bachelorarbeit an der Universität Ulm
Vorgelegt von:
Simon Stöferle
simon.stoefer[email protected]
Gutachter:
Prof. Dr. Manfred Reichert
Betreuer:
Nicolas Mundbrod
2015
Fassung 20. August 2015
c
2015 Simon Stöferle
Kurzfassung
Wissensarbeit wird immer mehr zur vorherrschenden Arbeitsform in hochentwickelten
Ländern. Dabei setzen Wissensarbeiter ihre Erfahrung, individuellen Fähigkeiten und
ihre Fachkenntnis ein, um schwierige und neuartige Probleme zu lösen. An einem
wissensintensiven Prozess sind meist mehrere Wissensarbeiter beteiligt, um ein ge-
meinsames Ziel zu erreichen. Bei ihrer täglichen Arbeit sehen sich Wissensarbeiter mit
vielen Herausforderungen konfrontiert. Das Hauptproblem der Wissensarbeit besteht in
der sehr hohen Komplexität der zu lösenden Probleme. Um Wissensarbeiter bei ihrer
Arbeit zu unterstützen, werden Vorgehensmodelle eingesetzt, die den wissensintensiven
Prozess typischerweise in verschiedene Phasen gliedern. Daher stellt sich die Frage, ob
es geeignete Kriterien gibt, anhand derer entschieden werden kann, ob ein bestimmtes
Vorgehensmodell zur Unterstützung eines wissensintensiven Prozesses geeignet ist.
Das Ziel dieser Arbeit ist es, einen Überblick über ausgewählte Vorgehensmodelle aus
verschiedenen wissensintensiven Domänen zu geben, sowie diese Modelle systematisch
zu analysieren und mithilfe eines Rahmenwerks zu vergleichen. Die Ergebnisse sollen
klären, wie ein Vorgehensmodell einen wissensintensiven Prozess unterstützen kann
und ob es markante Messgrößen für Vorgehensmodelle gibt, anhand derer man die
Eignung zur Unterstützung eines wissensintensiven Prozesses erkennen kann.
iii
Danksagung
Als erstes möchte ich mich bei meinem Betreuer Nicolas Mundbrod für seine zahlreichen
Tipps und Anregungen bedanken, die mir bei der Erstellung dieser Arbeit immer sehr
geholfen haben. Durch seinen spontanen Einsatz bei der Übernahme dieser Arbeit
wurde diese erst ermöglicht. Vielen Dank hierfür.
Schließlich möchte ich meiner Familie danken, die mir durch ihre uneingeschränkte
Unterstützung das Studium und somit auch diese Arbeit ermöglicht haben.
v
Inhaltsverzeichnis
1 Einleitung 1
1.1 Problemstellung ................................ 2
1.2 Zielsetzung ................................... 3
1.3 AufbauderArbeit................................ 4
2 Grundlagen 7
2.1 Wissen ..................................... 8
2.2 Wissensarbeit.................................. 9
2.3 Wissensarbeiter ................................ 10
2.4 Wissensintensiver Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Domäne..................................... 13
2.6 Vorgehensmodell................................ 14
3 Methodik 17
3.1 Methodik dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Vergleichsaspekte ............................... 20
3.2.1 Aspekte allgemeiner Vorgehensmodelle . . . . . . . . . . . . . . . 20
3.2.2 Aspekte wissensintensiver Prozesse . . . . . . . . . . . . . . . . . 29
3.3 Darstellung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse 39
4.1 V-ModellXT................................... 39
4.2 Kanban ..................................... 41
4.3 Scrum...................................... 43
vii
Inhaltsverzeichnis
4.4 VDIRichtlinie2221............................... 45
4.5 AEP - Anforderungs-Engineering-Prozessmodell . . . . . . . . . . . . . . 47
4.6 KlinischePfade................................. 48
4.7 Guide to the Project Management Body of Knowledge . . . . . . . . . . . 52
5 Einordnung und Vergleich von Vorgehensmodellen 55
5.1 V-ModellXT................................... 56
5.1.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Kanban ..................................... 68
5.2.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 73
5.3 Scrum...................................... 78
5.3.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 83
5.4 VDIRichtlinie2221............................... 88
5.4.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.4.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 92
5.5 AEP - Anforderungs-Engineering-Prozessmodell . . . . . . . . . . . . . . 95
5.5.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 100
5.6 KlinischePfade.................................104
5.6.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.6.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 109
5.7 Guide to the Project Management Body of Knowledge . . . . . . . . . . . 113
5.7.1 Allgemeine Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.7.2 Wissensintensive Aspekte . . . . . . . . . . . . . . . . . . . . . . . 118
5.8 Vergleich der Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . 122
6 Diskussion 135
6.1 Qualitative Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . 135
6.2 Beantwortung der Forschungsfragen . . . . . . . . . . . . . . . . . . . . . 145
viii
1
Einleitung
Durch den Wandel der Gesellschaft in hochentwickelten Ländern von einer Industrie-
gesellschaft hin zu einer wissensbasierten Gesellschaft entwickelt sich die Wissensarbeit
zur vorherrschenden Arbeitsart [
PS98
]. Wissensarbeit wird von Wissensarbeitern (z.B.
Mediziner, Ingenieure, Forscher) vollbracht, die in einer wissensintensiven Domäne
tätig sind. Dabei setzen die Wissensarbeiter ihre Erfahrung, individuellen Fähigkeiten
und ihre Fachkenntnis ein, um schwierige und neue Probleme zu lösen. Der Anteil
von Wissensarbeitern beträgt heutzutage 25-40% der Arbeitskraft in wissensintensiven
Bereichen [
DCMR15
]. An einem wissensintensiven Prozess sind meist mehrere Wis-
sensarbeiter beteiligt, um ein Problem mithilfe von Wissensarbeit zu lösen. Dabei ist
der Ablauf eines wissensintensiven Prozesses im Gegensatz zu einem traditionellen
Geschäftsprozess aufgrund der hohen Komplexität der Wissensarbeit nicht vorhersehbar
[
MR14
]. Wissensintensive Prozesse sind ein wichtiger Bestandteil der Arbeitswelt, da
viele Neuerungen durch wissensintensive Prozesse entstehen. Die Entwicklung eines
1
1 Einleitung
neuen Produktes, zum Beispiel, stellt einen wissensintensiven Prozess dar. Mithilfe die-
ser Prozesse entstehen viele Neuerungen und es werden schwierige Probleme gelöst,
für die es vorher noch keine Lösung gab. Deswegen ist es umso wichtiger, die Beteiligten
eines wissensintensiven Prozesses, die Wissensarbeiter, bei ihrer Arbeit zu unterstützen.
Dies stellt allerdings eine Herausforderung dar, da die Wissensarbeit inhärent eine
hohe Komplexität besitzt und ihr Ablauf nicht feststeht, sodass stets Abweichungen
auftreten können. Eine Möglichkeit wissensintensive Prozesse und ihre Beteiligten zu
unterstützen, ist der Einsatz von Vorgehensmodellen [
ERZ14
]. Vorgehensmodelle kön-
nen auch im Kontext traditioneller Geschäftsprozesse eingesetzt werden. Allerdings
sind bei diesen Prozessen der Ablauf, sowie die auszuführenden Tätigkeiten bereits
vorher bekannt, sodass ein Vorgehensmodell für einen traditionellen Geschäftsprozess
eher einem detaillierten Prozessmodell für Tätigkeiten entsprechen würde. Ein Vorge-
hensmodell für einen wissensintensiven Prozess dagegen gliedert typischerweise den
groben Ablauf des Prozesses in verschiedene Phasen [
Bre
]. Im Gegensatz zu traditio-
nellen Geschäftsprozessen sind bei wissensintensiven Prozessen keine detaillierten
Anleitungen zur Bearbeitung von Aufgaben möglich, da bei der Wissensarbeit stets
neuartige Probleme behandelt werden und die Aufgaben damit zu komplex sind, um
eine einheitliche Beschreibung für die Aufgaben zu finden.
1.1 Problemstellung
Wissensarbeiter sehen sich bei ihrer täglichen Arbeit in wissensintensiven Domänen
mit vielen Herausforderungen konfrontiert, um ein gemeinsames Ziel zu erreichen.
Das Hauptproblem der Wissensarbeit besteht in der sehr hohen Komplexität der zu
lösenden Probleme [
Hub05
]. An der Lösung eines Problems sind typischerweise meh-
rere Wissensarbeiter beteiligt. Um effektiv und effizient an der Lösung eines Problems
zusammenarbeiten zu können, ist eine Koordination zwischen den Wissensarbeitern
nötig. Die Aufgabenstellungen haben einen sehr hohen Neuheitsgrad und es existiert
in den meisten Fällen keine Standardlösung. Die Wissensarbeiter müssen also zuerst
einen Weg finden, wie sie eine Aufgabenstellung lösen können. Dies hat typischerweise
einen hohen Arbeitsaufwand zur Folge. Um diesen Arbeitsaufwand zu minimieren, ist
2
1.2 Zielsetzung
es wünschenswert, die Wissensarbeiter während ihrer Arbeit systematisch zu unter-
stützen. Eine Möglichkeit, um die Wissensarbeiter zu unterstützen, ist das Verwenden
von Vorgehensmodellen. Damit wird angestrebt den unvorhersehbaren Verlauf eines
wissensintensiven Prozesses in verschiedene Abschnitte zu gliedern, um somit die
Komplexität des Problems zu beherrschen, sowie die Qualität der Arbeitsergebnisse
wie auch die Koordination zu steigern. Allerdings bringen Vorgehensmodelle für die
Wissensarbeit erneut ein Problem mit sich: Es gibt viele unterschiedliche Vorgehens-
modelle und dadurch lässt sich nicht vorhersagen, ob ein bestimmtes Vorgehensmodell
für einen wissensintensiven Prozess geeignet ist. Deswegen stellt sich die Frage, ob es
geeignete Kriterien gibt, anhand derer entschieden werden kann, ob ein bestimmtes
Vorgehensmodell zur Unterstützung eines vorgegebenen wissensintensiven Prozesses
geeignet ist. Dabei fällt es schwer solche Kriterien zu definieren, da die Kriterien sehr
allgemein gehalten werden sollten, um die Bewertung möglichst vieler verschiedener
Vorgehensmodelle zu ermöglichen. Allerdings könnten dann spezielle Bedürfnisse ei-
nes wissensintensiven Prozesses bei der Bewertung unberücksichtigt bleiben. Somit
könnte ein den Kriterien nach passendes Vorgehensmodell ausgewählt werden, das
diese speziellen Bedürfnisse nicht erfüllen kann. Dadurch würden die Wissensarbeiter
allerdings nicht unterstützt, sondern das ungeeignete Vorgehensmodell würde ihre Arbeit
erschweren.
1.2 Zielsetzung
Wissensintensive Prozesse sind meist an eine Domäne gebunden, wie z.B. Forschung,
Entwicklung oder Medizin. Dadurch stellt sich die Frage, ob die unterschiedlichen Vor-
gehensmodelle, die zur Unterstützung von wissensintensiven Prozessen eingesetzt
werden, auch an eine Domäne gebunden sind. Das Ziel dieser Arbeit ist es, einen
Überblick über Vorgehensmodelle aus unterschiedlichen wissensintensiven Domänen zu
schaffen, sowie diese Vorgehensmodelle systematisch zu analysieren. Es sollen hierbei
Gemeinsamkeiten und Unterschiede zwischen den verschiedenen Vorgehensmodellen
systematisch herausgearbeitet werden, und in diesem Zusammenhang sollen durch die
3
1 Einleitung
Ergebnisse dieser Arbeit abschließend folgende Forschungsfragen (FF) beantwortet
werden:
•FF1: In wie weit sind etablierte Vorgehensmodelle domänenabhängig?
•
FF2:
Gibt es Messgrößen, anhand derer bewertet werden kann, wie gut ein Vor-
gehensmodell für einen wissensintensiven Prozess geeignet ist?
•
FF3:
Welchen Beitrag leisten Vorgehensmodelle zur Unterstützung der Wissens-
arbeiter?
1.3 Aufbau der Arbeit
An dieser Stelle soll ein Überblick über den weiteren Verlauf dieser Arbeit gegeben
werden. Im folgenden Kapitel 2 werden die grundlegenden Begriffe im Kontext wis-
sensintensiver Prozesse vorgestellt, sowie der Begriff des Vorgehensmodells näher
erläutert. In Kapitel 3 wird ein Rahmenwerk zur Analyse und zum Vergleich von Vorge-
hensmodellen zur Unterstützung wissensintensiver Prozesse entwickelt. Dabei werden
elf Vergleichsaspekte zur Analyse allgemeiner Merkmale eines Vorgehensmodells, sowie
zehn Vergleichsaspekte zur Analyse der wissensintensiven Eigenschaften von Vorge-
hensmodellen vorgestellt. Anschließend wird eine Darstellung für die gefundenen Ana-
lyseergebnisse eingeführt. In Kapitel 4 werden sieben untersuchte Vorgehensmodelle
vorgestellt und deren wichtigste Aspekte kurz erläutert. Außerdem wird auf weiterfüh-
rende Literatur für die jeweiligen Vorgehensmodelle verwiesen. Bei den untersuchten
Vorgehensmodellen handelt es sich um das V-Modell XT, Kanban, Scrum, die VDI
Richtlinie 2221, das Anforderungs-Engineering-Prozessmodell, klinische Pfade und den
Guide to the Project Management Body of Knowledge. In Kapitel 5 erfolgt die Darstellung
der Ergebnisse aus der Analyse der Vorgehensmodelle. Hierbei werden zu jedem der
sieben Vorgehensmodelle alle 21 Vergleichsaspekte untersucht und die Ergebnisse in
schriftlicher und visueller Form vorgestellt. Außerdem erfolgt ein Vergleich der Vorge-
hensmodelle anhand der zuvor vorgestellten Vergleichsaspekte. In Kapitel 6 werden die
Ergebnisse diskutiert und die Auswirkungen der Ergebnisse erläutert. Abschließend wird
4
2
Grundlagen
Die
Wissensarbeit
wird von dem Wissen und der Erfahrung der involvierten
Wissens-
arbeiter
geprägt. Daher wird der Begriff
Wissen
wird in Kapitel 2.1 genauer erläutert
und die zwei Arten von Wissen werden vorgestellt. Darauf aufbauend wird in Kapitel 2.2
die Arbeitsform Wissensarbeit definiert, während Wissensarbeiter in Kapitel 2.3 näher
beschrieben werden. In Kapitel 2.4 werden
wissensintensive Prozesse
charakterisiert
und der idealtypische Ablauf wissensintensiver Prozesse betrachtet. Wissensarbeiter
sind typischerweise in einer
Domäne
tätig, in der sie als Experte gelten und speziel-
les Expertenwissen für diese Domäne besitzen [
FF03
]. Der Begriff der Domäne wird
daher in Kapitel 2.5 erläutert. Da Wissensarbeit keine klaren, vordefinierten Abläufe
besitzt, benötigen Wissensarbeiter ein Rahmenmodell, welches einzelne Tätigkeiten in
verschiedene, strukturierte Abschnitte organisiert. Ein
Vorgehensmodell
gliedert diese
Abschnitte anschaulich in einer logischen Anordnung. Der Begriff des Vorgehensmodells
wird in Kapitel 2.6 näher erläutert.
7
2 Grundlagen
2.1 Wissen
Um zu verstehen, wie Wissensarbeiter in den unterschiedlichen Domänen arbeiten
und welche Vorgehensmodelle sie für ihre Arbeit einsetzen, ist es hilfreich, sich zuerst
mit dem Begriff
Wissen
auseinanderzusetzen. Es ist festzustellen, dass es für Wissen
keine eindeutige Definition gibt. Allerdings lassen sich vier wichtige Begriffe identifizie-
ren:
Zeichen
,
Daten
,
Informationen
und
Wissen
. Werden Zeichen in eine bestimmte
Ordnung gebracht, so entstehen Daten. Kann eine Person diese Daten nun in einem
bestimmten Kontext interpretieren, so entstehen Informationen für diese Person. Wissen
entsteht schließlich durch eine subjektive Interpretation der Informationen und durch die
Verknüpfung mit bereits vorhandenen Informationen [
Nor99
]. Dieser Zusammenhang
ist in Abbildung 2.1 verdeutlicht. Definition 2.1 stellt eine Definition des Begriffs Wissen
nach [DP00] dar.
Definition 2.1
(
Wissen
)
.Wissen ist eine Mischung aus Erfahrungen, Werten, Kontext-
informationen und Expertenverständnis, das den Rahmen für Auswertung und Aufnah-
me neuer Erfahrungen und Informationen bildet. Es entsteht in den Köpfen von Wissen-
den und wird auch dort eingesetzt. In Unternehmen wird es oft nicht nur in Dokumenten
festgehalten, sondern auch in organisatorischen Abläufen, Prozessen, Methoden und
Regeln.
Abbildung 2.1: Entstehung von Wissen nach [Hub05]
8
2.2 Wissensarbeit
Wissen lässt sich in zwei verschiedene Wissensarten unterscheiden:
explizites Wissen
und
implizites Wissen
. Explizites Wissen lässt sich einfach teilen und ist nicht an den
Wissenden gebunden. Implizites Wissen hingegen ist an den Wissenden gebunden
und lässt sich nur schwer teilen. Das Problem beim impliziten Wissen ist, dass man
den Kern des Wissens nicht ausdrücken kann. Hierzu kann man das Beispiel des
Fahrradfahrens betrachten. Es ist nicht möglich, das Wissen, wie man das Gleichgewicht
auf dem Fahrrad hält, zu transportieren. Somit kann man implizites Wissen nicht an eine
andere Person übertragen [
MKR13
]. Dieses Wissen muss sich die Person durch eigene
Erfahrungen aneignen. Ein Beispiel für explizites Wissen sind Informationen, die für die
Benutzung der Gangschaltung eines Fahrrads wichtig sind. Diese sind explizit, da sich
diese Informationen zwischen verschiedenen Personen austauschen und z.B. in einer
Betriebsanleitung festhalten lassen.
2.2 Wissensarbeit
[
Hub05
] trennt den Begriff
Wissensarbeit
von dem verwandten Begriff der
intellektuellen
Arbeit
. Intellektuelle Arbeit beinhaltet generelle Denkarbeit, wohingegen Wissensarbeit
nur das Lösen von neuartigen, komplexen Problemen, für die es keine Standardlösungen
gibt, umfasst [MKR13]. Dies führt zu folgender Definition 2.2 nach [Hub05]:
Definition 2.2
(
Wissensarbeit
)
.Wissensarbeit sind geistig objektivierende Tätigkei-
ten, die neuartige und komplexe Arbeitsprozesse und -ergebnisse betreffen, die äußere
Mittel zur Steuerung der Komplexität und ein zweifaches Handlungsfeld benötigen.
Das zweifache Handlungsfeld besteht aus dem Referenzhandlungsfeld, in dem das
Problem nur theoretisch behandelt wird, und dem faktischen Handlungsfeld, in dem
Werkzeuge zur Beherrschung der Komplexität eingesetzt werden, sowie die eigentlichen
Handlungen ausgeführt werden, um das Arbeitsziel zu erreichen (siehe Abbildung 2.2).
9
2 Grundlagen
2.3 Wissensarbeiter
Personen, die Wissensarbeit vollbringen, werden als
Wissensarbeiter
bezeichnet. Bei-
spiele für Wissensarbeiter sind Manager, Ärzte oder Forscher. Definition 2.3 führt den
Begriff Wissensarbeiter nach [Dav05] ein.
Definition 2.3
(
Wissensarbeiter
)
.Wissensarbeiter sind gut ausgebildete Experten,
mit viel Erfahrung und hohen Bildungsabschlüssen. Das Ziel ihrer Arbeit ist der Einsatz
und die Durchführung von Wissensarbeit.
Wie komplex und schwierig die Lösung eines Problems ist, hängt immer vom Standpunkt
des Betrachters ab. Eine unerfahrene Person wird bestimmte Aufgaben deutlich schwie-
riger bewerten, als eine erfahrene Person, da ihr die nötige Erfahrung fehlt. Womöglich
würde eine erfahrene Person die Aufgabe sogar als einen Routinevorgang einstufen, da
sie bereits mehrere gleichartige Probleme gelöst hat und eine routinierte Vorgehenswei-
se für derartige Probleme entwickelt hat. Aufgrund dieser Tatsache werden schwierige
und komplexe Probleme bei der Wissensarbeit meist in kleinere und einfachere Teil-
probleme aufgeteilt und an Wissensarbeiter verteilt, die die nötigen Fähigkeiten und
eventuell bereits Erfahrungen mit ähnlichen Problemen haben [MKR13].
2.4 Wissensintensiver Prozess
In einem
wissensintensiven Prozess
sind meist mehrere Wissensarbeiter beteiligt, um ei-
ne Aufgabenstellung mithilfe von Wissensarbeit zu lösen. Damit ähnelt ein wissensinten-
siver Prozess einem traditionellen Geschäftsprozess, allerdings hat ein wissensintensiver
Prozess keinen vordefinierten, detaillierten Prozessablauf. Der Ablauf eines wissensin-
tensiven Prozesses lässt sich aufgrund der hohen Komplexität der Wissensarbeit nur
sehr schwer festlegen. Allerdings ist der idealtypische Ablauf eines wissensintensiven
Prozesses nach [
Hub05
] in verschiedene Prozessphasen eingeteilt (siehe Abbildung 2.2).
Dabei kann jede Phase einmal, mehrmals oder gar nicht ausgeführt werden. In der
ersten Phase werden verschiedene Aufgaben aus der Zielsetzung abgeleitet, die zur
10
2.4 Wissensintensiver Prozess
Zielerreichung dienen sollen. In der zweiten und dritten Phase werden die Aufgaben kon-
kretisiert und über mögliche Hilfsmittel entschieden. Anschließend werden in der vierten
Phase theoretische Lösungen abgewogen und in der fünften Phase entsprechende Lö-
sungsstrategien entwickelt. Die sechste Phase stellt die praktische Lösung des Problems
dar, dies kann z.B. die Erstellung eines Textes sein. Die siebte Phase dient der Bewer-
tung der Qualität des Ergebnisses. Davon ausgehend werden eventuell Anpassungen
an der entwickelten Lösungsstrategie nötig. Dies geschieht in der achten Phase. Weist
die Lösung nicht die gewünschte Qualität auf, so kann mit der neunten Phase der ge-
samte Prozess erneut gestartet werden. Die Aufgaben werden in zwei Handlungsfeldern
durchgeführt: dem faktischen Handlungsfeld und dem Referenzhandlungsfeld.
Abbildung 2.2:
Ablauf eines idealtypischen, wissensintensiven Prozesses nach [
Hub05
]
Im faktischen Handlungsfeld werden Werkzeuge eingesetzt, um die Komplexität des
Arbeitsprozesses zu beherrschen, damit die Orientierung im Referenzhandlungsfeld
einfacher gelingt. Die Umsetzung der im Referenzhandlungsfeld festgelegten Lösungs-
strategie erfolgt im faktischen Handlungsfeld und hat das faktische Ergebnis zur Folge.
Im Referenzhandlungsfeld wird vom Wissensarbeiter nur probegehandelt. Damit kann
der Wissensarbeiter seine Handlungsmöglichkeiten im faktischen Handlungsfeld abwä-
gen und sich für eine Lösungsstrategie entscheiden. Im Referenzhandlungsfeld entsteht
11
2 Grundlagen
das Referenzergebnis, welches das faktische Ergebnis in Form symbolischer Gegen-
stände wie Zeichnungen, Schriftstücken oder Skizzen darstellt [Hub05].
Abbildung 2.3: Lebenszyklus eines wissensintensiven Prozesses nach [MKR13]
Zur Unterstützung wissensintensiver Prozesse hat [
MKR13
] einen Lebenszyklus für
wissensintensive Prozesse vorgestellt (siehe Abbildung 2.3). Dieser besteht aus vier
Lebenszyklus-Phasen:
Orientierung
,
Vorlagen-Entwurf
,
Gemeinsame Bearbeitungspha-
se und Auswertung der Datensätze.
In der
Orientierungsphase
werden Informationen über den wissensintensiven Prozess
gesammelt. Dabei können Wissensarbeiter Datensätze von abgeschlossenen Arbei-
ten benutzen, involvierte Wissensarbeiter befragen oder eine themenbezogene Lite-
raturrecherche durchführen. Das Ziel der Phase ist eine Prozessbeschreibung. In der
Vorlagen-Entwurfsphase
werden Zusammenarbeits-Vorlagen (
Collaboration Template
(CT)) erstellt. Ein CT soll Zugang zu Informationen liefern, sowie Kommunikation und
Koordination zwischen den Wissensarbeitern fördern. Ein CT muss dabei gut anpassbar
sein und muss deswegen gewissenhaft geplant werden, um die Wissensarbeiter zu
unterstützen. In der
gemeinsamen Bearbeitungsphase
können Wissensarbeiter eine
Zusammenarbeits-Instanz (
Collaboration Instance
(CI)) aus einem oder mehreren CTs
erzeugen. Die Wissensarbeiter sollen die CTs vollständig nutzen, um das gemeinsa-
me Ziel zu erreichen. Außerdem können Wissensarbeiter auf fertiggestellte CIs, sog.
Zusammenarbeits-Datensätze (
Collaboration Records
(CR)), zugreifen, um wichtige
12
2.5 Domäne
Informationen zu erhalten, die den Arbeitsprozess beschleunigen können. In der Phase
Auswertung der Datensätze
werden die fertiggestellten CIs zu CRs archiviert, die von
Wissensarbeitern jederzeit einsehbar sind, um an wichtige Informationen zu gelangen.
Außerdem werden die fertiggestellten CIs analysiert und evtl. Änderungen an existieren-
den CTs vorgenommen oder neue, spezifischere CTs entworfen, da die eingesetzten
CTs zu unspezifisch waren und die Wissensarbeiter dadurch unzureichend unterstützt
wurden.
2.5 Domäne
Wissensarbeiter sind typischerweise in einem Fachgebiet, d.h. einer
Domäne
, tätig, für
welches sie Expertenwissen besitzen. Eine Domäne zeichnet sich durch eine Fachspra-
che aus, die ein Wissensarbeiter in der Domäne beherrschen muss.
Wissensintensi-
ve Domänen
sind jene spezielle Domänen, in denen Wissensarbeiter tätig sind und
Wissensarbeit vollbringen. Typische Beispiele für wissensintensive Domänen sind die
Medizin und Forschung. Definition 2.4 führt den Begriff der wissensintensiven Domäne
in Anlehnung an [FF03] ein und fasst ihre wichtigsten Eigenschaften zusammen.
Definition 2.4
(
wissensintensive Domäne
)
.Eine wissensintensive Domäne stellt ein
Fachgebiet dar, in dem zum Großteil Wissensarbeit vollbracht wird. Eine wissensin-
tensive Domäne besitzt bekanntes Domänenwissen, welches von den Domänenexper-
ten, d.h. den Wissensarbeitern, benutzt wird und mit Intuition und Erfahrung kombi-
niert wird. In wissensintensiven Domänen bestehen die zu lösenden Aufgaben aus der
Vermischung mehrerer Aufgabentypen. Es besteht eine Vielfalt möglicher Ausgangssi-
tuationen und daraus resultierender Wege zur Aufgabenlösung. Es ist nicht bekannt,
welche Informationen zum Aufgabenlösen verwendet werden müssen. Informationen
sind nicht direkt messbar, sondern werden durch den Menschen erhoben und inter-
pretiert und sind dadurch subjektiv. Wissensintensive Domänen sind stark mit anderen
(benachbarten) Domänen verwoben.
13
2 Grundlagen
2.6 Vorgehensmodell
Vorgehensmodelle sind vor allem in der Systementwicklung und im Software Engineering
von sehr großer Bedeutung [
Bre
]. Definition 2.5 nach [
Bre
] schafft einen Überblick über
den Begriff des Vorgehensmodells.
Definition 2.5
(
Vorgehensmodell
)
.Ein Vorgehensmodell stellt eine modellhafte, ab-
strahierende Beschreibung von Vorgehensweisen, Richtlinien, Empfehlungen oder Pro-
zessen für einen Problembereich dar. Ein Vorgehensmodell gliedert eine Folge von Ak-
tivitäten, die zur Durchführung eines Projekts nötig sind, in verschiedene Phasen.
Dabei lässt sich ein Projekt meist in fünf verschiedene Phasen einteilen (siehe beispiel-
haft Abbildung 2.4):
1. Vorphase: Vorbereitungen für das Projekt werden getroffen.
2. Analysephase: Problemstellung wird analysiert.
3. Entwurfphase: Ausgehend von der Analyse wird ein Entwurf erarbeitet.
4. Realisierungsphase: Der Entwurf wird umgesetzt, z.B. Produktentwicklung.
5. Abschlussphase: Das Projekt wird abgeschlossen.
Für jede Phase ist jeweils festzulegen,
was zu tun
ist und
wie etwas zu tun
ist, d.h. welche
Methoden oder Werkzeuge einzusetzen sind. Des Weiteren werden für jede Phase
die Phasenergebnisse definiert. Durch die Phaseneinteilung wird die Komplexität des
Projektes verringert, da die Hauptaufgabe in überschaubare Teilaufgaben zerlegt wird.
Ein weiterer positiver Aspekt der Phaseneinteilung ist, dass Phasenziele (Meilensteine)
vorgegeben werden können. Mithilfe der Meilensteine kann die Qualität der Ergebnisse
stets kontrolliert werden und schnell auf eventuelle Fehler reagiert werden [
Bre
]. Ein
Vorgehensmodell stellt dabei eine konkrete Ausgestaltung einer Methodik dar, d.h.
es ermöglicht methodisches Vorgehen [
PP11
]. Allerdings legen Vorgehensmodelle
typischerweise nicht genau fest, welche Methoden innerhalb einer Phase zur Bearbeitung
der Aufgaben eingesetzt werden sollen. Die Auswahl der passenden Methoden ist
typischerweise die Aufgabe der involvierten Personen.
14
2.6 Vorgehensmodell
Abbildung 2.4: Vorgehensmodell für Software Engineering Projekt nach [Bre]
Ein konkretes Vorgehensmodell zur Unterstützung wissensintensiver Prozesse kann als
eine Vorlage betrachtet werden, ähnlich einem CT (siehe Kapitel 2.4). Dabei wird das
Vorgehensmodell für jeden wissensintensiven Prozess, der unterstützt werden soll, als CI
mit seinem Prozesskontext instanziiert. Somit dient der Einsatz eines Vorgehensmodells
bereits der Unterstützung eines wissensintensiven Prozesses nach dem Lebenszyklus
wissensintensiver Prozesse.
15
3
Methodik
In diesem Kapitel werden die zum Vergleich der unterschiedlichen Vorgehensmodelle
verwendeten Vergleichsaspekte vorgestellt. Zusätzlich werden Werte für die jeweiligen
Vergleichsaspekte definiert und beschrieben, damit ein methodisch sauberer Vergleich
möglich ist. Die Vergleichsaspekte sind in zwei unterschiedliche Kategorien gegliedert:
Aspekte allgemeiner Vorgehensmodelle
(Kapitel 3.2.1) und
Aspekte wissensintensiver
Prozesse
(Kapitel 3.2.2). In Kapitel 3.3 wird beschrieben, wie die erarbeiteten Ergebnisse
dargestellt werden.
Zuvor wird jedoch nun das allgemeine Vorgehen bei der Durchführung dieser Bachelor-
arbeit erläutert.
17
3 Methodik
3.1 Methodik dieser Arbeit
Um ein methodisches Vorgehen zu gewährleisten, wurde für diese Arbeit ein Vorge-
hensmodell entwickelt. Dieses ist in Abbildung 3.1 dargestellt. Am Anfang werden
wichtige Forschungsfragen festgelegt (siehe Kapitel 1.2), die mithilfe dieser Arbeit be-
antwortet werden sollen (siehe Kapitel 6.2). Anschließend wird ein umfangreiches
Vergleichs-Rahmenwerk mit insgesamt 21 Vergleichsaspekten für den Vergleich der
Vorgehensmodelle entwickelt (siehe Kapitel 3.2). Das Rahmenwerk orientiert sich an
dem Vergleichs-Rahmenwerk von [
Fil05
] für den Vergleich von Vorgehensmodellen
aus der Softwareentwicklung. Anschließend werden passende Vorgehensmodelle aus
den Bereichen Softwareentwicklung, Medizin, Ingenieurwesen und Projektmanagement
ausgewählt.
Das V-Modell XT ist ein Vorgehensmodell aus dem Bereich der Softwareentwicklung
und wurde ausgewählt, da es ein oft eingesetztes Vorgehensmodell ist [
BR05
] und eine
öffentlich zugängliche Dokumentation besitzt. Die Vorgehensmodelle Kanban und Scrum
wurden ausgewählt, da sie typische Vertreter der agilen Softwareentwicklung sind und
somit einen Gegensatz zum traditionellen V-Modell XT darstellen. Scrum ist dabei die in
der Praxis am meisten genutzte agile Methode, gefolgt von Kanban [
Kom14
]. Diese drei
Vorgehensmodelle werden vor allem in der Softwareentwicklung eingesetzt und liefern
somit gute Vertreter für diese wissensintensive Domäne.
Als Vertreter für die Ingenieursdomäne wurden die VDI Richtlinie 2221, sowie das
Anforderungs-Engineering-Prozessmodell (AEP) ausgewählt. Bei der Suche nach pas-
senden Vorgehensmodellen aus dem Ingenieurwesen ist die VDI Richtlinie 2221 in
den Fokus gerückt, da diese ein Referenzmodell für den Entwicklungs- und Konstrukti-
onsprozess darstellt [
Ber02
]. Das AEP wurde ausgewählt, da es ein sehr spezifisches
Vorgehensmodell darstellt und somit einen Gegensatz zur VDI Richtlinie 2221 bildet.
Die
klinischen
Pfade wurden als Vertreter für die wissensintensive Domäne Medizin
ausgewählt, da diese durch die Einführung eines neuen Vergütungssystems für Kran-
kenhäuser in Deutschland immer mehr an Bedeutung gewinnen, da die Krankenhäuser
durch begrenzte Finanzmittel gezwungen sind, die Kosteneffizienz ihrer Prozesse und
Organisationen zu optimieren und gleichzeitig die Qualität und Leistungsfähigkeit zu
18
3.1 Methodik dieser Arbeit
steigern [
Pha07
]. Die klinischen Pfade sollen als Lösung für dieses Problem dienen.
Der Guide to the Project Management Body of Knowledge, kurz PMBOK Guide, wurde
ausgewählt, da dieser ein Standardwerk für das Management von Projekten darstellt
[SS13b].
Für jedes Vorgehensmodell wird nach passender Literatur gesucht, damit ein Vergleich
möglich wird. Danach wird jedes Vorgehensmodell mit seinen wichtigsten Eigenschaften
und dem Ablauf beschrieben (siehe Kapitel 4) und anschließend mithilfe der Vergleich-
saspekte analysiert (siehe Kapitel 5). Dies wird für jedes der ausgewählten Vorgehens-
modelle durchgeführt. Anschließend wird der Vergleich zwischen den verschiedenen
Vorgehensmodellen durchgeführt (siehe Kapitel 5.8) und die gefundenen Ergebnisse
festgehalten (siehe Kapitel 6). Zum Schluss erfolgt die Beantwortung der Forschungsfra-
gen (siehe Kapitel 6.2).
Forschungsfragen
festlegen
Vergleichs-Rahmenwerk
erstellen
passende
Literatur
suchen
Wiederhole bis kein
Vorgehensmodelle mehr
zu analysieren ist
Ergebnisse
festhalten
Forschungsfragen
beantworten
Vorgehensmodelle
analysieren
Start
Ende
Abbildung 3.1: Vorgehensmodell für die Durchführung dieser Arbeit
19
3 Methodik
3.2 Vergleichsaspekte
In diesem Abschnitt werden allgemeine Gesichtspunkte von Vorgehensmodellen vor-
gestellt. Diese Aspekte betreffen das Vorgehensmodell an sich und gehen nicht näher
auf wissensintensive Prozesse ein. Die Aspekte sind nummeriert und verfügen über das
Kürzel „GA“ für general aspect1.
Anschließend werden die Vergleichsaspekte für wissensintensive Prozesse betrachtet.
Die wissensintensiven Aspekte werden mit dem Kürzel „KIA“ für
knowledge intensive
aspect2durchnummeriert.
Die Vergleichsaspekte werden in Kapitel 5 verwendet, um die ausgewählten Vorgehens-
modelle zu analysieren und anschließend miteinander zu vergleichen. Bei der Analyse
der Vorgehensmodelle kann ein Vergleichsaspekt auch mehrere Werte annehmen.
3.2.1 Aspekte allgemeiner Vorgehensmodelle
Die GAs wurden von [
Chr92
], [
Ger99
], [
NS99
] und aus dem Vergleichs-Rahmenwerk
von [
Fil05
] übernommen und teilweise angepasst, sowie durch eigene Aspekte erweitert.
GA1 – Phasenabdeckung
Das Vorgehensmodell wird unter dem Gesichtspunkt der Vollständigkeit der aufgeführten
Phasen betrachtet. Die in Tabelle 3.1 aufgeführten Phasen stellen den Ablauf eines allge-
meinen Projektes nach [
Ger99
] dar. Dieser Vergleichsaspekt wird als Phasenabdeckung
bezeichnet.
Schlüsselfrage: Welche der Phasen werden im Vorgehensmodell abgedeckt?
1dt. allgemeiner Vergleichsaspekt
2dt. wissensintensiver Vergleichsaspekt
20
3.2 Vergleichsaspekte
Phase Beschreibung
Identifikation
In dieser Phase wird das Projektziel (Entität) identifiziert.
Dies geschieht durch Betrachtung der Begrenzungen des
Projektes und der Umweltbeziehungen. Das Ziel der Phase
ist eine Definition der Entität.
Konzept
In der Konzeptphase wird die Entität näher spezifiziert. Un-
ter anderem werden die Aufgaben und Ziele definiert, die
die Entität erfüllen muss.
Anforderungen
Es werden Anforderungen an die Entität entwickelt und alle
relevanten Prozesse beschrieben, sowie alle funktionalen,
verhaltensmäßigen, informationellen und fähigkeitsrelevan-
ten Bedürfnisse gesammelt und dargestellt.
Vorläufiges Design
Es wird ein erster Grobentwurf entwickelt, der die Anforde-
rungen an die Entität aus der Anforderungsphase erfüllt.
Dabei werden nur die wichtigen Funktionen berücksichtigt
und nur grob spezifiziert.
Detailliertes Design
Der Grobentwurf wird schrittweise verfeinert, bis alle Funk-
tionalitäten aus der Anforderungsphase erfüllt sind und alle
Aspekte der Entität abgedeckt sind. Das Ergebnis ist ein
Feinentwurf.
Entwicklung
Der zuvor entwickelte Entwurf wird nun umgesetzt und das
Produkt wird entwickelt. Die Entwicklungsphase beinhal-
tet dabei die eigentliche Umsetzung des Entwurfs, sowie
Integration und Installation.
Betrieb
Die Entität wird nun produktiv eingesetzt und erfüllt die
Aufgabe, wie z.B. Produktion von Waren. Abweichungen
vom erwünschten Verhalten oder andere Gründe können
zu Veränderungsaufträgen führen.
Abbau
Das Vorgehensmodell bietet Unterstützung für den Abbau
der Entität. Dies kann durch Anleitungen zur Demontage
oder Datenarchivierung bereitgestellt werden oder es wird
eine Migration auf ein neues Produkt unterstützt.
Tabelle 3.1: Ausprägungen der Phasenabdeckung nach [Ger99]
21
3 Methodik
GA2 – Prozessabdeckung
Das Vorgehensmodell wird auf zusätzlich beschriebene Tätigkeiten untersucht. Zu-
sätzliche Tätigkeiten entsprechen dabei Tätigkeiten, die neben der Erstellung eines
Arbeitsergebnisses durchzuführen sind. Die Prozessabdeckung wurde von [
Fil05
] über-
nommen. Die zugehörigen Werte sind in Tabelle 3.2 zu finden.
Schlüsselfrage: Welche begleitenden Tätigkeiten werden beschrieben?
Tätigkeit Beschreibung
Produktentwicklung
Die eigentliche Entwicklung des Arbeitsergebnisses ist im
Vorgehensmodell enthalten. Es wird eine Strukturierung
der Produktionsschrittfolge und der Produktionsergebnisse
beschrieben, sowie Mittel und Methoden genannt, die zur
Produktion eingesetzt werden.
Projektmanagement
Das Projektmanagement unterstützt das Planen, Initiieren
und Kontrollieren von Projekten. Typische Aufgabenfelder
sind Budget-, Termin- und Ressourcenplanung.
Qualitätssicherung
Die Qualitätssicherung beschreibt Qualitätsanforderungen
und Testfälle. Sie unterstützt die Produkte bzw. den Prozess
bei der Einhaltung von Standards und Qualitätsanforderun-
gen.
Benchmarking
Die erreichten Ergebnisse sind anhand allgemeiner Ziel-
größen und ihrem Erfüllungsgrad beurteilbar. Das Modell
unterstützt eine solche Beurteilung.
Wissensmanagement
Erkenntnisse aus durchgeführten Projekten werden zur
Wissensgewinnung und -erhaltung gespeichert. Dadurch
können gewonnene Erfahrungen in neue Projekte einflie-
ßen.
Tabelle 3.2: Ausprägungen der Prozessabdeckung nach [Fil05]
GA3 – Abstraktionsstufe
Der Begriff Vorgehensmodell wird für die verschiedensten, unterschiedlich konkreten
Modelle angewendet. Vorgehensmodelle spiegeln in diesem Zusammenhang Methoden
22
3.2 Vergleichsaspekte
wider [
Fil05
]. Diese Methoden können in unterschiedlichen Abstraktionsstufen auftreten.
Deshalb ist ein Blick über den Tellerrand notwendig, um die verschiedenen Vorgehens-
modell zu untersuchen. Der Begriff des Vorgehensmodell wird für die Untersuchung der
Abstraktionsstufe weiter gefasst, um die verschiedenen Vorgehensmodelle in eine ent-
sprechende Kategorie einzuordnen. Die Abstraktionsstufe von [
Fil05
] wurde angepasst,
indem der Modelltyp
Metamodell
nicht übernommen wurde, da dieser kein konkretes
Modell darstellt, das für die Unterstützung von wissensintensiven Prozessen geeignet
ist. Die verschiedenen Werte der Abstraktionsstufe sind in Tabelle 3.3 aufgelistet.
Schlüsselfrage: In welcher Form ist das Vorgehensmodell definiert?
Modelltyp Beschreibung
Methodensammlung
Eine Methodensammlung besteht aus einer Sammlung
zueinander passender Methoden. Die Sammlung kann ein
vollständiger Methodenvorrat oder einzelne Methoden sein.
Rahmenwerk
Ein Rahmenwerk umfasst teilweise Definitionen des Vor-
gehens, unterstützt durch vorgegebene Bestandteile. Das
Rahmenwerk stellt einen Ordnungsrahmen her, der in den
unterschiedlichsten Formen unterstützt werden kann.
Vorgehensmodell
Das Modell entspricht der Definition 2.5 eines Vorgehens-
modells. Die Unterstützung für die Entwicklung ist umfas-
send definiert und kann bei bestimmten Modellen an die
projektspezifischen Gegebenheiten angepasst werden.
Tabelle 3.3: Ausprägungen der Abstraktionsstufe nach [Fil05]
GA4 – Detaillierungsgrad
Der Detaillierungsgrad dient dazu Modelle mit der Abstraktionsstufe
Vorgehensmodell
gemäß Definition 2.5 zu untersuchen. Hierbei wird die Granularität der Vorgehensmodelle
analysiert. Der Formalisierungsgrad wurde von [
Chr92
] übernommen und wird in dieser
Arbeit als Detaillierungsgrad bezeichnet. Die zugehörigen Werte sind in Tabelle 3.4
aufgelistet.
Schlüsselfrage: Welchen Detaillierungsgrad besitzt das Vorgehensmodell?
23
3 Methodik
Detaillierungsgrad Beschreibung
Universell
Das Vorgehensmodell beschreibt eine prinzipielle Ablauf-
struktur und gibt allgemeine Richtlinien vor.
Weltlich
Das Vorgehensmodell und die Abfolge der Aktivitäten sind
ausreichend stark detailliert beschrieben. Außerdem wer-
den Voraussetzungen für die Durchführung von Aktivitäten
vorgegeben. Dadurch sind die beschriebenen Aktivitäten
direkt ausführbar.
Atomar Das Vorgehensmodell beschreibt die Prozessschritte sehr
detailliert und legt genaue Bedingungen für deren Abfolge
fest.
Tabelle 3.4: Ausprägungen des Detaillierungsgrads nach [Chr92]
GA5 – Branchenfokus
Der Branchenfokus drückt aus, ob ein Vorgehensmodell für bestimmte Branchen speziell
entwickelt wurde oder ob es allgemein über alle Bereiche einsetzbar ist. Der Branchen-
fokus wurde von [
Fil05
] übernommen und die zugehörigen Werte sind in Tabelle 3.5
aufgelistet.
Schlüsselfrage:
Wurde das Vorgehensmodell für eine bestimmte Branche entwickelt?
Branchenfokus Beschreibung
Speziell
Das Vorgehensmodell wurde für eine spezielle Branche
entwickelt und ist dementsprechend angepasst.
Allgemein
Das Vorgehensmodell wurde für keine spezielle Branche
entwickelt und kann allgemein zum Einsatz kommen.
Tabelle 3.5: Ausprägungen des Branchenfokus nach [Fil05]
GA6 – Vorgehensweise
Unter dem Gesichtspunkt der Vorgehensweise wird untersucht, welche Vorgehensart das
Vorgehensmodell vorgibt. Dabei kann das Vorgehensmodell über die eingebetteten/dar-
gestellten Phasen verschiedene Vorgehensweisen unterstützen. Die Vorgehensweise
24
3.2 Vergleichsaspekte
wurde von [
Fil05
] übernommen. Dabei wurden nur die drei wichtigsten Vorgehensweisen,
die bei der Analyse bestehender Vorgehensmodelle und Methoden identifiziert wurden,
übernommen (siehe Tabelle 3.6).
Schlüsselfrage: Welche Vorgehensweise unterstützt das Vorgehensmodell?
Vorgehensweise Beschreibung
Evolutionär
Durch das zu erarbeitende Arbeitsziel werden neue Anfor-
derungen deutlich. Dadurch wird ein neuer Arbeitszyklus
gestartet, der auf dem existierenden Arbeitsergebnis auf-
setzt. Dabei unterscheidet sich diese Vorgehensweise von
der inkrementellen Vorgehensweise dadurch, dass bei der
evolutionären Vorgehensweise der Arbeitsprozess immer
ganz durchlaufen wird, d.h. das (Teil-)Ergebnis wird fertig-
gestellt und ausgehend davon wird ein neues Arbeitsprojekt
mit neuen Anforderungen gestartet.
Inkrementell
Das Arbeitsergebnis wird stückweise erarbeitet. Dabei ent-
stehen zuerst Teilergebnisse, die durch mehreren Wieder-
holungen stückweise verfeinert werden bis das Arbeitser-
gebnis vorliegt. Das Arbeitsergebnis wird dabei in einem
Arbeitsprojekt fertiggestellt
Sequentiell
Der Arbeitsprozess basiert auf dem klassischen Wasser-
fallmodell. Dabei wird das Arbeitsergebnis in einem Durch-
lauf des Arbeitsprozesses ohne Wiederholungen fertigge-
stellt.
Tabelle 3.6: Ausprägungen der Vorgehensweisen nach [Fil05]
GA7 – Prozesssteuerung
Vorgehensmodelle kontrollieren die Abfolge der Phasen auf unterschiedliche Weise. Die
Prozesssteuerung wurde von [
Fil05
] übernommen. Dabei wurde der Wert
vertragsori-
entiert
in
situationsorientiert
umbenannt, da die Prozesssteuerung situationsbedingt
erfolgt. Unter dem Aspekt der Prozesssteuerung werden die drei verschiedenen Kontroll-
mechanismen (siehe Tabelle 3.7) betrachtet.
Schlüsselfrage: Wie wird die Abfolge der Phasen des Vorgehensmodells gesteuert?
25
3 Methodik
Prozesssteuerung Beschreibung
Aktivitätsorientiert
Die Abfolge der Phasen im Vorgehensmodell wird durch
die Fertigstellung von Aktivitäten gesteuert. Wird eine ent-
sprechende Aktivität fertiggestellt, so kann in die nächste
Phase übergegangen werden. Dabei ist die Abfolge der
fertigzustellenden Aktivitäten festgelegt.
Ergebnisorientiert
Bei ergebnisorientierten Vorgehensmodellen werden Ent-
scheidungen bezüglich der Prozesssteuerung anhand der
erzeugten Ergebnisse getroffen. Der Entwicklungsprozess
wird „als Transformation und Evolution von Ergebnissen“
betrachtet.
Situationsorientiert Bei situationsorientierten Vorgehensmodellen werden Ent-
scheidungen bezüglich der Prozesssteuerung durch situati-
onsbedingte Entscheidungsmuster getroffen. Weiterführen-
de Tätigkeiten werden durch definierte Vor- und Nachbe-
dingungen ausgewählt.
Tabelle 3.7: Ausprägungen der Prozesssteuerung nach [Fil05]
GA8 – Prozessergebnis
Vorgehensmodelle dienen der Unterstützung von verschiedensten Prozessen mit ent-
sprechend verschiedenen Prozessergebnissen. Unter dem Aspekt des Prozessergeb-
nisses wird untersucht, welche Ergebnisse der vom Vorgehensmodell beschriebene
Prozess produziert. Die verschiedenen Ergebnisse sind in Tabelle 3.8 aufgelistet.
Schlüsselfrage:
Was ist das Ergebnis des vom Vorgehensmodell beschriebenen Pro-
zesses?
Prozessergebnis Beschreibung
Produkt
Das Vorgehensmodell beschreibt einen Prozess, der ein
Produkt/System zum Ergebnis hat.
Dienstleistung Das Ergebnis des Prozesses ist eine Dienstleistung.
Wissen Der Prozess produziert Wissen.
Tabelle 3.8: Ausprägungen der Prozessergebnisse
26
3.2 Vergleichsaspekte
GA9 – Modellarchitektur
Unter dem Aspekt der Modellarchitektur wird untersucht, wie eine Teilmenge der ver-
schiedenen Phasen eines Vorgehensmodells zeitlich angeordnet sind. Dieser Aspekt
ist an die Prozessarchitektur von [
NS99
] angelehnt. Die beiden möglichen Werte der
Modellarchitektur sind in Tabelle 3.9 enthalten.
Schlüsselfrage: Wie sind die Phasen im Vorgehensmodell angeordnet?
Modellarchitektur Beschreibung
Parallel
Die Phasen des Vorgehensmodells können parallel an-
geordnet werden. Somit ist eine zeitgleiche Ausführung
mehrerer Phasen möglich.
Sukzessiv
Die Phasen des Vorgehensmodells sind zeitlich hinterein-
ander angeordnet. Somit ist keine Parallelisierung möglich.
Tabelle 3.9: Ausprägungen der Modellarchitektur nach [NS99]
GA10 – Spezialisierbarkeit
Unter dem Aspekt der Spezialisierbarkeit wird untersucht, inwiefern sich ein Vorge-
hensmodell auf andere Domänen anpassen lässt. Die Adaption wurde von [
NS99
]
übernommen und wird in dieser Arbeit als Spezialisierbarkeit bezeichnet. Die Werte sind
in Tabelle 3.10 aufgelistet.
Schlüsselfrage:
Ist das Vorgehensmodell für die Nutzung in einer Domäne spezialisier-
bar?
27
3 Methodik
Spezialisierbarkeit Beschreibung
Domänenspezifisch
Das Vorgehensmodell ist speziell an eine Domäne ange-
passt und lässt sich nicht auf eine andere Domäne übertra-
gen, da es zu spezifisch ist.
Domänenneutral
Das Vorgehensmodell lässt sich ohne große Probleme an
eine andere Domäne anpassen, da es keine domänenspe-
zifischen Informationen enthält.
Tabelle 3.10: Ausprägungen der Spezialisierbarkeit nach [NS99]
GA11 – Modellkomplexität
Unter dem Aspekt der Modellkomplexität wird untersucht, wie komplex ein Vorgehens-
modell aufgebaut ist. Die Komplexität wird dabei an der Anzahl vorhandener Rollen,
beschriebener Aktivitäten und der Komplexität des Ablaufs gemessen. Komplexe Vor-
gehensmodelle besitzen eine Vielzahl an verschiedenen Rollen, viele durchzuführende
Aktivitäten und einen komplexen Ablauf. Dadurch benötigen Wissensarbeiter bei komple-
xen Vorgehensmodellen eine hohe Einarbeitungszeit, um alle Aspekte des Vorgehens-
modells zu verstehen und einsetzen zu können. Die drei Komplexitätsklassen sind in
Tabelle 3.11 enthalten.
Schlüsselfrage: Wie komplex ist das Vorgehensmodell?
Modellkomplexität Beschreibung
Niedrig
Das Modell ist einfach gehalten und es ist kein bzw. kaum
zusätzlicher Aufwand nötig, damit das Vorgehensmodell
eingesetzt werden kann.
Mittel
Der Einsatz des Vorgehensmodells erfordert zusätzlichen
Aufwand, damit die Beteiligten das Modell produktiv einset-
zen können und es verstehen.
Hoch
Es ist eine intensive Einarbeitungsphase für das Vorge-
hensmodell nötig, da es sonst nicht produktiv eingesetzt
werden kann.
Tabelle 3.11: Ausprägungen der Modellkomplexität
28
3.2 Vergleichsaspekte
3.2.2 Aspekte wissensintensiver Prozesse
Dadurch dass Vorgehensmodelle wissensintensive Prozesse unterstützen können, wei-
sen Vorgehensmodelle bestimmte Eigenschaften auf. Mithilfe der KIAs werden die wis-
sensintensiven Eigenschaften der Vorgehensmodelle untersucht. Dabei wurden einige
Aspekte aus [MKR13] und [Ger99] übernommen und durch eigene Aspekte erweitert.
KIA1 – Zuständigkeiten
In wissensintensiven Prozessen gibt es meist verschiedene Rollen für Wissensarbeiter.
Unter dem Aspekt der Zuständigkeiten wird untersucht, inwiefern das Vorgehensmodell
ein Rollenkonzept unterstützt und beschreibt. Die zugehörigen Werte sind in Tabelle 3.12
aufgelistet.
Schlüsselfrage: Beschreibt das Vorgehensmodell verschiedene Rollen?
Zuständigkeiten Beschreibung
Rollen vorgegeben
Das Vorgehensmodell unterstützt und beschreibt ein Rol-
lenkonzept und Zuständigkeiten für Wissensarbeiter.
Rollen festlegbar
Das Vorgehensmodell gibt keine Rollen vor, allerdings las-
sen sich Rollen festlegen.
keine Rollen Es werden keine Rollen unterstützt oder beschrieben.
Tabelle 3.12: Ausprägungen der Zuständigkeiten
KIA2 – Wissenstätigkeit
Wissen ist die wichtigste Ressource in wissensintensiven Prozessen. Diese Ressource
wird auf unterschiedlichste Art und Weise eingesetzt [
MR14
]. Unter dem Aspekt der
Wissenstätigkeit wird untersucht, welche Wissenstätigkeit das Vorgehensmodell zur
Problemlösung vorgibt. Dabei werden drei Wissenstätigkeiten unterschieden (siehe
Tabelle 3.13).
Schlüsselfrage: Wie wird das Wissen im Vorgehensmodell eingesetzt?
29
3 Methodik
Wissenstätigkeit Beschreibung
Wissensanwendung
Problemlösung durch aktives Anwenden der Fähigkeiten,
Erfahrung und Fachkenntnis der Wissensarbeiter.
Wissenserzeugung
Forschen und Erzeugen von neuem Wissen um ein unbe-
kanntes Problem zu lösen.
Wissenssuche
Suchen und Finden von existierendem Wissen um ein Pro-
blem zu lösen.
Tabelle 3.13: Ausprägungen der Wissenstätigkeiten
KIA3 – Prozessdauer
Wissensintensive Prozesse unterscheiden sich deutlich in der Prozessdauer. Mit dem
Aspekt Prozessdauer wird angestrebt, wissensintensive Prozesse in drei Kategorien
zu unterteilen. Allerdings hängt diese Klassifizierung immer von den involvierten Wis-
sensarbeitern ab. So ist anzunehmen, dass die Fertigstellung eines Prozesses bei
einem unerfahrenen Wissensarbeiter deutlich mehr Zeit beansprucht, als bei einem
erfahrenen Wissensarbeiter, der schon ähnliche Probleme gelöst hat. Zur Bewertung
der Prozessdauer wurden die Werte in Tabelle 3.14 aufgelistet.
Schlüsselfrage:
Wie lange benötigt der im Vorgehensmodell beschriebene wissensin-
tensive Prozess bis er fertiggestellt wird?
Prozessdauer Beschreibung
Kurz
Der wissensintensive Prozess hat eine sehr kurze Prozess-
dauer von unter drei Tagen.
Mittel
Die Prozessdauer des wissensintensiven Prozesses liegt
zwischen drei und 14 Tagen.
Lang Die Prozessdauer beträgt mehr als 14 Tage.
Tabelle 3.14: Ausprägungen der Prozessdauer
30
3.2 Vergleichsaspekte
KIA4 – Sichtenmodell
Zusätzlich zu einem eventuell vorhandenem Rollenmodell sollten Vorgehensmodelle
auch eine Unterstützung für Sichten unterstützen. Dabei stellen verschiedene Sichten
einen Teil des Vorgehensmodells dar, der für eine bestimmte Rolle vorgesehen ist.
So sollen Wissensarbeiter unterstützt werden, indem sie nur die für sie relevanten
Informationen des Vorgehensmodells sehen [
Ger99
]. Dadurch ergibt sich der Vorteil,
dass das Vorgehensmodell vereinfacht wird und dass die Wissensarbeiter mit den
für sie relevanten Informationen effektiver arbeiten können. Unter dem Aspekt des
Sichtenmodells wird untersucht, ob das Vorgehensmodell verschiedene Sichten für
verschiedene Rollen unterstützt. Dieser Aspekt wurde von [
Ger99
] übernommen. Die
zugehörigen Werte finden sich in Tabelle 3.15.
Schlüsselfrage:
Bietet das Vorgehensmodell verschiedene Sichten (z.B. basierend auf
Rollen) an?
Sichtenmodell Beschreibung
Ja
Das Vorgehensmodell unterstützt verschiedene Sichten für
verschiedene Rollen.
Nein
Es werden keine Sichten vom Vorgehensmodell unterstützt.
Tabelle 3.15: Ausprägungen des Sichtenmodells nach [Ger99]
KIA5 – Lebenszyklus Abdeckung
Um wissensintensive Prozesse zu unterstützen, sollten die vier Lebensyzklus-Phasen
eines wissenintensiven Prozesses nach [
MKR13
] (siehe Kapitel 2.4 und Abbildung 2.3)
vom Vorgehensmodell unterstützt werden. Unter dem Aspekt der Lebenszyklus Abde-
ckung wird untersucht, welche der vier Lebenszyklus-Phasen (siehe Tabelle 3.16) von
wissensintensiven Prozessen vom Vorgehensmodell abgedeckt werden.
Schlüsselfrage:
Werden die Lebenszyklus-Phasen eines wissensintensiven Prozesses
im Vorgehensmodell unterstützt?
31
3 Methodik
Lebenszyklus-Phase Beschreibung
Orientierung
Informationen über den wissensintensiven Prozess werden
gesammelt. Ziel der Phase ist eine Prozessbeschreibung.
Vorlagen-Entwurf
Eine Zusammenarbeits-Vorlage (
Collaboration Template
(CT)) wird für den wissensintensiven Prozess erstellt. Ein
CT enhält die wichtigsten Informationen, die ein Wissensar-
beiter in der Ausfühung des wissensintensiven Prozesses
benötigt.
Gemeinsame
Bearbeitungsphase
In der Bearbeitungsphase wird ein CT zu einer oder meh-
reren Zusammenarbeits-Instanzen (
Collaboration Instance
(CI)). Die CIs unterstützt dann den Wissensarbeiter wäh-
rend der Bearbeitungsphase. Fertiggestellte CIs können
von Wissensarbeitern eingesehen werden, um wichtige
Informationen zu erhalten.
Auswertung der
Datensätze
Fertiggestellte CIs werden zu Zusammenarbeits-
Datensätzen (
Collaboration Records
(CR)) archiviert,
die von Wissensarbeitern jederzeit eingesehen werden
können. Außerdem werden die fertiggestellten CIs ana-
lysiert und evtl. Veränderungen an existierenden CTs
vorgenommen.
Tabelle 3.16: Ausprägungen der Lebenszyklus Abdeckung nach [MKR13]
KIA6 – Kommunikationsformen
Kommunikation spielt in wissensintensiven Prozessen eine sehr wichtige Rolle, da Wis-
sensarbeiter sich so über die Aufgaben austauschen können. Dadurch verbessert sich ihr
Verständnis der Aufgabenstellung, was schließlich ihre Arbeitseffektivität und -effizienz
erhöht [
MR14
]. Daher wird unter dem Aspekt der Kommunikationsformen untersucht, ob
das Vorgehensmodell auf die Kommunikation eingeht und ob Kommunikationsvorgaben
festgelegt sind. Die entsprechenden Werte sind in Tabelle 3.17 aufgelistet.
Schlüsselfrage:
Gibt das Vorgehensmodell Richtlinien zur Kommunikation der Wissens-
arbeiter vor?
32
3.2 Vergleichsaspekte
Kommunikationsform Beschreibung
tägliches Meeting
Das Vorgehensmodell gibt ein tägliches Meeting der Wis-
sensarbeiter vor.
wöchentliches Meeting
Ein wöchentliches Meeting wird vom Vorgehensmodell vor-
geschrieben.
andere Vorgaben
Das Vorgehensmodell gibt eine andere Kommunikations-
form vor, die sich nicht zeitlich einordnen lässt.
keine Vorgaben Es wird keine Kommunikationsform vorgegeben.
Tabelle 3.17: Ausprägungen der Kommunikationsformen
KIA7 – Zielspezifikation
Aufgrund der hohen Komplexität von wissensintensiven Prozessen wird das Gesamtziel
meist in mehrere kleine Ziele (z.B. Meilensteine) unterteilt. Unter dem Aspekt der
Zielspezifikation wird untersucht, ob das Vorgehensmodell Ziele und/oder Meilensteine
festlegt und ob sich eigene Ziele festlegen lassen. Die zugehörigen Werte finden sich in
Tabelle 3.18.
Schlüsselfrage:
Gibt das Vorgehensmodell Zielvorgaben vor und lassen sich eigene
Zielvorgaben festlegen?
Zielspezifikation Beschreibung
Gesamtziel Das Vorgehensmodell gibt das Gesamtziel vor.
Meilensteine Das Vorgehensmodell legt Meilensteine fest.
eigene Ziele Es lassen sich eigene Ziele/Meilensteine festlegen.
keine Zielvorgaben
Das Vorgehensmodell gibt keine Zielvorgaben und es kön-
nen keine eigenen Ziele festgelegt werden.
Tabelle 3.18: Ausprägungen der Zielspezifikation
33
3 Methodik
KIA8 – Qualitätssicherungsmaßnahmen
Zur Qualitätssicherung von wissensintensiven Prozessen gibt es verschiedene
Ansätze
.
Unter diesem Aspekt wird das Vorgehensmodell dahingehend untersucht, welche Quali-
tätssicherungsmaßnahmen vorgegeben werden. Durch Qualitätssicherungsmaßnahmen
wird angestrebt, die Prozessergebnisse, sowie den Prozess an sich zu verbessern,
damit die Wissensarbeiter produktiver arbeiten können. Die verschiedenen Qualitätssi-
cherungsmaßnahmen sind in Tabelle 3.19 aufgelistet.
Schlüsselfrage:
Welche Qualitätssicherungsmaßnahmen gibt das Vorgehensmodell
vor?
QS-Maßnahme Beschreibung
Tests
Das Vorgehensmodell sieht Tests des Prozessergebnisses
vor.
Prozessanalyse
Der Prozess an sich wird analysiert. Dadurch wird versucht
den Prozess zu verbessern.
Ergebnisauswertung
Das Ergebnis des Prozesses wird evaluiert und dadurch
Rückschlüsse auf die Prozessqualität gezogen.
Tabelle 3.19: Ausprägungen der Qualitätssicherungsmaßnahmen
KIA9 – Wissensdokumentation
Wissensintensive Prozesse produzieren typischerweise Wissen als Teilergebnis des
Prozesses [
MKR13
]. Allerdings ist die Menge an produziertem explizitem Wissen von
Prozess zu Prozess unterschiedlich. Unter dem Aspekt der Wissensdokumentation
wird untersucht, wie viel explizites Wissen in Form von Artefakten (z.B. Dokumente)
produziert wird. Zur Bewertung wird die Anzahl der anzulegenden Dokumente betrachtet.
Die entsprechenden Werte finden sich in Tabelle 3.20.
Schlüsselfrage:
Wie viel explizites Wissen muss ausgehend vom Vorgehensmodell
dokumentiert werden?
34
3.2 Vergleichsaspekte
Wissensdokumentation Beschreibung
Niedrig
Es wird kein oder kaum explizites Wissen in Form von
Dokumenten dokumentiert.
Mittel
Es gibt eine vom Modell vorgegebene überschaubare
Menge von anzulegenden Dokumenten, um das gewon-
nene explizite Wissen zu dokumentieren.
Hoch Es wird sehr viel explizites Wissen dokumentiert.
Tabelle 3.20: Ausprägungen der Wissensdokumentation
KIA10 – Problemkomplexität
Um das Ziel eines wissensintensiven Prozesses zu erreichen, müssen unterschiedlich
komplexe Probleme gelöst werden. Obwohl alle wissensintensiven Prozesse komplexe
Probleme lösen müssen, gibt es ein breites Spektrum zwischen komplexen und wahnsin-
nig komplexen Problemen [
WK08
]. Die drei Komplexitätsklassen in Tabelle 3.21 beziehen
sich dabei auf die Komplexitätsklasse, für die wissensintensiven Prozesse eingesetzt
werden. Die Komplexitätsklasse wird in drei Unterklassen eingeteilt: niedrige, mittlere
und hohe Komplexität (siehe Abbildung 3.2). Dadurch wird angestrebt die wissensinten-
siven Prozesse in drei Klassen zu unterteilen. Unter dem Aspekt der Problemkomplexität
wird untersucht, für welche Problemkomplexitätsklassen die Vorgehensmodelle geeignet
sind.
Schlüsselfrage:
Für welche Komplexitätsklassen ist das Vorgehensmodell einsetzbar?
Klasse der Probleme für
die wissensintensive
Prozesse eingesetzt
werden
„Einfache“ Probleme
niedrige Komplexität
„Mittelschwere“
Probleme
mittlere Komplexität
„Schwere“ Probleme
hohe Komplexität
Abbildung 3.2:
Veranschaulichung der Komplexitätsklassen wissensintensiver Prozesse
35
3 Methodik
Problemkomplexität Beschreibung
Niedrig
Wissensintensive Prozesse mit einer niedrigen Komplexi-
tät behandeln häufig auftretende und weniger komplexe
Probleme.
Mittel
Die behandelten Probleme sind komplexer und treten nur
noch ab und zu auf.
Hoch
Wissensintensive Prozesse mit einer hohen Komplexität
bearbeiten neuartige hochkomplexe Probleme.
Tabelle 3.21: Ausprägungen der Problemkomplexität
3.3 Darstellung der Ergebnisse
Die Darstellung der Ergebnisse lässt sich auf verschiedene Arten realisieren. Die ein-
fachste Methode wäre eine tabellarische Darstellung. Da dies aufgrund der recht großen
Anzahl an Vergleichspunkten äußerst unübersichtlich wäre, wird in dieser Arbeit davon
abgesehen. Die verwendete Darstellung ist angelehnt an die Ergebnisdarstellung von
[
Fil05
]. Die Vergleichsaspekte werden dabei in zwei Grafiken dargestellt. Eine Grafik
für die allgemeinen Eigenschaften eines Vorgehensmodells (siehe Abbildung 3.4) und
eine Grafik für die wissensintensiven Eigenschaften eines Vorgehensmodells (siehe
Abbildung 3.5).
Inwiefern die Eigenschaften der Vorgehensmodelle erfüllt sind, wird anhand verschieden-
farbiger Markierungen dargestellt (siehe Abbildung 3.3). Dabei wird das Ampelprinzip
verwendet. Eine rote gestrichelte Markierung bedeutet, dass die Eigenschaft nicht erfüllt
ist. Bei gelber Markierung lässt sich keine eindeutige Aussage über die Eigenschaft
machen und bei grüner Markierung ist die Eigenschaft erfüllt.
Eigenschaft erfüllt
Eigenschaft teilweise erfüllt
Eigenschaft nicht erfüllt
Abbildung 3.3: Markierung der Ergebnisse
36
3.3 Darstellung der Ergebnisse
Die textuelle Darstellung der Ergebnisse erfolgt auf ähnliche Weise. Zu jedem Vergleichs-
aspekt werden die angenommenen Werte dargestellt. Ist ein Wert voll erfüllt, so wird
dieser fett markiert (
Beispiel
). Ist ein Wert nur teilweise erfüllt oder lässt sich keine
eindeutige Aussage treffen, so wird dieser kursiv markiert (
Beispiel
). Ist ein Wert nicht
erfüllt, so wird er nicht explizit aufgeführt.
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 3.4: Darstellung gefundener allgemeiner Aspekte
37
3 Methodik
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 3.5: Darstellung gefundener wissensintensive Aspekte
38
4
Vorgehensmodelle zur Unterstützung
wissensintensiver Prozesse
In diesem Kapitel werden die verschiedenen Vorgehensmodelle vorgestellt, die in dieser
Arbeit analysiert werden. Zu jedem Vorgehensmodell wird eingehend erläutert, warum
das Vorgehensmodell ausgewählt wurde. Außerdem werden die einzelnen Vorgehens-
modelle kurz beschrieben und auf deren Herkunft eingegangen.
4.1 V-Modell XT
Das V-Modell XT (Version 1.4) wird in dieser Arbeit untersucht, da es ein weit verbreitetes
Vorgehensmodell der Softwareentwicklung ist [BR05].
39
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
1992 wurde die erste Version des V-Modells von der Bundeswehr veröffentlicht [
BMI
].
Das ursprüngliche V-Modell wurde im Laufe der Zeit aufgrund von neuen Ansätzen in
der Softwareentwicklung (z.B. Objektorientierung) angepasst. So entstand das V-Modell
97 im Jahr 1997 [
BMI
]. Dieses wurde im Februar 2005 durch das V-Modell XT in der
Version 1.0 abgelöst. Das XT steht dabei für „eXtreme Tailoring“ was bedeutet, dass das
V-Modell XT flexibel an verschiedene Projekte anpassbar ist. Seit Mai 2012 liegt das
V-Modell XT in Version 1.4 vor, das die Grundlage für die folgende Betrachtung darstellt
[BMI].
Das V-Modell XT besteht aus sogenannten Vorgehensbausteinen, die ähnliche Tätig-
keiten zusammenfassen. Insgesamt sind 22 solche Vorgehensbausteine vorhanden.
Je nach Projekttyp gibt es vorgeschriebene Vorgehensbausteine, die enthalten sein
müssen (siehe Abbildung 4.1). Vorgehensbausteine, die in jedem Projekt Verwendung
finden, werden als der V-Modell-Kern bezeichnet. Dies sind die Bausteine
Projektmana-
gement
,
Qualitätssicherung
,
Konfigurationsmanagement
und
Problem- & Änderungs-
management
. Weitere Vorgehensbausteine sind z.B. die
Systemerstellung
, die
Anforde-
rungsfestlegung
oder der
Vertragsabschluss
. Die verschiedenen Projekttypen, die vom
V-Modell XT unterstützt werden, sind
Systementwicklungsprojekt (AG/AN)
,
Systement-
wicklungsprojekt (AG)
und
Systementwicklungsprojekt (AN)
(siehe Abbildung 4.1). AG
steht hierbei für Auftraggeber und AN für Auftragnehmer.
Es werden also Projekte unterstützt, in denen Arbeitnehmer und Arbeitgeber direkt in
einem Projekt zusammenarbeiten, sowie Projekte für je eine der beiden Parteien. Ein
wichtiger Aspekt des V-Modell XT ist das sogenannte
Tailoring1
. Mit Tailoring wird die
Anpassung des allgemeinen Vorgehensmodells an projektspezifische Gegebenheiten
bezeichnet. Das V-Modell XT stellt für das Tailoring standardmäßig eine Softwarelösung
in Form des V-Modell XT Projektassistenten bereit [
BMI
]. Damit kann der Projektma-
nager den Projekttyp und eine Projekttypvariante (z.B. Entwicklung, oder Wartung &
Pflege) auswählen. So werden ihm bereits die erforderlichen Vorgehensbausteine vorge-
geben. Anschließend können, falls gewünscht, noch zusätzliche Vorgehensbausteine
hinzugewählt werden. Anschließend wird ein initialer Projektplan erstellt. Natürlich kann
das Tailoring auch ohne den Projektassistenten durchgeführt werden. Das V-Modell XT
1dt. Zuschnitt
40
4.2 Kanban
definiert über 100 verschiedene Dokumente, die auch als
Produkte
bezeichnet werden.
Mithilfe der Produkte wird die Planung und Entwicklung des angestrebten Ergebnisses
dokumentiert und unterstützt. Wichtige Produkte sind z.B. die
Anforderungen
(Lasten-
heft) und die
Gesamtsystemspezifikation
(Pflichtenheft). Der Projektverlauf wird anhand
von sogenannten
Entscheidungspunkten
gesteuert. Entscheidungspunkte entsprechen
Meilensteinen, an denen über die Projektfortführung entschieden wird.
Weitergehende Informationen über das V-Modell XT lassen sich in der offiziellen Doku-
mentation ([BMI]) nachlesen.
Abbildung 4.1:
Vorgehensbausteine eines V-Modells XT für das Systementwicklungspro-
jekt (AG) nach [BMI]
4.2 Kanban
Kanban ist ein typischer Vertreter der agilen, evolutionären Softwareentwicklung [
Kom14
].
Das Prinzip von Kanban in der IT wurde 2007 von David Anderson erstmals der Öffent-
lichkeit vorgestellt. Kanban bedeutet im japanischen
Signalkarte
und stellt eine Technik
aus dem Toyota-Produktionssystem dar [BW15].
Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess schlanker
und flexibler zu machen. Klassische Vorgehensmodelle, wie das V-Modell, gelten oft
als sehr dokumentenlastig organisiert [
VMS
]. Die agile Softwareentwicklung stellt eine
41
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
Gegenbewegung zu diesen klassischen Vorgehensmodellen dar. Kanban wird in dieser
Arbeit untersucht, da es eine der meistverbreiteten agilen Methoden darstellt [Kom14].
Kernstück von Kanban ist die Visualisierung des Prozesses mithilfe des sogenanten
Kanban-Boards. Dies kann z.B. ein einfaches
Whiteboard
mit Haftnotizen oder Karteikar-
ten sein. Jede Karte steht dabei für eine Aufgabe. Das Whiteboard wird in verschiedene
Phasen eingeteilt, allerdings sind diese frei wählbar [
Epp11
]. Abbildung 4.2 stellt ein
beispielhaftes Kanban-Board dar. Die Phasen Umsetzung und Testen sind dabei noch
einmal in zwei Spalten unterteilt: aktuell und erledigt. Karten in der aktuell-Spalte wer-
den gerade bearbeitet, Karten in der erledigt-Spalte können in die nächste Phase
übernommen werden. Kanban hat das Ziel einen kontinuierlichen Arbeitsfluss (
Flow
)
sicherzustellen. Deswegen gibt es für jede Phase einen begrenzten
Work in Progress
(WIP)
, also eine begrenzte Menge an parallelen Aufgaben. Dadurch sollen Aufgaben
schneller und ohne lange Wartezeiten erledigt werden. Wird der Flow behindert, so lässt
sich dies aufgrund der Visualisierung meist schnell beheben.
Abbildung 4.2: Kanban-Board nach [ita]
42
4.3 Scrum
Der Ablauf von Kanban beginnt mit der Sammlung der priorisierten Anforderungen im
Backlog2
. Je nach Priorisierung gelangen die Aufgaben nach und nach in Bearbeitung.
Aufgaben werden nach dem Pull-Prinzip verteilt. Jeder Mitarbeiter nimmt sich eine
Aufgabe, die er bearbeiten möchte. Karten in den erledigt-Spalten können beim
Daily
Standup, einem täglichen Treffen der Teammitglieder, nach gemeinsamer Abstimmung
in die nächste Phase verschoben werden, solange das WIP Limit nicht verletzt wird.
Ein wichtiger Bestandteil von Kanban ist
Benchmarking3
. Beim Benchmarking werden
verschiedene Metriken wie z.B. die Durchlaufzeit oder die durchschnittliche Fertigstel-
lungsrate erfasst, um stets Aussagen über die vorraussichtliche Fertigstellung des
Projekts zu ermöglichen.
[
BW15
] enthält weiterführende Informationen über Kanban und den praktischen Einsatz
für das Projektmanagement. [
ita
] liefert einen kurzen Überblick über die wichtigsten
Ansatzpunkte von Kanban.
4.3 Scrum
Scrum ist ein weiterer Vertreter der agilen Softwareentwicklung [
Sei
]. Allerdings unter-
scheidet sich Scrum von Kanban, z.B. in Bezug auf die verwendete Vorgehensweise.
Während Kanban eine evolutionäre Vorgehensweise verfolgt, gibt Scrum eine inkre-
mentelle Vorgehensweise vor [
SS13a
]. Scrum wird in dieser Arbeit untersucht, um zwei
Vertreter der agilen Softwareentwicklung miteinander zu vergleichen.
Scrum ist ein Rahmenwerk, welches drei zentrale Rollen für ein Projekt der Softwareent-
wicklung beschreibt. Der
Produkt Owner
erstellt fachliche Anforderungen und priorisiert
diese. Der
ScrumMaster
verwaltet den Prozess und beseitigt eventuell auftretende Hin-
dernisse, die die Produktivität einschränken. Die Mitglieder des
Entwicklungsteams
sind
für die Entwicklung des Produktes verantwortlich.
Der Scrum Prozess (siehe Abbildung 4.3) ist ein schlanker Prozess und ist dadurch
einfach zu verstehen. Die Anforderungen des Product Owners werden anfangs im
2eine priorisierte Anforderungsliste
3dt. Leistungsvergleich
43
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
Produkt-Backlog
platziert. Zu Beginn der Entwicklung wird ein
Sprint Planning
abgehal-
ten. In diesem Meeting wird die Arbeit für den kommenden Entwicklungszyklus, den
sogenannten
Sprint
, geplant. Dabei wird vom Team entschieden, welche Einträge aus
dem Produkt-Backlog in einem Sprint umsetzbar sind und wählt diese Einträge entspre-
chend aus. Die Ergebnisse des Sprint Plannings werden im Sprint-Backlog festgehalten.
Anschließend startet der Sprint mit einer typischen Dauer von 30 Tagen. Das Ziel ei-
nes Sprints ist ein Inkrement an Funktionalität für das Produkt und dieses sollte nach
jedem Sprint auslieferbar sein. Während des Sprints wird vom Team versucht, die aus-
gewählten Anforderungen umzusetzen. Ein tägliches
Daily Scrum
während dem Sprint
bietet den Teammitgliedern die Möglichkeit, sich über ihre Fortschritte und den aktuellen
Sprintfortschritt auszutauschen. Das Daily Scrum findet jeden Tag zur gleichen Uhrzeit
statt und dauert nicht länger als 15 Minuten. Änderungen, die das Sprint-Ziel gefährden
würden, können erst nach einem abgeschlossenen Sprint getroffen werden. Am Ende
eines Sprints findet ein
Sprint Review
statt. Das Team präsentiert das Produktinkrement
und eventuell wird das Produkt-Backlog angepasst. Außerdem findet nach dem Sprint
Review und vor dem nächsten Sprint Planning eine
Sprint Retrospektive
statt. In diesem
Meeting erstellen das Team und der ScrumMaster einen Verbesserungsplan für den
kommenden Sprint.
Abbildung 4.3: Scrum Prozess nach [Sei]
44
4.4 VDI Richtlinie 2221
[
Sch07
] enthält weiterführende Informationen über Scrum und die persönlichen Erfah-
rungen von Scrum-Begründer Ken Schwaber beim praktischen Einsatz von Scrum in
unterschiedlichen Unternehmen. Im offiziellen Scrum Guide [
SS13a
] wird Scrum im
Detail vorgestellt und ein Überblick über das Konzept vermittelt. [
Sei
] liefert einen kurzen
Überblick über die wichtigsten Ansatzpunkte von Scrum.
4.4 VDI Richtlinie 2221
Die VDI Richtlinie 2221 beschreibt die Methodik zum Entwickeln und Konstruieren tech-
nischer Systeme und Produkte und stellt einen Vertreter der Vorgehensmodelle aus dem
Ingenieurwesen dar [
VDI93
]. Die VDI Richtlinie 2221 wurde für diese Arbeit ausgewählt,
da diese ein Referenzmodell für den Entwicklungs- und Konstruktionsprozess darstellt
[Ber02].
Der Verein Deutscher Ingenieure (VDI) veröffentlichte im November 1986 die VDI Richtli-
ne 2221 - Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte.
Die VDI Richtlinie 2221 beschränkt sich auf den Entwicklungsprozess von Systemen
bzw. von Produkten. Dabei wird der Entwicklungsprozess in sieben Schritte unterteilt
(siehe Abbildung 4.4).
In der ersten Phase werden die Anforderungen präzisiert und die Aufgaben geplant.
Das Ergebnis dieser Phase ist eine vollständige Anforderungsliste. Sollten Änderungen
an den Anforderungen im Projektverlauf notwendig sein, so kann zurück zur ersten
Phase gesprungen werden. Die zweite und dritte Phase der Richtlinie widmen sich der
Festlegung einer Lösung. In der zweiten Phase werden die Gesamtfunktion, sowie die
zu erfüllenden Teilfunktionen identifiziert. Das Ergebnis dieser Phase ist eine Funktions-
struktur. In der dritten Phase werden für die ermittelten Funktionen Lösungsprinzipien
gesucht. Das Ergebnis ist die „prinzipielle Lösung“ eines Produktes. Diese erfüllt die
Funktionsanforderungen am wahrscheinlichsten und optimalsten. Der vierte Arbeits-
schritt befasst sich mit der Gliederung der Bauteile in realisierbare Module. Das Ergebnis
ist eine modulare Struktur. In der fünften Phase wird zuerst für die maßgebenden Module
ein Grobentwurf erarbeitet. Die sechste Phase ergänzt den Grobentwurf um die noch
45
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
nicht bearbeiteten Gruppen und Elemente. Das Ergebnis ist ein Gesamtentwurf, der die
wesentlichen geometrischen und stofflichen Merkmale eines Produktes enthält. Der sieb-
te Arbeitsschritt befasst sich mit der endgültigen Gestaltung. Hierfür werden endgültige
Zeichnungen der Bauelemente gefertigt. Das Ergebnis ist die Produktdokumentation, die
alle notwendigen Dokumente für die Herstellung und Nutzung des Produktes umfasst.
Abbildung 4.4: VDI Richtlinie 2221 nach [Ins]
46
4.5 AEP - Anforderungs-Engineering-Prozessmodell
Die VDI Richtlinie 2221 [
VDI93
] erläutert die Grundlagen der Richtlinie, stellt diese vor
und beschreibt mehrere Beispiele für den praktischen Einsatz. [
Ins
] vermittelt einen
Überblick über die verschiedenen Arbeitsschritte der Richtlinie.
4.5 AEP - Anforderungs-Engineering-Prozessmodell
Das Anforderungs-Engineering-Prozessmodell (AEP) beschreibt die Anforderungser-
stellung bei Bauprojekten. Das Vorgehensmodell wurde ausgewählt, da es eines der
wenigen Vorgehensmodelle ist, das sich mit dem Anforderungs-Engineering
4
im Bauwe-
sen befasst [Kro10] und einen weiteren Vertreter der Ingenieursmodelle darstellt.
Das AEP wurde 2010 von Gerhard Girmscheid veröffentlicht [
Gir10a
,
Gir10b
] und liegt
seitdem in der gleichen Version vor.
Das AEP ist ein Vorgehensmodell für das Anforderungs-Engineering im Bauingenieur-
wesen. Die Planung des Bauobjektes wird in unterschiedliche Projektphasen zerlegt.
In jeder Phase werden spezielle Ziele in Anforderungen umgesetzt. Zu Beginn je-
der Phase wird ein Zielvektor aufgestellt, in dem die Ziele der Phase gewichtet wer-
den. Anschließend werden die Anforderungen aus den Zielen entwickelt. Am Ende
jeder Phase wird mit Hilfe des Zielvektors der Zielerreichungsgrad untersucht. Der
Zielerreichungsgrad ist eine Metrik dafür, wie gut die Anforderungen die gesetzten
Ziele erfüllen. Ist der Zielerreichungsgrad hoch genug, so wird in die nächste Pha-
se übergegangen. Ist das Gegenteil der Fall, so wird der sogenannte kybernetische
Prozess (siehe Abbildung 4.5) erneut durchlaufen. Die Anforderungen werden in den
unterschiedlichen Phasen je nach Planungstiefe systematisch entwickelt. Dabei werden
folgende Anforderungsdimensionen bearbeitet: Investorenanforderungen,Nutzeranfor-
derungen
,
Standortanforderungen
,
Systemstandardanforderungen
,
Umfeldanforderun-
gen
,
Umwelt- & Sicherheitsanforderungen
,
Normen- & Gesetzesanforderungen
,
Bau-
grundanforderungen
,
Gestaltungsanforderungen
und
Ausführungsanforderungen
. Die
Umsetzung der Anforderungen erfolgt beim AEP, indem die Aufgaben an verschiedene
4systematische Erstellung von Anforderungen
47
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
Firmen verteilt werden. Dabei sieht das AEP eine Phase zur Überwachung der verteilten
Aufgaben vor.
Das Vorgehen des AEP wird von Gerhard Girmscheid in [
Gir10a
] und [
Gir10b
] beschrie-
ben. Dabei wird in [
Gir10a
] die Zielsetzung des AEP erläutert sowie das Prinzip des
Zielerreichungsgrades beschrieben. In [
Gir10b
] werden die verschiedenen Projektpha-
sen beschrieben. Außerdem wird auf die Überprüfung des Zielerreichungsgrads im
Sinne des Zielerreichungs-Controllings eingegangen.
Ziele
Zielerreichung
Anforderungen
Entscheidung
Ziele
erreicht
?
Ja
Nächste
Phase
Nein
Identifikation der
Anforderungen
Anforderungen
dokumentieren und mit
Kunden validieren
Modifizieren der Ziele
Abbildung 4.5: Kybernetischer Prozess nach [Gir10b]
4.6 Klinische Pfade
Klinische Pfade stellen ein Vorgehensmodell zur Unterstützung der Wissensarbeiter in
Krankenhäusern dar. Sie werden in dieser Arbeit untersucht, da sie aus der Domäne
48
4.6 Klinische Pfade
der Medizin stammen und so ein Vergleich verschiedener Vorgehensmodelle aus ver-
schiedenen Domänen möglich ist. Klinische Pfade sind in den USA weit verbreitet und
gewinnen in Deutschland aufgrund der Einführung eines neuen Vergütungssystems für
Krankenhäuser zunehmend an Bedeutung. Durch das neue Vergütungssystem sind die
Krankenhäuser gezwungen, die Kosteneffizienz ihrer Prozesse und Organisationen zu
optimieren und gleichzeitig die Qualität und Leistungsfähigkeit zu steigern [
Pha07
]. Die
klinischen Pfade sollen als Lösung für dieses Problem dienen.
Klinische Pfade stammen ursprünglich von der
Netzplantechnik
aus den 1950er Jahren
ab. Diese Technik wurde vor allem in Frankreich und in den USA eingesetzt [
RK07
].
Dabei wird der gesamte Projektverlauf als
Netzplan
grafisch dargestellt. Ein Netzplan
veranschaulicht die logische und zeitliche Abfolge von Teilvorgängen. In den 1970er
Jahren wurde die Netzplantechnik in den USA in das Gesundheitswesen übernommen
und davon die klinischen Behandlungspfade („Clinical pathway“) abgeleitet. In Deutsch-
land gewinnen klinische Behandlungspfade immer mehr an Bedeutung, aufgrund des
zunehmenden Kostendrucks [Pha07].
Ein klinischer Pfad ist ein vom Behandlungsteam selbst gefundener berufsgruppen-
und institutionsübergreifender Konsens der Behandlung in Krankenhäusern. Die Be-
handlungsqualität soll durch klinische Pfade steigen, bei gleichzeitig sinkenden oder
gleichbleibenden Kosten. Ein klinischer Pfad steuert den Behandlungsablauf und ist
gleichzeitig das behandlungsbegleitende Dokumentationsinstrument und erlaubt jeder-
zeit eine Abweichung vom festgelegten Behandlungsablaufs. Dies ist notwendig, wenn
bei einem Patienten nicht die gewünschten Behandlungsergebnisse auftreten. Das
Prinzip der klinischen Pfade ist in Abbildung 4.6 dargestellt. In Abbildung 4.7 ist ein
Ausschnitt eines konkreten klinischen Pfads des Universitätsklinikums Dresden für die
Implantation von Hüftendoprothesen dargestellt.
Die Einführung von klinischen Pfaden und deren Auswirkungen werden in [
KBT06
]
beschrieben. [
UDT+09
] unterscheidet klinische Pfade anhand von Entwicklungsstufen.
Die Stufen gehen hierbei von E1 bis E4, wobei E4 die höchste Entwicklungsstufe darstellt.
[
RK07
] liefert eine ausführliche Definition des Begriffs des klinischen Behandlungspfads.
49
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
4.7 Guide to the Project Management Body of Knowledge
Der
Guide to the Project Management Body of Knowledge
(PMBOK Guide) ist seit
1998 vom American National Standards Institute (ANSI)
5
, sowie später vom Institute of
Electrical and Electronics Engineers (IEEE)
6
als Standard für das Projektmanagement
anerkannt. Der PMBOK Guide wird in dieser Arbeit untersucht, um ein Vorgehensmodell,
das speziell für das Projektmanagement ausgelegt ist, mit anderen Vorgehensmodellen
vergleichen zu können, die das Projektmanagement als Nebenaktivität vorgeben. Die
hier untersuchte Version des PMBOK Guides ist die zweite Auflage aus dem Jahr 2000
[Pro00].
Das Project Management Institute (PMI) ist ein Projektmanagementverband aus den
USA, der 1969 gegründet wurde. Das PMI bietet Seminare und Schulungen, sowie
Zertifizierungen rund um das Projektmanagement an. Das PMI ist auch Herausgeber
des PMBOK Guides, welcher seit Januar 2013 bereits in der fünften Auflage erschie-
nen ist. Im Guide werden die wichtigsten Themen des Projektmanagements, wie z.B.
Organisationen, Begriffe, Managementfähigkeiten, usw. erläutert. Der Guide ist sehr
allgemein gehalten und kann daher in jedem Projekt, welches Projektmanagement
benötigt, eingesetzt werden.
Der PMBOK Guide ist prozessorientiert, d.h. Arbeit wird in Form von Prozessen beschrie-
ben und erledigt. Ein Projekt ist das Zusammenspiel vieler unterschiedlicher Prozesse.
Basierend auf der Prozessorientierung werden die 42 Prozesse des PMBOK Guides in
fünf verschiedene Prozessgruppen eingeteilt:
Initiierung, Planung, Ausführung, Überwa-
chung & Steuerung, Abschluss
. Die Prozessgruppen interagieren in jeder Projektphase
miteinander (siehe Abbildung 4.8).
In der Prozessgruppe
Initiierung
sind Prozesse enthalten, die zur formalen Autorisierung
des Projektes dienen. Das Ergebnis der Prozessgruppe ist der Projektauftrag und eine
vorläufige Beschreibung des Projektumfangs. Die Prozessgruppe
Planung
legt den
Projektumfang fest und erstellt einen Projektmanagementplan. Außerdem werden die
verschiedenen Planungsprozesse ausgeführt mit Ergebnissen, wie dem Projektstruktur-
5ANSI/PMI 99-001
6IEEE Std 1490–2003
52
4.7 Guide to the Project Management Body of Knowledge
Initiierungsprozesse Planungsprozesse
Überwachungs-
und Steuerprozesse Ausführungsprozesse
Abschlussprozesse
Abbildung 4.8: Interaktion der verschiedenen Prozessgruppen des [Pro00]
plan, Terminplan, Kostenplan und Risikoplan. Die Prozessgruppe
Ausführung
enthält
Prozesse, um sicherzustellen, dass die Aktivitäten ausgeführt werden, wie sie geplant
wurden. Die Qualitätssicherung fällt ebenfalls in diese Prozessgruppe. Das Ergebnis
ist der eigentliche Liefergegenstand des Projekts. In der Prozessgruppe
Überwachung
& Steuerung
sind Prozesse enthalten, die Informationen über den Projektfortschritt
sammeln und diese auswerten. Das Risikomanagement fällt ebenfalls in diese Prozess-
gruppe. Das Ergebnis sind eventuell notwendige Änderungen am Projekt, sogenannte
Change Requests. Die Prozessgruppe
Abschluss
enthält Prozesse zur Vertragsbeendi-
gung und für den Projektabschluss.
Die verschiedenen Aktivitäten des PMBOK Guides werden den neun Wissensgebieten
eindeutig zugeordnet [
Pro00
]. Das Wissensgebiet
Integrationsmanagement
enthält Pro-
zesse und Vorgänge zur Koordinierung des Projektes. Wichtigstes Instrument hierfür ist
die Erstellung eines Projektplans. Die Ausführung des Projektplans gehört ebenfalls zu
diesem Wissensgebiet. Das Wissensgebiet
Inhalts- und Umfangsmanagement
enthält
53
4 Vorgehensmodelle zur Unterstützung wissensintensiver Prozesse
die Prozesse, die benötigt werden, um zu versichern, dass das Projekt alle notwendigen
Tätigkeiten enthält, um das Projekt erfolgreich abzuschließen. Es wird festgelegt, was
im Projekt eingeschlossen ist und was nicht. Das Wissensgebiet
Terminmanagement
enthält die Prozesse, die zur Einhaltung des Zeitrahmens und Terminen benötigt werden.
Wichtiges Mittel hierfür ist der Projektplan. Das Wissensgebiet
Kostenmanagement
ent-
hält Prozesse, um die Einhaltung des Budgets zu gewährleisten. Sollten Abweichungen
wahrscheinlich sein, so sind Prozesse vorhanden, die Gegenmaßnahmen einleiten.
Das Wissensgebiet
Qualtitätsmanagement
enthält Prozesse, die sicherstellen sollen,
dass das Projekt die angestrebten Ziele erfüllen wird. Hierzu werden Qualitätsstandards
festgelegt, die im Projektverlauf überprüft werden und so der Projektfortschritt kon-
trolliert werden kann. Das Wissensgebiet
Personalmanagement
enthält Prozesse, die
das Projektteam organisieren und verwalten. Hierbei werden Rollen und Zuständig-
keiten festgelegt und entsprechenden Mitarbeitern zugewiesen. Das Wissensgebiet
Kommunikationsmanagement
enthält Prozesse, die für das Erzeugen, Sammeln, Vertei-
len, Speichern, Abrufen und Verwenden von Projektinformationen notwendig sind. Das
Wissensgebiet
Risikomanagement
enthält Prozesse zur Identifizierung und Analyse
von Risiken, sowie zur Reaktion auf bekannte Risiken. Durch das Risikomanagement
sollen Risiken minimiert werden. Das Wissensgebiet
Beschaffungsmanagement
enthält
Prozesse, die für den Kauf von Produkten, Dienstleistungen oder Ergebnissen benötigt
werden. Der Kauf von Produkten außerhalb des Projektteams kann nötig sein, um die
Arbeit durchführen zu können.
54
5
Einordnung und Vergleich von
Vorgehensmodellen
In diesem Kapitel werden die Vorgehensmodelle auf die in Kapitel 3 festgelegten Ver-
gleichsaspekte untersucht. Als erstes werden die drei Vorgehensmodelle aus dem Be-
reich der Softwareentwicklung (siehe Kapitel 5.1, 5.2 und 5.3) untersucht, anschließend
folgen die zwei Vorgehensmodelle aus den Ingenieurswissenschaften (siehe Kapitel 5.4
und 5.5). Danach werden die klinischen Behandlungspfade (siehe Kapitel 5.6) und
der Project Management Body of Knowledge Guide (siehe Kapitel 5.7) untersucht.
Abschließend erfolgt ein Vergleich der verschiedenen Vorgehensmodelle in Kapitel 5.8.
55
5 Einordnung und Vergleich von Vorgehensmodellen
5.1 V-Modell XT
Das V-Modell XT (siehe Kapitel 4.1) wurde mithilfe der offiziellen Dokumentation [
BMI
]
auf die Vergleichsaspekte untersucht. Die Ergebnisse sind nachfolgend textuell beschrie-
ben und in den Abbildungen 5.1 und 5.4 dargestellt.
5.1.1 Allgemeine Aspekte
In diesem Abschnitt wird das V-Modell XT mithilfe der allgemeinen Vergleichsaspekte
(GA) aus Kapitel 3.2.1 analysiert und die Ergebnisse textuell und graphisch dargestellt
(siehe Abbildung 5.1).
GA1 – Phasenabdeckung
Werte: Identifikation
,
Konzept
,
Anforderungen
,
vorläufiges Design
,
detailliertes
Design,Entwicklung,Betrieb,Abbau
Das V-Modell XT unterstützt die klassischen Phasen der Systementwicklung, von der
Projektplanung bis zur Realisierung. Somit sind die Phasen
Identifikation
,
Konzept
,
Anforderungen
,
vorläufiges Design
,
detailliertes Design
und
Entwicklung
im Modell ab-
gedeckt. Die Phase
Betrieb
ist nur teilweise unterstützt, da für den Betrieb nur eine
Dokumentation geliefert wird, z.B. in Form einer Installationsanleitung. Die Phase
Abbau
ist ebenfalls nur sehr beschränkt abgedeckt, da nur die Migration auf ein neues Produkt
unterstützt wird.
GA2 – Prozessabdeckung
Werte: Produktentwicklung
,
Projektmanagement
,
Qualitätssicherung
,
Benchmar-
king
Die verschiedenen Subprozesse im V-Modell XT werden in Form von Vorgehensbau-
steinen beschrieben. Die Produktentwicklung wird vom V-Modell XT unterstützt, da
56
5.1 V-Modell XT
das Vorgehensmodell zur Produktentwicklung entwickelt wurde und dies der zentra-
le Bestandteil des V-Modell XT ist. Die Produktentwicklung ist im Vorgehensbaustein
Systemerstellung
beschrieben. Außerdem wird das Projektmanagement unterstützt: Im
Vorgehensbaustein
Projektmanagement
werden Aktivitäten wie
Kompetenzen festle-
gen
,
Mittel und Ressourcen einteilen
,
Rahmenbedinungen schaffen
und viele weitere
beschrieben. Ein weiterer wichtiger Bestandteil des V-Modell XT ist die Qualitätssiche-
rung aus dem Vorgehensbaustein
Qualitätssicherung
. Um eine Aktivität erfolgreich zu
beenden, müssen die erzeugten Produkte geprüft werden. Dies kann durch die Eigen-
prüfung der beteiligten Personen oder durch eine eigenständige Qualitätssicherung
erfolgen. Vom Modell vorgegeben ist eine formale und inhaltliche Kontrolle der Produkte.
Außerdem muss auch die inhaltliche Konsistenz mit anderen Produkten aufgrund von
Produktabhängigkeiten überprüft werden. Durch den Vorgehensbaustein
Messung und
Analyse
kann das Benchmarking unterstützt werden. Dabei werden Kenngrößen des
Projektes gesammelt und ausgewertet und somit die Projektqualität bewertet.
GA3 – Abstraktionsstufe
Wert: Vorgehensmodell
Das V-Modell XT ist ein Vorgehensmodell, das der Definition eines Vorgehensmodells
voll entspricht. Außerdem ist die Unterstützung wissensintensiver Prozesse umfassend,
da viele verschiedene Aspekte abgedeckt werden. Des Weiteren lässt sich mithilfe
des projektspezifischen Tailorings das Modell an die individuellen Gegebenheiten des
Projektes anpassen.
GA4 – Detaillierungsgrad
Wert: weltlich
Der Detaillierungsgrad des V-Modell XT ist weltlich, da die Abfolge der Prozessschritte
genau bestimmt ist. Außerdem sind die Prozessschritte in der offiziellen Dokumen-
tation ausführlich beschrieben. Allerdings fehlt eine detailliertere Ausgestaltung der
Prozessschritte, um die Einstufung als atomares Modell zu rechtfertigen.
57
5 Einordnung und Vergleich von Vorgehensmodellen
GA5 – Branchenfokus
Wert: speziell
Das V-Modell XT ist speziell für die Software- bzw. Hardware-Entwicklung ausgelegt
und daher an Informatik-nahe Branchen gebunden. Durch das Tailoring lässt sich das
V-Modell für verschiedene Projekte individuell anpassen. Es werden reine Software- und
Hardware-Projekte unterstützt, sowie Software+Hardware Projekte.
GA6 – Vorgehensweise
Werte: evolutionär,inkrementell
Im V-Modell XT werden verschiedene Vorgehensweisen unterstützt. In einem Projekt zur
Weiterentwicklung bestehender Produkte wird ein evolutionäres Vorgehen eingesetzt,
das auf dem bestehenden Produkt aufbaut. Dabei werden neue Anforderungen in
neuen Projekten umgesetzt. Des Weiteren unterstützt das V-Modell XT die inkrementelle
Entwicklung: Das Produkt wird über mehrere Iterationsphasen entwickelt und damit stetig
weiterentwickelt. Im Gegensatz zur evolutionären Entwicklung geschieht dies allerdings
innerhalb eines Projektes bis das Produkt fertiggestellt ist.
GA7 – Prozesssteuerung
Wert: ergebnisorientiert
Die Prozesssteuerung im V-Modell XT basiert auf Ergebnissen. Produkte sind die
zentralen Projektergebnisse und basierend auf diesen Produkten werden Projektent-
scheidungen getroffen und der Prozess gesteuert. Somit unterstützt das V-Modell XT
eine ergebnisorientierte Prozesssteuerung.
58
5.1 V-Modell XT
GA8 – Prozessergebnis
Werte: Produkte,Wissen
Das zentralen Ergebnisse des V-Modell XT sind Produkte, meist in Form von Software
oder Hardware. Allerdings wird im Laufe des Prozesses auch Wissen in Form von
Dokumenten oder, allgemein, externalisierten Informationen produziert.
GA9 – Modellarchitektur
Werte: sukzessive,parallel
Im V-Modell XT werden sowohl die parallele, als auch die sukzessive Abfolge von
Aktivitäten unterstützt. Parallele Aktivitäten sind möglich, wenn z.B. mehrere Systemteile
gleichzeitig in Entwicklung sind.
GA10 – Spezialisierbarkeit
Wert: domänenneutral
Das V-Modell XT ist sehr auf IT Projekte zugeschnitten, allerdings lassen sich Adaptionen
des V-Modells XT in anderen Domänen wiederfinden wie z.B. die VDI Richtlinie 2206.
Somit lässt sich feststellen, dass das V-Modell XT aufgrund der Adaption in anderen
Domänen eher domänenneutral ist.
GA11 – Modellkomplexität
Werte: mittel,hoch
Die Komplexität des V-Modell XT wird als mittel bis hoch eingestuft, da je nach Rolle
im Projekt eine teilweise recht intensive Einarbeitung nötig ist. Um den Ablauf des
V-Modells zu verstehen, ist das Lesen der Dokumentationsteile eines und zwei hilfreich.
Je nach Rolle sind weitere Teile der Dokumentation relevant. So wird das Studium
von mehreren hundert Seiten Dokumentation notwendig, um das V-Modell produktiv
59
5 Einordnung und Vergleich von Vorgehensmodellen
einsetzen zu können. Daher wird die Modellkomplexität aufgrund eines relativ hohen
Einarbeitungsaufwands als mittel bis hoch eingestuft.
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.1: Allgemeine Aspekte des V-Modells XT
60
5.1 V-Modell XT
5.1.2 Wissensintensive Aspekte
In diesem Abschnitt wird das V-Modell XT mithilfe der wissensintensiven Vergleichsa-
spekte (KIA) aus Kapitel 3.2.2 analysiert und die Ergebnisse textuell und graphisch
dargestellt (siehe Abbildung 5.4).
KIA1 – Zuständigkeiten
Wert: Rollen vorgegeben
Im V-Modell XT gibt es ein sehr stark ausgeprägtes Rollenkonzept mit einer Vielzahl
an unterschiedlichen Rollen (siehe Abbildung 5.2). Dabei ist es möglich, Rollen pro-
jektspezifisch und unabhängig von organisatorischen Rollen zu besetzten. So können
verschiedene Mitarbeiter mit organisatorischen Rollen in einem Projekt eine andere
Rolle einnehmen. Daher wird jeder Rolle im V-Modell XT eine Rollenkategorie (projekt-
spezifische Rolle oder organisatorische Rollen) zugeordnet. Die Rollen im V-Modell
XT sind jedoch vorgegeben und es lassen sich damit keine eigenen Rollen definieren.
Allerdings lassen sich die Rollen individuell besetzen und es müssen auch nicht alle
vorgegebenen Rollen besetzt sein.
KIA2 – Wissenstätigkeit
Werte: Wissensanwendung,Wissenserzeugung
Beim V-Modell XT geht es vor allem um die Entwicklung von Produkten durch Anwen-
den von Fachkenntnis und Erfahrung durch die Wissensarbeiter. Diese verwenden ihr
vorhandenes Wissen in der Projektplanung, Anforderungsanalyse und Entwicklung und
allgemein zum Lösen von Problemen. Somit unterstützt das V-Modell XT die Wissenstä-
tigkeit
Wissensanwendung
. Außerdem wird neues Wissen in Form von unterschiedlichen
Artefakten festgehalten. Dies entspricht der Wissenstätigkeit Wissenserzeugung.
61
5.1 V-Modell XT
KIA3 – Prozessdauer
Werte: lang
Das V-Modell XT bietet sich vor allem für Projekte mit langer Prozessdauer an, da
der Planungsaufwand für ein neues Projekt nicht unerheblich ist. Zur Vorbereitung
eines Projektes sind laut V-Modell XT folgende Schritte erforderlich: Projektplanung,
Ausschreibung des Projektes auf Auftraggeberseite bzw. Angebotsunterbreitung auf
Auftragnehmerseite mit anschließenden Vertragsverhandlungen.
KIA4 – Sichtenmodell
Wert: ja
Das V-Modell XT unterstützt ein Sichtenmodell, das auf der Dokumentation und dem
projektspezifischen Tailoring basiert. Die Dokumentation besteht aus sieben Teilen.
Dabei sind die Teile eins und zwei als verpflichtende Lektüre für Projektbeteiligte anzu-
sehen. Rollenspezifische Informationen können dann über die sogenannten V-Modell-
Referenzen erhalten werden. Diese Referenzen erlauben eine spezifische Sicht auf die
Inhalte des V-Modells und stellen die relevanten Informationen für die jeweiligen Rollen
bereit. Das projektspezifische Tailoring unterstützt das Sichtenmodell dahingehend,
dass der Projektleiter die für das Projekt relevanten Parameter auswählt und somit die
unwichtigen Aspekte für das komplette Projekt ausgeblendet werden. Somit werden nur
die wichtigen Bausteine für die Projektplanung berücksichtigt.
KIA5 – Lebenszyklus Abdeckung
Werte: Orientierung,Vorlagen-Entwurf,Gemeinsame Bearbeitungsphase
Die verschiedenen Lebenszyklusphasen zur Unterstützung eines wissenintensiven
Prozesses werden im V-Modell XT zum Teil abgedeckt. Die erste Phase
Orientierung
stellt die Auseinandersetzung mit den Aufgaben im Projektmanagement dar. Dabei
wird das Projekt dahingehend untersucht, ob es umsetzbar ist und wie das Projekt
63
5 Einordnung und Vergleich von Vorgehensmodellen
geplant werden soll. Die nächste Phase
Vorlagen-Entwurf
wird ebenfalls unterstützt.
Vom V-Modell XT wird der V-Modell Projektassistent bereitgestellt. Mithilfe dieses Tools
können eigene Vorlagen in Form von Dokumenten angelegt werden. Die
gemeinsame
Bearbeitungsphase
wird ebenfalls unterstützt, da in dieser Phase die angelegten bzw.
auch die vom V-Modell XT bereitgestellten vorgefertigten Vorlagen verwendet werden,
um die Wissensarbeiter zu unterstützen. Ein Auszug aus der Vorlage für das Lastenhaft
ist in Abbildung 5.3 dargestellt.
KIA6 – Kommunikationsformen
Werte: andere Vorgaben,wöchentliches Meeting
Grundsätzlich werden im V-Modell XT keine Vorgaben zu Besprechungen oder zur
Kommunikation gegeben. Allerdings werden Vorgaben für die Einsetzung eines soge-
nannten
Lenkungsausschusses
gegeben. Der Lenkungsausschuss entscheidet über
den Projektverlauf. Der Ausschuss trifft sich meist in speziell dafür vorgesehen Sitzungen
kurz vor wichtigen Entscheidungspunkten. Somit stellen die Treffen des Lenkungsaus-
schusses regelmäßige Meetings dar, in denen über den Projektverlauf entschieden wird.
Deswegen wird dies als w
öchentliches Meeting
angesehen. Da diese Meetings aber
nicht wöchentlich stattfinden müssen, wird der Wert eines
wöchentlichen Meetings
als
nur teilweise unterstützt bewertet. Außerdem ist eine Sitzung mit allen Projektbeteiligten
am Anfang eines jeden Projektes vorgesehen, sowie eine Abschlusssitzung nach Fertig-
stellung des Projektes. Somit sind Sitzungen zu wichtigen Anlässen vorgesehen. Dies
wird als Abdeckung von der Eigenschaft andere Vorgaben eingestuft.
KIA7 – Zielspezifikation
Werte: Gesamtziel,Meilensteine,eigene Ziele
Im V-Modell XT ist das Gesamtziel des Projektes vorgegeben. Dies wird durch verschie-
dene Projekttypen realisiert, z.B. der Projekttyp Systementwicklung hat das Ziel, ein
Software-System zu entwickeln. Außerdem lässt sich das Projekt mithilfe des V-Modell
XT auch in mehrere Teilprojekte aufteilen mit eigenen Projektzielen. Des Weiteren
64
5.1 V-Modell XT
Abbildung 5.3: Auszug aus der Vorlage für das Lastenheft
65
5 Einordnung und Vergleich von Vorgehensmodellen
werden Meilensteine in Form von vordefinierten Entscheidungspunkten unterstützt. An
diesen Entscheidungspunkten wird entschieden, ob die Produkte den Ansprüchen genü-
gen und ob in die nächste Phase übergegangen wird bzw. ob die Aktivität fertiggestellt
wurde. Diese Entscheidungspunkte sind für die jeweiligen Projekttypen vorgegeben.
Außerdem lassen sich bei der Projektplanung eigene Entscheidungspunkte festlegen.
Dies entspricht der Festlegung von eigenen Zielen.
KIA8 – Qualitätssicherungsmaßnahmen
Werte: Tests,Prozessanalyse,Ergebnisauswertung
Die im V-Modell XT unterstützten Qualitätssicherungsmaßnahmen sind
Tests
,
Pro-
zessanalyse
und
Ergebnisauswertung
. Tests werden vom V-Modell XT in Form von
einer Eigenprüfung durch den Verfasser bzw. Entwickler des Produkts vorgesehen.
Außerdem können Tests durch einen eigenständigen Qualitätssicherungsprozess durch-
geführt werden. Dies bedeutet, dass ein außenstehender Prüfer den Prüfungsprozess
durchführt und die Ergebnisse protokolliert. Eine Prozessanalyse wird vom V-Modell
XT bei der Einführung eines organisationsspezifischen Vorgehensmodells vorgesehen.
Außerdem kann eine Prozessanalyse zur Verbesserung der Prozessqualität auch in
Entwicklungsprojekten durchgeführt werden. Die Ergebnisauswertung wird durch die
stetige inhaltliche und formale Prüfung von erzeugten Artefakten durchgeführt.
KIA9 – Wissensdokumentation
Wert: hoch
Da im V-Modell XT eine Vielzahl an unterschiedlichen Artefakten zur Dokumentation des
Projektfortschritts und wichtigen Entscheidungen erstellt wird, wird die Wissensdokumen-
tation als hoch eingestuft. Die erstellten Artefakte sind ein Nebenprodukt des Prozesses,
allerdings sind diese ein wichtiger Aspekt, um das Projekt verfolgen zu können.
66
5.1 V-Modell XT
KIA10 – Problemkomplexität
Werte: niedrig,mittel,hoch
Das V-Modell XT bietet sich für jede der drei verschiedenen Komplexitätsklassen an,
da das V-Modell XT jeweils projektspezifisch angepasst werden kann. Um Projekte mit
einer sehr hohen Komplexität zu unterstützen, kann das große komplexe Projekt auch
in mehrere kleine Projekte unterteilt werden. Somit wird versucht die Komplexität des
Problems zu unterteilen, um sie beherrschbar zu machen.
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.4: Wissensintensive Aspekte des V-Modell XT
67
5 Einordnung und Vergleich von Vorgehensmodellen
5.2 Kanban
Kanban (siehe Kapitel 4.2) wurde mithilfe von [
BW15
] und [
Epp11
] auf die festgelegten
Vergleichsaspekte untersucht. Die Ergebnisse sind nachfolgend textuell beschrieben
und in den Abbildungen 5.5 und 5.6 dargestellt.
5.2.1 Allgemeine Aspekte
In diesem Abschnitt werden die allgemeinen Aspekte von Kanban untersucht und textuell
und graphisch dargestellt (siehe Abbildung 5.5).
GA1 – Phasenabdeckung
Werte: Anforderungen,Entwicklung,Betrieb
Die Projektphase
Anforderungen
wird in Kanban entweder durch das Erstellen von
eigenen Anforderungen an das Produkt im
Requirements Engineering1
abgedeckt oder
die Anforderungen werden von extern geliefert und dann im Kanban Team priorisiert
und nach Wichtigkeit geordnet.
Die Entwicklungphase besteht bei Kanban aus drei verschiedenen Aktivitäten. Der
Entwickler überlegt sich zuerst, wie er die Aufgabe realisieren kann. Er erstellt einen
Entwurf zur Problemlösung. Im nächsten Schritt wird dann der Entwurf implementiert.
Ist die Implementierung abgeschlossen, so erfolgt eine Qualitätssicherung. Somit setzt
sich die Entwicklungsphase aus den drei Aktivitäten
Entwurf erstellen
,
Implementierung
und
Qualitätssicherung
zusammen. Dieser Ablauf ähnelt dem idealtpyischen Ablauf
wissensintensiver Prozesse (siehe Kapitel 2.4).
Die Phase
Betrieb
wird in Kanban indirekt unterstützt. Kanban verfolgt das Prinzip
von
continous delivery2
. Fertig implementierte und fertig getestete Funktionalitäten
1
Requirements Engineering bezeichnet den Prozess der Ermittlung, Dokumentation und Überprüfung von
Anforderungen.
2
dt. kontinuierliche Auslieferung: die Software wird durch Testautomatisierung qualitätsgesichert. Dadurch
kann schnell, zuverlässig und wiederholbar geliefert werden.
68
5.2 Kanban
fließen direkt in das Produkt mit ein. Durch die automatisierten Tests und automatisierte
Release-Erstellung ist es möglich, schnell neue Funktionalitäten auszuliefern. Werden
nun im Betrieb neue Anforderungen an das Produkt entdeckt, so können diese neuen
Anforderungen schnell umgesetzt werden und schnell ausgeliefert werden.
GA2 – Prozessabdeckung
Werte: Produktentwicklung
,
Projektmanagement
,
Qualitätssicherung
,
Benchmar-
king
Der Kernfokus von Kanban ist die Entwicklung von Produkten. Somit ist die Produktent-
wicklung in Kanban direkt unterstützt.
In Kanban arbeitet das Team selbstorganisiert und eigenständig. Aufgaben werden nach
dem verteilten „Pull Prinzip“ bearbeitet. Dabei werden die Aufgaben nicht zentral vom
Projektmanagement verteilt, sondern jedes Teammitglied nimmt sich Aufgaben, um
sie zu bearbeiten. Die Aufgabe des Projektmanagements besteht im Überwachen des
Projektfortschritts mithilfe von Benchmarking.
Kanban unterstützt das Benchmarking, da explizit wichtige Kenngrößen zur Messung des
Projektfortschritts gegeben werden. Die wichtigsten Kenngrößen
Durchlaufzeit
,
Work In
Progress und Fertigstellungsrate sind in einer zentralen Gleichung enthalten:
Durchlaufzeit =
Work In Progress
Fertigstellungsrate (5.1)
GA3 – Abstraktionsstufe
Wert: Methodensammlung
Zentrale Aspekte von Kanban sind das Kanban-Board mit dem Kartensystem und die
Daily Standups. Dies sind agile Methoden, die an projektspezifische Gegebenheiten
angepasst werden können. Kanban kann auch als Unterstützung für ein bestehendes
Vorgehensmodell (z.B. V-Modell XT) eingesetzt werden. Damit lässt sich Kanban als
agile Methodensammlung beschreiben.
69
5 Einordnung und Vergleich von Vorgehensmodellen
GA4 – Detaillierungsgrad
Wert: nicht bewertbar, da kein Vorgehensmodell
GA5 – Branchenfokus
Wert: allgemein
Kanban ist leicht verständlich und allgemein gehalten. Dadurch ist Kanban allgemein
für das Projektmanagement geeignet. Kanban kann dabei in den verschiedensten
Domänen eingesetzt werden, es ist vor allem jedoch in der Software-Entwicklung und
in der Automobilindustrie weit verbreitet [
Epp11
]. Die Ursprünge von Kanban liegen
in der Automobilindustrie [
Epp11
]. Deswegen wird Kanban als ein allgemeines Modell
bewertet.
GA6 – Vorgehensweise
Wert: evolutionär
Kanban verfolgt das Ziel einer kontinuierlichen Entwicklung nach den Prinzipien von
„continous delivery“. Dabei fließen fertig implementierte und getestete Aufgaben direkt in
das Produkt ein. Das Produkt wird beständig weiterentwickelt. Dabei gibt es keine festen
Entwicklungszyklen. Werden neue Anforderungen an das Produkt gestellt, so werden
die Anforderungen direkt in den Entwicklungsprozess aufgenommen. Kanban verfolgt
somit eine evolutionäre Vorgehensweise, um das Produkt beständig weiterzuentwickeln.
GA7 – Prozesssteuerung
Wert: aktivitätsorientiert
Kanban definiert eine Limitierung des
Work in Progress
(laufende Arbeit). Somit werden
die Mitarbeiter dazu „gezwungen“, ihre Arbeit abzuschließen bevor sie mit einer neuen
Aufgabe beginnen. Es soll stets eine bestimmte Anzahl an Aufgaben in jeder Phase in
70
5.2 Kanban
Bearbeitung sein. Diese Limitierung des Work in Progress setzt die agile Denkweise
„stop starting, start finishing“
3
um [
LK12
]. Da es eine Limitierung der gleichzeitig in
Bearbeitung befindlichen Aufgaben gibt, werden die Prozessabläufe in Kanban durch die
Fertigstellung von Aufgaben geregelt. Wird eine Aufgabe fertiggestellt, so wird aufgrund
der Limitierung entschieden, ob die Aufgabe in die nächste Phase übergehen kann.
Ist dies nicht möglich, so muss versucht werden andere Mitarbeit zu unterstützen ihre
Aufgaben fertigzustellen, damit der Arbeitsfluss nicht ins Stocken gerät. Kanban ist somit
ein aktivitätsorientiertes Modell.
GA8 – Prozessergebnis
Wert: Produkt,Dienstleistung,Wissen
Kanban kann allgemein für das Projektmanagement eingesetzt werden. Dadurch gibt es
keine Limitierung des Prozessergebnisses und somit können alle drei Formen vorkom-
men. Allerdings stammt Kanban aus der Automobilindustrie und wird auch häufig in der
Software-Entwicklung eingesetzt. In diesen beiden Domänen unterstützt Kanban den
Produktentwicklungsprozess. Somit wird das Prozessergebnis
Produkt
als vollständig
unterstützt bewertet, die Ergebnisse
Dienstleistung
und
Wissen
werden als teilweise
unterstützt bewertet.
GA9 – Modellarchitektur
Werte: sukzessive
Kanban limitiert den Work in Progress. Dadurch sollen Teammitglieder nicht zu viele Auf-
gaben parallel bearbeiten. Nach Fertigstellung einer Aufgabe, wird diese in die nächste
Phase übernommen, sofern das Work in Progress Limit nicht verletzt wird. Dadurch
erfolgt eine sukzessive Abfolge der verschiedenen Phasen. Da mehrere Wissensarbeiter
parallel an verschiedenen Aufgaben aus verschiedenen Phasen arbeiten, stellt Kanban
eine Pipeline aus sukzessiven Phasen dar.
3
dt. „höre auf anzufangen, beginne fertigzustellen": Fokussierung auf die Fertigstellung weniger Aufgaben,
statt den Anfang vieler Aufgaben
71
5 Einordnung und Vergleich von Vorgehensmodellen
GA10 – Spezialisierbarkeit
Wert: domänenneutral
Kanban ist domänenneutral, da es sehr allgemein gehalten und aufgrund fehlender
limitierender Vorgaben sehr stark anpassbar ist. Dadurch ist es für viele Arten von
Projekten einsetzbar.
GA11 – Modellkomplexität
Wert: niedrig
Kanban ist ein einfach gehaltenes, allgemeines Modell, da es nur wenige Vorgaben gibt
und sich stark an individuelle Projektbedürfnisse anpassen lässt. Es lässt sich auch zur
Unterstützung von bereits existierenden Vorgehensmodellen einsetzen.
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.5: Allgemeine Aspekte von Kanban
72
5.2 Kanban
5.2.2 Wissensintensive Aspekte
In diesem Abschnitt werden die wissensintensiven Aspekte von Kanban untersucht und
textuell und graphisch dargestellt (siehe Abbildung 5.6).
KIA1 – Zuständigkeiten
Wert: Rollen festlegbar
Kanban gibt an sich kein Rollenkonzept vor. Allerdings ist eine Rollenverteilung möglich.
So bestehen viele Kanban-Teams aus Mitarbeitern aus verschiedenen Disziplinen, z.B.
Requirements Engineering, Entwicklung, Qualitätssicherung und Projektmanagement für
Software Entwicklungsteams [
Epp11
]. Deshalb erfüllt Kanban den Wert Rollen festlegbar.
KIA2 – Wissenstätigkeit
Wert: Wissensanwendung
Der Fokus von Kanban liegt im Entwicklungsprozess. Das Ziel ist das agile Erstellen von
qualitativ hochwertigen Produkten. Um dieses Ziel zu erreichen, setzen die Wissensar-
beiter ihr vorhandenes Wissen und ihre Erfahrung ein. Somit wird bei Kanban primär die
Wissenstätigkeit Wissensanwendung unterstützt.
KIA3 – Prozessdauer
Werte: kurz,mittel,lang
Da Kanban eine evolutionäre Vorgehensweise darstellt, sind alle drei Prozessdauern
möglich. Eine kurze Prozessdauer kommt vor, wenn es nur wenige Anforderungen gibt
und keine neuen Anforderungen hinzukommen. Dies könnte z.B. bei einem finalen
Produkt eine Nachbesserung sein, bei der nur wenige Fehler behandelt werden müssen.
Mittlere und lange Prozessdauern kommen bei normalen Entwicklungsprozessen vor, da
je nach Umfang die Entwicklung deutlich länger braucht. Allerdings wird bei Kanban die
73
5 Einordnung und Vergleich von Vorgehensmodellen
Durchlaufzeit einer einzelnen Aufgabe minimiert, damit ein hoher Aufgabendurchsatz
möglich ist und möglichst viele Anforderungen in relativ wenig Zeit umgesetzt werden
können.
KIA4 – Sichtenmodell
Wert: ja
Ein Grundprinzip von Kanban ist die Visualisierung vom bestehenden Workflow, der
vorhandenen Arbeit und von Problemen. Dies wird mit dem Kanban-Board erreicht. Das
Kanban-Board kann z.B. ein einfaches Whiteboard sein auf dem Karteikarten befestigt
werden können. Auf dem Kanban-Board sind dann individuell festlegbare Entwicklungs-
phasen zu markieren. Typische Phasen sind z.B.
Bereit
,
Umsetzung
,
Testen
,
Lieferbar
und
Fertiggestellt
(siehe Abbildung 4.2). Dabei haben die Phasen
Umsetzung
und
Tes-
ten
zwei Spalten. Eine Spalte für die aktuell in Bearbeitung befindlichen Aufgaben und
eine für die fertiggestellten Aufgaben. Wird eine Aufgabe fertiggestellt, so kann mit der
Bearbeitung in der nächsten Phase begonnen werden, falls das Limit des Work in Pro-
gress nicht überschritten wird. Somit lässt sich der Arbeitsfluss übersichtlich darstellen.
Sollten Probleme auftreten, z.B. aufgrund zu geringer Work in Progress Limits, so lässt
sich dies anhand des Kanban-Boards frühzeitig erkennen [BW15].
KIA5 – Lebenszyklus Abdeckung
Werte: Orientierung,Gemeinsame Bearbeitungsphase
Bei Kanban werden in der Orientierungsphase die Aufgaben näher spezifiziert und
priorisiert. Dabei entstehen drei Arten von Anforderungen:
notwendige
,
mögliche
und
zusätzliche
Anforderungen. Notwendige Anforderungen müssen auf jeden Fall umge-
setzt werden, um das Projekt erfolgreich abzuschließen. Mögliche Anforderungen sollten,
falls möglich, umgesetzt werden. Zusätzliche Anforderungen dagegen müssen nicht
notwendigerweise umgesetzt werden.
Die gemeinsame Bearbeitungsphase wird in Kanban nur teilweise unterstützt, da kei-
ne Zusammenarbeits-Vorlagen existieren, die instanziiert werden können. Allerdings
74
5.2 Kanban
werden die Wissensarbeiter durch das Kanban-Board unterstützt, das den Arbeitsfluss
visualisiert und dadurch mögliche Probleme frühzeitig aufzeigt.
KIA6 – Kommunikationsformen
Wert: tägliches Meeting
Bei Kanban sind keine Planungsmeetings vor der Entwicklung angedacht. Das einzige
vorgegebene Meeting ist der
Daily Standup
. Dieses Meeting findet an jedem Arbeitstag
zur gleichen Uhrzeit statt und sollte nicht länger als 15 Minuten dauern. Es sollten alle
Teammitglieder anwesend sein. In dem Meeting berichtet jedes Teammitglied woran er
seit dem letzten Daily Standup gearbeitet hat, ob er Probleme dabei hatte und was er bis
zum nächsten Daily Standup arbeiten wird. Falls er Probleme hatte, so kann er Hilfe von
seinen Teammitglieder erfragen. Das Daily Standup wird im Stehen durchgeführt. Dies
hat den Grund, dass auf Bequemlichkeit verzichtet wird und sich die Teammitglieder
somit besser auf das kurze Meeting konzentrieren.
KIA7 – Zielspezifikation
Werte: Gesamtziel
Bei Kanban werden die Anforderungen zu Beginn priorisiert, z.B. mit der MoSCoW-
Priorisierung
4
. So gibt es die vier Anforderungsklassen
Must
,
Should
,
Could
und
Won’t
have
.
„Must have“
-Anforderungen müssen unbedingt umgesetzt werden und sind er-
forderlich.
„Should have“
-Anforderungen sollten umgesetzt werden, wenn alle
„Must
have“
-Anforderungen umgesetzt wurden.
„Could have“
-Anforderungen können umge-
setzt werden, wenn noch Zeit vorhanden ist und die
„Must have“
und
„Should have“
-
Anforderungen umgesetzt wurden.
„Won’t have“
-Anforderungen werden evtl. in einem
späteren Projekt umgesetzt. Des Weiteren gibt Kanban die Ziele Minimierung der Durch-
flusszeit und eine stetige Verbesserung des Entwicklungsprozesses vor.
4Abkürzung für Must, Should, Could, Won’t have.
75
5 Einordnung und Vergleich von Vorgehensmodellen
KIA8 – Qualitätssicherungsmaßnahmen
Werte: Tests,Prozessanalyse
Ein wichtiger Punkt von Kanban ist die Etablierung von automatischen Tests. Dies ist
ersichtlich daran, dass die Entwicklungsphase erst abgeschlossen ist, wenn das Produkt
ausgiebig getestet wurde. Dies kann mit der Definition des fertig-Status vorgegeben
werden. So gilt ein Produkt erst als fertig implementiert, wenn es entsprechend getestet
wurde. Dies basiert auf dem „continous delivery“ Prinzip.
Die Prozessanalyse ist in Kanban als Qualitätssicherungsmaßnahme vorgegeben, da
Kanban das Ziel hat, den Entwicklungsprozess stetig zu verbessern. Dies wird durch
Auswerten der Projektkennzahlen Durchflussrate, Work in Progress und durchschnittliche
Fertigstellungsrate erreicht. Die drei Kennzahlen hängen voneinander ab, wie in Formel
5.1 zu sehen ist.
KIA9 – Wissensdokumentation
Wert: niedrig
Kanban gibt keine speziellen Vorgaben zur Wissensdokumentation. Lediglich der Einsatz
eines Kanban-Boards ist erwünscht. Dies kann auch digital vorliegen. Durch das Kanban-
Board und die Aufgaben ist ein minimaler Dokumentationsaufwand vorhanden, da
dokumentiert werden muss, wer welche Aufgabe bearbeitet.
KIA10 – Problemkomplexität
Werte: niedrig,mittel,hoch
Da Kanban leicht verständlich und sehr allgemein gehalten ist, lässt es sich für alle
Arten von komplexen Projekten einsetzen [
BW15
]. Auch sehr komplexe Projekte sind mit
Kanban durchführbar. Die Komplexität wird durch den evolutionären Entwicklungsansatz
reduziert, da das Produkt Stück für Stück umgesetzt wird. Durch die Limitierung des Work
in Progress ist dabei sichergestellt, dass sich nur eine begrenzte Anzahl an Aufgaben
76
5.2 Kanban
parallel in Bearbeitung befinden. Des Weiteren lässt sich die Komplexität durch die
Visualisierung des Arbeitsflusses am Kanban-Board reduzieren.
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.6: Wissensintensive Aspekte von Kanban
77
5 Einordnung und Vergleich von Vorgehensmodellen
5.3 Scrum
Scrum (siehe Kapitel 4.3) wurde mithilfe von [
Sch07
] und dem offiziellen Scrum-Guide
[
SS13a
] auf die festgelegten Vergleichsaspekte untersucht. Die Ergebnisse sind nachfol-
gend textuell beschrieben und in den Abbildungen 5.7 und 5.8 dargestellt.
5.3.1 Allgemeine Aspekte
In diesem Abschnitt werden die allgemeinen Aspekte von Scrum analysiert und textuell
und graphisch dargestellt (siehe Abbildung 5.7).
GA1 – Phasenabdeckung
Werte: Anforderungen,vorläufiges Design,Entwicklung,Betrieb
Die Anforderungsphase in Scrum wird vom Product Owner durchgeführt. Dieser erstellt
einen Anforderungskatalog, den sogenannten
Product Backlog
, in dem alle Anforderun-
gen festgehalten werden und nach Priorität geordnet sind.
Das
Sprint Planning Meeting
entspricht der Phase
vorläufiges Design
, da in diesem
Meeting die umsetzbaren Anforderungen für den anstehenden
Sprint
ausgewählt werden
und der Sprint dadurch geplant wird. Die Entwicklungsphase in Scrum ist durch die
sogenannten Sprints abgedeckt (siehe Kapitel 4.3). Ein Sprint hat dabei zum Ziel, die im
Sprint Planning Meeting ausgewählten Anforderungen umzusetzen.
Die Phase
Betrieb
wird nur teilweise unterstützt, da Scrum eine kontinuierliche, inkre-
mentelle Entwicklung vorsieht. Die Inkremente sollen dabei auslieferbar sein. Somit ist
ein früher Produktiveinsatz möglich, obwohl die Entwicklung noch nicht abgeschlossen
ist. Weitere Funktionalität wird mit jedem weiteren Sprint als neues Release geliefert.
78
5.3 Scrum
GA2 – Prozessabdeckung
Werte: Produktentwicklung,Projektmanagement,Qualitätssicherung
Die Produktentwicklung ist in Scrum der Hauptfokus. Dies ist daran ersichtlich, dass
während eines Sprints vom
ScrumMaster
(siehe Kapitel 4.3) alles versucht wird, sein
Entwicklungsteam von äußeren Einflüssen zu bewahren, damit die Entwickler effektiv
arbeiten können.
Das Projektmanagement ist in Scrum nur teilweise unterstützt, da es kein extra Projekt-
management im eigentlichen Sinne gibt. Die Teams stehen unter Eigenverwaltung und
es gibt keine Projektmanager. Die Teams sind sozusagen ihre eigenen Manager mit
eigener Verwaltung und Entscheidungsfindung.
Eine eigene Qualitätssicherung gibt es in Scrum ebenfalls nicht. Allerdings ist es der
Anspruch von Scrum, Produkte mit hoher Qualität herzustellen. In Folge dessen muss
jedes Inkrement auslieferbar sein. Damit dies möglich ist, muss das Inkrement stets gut
auf etwaige Fehler getestet sein. Somit lässt sich die Qualitätssicherung als teilweise
unterstützt ansehen, da die Tests implizit im Scrum Vorgehen enthalten sind.
GA3 – Abstraktionsstufe
Wert: Rahmenwerk
Scrum ist kein traditionelles Vorgehensmodell, da es keine detaillierte Beschreibung
von einzelnen Aktivitäten enthält und sehr einfach und leicht verständlich gehalten ist.
Scrum bildet einen
Ordnungsrahmen
und regelt den groben Verlauf eines Projektes.
Am Anfang steht das Product Backlog. Dieses wird in 30 Tage dauernden Sprints
inkrementell umgesetzt. Außerdem gibt es ein täglich vorgeschriebenes Meeting, das
Daily Scrum. Die Aufgaben für jeden Sprint werden im Sprint Backlog festgehalten.
Dadurch ist Scrum recht allgemein gehalten und leicht verständlich.
GA4 – Detaillierungsgrad
Werte: nicht bewertbar, da kein Vorgehensmodell
79
5 Einordnung und Vergleich von Vorgehensmodellen
GA5 – Branchenfokus
Wert: allgemein
Scrum ist leicht verständlich und allgemein gehalten. Dadurch ist Scrum allgemein für
das Projektmanagement geeignet. Scrum kann dabei in den verschiedensten Domänen
eingesetzt werden, es ist vor allem jedoch in der Software- und Hardware-Entwicklung
weit verbreitet [
All13
]. Deswegen liegt bei Scrum auch kein spezieller Branchfokus vor
und das Modell wird als allgemein bewertet.
GA6 – Vorgehensweise
Wert: inkrementell
Die Basis von Scrum ist die inkrementelle Vorgehensweise. Ausgehend vom Product
Backlog werden die geforderten Funktionalitäten in mehreren Sprints, also inkrementel-
len Entwicklungszyklen, umgesetzt. Ein fertiggestellter Sprint bedeutet für das Produkt
dann ein Inkrement an Funktionalität.
GA7 – Prozesssteuerung
Wert: ergebnisorientiert
Bei Scrum wird das Produkt über einen oder mehrere Sprints entwickelt. Dabei stellt
ein fertiggestellter Sprint eine Evolution des Produkts dar. Den Prozess betreffende
Entscheidungen können am Ende eines Sprints basierend auf dem aktuellen Inkrement
im Sprint Review Meeting getroffen werden. Somit kann der nächste Sprint beeinflusst
werden.
80
5.3 Scrum
GA8 – Prozessergebnis
Werte: Produkt,Dienstleistung,Wissen
Bei Scrum steht das Ergebnis im Vordergrund und es wird das Ziel verfolgt, Produkte
mit hoher Qualität zu erstellen. Dazu wird das Team vom ScrumMaster während des
Sprints von äußeren Einflüssen beschützt, damit das Team produktiv bleiben kann.
Da Scrum ein allgemeines Rahmenwerk ist, lässt es die drei verschiedenen Prozes-
sergebnisse zu. So lässt sich Scrum z.B. in der Software Entwicklung einsetzen mit
Software als Ergebnis. Außerdem lässt sich Scrum z.B. im Finanzwesen einsetzen
[
All13
]. Das Prozessergebnis wäre in diesem Falle eine Dienstleistung. Wird Scrum in
Forschungsprojekten eingesetzt, so ist das Prozessergebnis Wissen [All13].
GA9 – Modellarchitektur
Wert: sukzessiv
Der Scrum-typische Ablauf vom Product Backlog zum fertigen Produkt kommt einer
sukzessiven Phasenanordnung sehr nahe. Allerdings existieren bei Scrum keine wirkli-
chen Projektphasen. Am Anfang eines Scrum Projektes werden die Anforderungen im
Product Backlog gesammelt und mit Prioritäten versehen. Anschließend wird der erste
Sprint im Sprint Planning Meeting geplant. Die Sprints, in denen das Product Backlog
dann umgesetzt wird, stellen den Hauptteil von Scrum dar. Da diese drei „Phasen“
nacheinander ablaufen, wird die Modellarchitektur als teilweise sukzessiv bewertet.
GA10 – Spezialisierbarkeit
Wert: domänenneutral
Scrum ist domänenneutral, da das Rahmenwerk sehr allgemein gehalten ist und es für
viele Arten von Projekten einsetzbar ist. Somit lässt sich Scrum in vielen Bereichen wie
z.B. Informationstechnologie oder Finanzwesen einsetzen. Wichtig dabei ist allerdings,
dass die vom Rahmenwerk vorgegebenen Regeln eingehalten werden. Ansonsten ist
eine Adaption an andere Domänen jederzeit möglich.
81
5 Einordnung und Vergleich von Vorgehensmodellen
GA11 – Modellkomplexität
Wert: niedrig
Die wichtigsten Prinzipien von Scrum sind die Leichtgewichtigkeit und die Einfachheit.
Durch die wenigen, aber wichtigen Regeln ist das Konzept von Scrum leicht verständlich.
Außerdem gibt es keine unnötige Komplexität durch viele verschiedene Rollen oder
viele zu erstellende Artefakte, da Scrum aus lediglich drei Rollen und zwei wichtigen
Artefakten besteht.
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.7: Allgemeine Aspekte von Scrum
82
5.3 Scrum
5.3.2 Wissensintensive Aspekte
In diesem Abschnitt werden die wissensintensiven Aspekte von Scrum untersucht. Die
Ergebnisse werden textuell beschrieben und in Abbildung 5.8 graphisch dargestellt.
KIA1 – Zuständigkeiten
Wert: Rollen vorgegeben
In Scrum sind genau drei Rollen vorgesehen. Dies sind der
Product Owner
,
ScrumMas-
ter und das Team. Diese drei Rollen teilen sich die Management-Verantwortlichkeiten.
Der Product Owner repräsentiert die Interessen der Stakeholder. Er ist dafür verant-
wortlich ein vollständiges Product Backlog anzulegen und die verschiedenen Punkte im
Product Backlog zu priorisieren. Außerdem ist er für die Budgetierung des Projektes
verantwortlich.
Das Team verwaltet und organisiert sich selbst. Es ist dafür verantwortlich, innerhalb
eines Sprints die ausgewählten Anforderungen aus dem Product Backlog umzusetzen
und ein Inkrement mit zusätzlicher Funktionalität zu erschaffen. Das Team ist maßgeblich
für den Projekterfolg verantwortlich.
Der ScrumMaster trägt die Verantwortung für den Scrum-Prozess. Er führt Schulungen
für die Beteiligten durch und fördert diese. Außerdem überwacht er die Einhaltung der
Scrum-Regeln und -Verfahren. Er ist für das Team eine begleitende Unterstützung, da
er versucht das Team während eines Sprints von äußeren Einflüssen zu beschützen.
KIA2 – Wissenstätigkeit
Wert: Wissensanwendung
Bei Scrum werden Probleme durch Anwenden von bekanntem Wissen bzw. Erfahrungen
der Wissensarbeiter gelöst. Dies kann auch durch gegenseitigen Austausch von Wissen
im Team erfolgen.
83
5 Einordnung und Vergleich von Vorgehensmodellen
KIA3 – Prozessdauer
Werte: mittel,lang
Scrum Projekte haben eine mittlere Prozessdauer, falls nur sehr wenig Funktionalität
gefordert wird. Somit kann dies innerhalb eines Sprints umgesetzt werden.
Normalerweise hat ein Scrum Projekt eine lange Prozessdauer, da meist mehrere
Sprints vorgesehen sind und das Produkt so stetig an Funktionalität hinzugewinnt.
KIA4 – Sichtenmodell
Wert: nein
Bei Scrum wird kein Sichtenmodell unterstützt.
KIA5 – Lebenszyklus Abdeckung
Wert: Gemeinsame Bearbeitungsphase
Die gemeinsame Bearbeitungsphase wird in Scrum durch Sprints abgedeckt. Allerdings
ist die gemeinsame Bearbeitungsphase nur teilweise unterstützt, da keine Zusammenarbeits-
Vorlagen existieren, die instanziiert werden können. Die Wissensarbeiter werden aller-
dings während der Bearbeitungsphase vom ScrumMaster unterstützt, da dieser alle
eventuell auftretende Hindernisse beseitigt.
KIA6 – Kommunikationsformen
Werte: tägliches Meeting,andere Vorgaben
Ein wichtiger Bestandteil von Scrum ist das tägliche Scrum Meeting, das sogenannte
Daily Scrum
. Beim Daily Scrum beantwortet jedes Teammitglied die folgenden drei
Fragen [Sch07]:
•Was habe ich seit dem letzten Daily Scrum gemacht ?
84
5.3 Scrum
•Was mache ich bis zum nächsten Daily Scrum ?
•Sind Hindernisse bei der Umsetzung aufgetreten ?
Des Weiteren gibt es noch mehr vorgeschriebene Meetings. Somit ist der Aspekt
andere
Vorgaben
ebenfalls erfüllt. Diese Meetings sind das
Sprint Planning Meeting
, das
Sprint
Review Meeting und das Sprint Retrospective Meeting.
Beim Sprint Planning Meeting wählen der Product Owner und das Team die umzuset-
zenden Punkte aus dem Product Backlog mit höchster Priorität aus. Außerdem wird bei
diesem Meeting der Sprint geplant und der Sprint Backlog angelegt.
Beim Sprint Review Meeting werden die Ergebnisse des Sprints dem Product Owner
präsentiert. Außerdem ist es bei diesem Meeting möglich neue Anforderungen zum
Product Backlog hinzuzufügen und die Anforderungen anders zu priorisieren.
Das Sprint Retrospective Meeting dient zur Diskussion, was im nächsten Sprint besser
gemacht werden kann. Das Meeting wird vom ScrumMaster abgehalten und dient der
stetigen Verbesserung des Entwicklungsprozesses.
KIA7 – Zielspezifikation
Werte: Gesamtziel,Meilensteine,eigene Ziele
Das Hauptziel von Scrum ist die schnelle und effiziente Entwicklung von qualitativ
hochwertigen Produkten. Somit ist das Gesamtziel von Scrum bereits vorgegeben.
Ein fertiggestellter Sprint entspricht in etwa einem Meilenstein. Da jedes Inkrement nach
einem Sprint auslieferbar sein soll und es stets an Funktionalität hinzugewinnt, stellt das
Inkrement jeweils einen eigenen Meilenstein dar.
Eigene Ziele sind nur teilweise unterstützt, da sich nur die Reihenfolge der Meilensteine
verändern lässt. Wählt das Team für einen Sprint Anforderungen aus, so plant es seinen
nächsten Sprint und somit auch den nächsten Meilenstein, da sie mit der Auswahl
der umzusetzenden Anforderungen festlegen, welche Funktionalitäten das nächste
Inkrement haben soll. Somit lassen sich die Meilensteine individualisieren.
85
5 Einordnung und Vergleich von Vorgehensmodellen
KIA8 – Qualitätssicherungsmaßnahmen
Wert: Tests,Prozessanalyse
Aufgrund der Tatsache, dass jedes Inkrement auslieferbar sein soll, muss sichergestellt
werden, dass das Inkrement den Anforderungen entspricht sowie qualitativ hochwertig
ist. Dies wird durch ausgiebige Tests sichergestellt. Diese Tests sind implizit im Sprint
gefordert.
Eine Prozessanalyse wird im Sprint Retrospective Meeting durchgeführt. Dabei wird
diskutiert, wie der Entwicklungsprozess im nächsten Sprint verbessert werden kann.
KIA9 – Wissensdokumentation
Wert: niedrig
Der Kernfokus von Scrum liegt in der Entwicklung von qualitativ hochwertigen Produkten.
Daher wird bei Scrum kaum eine Wissensdokumentation explizit gefordert, da es nur
zwei wichtige Artefakte gibt: Product Backlog und Sprint Backlog. Beide Dokumente
beinhalten nur Anforderungen, die während eines Sprints bzw. während des gesamten
Projektes umgesetzt werden sollen. Somit lässt sich die Wissensdokumentation als
niedrig einstufen.
KIA10 – Problemkomplexität
Werte: niedrig,mittel,hoch
Da Scrum ein sehr allgemeines Rahmenwerk ist, lässt es sich auch für alle Arten von
komplexen Projekten einsetzen. Somit sind auch sehr komplexe Projekte sehr gut mit
Scrum umsetzbar. Durch die inkrementelle Entwicklung in Form von Sprints wird die
Komplexität des Projektes eingeschränkt, da immer nur ein kleiner Teil des Produkts
entwickelt wird und dies inkrementell zum Gesamtprodukt weiterentwickelt wird.
86
5.3 Scrum
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.8: Wissensintensive Aspekte von Scrum
87
5 Einordnung und Vergleich von Vorgehensmodellen
5.4 VDI Richtlinie 2221
Die VDI Richtlinie 2221 (siehe Kapitel 4.4) wurde mithilfe der offiziellen Richtlinie [
VDI93
]
sowie einer Kurzübersicht [
Ins
] auf die festgelegten Vergleichsaspekte untersucht. Die
Ergebnisse sind nachfolgend textuell beschrieben und in den Abbildungen 5.9 und 5.10
dargestellt.
5.4.1 Allgemeine Aspekte
In diesem Abschnitt werden die allgemeinen Aspekte der VDI Richtlinie 2221 untersucht
und die Ergebnisse textuell und graphisch dargestellt (siehe Abbildung 5.9).
GA1 – Phasenabdeckung
Werte: Identifikation,Anforderungen,vorläufiges Design,detailliertes Design
In der Identifikationsphase der VDI Richtlinie 2221 werden die Anforderungen geklärt
bzw. präzisiert und es werden alle verfügbaren Informationen über das gewünschte
Produkt gesammelt und eventuell Informationslücken identifiziert. Das Phasenergebnis
ist die Anforderungsliste.
Die Anforderungsphase besteht aus der Ermittelung von Funktionen, die die gewünsch-
ten Anforderungen erfüllen. Dabei werden die Gesamtfunktion und zu erfüllende Teil-
funktionen identifiziert. Das Ergebnis sind eine oder mehrere Funktionsstrukturen.
Die Phase vorläufiges Design beschäftigt sich mit der Konkretisierung und Gestaltung
der maßgebenden Module des gewünschten Produkts. Hierfür werden erste grobe
Entwürfe in Form von maßstabsgetreuen Zeichnungen oder ähnlichen Plänen erstellt.
In der Phase detailliertes Design wird der Grobentwurf aus der vorherigen Phase
konkretisiert und durch die restlichen noch nicht bearbeiteten Gruppen und Elemente
ergänzt. Somit entsteht ein Gesamtentwurf.
Die verschiedenen Phasen der VDI Richtlinie 2221 sind in Abbildung 4.4 dargestellt.
88
5.4 VDI Richtlinie 2221
GA2 – Prozessabdeckung
Wert: Produktentwicklung
Die VDI Richtlinie 2221 unterstützt die Produktentwicklung durch eine Anforderungs-
analyse und den Designprozess. Die eigentliche Produktfertigung ist nicht im Modell
enthalten.
GA3 – Abstraktionsstufe
Wert: Vorgehensmodell
Die VDI Richtlinie 2221 entspricht einem Vorgehensmodell, da es verschiedene Aktivitä-
ten beschreibt, deren Ergebnisse vorgibt und sie in unterschiedliche Phasen gliedert.
Außerdem ist die Richtlinie sehr allgemein gehalten und ist deswegen an projektspezifi-
sche Gegebenheiten anpassbar.
GA4 – Detaillierungsgrad
Wert: universell
Die VDI Richtlinie 2221 entspricht einem universellen Vorgehensmodell, da die prinzipi-
ellen Schritte beschrieben sind und allgemeine Richtlinien vorgegeben werden.
GA5 – Branchenfokus
Wert: allgemein
Vorgänge und Aktivitäten werden sehr allgemein beschrieben. Dadurch ist die VDI
Richtlinie 2221 auf keine spezielle Branche limitiert. Daraus folgt eine Allgemeingültigkeit
in unterschiedlichen Branchen.
89
5 Einordnung und Vergleich von Vorgehensmodellen
GA6 – Vorgehensweise
Wert: inkrementell
Die Vorgehensweise der VDI Richtlinie 2221 ist ein inkrementelles Vorgehen, da es
möglich ist, zu vorangegangen Abschnitten zurückzugehen und somit eine schrittweise
Optimierung möglich ist.
GA7 – Prozesssteuerung
Wert: ergebnisorientiert
Die einzelnen Projektphasen liefern jeweils eigenständige Ergebnisse, wie z.B. die
Anforderungsliste oder die Funktionsstruktur. Basierend auf diesen Ergebnissen werden
Entscheidungen getroffen, ob die Phase wiederholt werden soll, um das Ergebnis zu
optimieren oder ob in die nächste Phase übergegangen werden soll.
GA8 – Prozessergebnis
Werte: Produkt,Wissen
Das Kernergebnis der VDI Richtlinie 2221 ist eine komplette Produktdokumentation, die
dann zur Fertigung des Produkts im späteren Verlauf verwendet wird. Eine Produktdoku-
mentation enthält wichtige Informationen über das Produkt.
GA9 – Modellarchitektur
Werte: sukzessiv,parallel
Eine parallele Arbeitsteilung ist bei der VDI Richtlinie 2221 möglich. Hierzu wird das
Problem bzw. die Aufgabenstellung in kleinere Teilprobleme bzw. Teilaufgaben geteilt.
Dadurch wird versucht die Komplexität des Problems zu beherrschen. Die sukzessive
Abfolge von Aktivitäten wird ebenfalls unterstützt und entspricht dem Standardvorgehen.
90
5.4 VDI Richtlinie 2221
GA10 – Spezialisierbarkeit
Wert: domänenneutral
Durch die allgemeingültige Beschreibung der VDI Richtlinie 2221 sind Anpassungen an
die unterschiedlichsten Domänen möglich. So kann die Richtlinie z.B. im Maschinenbau,
in der Verfahrenstechnik oder auch in der Softwareentwicklung eingesetzt werden.
GA11 – Modellkomplexität
Wert: niedrig
Die Richtlinie hat einen einfachen Ablauf mit wenigen Aktivitäten, die in verschiedene
Phasen mit unterschiedlichen Aufgaben getrennt sind. Somit wird die Modellkomplexität
als niedrig bewertet.
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.9: Allgemeine Aspekte der VDI Richtlinie 2221
91
5 Einordnung und Vergleich von Vorgehensmodellen
5.4.2 Wissensintensive Aspekte
In diesem Abschnitt werden die wissensintensiven Aspekte der VDI Richtlinie 2221
untersucht. Die Ergebnisse werden textuell beschrieben und in Abbildung 5.10 graphisch
dargestellt.
KIA1 – Zuständigkeiten
Wert: keine Rollen
Die VDI Richtlinie 2221 unterstützt kein dediziertes Rollenkonzept.
KIA2 – Wissenstätigkeit
Werte: Wissensanwendung,Wissenserzeugung
In der VDI Richtlinie wird Wissen zur Problemlösung während des Entwicklungs- und De-
signprozesses angewendet. Außerdem wird Wissen in Form der Produktdokumentation
erzeugt.
KIA3 – Prozessdauer
Wert: mittel,lang
Die Prozessdauer der VDI Richtlinie 2221 ist mittel bis lang, da verschiedene Phasen
evtl. mehrmals durchlaufen werden müssen [
VDI93
]. Außerdem gibt es zwei Phasen
speziell für den Designprozess. Zuerst wird ein Grobentwurf erstellt und danach ein
Feinentwurf, in dem alles berücksichtigt wird.
KIA4 – Sichtenmodell
Wert: nein
Die VDI Richtlinie 2221 unterstützt kein Sichtenmodell.
92
5.4 VDI Richtlinie 2221
KIA5 – Lebenszyklus Abdeckung
Wert: Gemeinsame Bearbeitungsphase
Die VDI Richtlinie sieht keinen Vorlagen-Entwurf vor. Deswegen existieren in der gemein-
samen Bearbeitungsphase keine Vorlagen, die instanziiert werden können. Allerdings
ist die gemeinsame Bearbeitungsphase teilweise unterstützt, da der Entwurfsprozess
als gemeinsamer Prozess mit mehreren Wissensarbeiter durchgeführt wird.
KIA6 – Kommunikationsformen
Wert: keine Vorgaben
Die VDI Richtlinie gibt keine Vorgaben über die Kommunikation.
KIA7 – Zielspezifikation
Wert: Gesamtziel,Meilensteine
Das Gesamtziel der Richtlinie ist eine wettbewerbsfähige Herstellung technischer Pro-
dukte. Meilensteine werden von der Richtlinie teilweise in Form der Ergebnisse der
einzelnen Phasen unterstützt. Diese entsprechen Meilensteinen während dem Entwick-
lungsprozess.
KIA8 – Qualitätssicherungsmaßnahmen
Wert: keine Qualitätssicherungsmaßnahmen im Modell enthalten
Tests und ähnliche Maßnahmen werden im späteren Projektverlauf durchgeführt. Dies
ist allerdings nicht Bestandteil der VDI Richtlinie 2221 selbst.
93
5 Einordnung und Vergleich von Vorgehensmodellen
KIA9 – Wissensdokumentation
Wert: mittel
Jede Phase der Richtlinie hat ein oder mehrere Artefakte als Ergebnis, wie z.B. die
Anforderungsliste, Funktionsstruktur, Vorentwürfe, Gesamtentwurf und eine komplette
Produktdokumentation.
KIA10 – Problemkomplexität
Wert: niedrig,mittel,hoch
Mit der VDI Richtlinie 2221 lassen sich auch Probleme mit hohem Komplexitätsgrad lösen.
Dies geschieht durch die Problemteilung in Teilprobleme und die Parallelisierung der
Aufgaben. Außerdem werden Probleme mit mittlerem und niedrigem Komplexitätsgrad
ebenfalls unterstützt.
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.10: Wissensintensive Aspekte der VDI Richtlinie 2221
94
5.5 AEP - Anforderungs-Engineering-Prozessmodell
5.5 AEP - Anforderungs-Engineering-Prozessmodell
Das Anforderungs-Engineering-Prozessmodell (siehe Kapitel 4.5) wurde mithilfe von
[
Gir10a
] und [
Gir10b
] auf die festgelegten Vergleichsaspekte untersucht. Die Ergebnisse
sind nachfolgend textuell beschrieben und in den Abbildungen 5.11 und 5.12 dargestellt.
5.5.1 Allgemeine Aspekte
In diesem Abschnitt werden die allgemeinen Aspekte des Anforderungs-Engineering-
Prozessmodells untersucht. Die Ergebnisse werden textuell und graphisch dargestellt
(sieh Abbildung 5.11).
GA1 – Phasenabdeckung
Werte: Identifikation,Konzept,Anforderungen,Betrieb
Die Identifikationsphase ist im AEP abgedeckt durch die AEP Phase
Zielentwicklungs-
prozess Kundenziele
. In dieser Phase werden die grundlegenden Projektziele definiert
und festgelegt.
Die Konzeptphase wird von der AEP Phase
Projektentwicklung
abgedeckt. In dieser
Phase werden erste Lösungsansätze durchdacht und wichtige Projektentscheidungen
getroffen.
Die Anforderungsphase wird von der AEP Phase
Vorplanung
abgedeckt. Hierbei werden
die bisherigen Anforderungen an das Projekt detaillierter beschrieben und erweitert.
Die Betriebsphase wird von der AEP Phase
Ausführungsphase/Objektüberwachung
abgedeckt. In dieser Phase werden die Anforderungen in einem anderen Projekt von
Auftragnehmern umgesetzt.
95
5 Einordnung und Vergleich von Vorgehensmodellen
GA2 – Prozessabdeckung
Werte: Produktentwicklung
,
Projektmanagement
,
Benchmarking
,
Qualitätssiche-
rung
Die Produktentwicklung wird vom AEP abgedeckt, da der Fokus des AEP auf der
Entwicklung von Anforderungen für Bauprojekte liegt.
Des Weiteren wird das Projektmanagement unterstützt, da AEP das Planungs-, Kosten-
steuerungs- und Ausführungsmanagement unterstützt.
Benchmarking wird ebenfalls vom AEP unterstützt, da Messgrößen, Key-Performance In-
dikatoren (KPI) genannt, zum Analysieren des Zielerreichungsgrads vorgegeben werden.
Werden die Ziele erfüllt, so wird in die nächste Phase übergegangen. Werden die Ziele
allerdings nicht erfüllt, so müssen Anpassungen an den Anforderungen vorgenommen
werden und ein neuer Durchlauf gestartet werden.
Qualitätssicherung wird teilweise durch die KPIs abgedeckt, da diese den Zielerrei-
chungsgrad darstellen und somit die Qualität der Entwicklung darstellen.
GA3 – Abstraktionsstufe
Wert: Vorgehensmodell
Das AEP ist ein Vorgehensmodell, da es eine umfassende Unterstützung für die Entwick-
lung von Anforderungen für Bauprojekte bereitstellt und den Ablauf für die Erhebung der
Anforderungen regelt. Außerdem gibt das AEP bestimmte Werkzeuge zur Unterstützung
vor (siehe Kapitel 4.5).
GA4 – Detaillierungsgrad
Wert: universell
Das AEP ist ein universelles Vorgehensmodell, da die prinzipiellen Schritte beschrieben
werden und allgemeine Richtlinien, wie z.B. die Überprüfung des Zielerreichungsgrads
mithilfe von KPIs, vorgegeben wird.
96
5.5 AEP - Anforderungs-Engineering-Prozessmodell
GA5 – Branchenfokus
Wert: speziell
Das AEP ist ein speziell für die Baubranche entwickeltes Vorgehensmodell.. Deswegen
wird der Branchenfokus mit speziell bewertet.
GA6 – Vorgehensweise
Wert: sequentiell
Im AEP folgen die inkludierten Phasen sukzessive aufeinander. Die Anforderungen
werden dabei in jeder Phase immer detaillierter entwickelt. Die Überprüfung des Zieler-
reichungsgrad entscheidet am Ende einer Phase, ob in die nächste Phase übergegangen
wird oder ob weitere Anpassungen an den Anforderungen notwendig sind.
GA7 – Prozesssteuerung
Wert: ergebnisorientiert
Die Prozesssteuerung erfolgt durch die Ergebnisse der jeweiligen Phase. Das Ergebnis
einer Phase sind dabei die Anforderungen, die entwickelt wurden. Der Zielerreichungs-
grad entscheidet dabei, ob in die nächste Phase übergegangen wird oder ob weitere
Anpassungen notwenig sind.
GA8 – Prozessergebnis
Wert: Produkt,Wissen
Das Prozessergebnis sind Anforderungen für die Realisierung eines Bauprojektes.
Anforderungen sind ein immaterielles Produkt mit enthaltenem Projektwissen.
97
5 Einordnung und Vergleich von Vorgehensmodellen
GA9 – Modellarchitektur
Wert: sukzessiv
Die Projektphasen des AEP folgen sukzessive aufeinander, da am Ende einer Phase
eine Überprüfungen des Zielerreichungsgrads notwendig ist, um in die nächste Phase
überzugehen. Somit sind keine parallelen Phasen möglich.
GA10 – Spezialisierbarkeit
Wert: domänenspezifisch
Das AEP ist ein speziell für die Bauindustrie entwickeltes Vorgehensmodell. Dabei
berücksichtigt es die speziellen Bedürfnisse der Bauindustrie, indem es z.B. die wichtigs-
ten Anforderungsdimensionen vorgibt. Dadurch ist das AEP ein domänenspezifisches
Vorgehensmodell.
GA11 – Modellkomplexität
Wert: mittel
Das AEP ist von mittlerer Komplexität, da für die Überprüfung des Zielerreichungsgrads
höhere Mathematik notwendig ist. Des Weiteren sind viele verschiedene Anforderungsdi-
mensionen vorgegeben, für die Anforderungen erhoben werden müssen. Dadurch sind
viele Tätigkeiten, die ausgeführt werden müssen, vorgegeben.
98
5.5 AEP - Anforderungs-Engineering-Prozessmodell
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.11: Allgemeine Aspekte von AEP
99
5 Einordnung und Vergleich von Vorgehensmodellen
5.5.2 Wissensintensive Aspekte
In diesem Abschnitt werden die wissensintensiven Aspekte des Anforderungs-Engineering-
Prozessmodells analysiert. Die Ergebnisse werden textuell und graphisch in Abbil-
dung 5.12 dargestellt.
KIA1 – Zuständigkeiten
Wert: keine Rollen
Das AEP gibt keine Rollen vor.
KIA2 – Wissenstätigkeit
Wert: Wissensanwendung,Wissenserzeugung
Im AEP werden Bauprojekte durch den Einsatz von Wissen und Erfahrung geplant.
Außerdem wird viel Wissen in Form von Anforderungen an das Bauprojekt erzeugt. Die
Wissenstätigkeiten sind also Wissensanwendung und Wissenserzeugung.
KIA3 – Prozessdauer
Wert: lang
Die Prozessdauer von AEP ist sehr lang, da für Bauprojekte eine sehr lange Planung
nötig ist [
GB03
]. Viele Einzelheiten müssen geplant und berücksichtigt werden und
Bauprojekte besitzen eine sehr hohe Komplexität.
KIA4 – Sichtenmodell
Wert: nein
Das AEP unterstützt keine verschiedene Sichten.
100
5.5 AEP - Anforderungs-Engineering-Prozessmodell
KIA5 – Lebenszyklus Abdeckung
Wert: Orientierung,Gemeinsame Bearbeitungsphase
In der Orientierungsphase werden die Ziele jeder Phase festgelegt. Die Phasenziele
werden dabei abhängig von den zu bearbeitenden Anforderungsdimensionen gewählt.
Die festgelegten Ziele werden durch einen gewichteten Zielvektor dargestellt.
In der gemeinsamen Bearbeitungsphase werden die Anforderungen abhängig von den
festgelegten Phasenziele erhoben. Am Ende einer Phase wird der Zielerreichungsgrad
mithilfe des gewichteten Zielvektors untersucht. Allerdings ist die gemeinsame Bearbei-
tungsphase nur teilweise unterstützt, da keine Zusammenarbeits-Vorlagen existieren,
die in der Bearbeitungsphase zur Unterstützung der Wissensarbeiter instanziiert werden
können.
KIA6 – Kommunikationsformen
Wert: keine Vorgaben
Das AEP legt keine Vorgaben für die Kommunikation fest.
KIA7 – Zielspezifikation
Wert: Gesamtziel,Meilensteine
Beim AEP wird das Gesamtziel vorgegeben. Dies ist die vollständige Abdeckung des
Zielerreichungsgrads, der sich aus allen Projektzielen zusammensetzt. Dies sind z.B.
Rendite-/Finanzziele, Leistungs- & Nutzungsziele, Standortziele, Termin- & Qualitätsziele
und Imageziele.
Meilensteine werden vom AEP ebenfalls unterstützt, da nach jeder Projektphase der
aktuelle Zielerreichungsgrad untersucht wird und ob alle Anforderungen umgesetzt
wurden. Dies entspricht einem Meilenstein.
101
5 Einordnung und Vergleich von Vorgehensmodellen
KIA8 – Qualitätssicherungsmaßnahmen
Wert: Ergebnisauswertung
Am Ende jeder Phase wird beim AEP eine Kontrolle des Zielerreichungsgrads mithilfe
von KPIs durchgeführt. Damit wird die Qualität des Produkts sowie die Prozessqualität
verbessert.
KIA9 – Wissensdokumentation
Wert: mittel
Beim AEP werden in jeder Projektphase spezifische Anforderungsspezifikationen entwi-
ckelt. Außerdem müssen die Ziele und die externen Bedingungen dokumentiert werden.
Dies entspricht einem mittleren Dokumentationsaufwand.
KIA10 – Problemkomplexität
Wert: mittel,hoch
Da das AEP für Bauprojekte ausgelegt ist und diese einen sehr hohen Komplexitätsgrad
besitzen (aufgrund vieler Abhängigkeiten und vieler Außeneinflüssen), ist AEP für Pro-
bleme mit hoher Komplexität einsetzbar, da das Problem in mehreren Phasen vereinfacht
wird. Des Weiteren kann das AEP auch für Probleme mit mittlerer Komplexität eingesetzt
werden. Dies würde z.B. dem Bau eines Standard-Einfamilienhauses entsprechen.
102
5.5 AEP - Anforderungs-Engineering-Prozessmodell
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.12: Wissensintensive Aspekte von AEP
103
5 Einordnung und Vergleich von Vorgehensmodellen
5.6 Klinische Pfade
Die klinischen Pfade (siehe Kapitel 4.6) wurden mithilfe von [
KBT06
], [
PKR+07
], [
RK07
],
sowie [
RVU+09
] auf die festgelegten Vergleichsaspekte untersucht. Die Ergebnisse sind
nachfolgend textuell beschrieben und in den Abbildungen 5.13 und 5.14 dargestellt.
5.6.1 Allgemeine Aspekte
In diesem Abschnitt werden die allgemeinen Aspekte der klinischen Pfade analysiert.
Die Ergebnisse werden textuell und graphisch in Abbildung 5.13 dargestellt.
GA1 – Phasenabdeckung
Werte: Konzept
,
Entwicklung
,
Abbau
,
Anforderungen
,
vorläufiges Design
,
detaillier-
tes Design
Die Phase
Konzept
wird bei klinischen Pfaden durch die
Aufnahme
des Patienten
abgedeckt. Hierbei werden bereits die ersten Untersuchungen durchgeführt, die dann
zu einer Diagnose beitragen.
Die Phasen
Anforderungen
,
vorläufiges Design
und
detailliertes Design
sind bei kli-
nischen Pfaden durch den Abschnitt
Diagnose
teilweise abgedeckt. In der Diagnose
wird, aufbauend auf Untersuchungen, der weiterführende Weg auf dem klinischen Pfad
festgelegt.
Die Phase
Entwicklung
entspricht der
Therapie
bei klinischen Pfaden. Bei der Therapie
werden Maßnahmen durchgeführt, die zur Heilung des Patienten beitragen.
Mit der
Entlassung
des (geheilten) Patienten wird auch die Phase
Abbau
von klinischen
Pfaden unterstützt.
104
5.6 Klinische Pfade
GA2 – Prozessabdeckung
Werte: Produktentwicklung
Bei klinischen Pfaden versteht man unter der Produktentwicklung die Heilung des Patien-
ten. Das Ergebnis eines klinischen Pfades ist typischerweise ein gesunder Patient. Das
Ergebnis wird dabei im Verlauf des klinischen Pfades durch verschiedene Behandlungen
entwickelt. Dadurch ist die Produktentwicklung bei klinischen Pfaden abgedeckt.
GA3 – Abstraktionsstufe
Wert: Vorgehensmodell,Rahmenwerk
Klinische Pfade regeln den Ablauf einer standardisierten Behandlung für Patienten
mit der gleichen Krankheit. Bei unerwarteten Behandlungsergebnissen oder einer sich
ändernden Diagnose kann auch vom klinischen Pfad abgewichen werden. Somit stellt
das Prinzip klinischer Pfade einen Ordnungsrahmen für verschiedene Behandlungsmög-
lichkeiten dar. Ein konkreter klinischer Pfad dagegen ist ein Vorgehensmodell für die
Behandlung einer bestimmten Krankheit.
GA4 – Detaillierungsgrad
Wert: weltlich
Ein konkreter klinischer Pfad stellt ein weltliches Vorgehensmodell dar, da der klini-
sche Pfad die Abfolge der durchzuführenden Aktivitäten festlegt. Des Weiteren werden
Voraussetzungen für die Durchführung von Behandlungsmaßnahmen festgelegt.
GA5 – Branchenfokus
Wert: speziell
Klinische Pfade haben einen speziellen Branchenfokus, da sie an die Medizin ausgerich-
tet sind.
105
5 Einordnung und Vergleich von Vorgehensmodellen
GA6 – Vorgehensweise
Wert: sequentiell
Klinische Pfade haben eine sequentielle Prozessvorgehensweise, da die Schritte nach-
einander abgearbeitet werden. Dies Entspricht einem Arbeitsplan. Verändert sich al-
lerdings die Diagnose, so muss der Verlauf des klinischen Pfades geändert werden.
Dadurch wird die Behandlung ebenfalls verändert. Weichen die Behandlungsergebnisse
stark von den erwarteten Ergebnissen des klinischen Pfades ab, so kann der Pfad
verlassen werden und eine individuelle Behandlung erfolgen.
GA7 – Prozesssteuerung
Wert: ergebnisorientiert
Die Steuerung des Pfadverlaufs basiert auf Ergebnissen von Untersuchungen, Tests,
Labor, etc. Je nach Ergebnis wird ein anderer Verlauf des Pfades gewählt, Schritte wie-
derholt oder der Pfad komplett verlassen. Somit sind klinische Pfade ergebnisorientiert.
GA8 – Prozessergebnis
Wert: Dienstleistung
Das Ziel klinischer Pfade ist die Heilung von Patienten von Krankheiten. Somit sind klini-
sche Pfade eine Dienstleistung, die von den verschiedenen beteiligten Rollen erbracht
wird.
GA9 – Modellarchitektur
Werte: parallel,sukzessiv
Bei klinischen Pfaden sind beide Formen der Modellarchitektur möglich. Eine sukzessive
Abfolge der Aktivitäten ist nötig, wenn mehrere Untersuchungen am Patienten durchge-
führt werden. Diese können nur in Anwesenheit des Patienten durchgeführt werden. Eine
106
5.6 Klinische Pfade
parallele Abfolge der Aktivitäten ist möglich, wenn z.B. im Labor der Bluttest ausgewertet
wird und der Patient sich währenddessen in einer weitere Untersuchung befindet.
GA10 – Spezialisierbarkeit
Wert: domänenspezifisch
Klinische Pfade sind speziell an die Domäne Medizin angepasst, da sie einen Ablauf-
plan für die Behandlung von Patienten darstellen. In klinischen Pfaden ist sehr viel
Domänenwissen enthalten, da viele klinischen Pfade für unterschiedliche Probleme
existieren. Die Erstellung eines klinischen Pfades verläuft typischerweise von Klinik zu
Klinik unterschiedlich, da ein klinischer Pfad den im Behandlungsteam selbst gefunden
Konsens bezüglich der besten Gesamtbehandlung darstellt [RK07].
GA11 – Modellkomplexität
Wert: niedrig
Die Modellkomplexität von klinischen Pfaden ist niedrig, da durch den vorgegebenen
Ablauf gute Einarbeitungsmöglichkeiten für neue Mitarbeiter bestehen [
KWEG+07
].
Somit können sich diese mit dem Ablauf vertraut machen.
107
5 Einordnung und Vergleich von Vorgehensmodellen
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenspezifisch
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.13: Allgemeine Aspekte von klinischen Pfaden
108
5.6 Klinische Pfade
5.6.2 Wissensintensive Aspekte
In diesem Abschnitt werden die wissensintensiven Aspekte der klinischen Pfade unter-
sucht und die Ergebnisse textuell und graphisch dargestellt (siehe Abbildung 5.14).
KIA1 – Zuständigkeiten
Wert: Rollen vorgegeben
Klinische Pfade geben verschiedene Rollen für unterschiedliche Berufsgruppen wie
z.B. Arzt, Pflege, Anästhesie, Operateur vor. Zusätzlich werden Aufgaben für die ver-
schiedenen Rollen vordefiniert. Dabei sind bestimmte Rollen für die Durchführung von
Aktivitäten verantwortlich.
KIA2 – Wissenstätigkeit
Wert: Wissensanwendung,Wissenssuche
In klinischen Pfaden setzen die verschiedenen Rollen ihr Wissen und ihre Erfahrung ein,
um Symptome zu erkennen und eine entsprechende Diagnose zu erstellen. Zusätzlich
wird das Wissen und die Erfahrung verwendet, um die Patienten gemäß dem klinischen
Pfad zu behandeln und zu heilen. Zusätzlich zur Anwendung des vorhandenen Wissens
wird eine Wissenssuche nach der richtigen Diagnose bei klinischen Pfaden durchgeführt.
Dies kann z.B. durch eine Literaturrecherche oder das Studium von Leitlinien erfolgen
[RK07].
KIA3 – Prozessdauer
Wert: kurz
Die Prozessdauer klinischer Pfade beträgt meist nur wenige Tage. Dies ist jedoch
abhängig von der Krankheit und deren Komplexität [
KWEG+07
]. Durch klinische Pfade
wird vor allem eine Verweildauerverkürzung erreicht, d.h. die Behandlung der Patienten
erfolgt effizienter und die Patienten verbringen weniger Zeit im Krankenhaus.
109
5 Einordnung und Vergleich von Vorgehensmodellen
KIA4 – Sichtenmodell
Wert: ja
Zur besseren Patienteninformation stellen klinische Pfade im Idealfall Informationsblätter
bereit [
KBT06
]. Diese beschreiben den Verhandlungsablauf und liefern Informationen
über ihre Krankheit. Dies entspricht einer teilweisen Sicht auf den klinischen Pfad.
Deswegen ist das Sichtenmodell als teilweise abgedeckt bewertet.
KIA5 – Lebenszyklus Abdeckung
Werte: Vorlagen-Entwurf
,
gemeinsamen Bearbeitungsphase
,
Auswertung der Da-
tensätze
Bei der Einführung klinischer Pfade können Dokumentationsvorlagen erstellen werden,
d.h. dies entspricht der Phase Vorlagen-Entwurf. Außerdem werden Zuständigkeiten
zugewiesen und es können Checklisten erstellt werden [KBT06].
In der gemeinsamen Bearbeitungsphase wird der klinische Pfad ausgeführt und die
einzelnen Schritte mithilfe der zuvor erstellten Dokumentationsvorlage dokumentiert.
In der Phase Auswertung der Datensätze können bei vielen Abweichungen vom klini-
schen Pfad Änderungen am klinischen Pfad vorgenommen werden und neue Dokumen-
tationsvorlagen erstellt werden [KBT06].
KIA6 – Kommunikationsformen
Wert: keine Vorgaben
Klinische Pfade legen keine Meetings oder weitere Kommunikationsformen a priori fest.
Die Kommunikation während eines klinischen Pfades ist damit nicht explizit im Modell
enthalten.
110
5.6 Klinische Pfade
KIA7 – Zielspezifikation
Werte: Gesamtziel,Meilensteine
Klinische Pfade legen die Gesamtziele des klinischen Pfades fest. Dies sind die Heilung
des Patienten (Gesamtbehandlungsergebnis), die Reduzierung der Kosten und die
Erhöhung der Behandlungsqualität [KBT06].
Meilensteine stellen ein Teilbehandlungsergebnis dar. Dies dient zur Überprüfung, ob
die Maßnahmen wirksam sind, um das angestrebte Ergebnis zu erreichen.
KIA8 – Qualitätssicherungsmaßnahmen
Werte: Tests,Prozessanalyse,Ergebnisauswertung
Tests bei klinischen Pfaden entsprechen Untersuchungen bei Patienten, die Aufschluss
über die Effektivität der verwendeten Behandlungsmaßnahmen liefern.
Im Benchmarking wird untersucht, welche Auswirkungen der klinische Pfad auf die Be-
handlungsqualität hat. So werden verschiedene Größen gemessen und ausgewertet, wie
z.B. die Verweildauer oder die Personalkosten [
KBT06
]. Basierend auf diesen Erkennt-
nissen kann dann der Prozess verbessert werden, was letzlich einer Prozessanalyse
entspricht [KBT06].
Bei der Ergebnisauswertung wird untersucht, ob sich Unterschiede zum gewünschten
Behandlungsergebnis feststellen lassen. Ist dies der Fall, so müssen die Zielvorgaben
geändert werden oder andere Maßnahmen, wie z.B. das Verlassen des klinischen
Pfades und eine individuelle Behandlung des Patienten erfolgen.
KIA9 – Wissensdokumentation
Wert: mittel
Die Wissensdokumentation von klinischen Pfaden wird als mittel eingestuft, da jeder
Behandlungsschritt in einem ganzheitlichen Dokument festgehalten wird [
Opi04
]. Die-
111
5 Einordnung und Vergleich von Vorgehensmodellen
ses Dokument ist für jede Rolle einsehbar. Dadurch wird ein Ergebnisaustausch und
Wissenstransfer zwischen den verschiedenen Rollen gefördert.
KIA10 – Problemkomplexität
Werte: niedrig,mittel
Klinische Pfade werden bevorzugt bei Problemen eingesetzt, die sich standardisieren
lassen. Dies ist jedoch meist nur bei Problemen mit niedriger oder mittlerer Komplexität
möglich. So wäre z.B. eine häufig auftretende, behandelbare Krebserkrankung ein
Problem mit mittlerer Komplexität, für dessen Behandlung ein klinischer Pfad denkbar
wäre.
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.14: Wissensintensive Aspekte von klinischen Pfaden
112
5.7 Guide to the Project Management Body of Knowledge
5.7 Guide to the Project Management Body of Knowledge
Zur Untersuchung des Guide to the Project Management Body of Knowledge (PMBOK
Guide, siehe Kapitel 4.7) wurde die zweite Version aus dem Jahr 2000 [
Pro00
] verwendet.
Die Ergebnisse sind nachfolgend beschrieben und in den Abbildungen 5.15 und 5.16
dargestellt.
5.7.1 Allgemeine Aspekte
In diesem Abschnitt werden die allgemeinen Aspekte des PMBOK Guides untersucht.
Die Ergebnisse werden textuell beschrieben und in Abbildung 5.15 graphisch dargestellt.
GA1 – Phasenabdeckung
Werte: Identifikation,Konzept,Entwicklung,Abbau
Beim PMBOK Guide werden die verschiedenen Prozesse für das Projektmanagement
in fünf Prozessgruppen eingeteilt. Dies sind
Initiierung, Planung, Ausführung, Überwa-
chung & Steuerung und Abschluss.
Die Prozessgruppe Initiierung entspricht der Projektphase Identifikation. In dieser Phase
wird das Projekt formal autorisiert. Ergebnisse der Phase sind der Projektauftrag und
eine vorläufige Beschreibung des Projektumfangs.
Die Prozessgruppe Planung entspricht der Projektphase Konzept. Hier wird der Projekt-
umfang festgelegt und die Planung durchgeführt. Ergebnisse der Projektplanung sind
z.B. der Projektstrukturplan, Terminplan, Kostenplan und der Risikoplan.
Die beiden Prozessgruppen Durchführung und Überwachung & Steuerung fallen zu
einer großen Projektphase zusammen. Diese Projektphase ist die Entwicklungsphase.
In dieser Phase wird sichergestellt, dass die Prozesse wie geplant ausgeführt werden.
Außerdem werden Informationen zur Projekt-Leistung gesammelt und bewertet und eine
Risikoüberwachung findet statt.
113
5 Einordnung und Vergleich von Vorgehensmodellen
GA2 – Prozessabdeckung
Werte: Projektmanagement
,
Qualitätssicherung
,
Benchmarking
,
Wissensmana-
gement
Der PMBOK Guide beschreibt die Tätigkeiten Projektmanagement, Benchmarking,
Qualitätssicherung und Wissensmanagement.
Der Kernfokus des PMBOK Guides liegt auf dem Projektmanagement. Die verschiede-
nen Aspekte des Projektmanagements werden im PMBOK Guide beschrieben, wie z.B.
Kostenmanagement, Personalmanagement und Risikomanagement.
Zusätzlich wird die Qualitätssicherung beschrieben, die dafür zuständig ist, dass die
Produkte ohne Fehler ausgeliefert werden. Die Qualitätssicherung besteht beim PMBOK
Guide aus drei Prozessen:
Qualitätsplanung
,
Qualitätssicherheit
und
Qualitätsüberwa-
chung
. In der Qualitätsplanung werden Qualitätsstandards festgelegt, die eingehalten
werden müssen. Die Qualitätskontrolle beschreibt die geplanten Qualitätssicherungs-
maßnahmen. Die Qualitätsüberwachung überwacht das Projekt und die Einhaltung
der festgelegten Qualitätsstandards. Je mehr Qualitätssicherung betrieben wird, desto
wahrscheinlicher ist es, dass das Produkt keine bzw. nur sehr wenige Fehler enthält.
Wichtig ist es hier eine gute Balance zwischen Aufwand und der Produktqualität zu
finden.
Des Weiteren wird das Benchmarking beschrieben. Das Benchmarking wird beim
PMBOK
Guide durch Leistungsberichte durchgeführt. Dabei werden Informationen
über den Projektfortschritt gesammelt, wie z.B. den aktuellen Status oder den Fortschritt
des Projekts.
Das Wissensmanagement wird im PMBOK Guide ebenfalls unterstützt. Informationen
aus abgeschlossenen Projekten sowie die daraus gewonnenen Erfahrungen werden
in einer Wissensdatenbank abgespeichert. Diese Informationen stehen den Wissens-
arbeitern für neue Projekte zur Verfügung, damit die bereits gewonnenen Erfahrungen in
neue Projekte miteinfließen können.
114
5.7 Guide to the Project Management Body of Knowledge
GA3 – Abstraktionsstufe
Wert: Vorgehensmodell
Beim PMBOK Guide handelt es sich um ein Vorgehensmodell für das Management von
Projekten. Der Ablauf des Projektes wird vom PMBOK Guide geregelt und die einzelnen
Aufgaben sind detailliert beschrieben. Außerdem werden für jede Aufgabe passende
Werkzeuge oder Methoden beschrieben und erklärt.
GA4 – Detaillierungsgrad
Wert: weltlich
Der PMBOK Guide beschreibt die einzelnen Prozesse detailliert und benennt diese.
Außerdem werden für die Durchführung der einzelnen Prozesse passende Werkzeuge
oder Methoden beschrieben. Es gibt allerdings keine genauen Bedingungen für die
Abfolge der Prozesse.
GA5 – Branchenfokus
Wert: allgemein
Der PMBOK Guide beschreibt allgemeines Projektmanagement, das in dieser Form in
jeder Branche einsetzbar ist.
GA6 – Vorgehensweise
Wert: sequentiell
Die Phasen des PMBOK Guides werden nacheinander abgearbeitet. Dies entspricht
einem sequentiellen Vorgehen.
115
5 Einordnung und Vergleich von Vorgehensmodellen
GA7 – Prozesssteuerung
Wert: ergebnisorientiert
Der PMBOK Guide ist ergebnisorientiert, da jede Projektphase von der Fertigstellung
eines Ergebnisses charakterisiert wird. Anhand dieser Ergebnisse wird der Projektfort-
schritt validiert und entschieden, ob die aktuelle Phase abgeschlossen ist und in die
nächste Phase übergegangen werden soll, oder ob die Ergebnisse nochmals überarbei-
tet werden müssen.
GA8 – Prozessergebnis
Werte: Produkt,Wissen
Im Laufe des Projektmanagements wird viel Wissen in Form von Artefakten, z.B. Doku-
mente, produziert. Somit hat der PMBOK Guide das Prozessergebnis Wissen.
Andererseits wird das Projektmanagement meist im Kontext eines Produktentwicklungs-
projektes eingesetzt. Somit hat der PMBOK Guide Produkte als zweites Ergebnis.
GA9 – Modellarchitektur
Werte: sukzessiv,parallel
Beim PMBOK Guide sind die Modellarchitekturen parallel und sukzessiv möglich. Eine
sukzessive Abfolge der Projektphasen entspricht dem typischen Vorgehen in den meisten
Projekten.
Allerdings ist eine parallele Abfolge der Phasen möglich, z.B. beim
fast tracking5
. Hierbei
werden Tätigkeiten parallel ausgeführt, die normalerweise nacheinander ausgeführt
werden. Dadurch wird die Projektdauer verkürzt.
5dt. Schnellverfahren
116
5.7 Guide to the Project Management Body of Knowledge
GA10 – Spezialisierbarkeit
Wert: domänenneutral
Der PMBOK Guide beschreibt das Projektmanagement in einer allgemeinen Art und
Weise. Dadurch dass der PMBOK Guide ein Standardwerk für das Projektmanagement
darstellt [
SS13b
], ist es in unterschiedlichen Domänen einsetzbar. Somit ist der PMBOK
Guide domänenneutral.
GA11 – Modellkomplexität
Wert: mittel
Im PMBOK Guide werden viele verschiedene Prozesse beschrieben und es gibt viele zu
erstellende Artefakte für die Wissensdokumentation. Basierend auf der großen Anzahl
an Aufgaben und Artefakten wird die Komplexität als mittel eingestuft.
domänenspezifisch
Allgemeine Aspekte
Phasenabdeckung
Identifikation
Konzept
Anforderungen
vorläufiges Design
detailliertes Design
Entwicklung
Betrieb
Abbau
Produktentwicklung
Projektmanagement
Qualitätssicherung
Benchmarking
Wissensmanagement
Abstraktionsstufe
Methodensammlung
Rahmenwerk
Vorgehensmodell
Detaillierungsgrad
universell
weltlich
atomar
Prozesssteuerung
aktivitätsorientiert
ergebnisorientiert
situationsorientiert
Branchenfokus
speziell
allgemein
Vorgehensweise
evolutionär
inkrementell
sequentiell
Prozessergebnis
Produkt
Dienstleistung
Wissen
Modellarchitektur
parallel
sukzessiv
Spezialisierbarkeit
domänenneutral
Modellkomplexität
niedrig
mittel
hoch
Prozessabdeckung
Abbildung 5.15: Allgemeine Aspekte des PMBOK Guides
117
5 Einordnung und Vergleich von Vorgehensmodellen
5.7.2 Wissensintensive Aspekte
In diesem Abschnitt werden die wissensintensiven Aspekte des PMBOK Guides unter-
sucht. Die Ergebnisse werden textuell beschrieben und in Abbildung 5.16 graphisch
dargestellt.
KIA1 - Zuständigkeiten
Wert: Rollen festlegbar
Vom PMBOK Guide werden keine Rollen vorgegeben, allerdings lassen sich Rollen
projektspezifisch im Personalmanagement festlegen und an entsprechende Personen
zuweisen.
KIA2 – Wissenstätigkeit
Wert: Wissensanwendung,Wissenserzeugung
Die Mitarbeiter wenden ihr Wissen zum Lösen von komplexen Problemen an, z.B. beim
Personal- oder Risikomanagement.
Außerdem wird im Laufe des PMBOK Guides explizites Wissen in Form von Artefakten
erzeugt.
KIA3 – Prozessdauer
Wert: mittel,lang,kurz
Beim PMBOK Guide gibt es keine speziellen Vorgaben über die Prozessdauer. Dies ist
abhängig vom Einsatzgebiet. Grundsätzlich lässt sich das Modell für jede Prozessdauer
einsetzen. Eine kurze Prozessdauer ist allerdings nur teilweise geeignet, da ein großer
Mehraufwand, z.B. in Form von Planungsmaßnahmen durch den PMBOK Guide entsteht.
118
5.7 Guide to the Project Management Body of Knowledge
KIA4 – Sichtenmodell
Wert: ja
Der PMBOK Guide ist unterteilt in die 12 verschiedenen Wissensgebiete. Jeder Prozess
ist dabei einem Wissensgebiet zugeordnet und im Kapitel zum zugehörigen Wissens-
gebiet ausführlich beschrieben. Für jedes Wissensgebiet können die wichtigsten Infor-
mationen in den einzelnen Kapiteln nachgelesen werden. Somit wird das Sichtenmodell
als teilweise unterstützt bewertet.
KIA5 – Lebenszyklus Abdeckung
Wert: Orientierung,Vorlagen-Entwurf,gemeinsame Bearbeitungsphase
Die Orientierungsphase entspricht der Initiierungsphase des Projektes, in der das Projekt
formal autorisiert wird und Informationen über das Projekt gesammelt werden.
In der Phase Vorlagen-Entwurf werden verschiedene Vorlagen (CTs) erstellt, z.B. für
die Qualitätssicherung, das Risikomanagement oder für den Projektstrukturplan. Die
Vorlagen werden dabei in Form von Artefakten, wie z.B. Dokumenten erstellt. Die Phase
Vorlagen-Entwurf entspricht der Projektphase Konzept.
In der gemeinsame Bearbeitungsphase werden die Vorlagen dann verwendet, um die
jeweiligen Aktivitäten zu vereinfachen. Artefakte, wie der Projektstrukturplan, verändern
sich von Projekt zu Projekt. Allerdings können allgemeine Vorlagen verwendet werden,
die projektspezifisch angepasst werden.
KIA6 – Kommunikationsformen
Wert: keine Vorgaben
Der PMBOK Guide definiert keine Vorgaben, wie die Kommunikation ablaufen soll. Dies
wird allerdings im Kommunikationsmanagements (siehe Kapitel 4.7) festgelegt.
119
5 Einordnung und Vergleich von Vorgehensmodellen
KIA7 – Zielspezifikation
Wert: Gesamtziel,Meilensteine
Das Gesamtziel des PMBOK Guides ist die Fertigstellung aller Meilensteine und das
erfolgreiche Abschließen des Projektes. Damit werden Meilensteine vom PMBOK Guide
ebenfalls unterstützt. Diese werden in der Planungsphase festgelegt.
KIA8 – Qualitätssicherungsmaßnahmen
Weret: Tests,Prozessanalyse,Ergebnisauswertung
Tests bzw. Experimente dienen zur Kontrolle, ob die Anforderungen erfüllt wurden. Dies
wird vom PMBOK Guide im Zuge der Qualitätssicherung unterstützt.
Die Prozessanalyse wird mithilfe des Benchmarkings unterstützt, da Kenngrößen über
den Prozess erfasst werden. Anhand der Kenngrößen kann die Prozessqualität beurteilt
werden.
Die Ergebnisauswertung wird durch das Wissensmanagements unterstützt. Dabei wer-
den Erfahrungen und Informationen aus abgeschlossenen Projekten in einer Wissens-
datenbank gespeichert, um sie neuen Projekten zur Verfügung stellen zu können.
KIA9 – Wissensdokumentation
Wert: hoch
Aufgrund der vielen unterschiedlichen Prozesse und den vielen unterschiedlichen Arte-
fakten ist beim PMBOK Guide ein hoher Dokumentationsaufwand vorhanden.
KIA10 – Problemkomplexität
Werte: niedrig,mittel,hoch
Da der PMBOK Guide ein allgemeines Projektmanagement beschreibt, kann dieses für
jede Problemkomplexität eingesetzt werden. Das Modell ist auch für Probleme mit hoher
120
5.7 Guide to the Project Management Body of Knowledge
Komplexität geeignet, da es Tätigkeiten wie Qualitätssicherung und Risikomanagement
vorsieht.
Wissensintensive Aspekte
Wissensdokumentation
Sichtenmodell
Prozessdauer
QS-Maßnahmen
Zuständigkeiten Wissenstätigkeit
Problemkomplexität
Zielspezifikation
Kommunikationsformen
Lebenszyklus Abdeckung
Rollen vorgegeben
Rollen festlegbar
keine Rollen
Wissensanwendung
Wissenserzeugung
Wissenssuche
kurz
mittel
lang
ja
nein
Orientierung
Vorlagen-Entwurf
gemeinsame Bearbeitungszeit
Auswertung der Datensätze
tägliches Meeting
wöchentliches Meeting
andere Vorgaben
keine Vorgaben
keine Zielvorgaben
eigene Ziele
Meilensteine
Gesamtziel
Tests
Prozessanalyse
Ergebnisauswertung
niedrig
mittel
hoch
niedrig
mittel
hoch
Abbildung 5.16: Wissensintensive Aspekte des PMBOK Guides
121
5 Einordnung und Vergleich von Vorgehensmodellen
5.8 Vergleich der Vorgehensmodelle
GA1 – Phasenabdeckung
Jedes Vorgehensmodell, außer der PMBOK Guide, hat eine Phase, in der Anforde-
rungen definiert werden. Dabei ist auffällig, dass jedes Vorgehensmodell, das in der
Produktentwicklung eingesetzt wird, Anforderungen definiert. Bei klinischen Pfaden
entspricht die Anforderungs- und Designphase der Diagnose, in der Anforderungen für
den weiteren Behandlungsablauf festgelegt werden. Scrum, die VDI Richtlinie 2221 und
der PMBOK Guide bestehen aus vier Projektphasen. Kanban, klinische Pfade und das V-
Modell XT jedoch setzen sich aus mehr bzw. weniger Phasen zusammen. Das V-Modell
XT unterstützt alle definierten Projektphasen zumindest teilweise und ist somit das
kompletteste der untersuchten Vorgehensmodelle in Bezug auf die Phasenabdeckung.
Auffällig ist ebenfalls, dass jedes Vorgehensmodell Phasen aus den Bereichen Analyse
(Anforderungen) und Entwicklung oder Entwurf enthält. Außerdem unterstützen nur
drei der sieben untersuchten Vorgehensmodelle die Projektphase Abbau. Die genaue
Verteilung der Werte des Aspekts Phasenabdeckung ist in Abbildung 5.17 zu erkennen.
Abbildung 5.17: Werteverteilung der Phasenabdeckung
GA2 – Prozessabdeckung
Der Subprozess Produktentwicklung ist in allen Vorgehensmodellen enthalten, die für
die Produktentwicklung eingesetzt werden. Nur beim PMBOK Guide wird die Produkt-
entwicklung nicht abgedeckt, da hier der Hauptfokus auf dem Projektmanagement liegt.
Ebenfalls auffällig ist, dass die Qualitätssicherung oder das Benchmarking in (fast)
122
5.8 Vergleich der Vorgehensmodelle
allen Vorgehensmodellen enthalten sind. Somit sind die Qualitätssicherung und das
Benchmarking wichtige Subprozesse zur Sicherung der Produkt- und Prozessquali-
tät. Das Projektmanagement ist sehr oft als Teilprozess enthalten, bzw. beim PMBOK
Guide ist dies der Hauptprozess. Dies lässt darauf schließen, dass die Steuerung und
Verwaltung der Projekte ein wichtiger Aspekt von Vorgehensmodell ist. Das Wissens-
management wird explizit nur vom PMBOK Guide unterstützt. Dies lässt vermuten, dass
es scheinbar als nicht wichtig genug angesehen wird. Allerdings ist das Wissensma-
nagement ein wichtiger Subprozess zur Unterstützung der Wissensarbeiter [
Hel
]. Die
VDI Richtlinie unterstützt als einziges Modell nur einen Subprozess und ist somit das
eingeschränkteste von den untersuchten Vorgehensmodellen. Siehe zur Verteilung der
Werte Abbildung 5.18.
Abbildung 5.18: Werteverteilung der Prozessabdeckung
GA3 – Abstraktionsstufe
In dieser Arbeit wurden vier Vorgehensmodelle, zwei Rahmenwerke und eine Metho-
densammlung untersucht. Daraus ist ersichtlich, dass zur Steuerung des Vorgehens bei
wissensintensiven Prozessen nicht unbedingt ein traditionelles Vorgehensmodell nötig
ist. Dies lässt sich auch mit Rahmenwerken oder Methodensammlungen bewerkstelligen
(siehe Scrum, Kanban und klinische Pfade). Traditionelle Vorgehensmodelle sind dabei
aber meist detaillierter aufgebaut als Rahmenwerke oder Methodensammlungen (sie-
he Modellkomplexität). Die Werteverteilung der Abstraktionsstufe ist in Abbildung 5.19
dargestellt.
123
5 Einordnung und Vergleich von Vorgehensmodellen
Abbildung 5.19: Werteverteilung der Abstraktionsstufe
GA4 – Detaillierungsgrad
Es wurden zwei universelle und drei weltliche Vorgehensmodelle in dieser Arbeit be-
trachtet. Dabei fiel auf, dass keines der drei weltlichen Vorgehensmodelle als atomar
einstufbar war, da die Prozessschritte noch zu ungenau beschrieben waren und es keine
genauen Bedingungen für die Abfolge der Prozessaktivitäten gab. Somit wurden der
PMBOK Guide, klinische Pfade und das V-Modell XT als weltliche Vorgehensmodelle
eingestuft und das AEP und die VDI Richtlinie 2221 als universelle Vorgehensmodelle
bewertet. Die Verteilung der Werte des Aspekts Detaillierungsgrad ist in Abbildung 5.20
zu erkennen.
Abbildung 5.20: Werteverteilung des Detaillierungsgrad
GA5 – Branchenfokus
Vier der sieben Vorgehensmodelle können branchenübergreifend eingesetzt werden, da
sie einen allgemeinen Ablauf beschreiben und somit für das individuelle Projekt adaptier-
bar sind. Somit sind diese Vorgehensmodelle an keine spezielle Branche gebunden. Das
V-Modell XT, klinische Pfade und das AEP hingegen sind an ihre jeweiligen Branchen
gebunden, da sie spezielle Aspekte der jeweiligen Branche abdecken. Die Werte des
Aspekts Branchenfokus sind in Abbildung 5.21 dargestellt.
124
5.8 Vergleich der Vorgehensmodelle
Abbildung 5.21: Werteverteilung des Branchenfokus
GA6 – Vorgehensweise
Auffällig ist, dass die Vorgehensmodelle, die vor allem im Fachbereich Informatik ein-
gesetzt werden (V-Modell XT, Scrum, Kanban) nicht mehr die traditionelle sequentielle
Prozessvorgehensweise unterstützen. Stattdessen wird in diesen Vorgehensmodellen
inkrementelles bzw. evolutionäres Vorgehen oder, im Falle des V-Modells XT, beide
Vorgehensweisen unterstützt. Die anderen Vorgehensmodelle (mit Ausnahme der VDI
Richtlinie 2221) setzen auf das traditionelle sequentielle Vorgehen. Somit zeigt sich,
dass die Vorgehensmodelle aus der Softwareentwicklung eine stetige Weiterentwicklung
der Ergebnisse durch die inkrementelle und evolutionäre Vorgehensweise anstreben
[
Ste04
]. Dies lässt sich durch die rasanten Innovationszyklen in der Softwareentwicklung
erklären [JG]. Siehe zur Verteilung der Werte Abbildung 5.22.
Abbildung 5.22: Werteverteilung der Vorgehensweise
GA7 – Prozesssteuerung
Alle betrachteten Vorgehensmodelle, außer Kanban, sind ergebnisorientiert, d.h. die
Prozesssteuerung erfolgt mithilfe der erzeugten Ergebnisse. Somit stehen bei diesen
Vorgehensmodellen die Ergebnisse im Mittelpunkt. Kanban hingegen ist als einziges
Modell aktivitätsorientiert, da bei Kanban die Fertigstellung der Aufgaben im Mittelpunkt
steht und dies durch die Limitierung des Work in Progress erreicht werden soll. Die
125
5 Einordnung und Vergleich von Vorgehensmodellen
genaue Verteilung der Werte des Aspekts Prozesssteuerung ist in Abbildung 5.23 zu
erkennen.
Abbildung 5.23: Werteverteilung der Prozesssteuerung
GA8 – Prozessergebnis
Sechs Vorgehensmodelle haben Produkte als Prozessergebnis, wobei immer zusätzli-
ches Wissen entsteht, z.B. in Form von Artefakten. Klinische Pfade haben eine Dienst-
leistung in Form der Heilung des Patienten als Prozessergebnis. Die Vorgehensmodelle
Kanban und Scrum können ebenfalls für Dienstleistungsprojekte, z.B. im Finanzwesen,
eingesetzt werden. Die Werteverteilung des Prozessergebnisses ist in Abbildung 5.24
dargestellt.
Abbildung 5.24: Werteverteilung des Prozessergebnisses
GA9 – Modellarchitektur
Sowohl die parallele als auch die sukzessive Abfolge der Projektphasen ist in vier der
untersuchten Vorgehensmodellen enthalten. Somit kann bei den Vorgehensmodellen
klinische Pfade, PMBOK Guide, VDI Richtlinie 2221 und V-Modell XT festgelegt werden,
welche der beiden Modellarchitekturen oder ob eine Mischform verwendet werden
soll. Bei den Vorgehensmodellen AEP, Kanban und Scrum ist nur eine sukzessive
Abfolge der Projektphasen möglich. Kanban nimmt dabei eine Sonderstellung ein, da
126
5.8 Vergleich der Vorgehensmodelle
Kanban eine Pipeline aus sukzessiven Phasen darstellt, da sich mehrere Aufgaben aus
unterschiedlichen Phasen parallel in Bearbeitung befinden. Die genaue Verteilung der
Werte des Aspekts Modellarchitektur sind in Abbildung 5.25 dargestellt.
Abbildung 5.25: Werteverteilung der Modellarchitektur
GA10 – Spezialisierbarkeit
Bei der Analyse der Ergebnisse fällt auf, dass fast alle Vorgehensmodelle auf andere
Domänen anpassbar sind. Lediglich das AEP und die klinischen Pfade sind nicht ad-
aptierbar, da sie spezielle Vorgehensmodelle für die jeweilige Domäne darstellen. Alle
anderen Vorgehensmodelle sind domänenneutral. Allerdings ist für die Adaption jedes
Vorgehensmodells in eine andere Domäne ein entsprechender Aufwand notwendig, um
die Vorgehensmodelle anzupassen. Siehe zur Verteilung der Werte Abbildung 5.26
Abbildung 5.26: Werteverteilung der Spezialisierbarkeit
GA11 – Modellkomplexität
Das V-Modell XT, AEP und der PMBOK Guide wurden mit einer mittleren bis hohen
Modellkomplexität eingestuft. Dies liegt daran, dass das V-Modell XT eine Vielzahl an
Vorgaben macht, die zum Verstehen des Modells notwendig sind. Außerdem gibt es
ein komplexes Rollensystem und eine Vielzahl von Produkten vor, die eine zentrale
Rolle im V-Modell XT spielen. Das AEP hat eine mittlere Modellkomplexität, da für
den produktiven Einsatz gute Mathematikkenntnisse nötig sind und da viele Tätigkeiten
127
5 Einordnung und Vergleich von Vorgehensmodellen
vorgegeben werden, die ausgeführt werden müssen. Der PMBOK Guide wurde ebenfalls
mit einer mittleren Modellkomplexität eingestuft, da viele Prozesse beschrieben und
viele zu erstellende Artefakte vorgegeben werden. Alle anderen Vorgehensmodelle
haben eine niedrige Modellkomplexität und sind daher leicht verständlich, da diese
Vorgehensmodelle deutlich weniger umfangreich als das V-Modell XT, das AEP und der
PMBOK Guide sind. Die Verteilung der Werte des Aspekts Modellkomplexität sind in
Abbildung 5.27 zu finden.
Abbildung 5.27: Werteverteilung der Modellkomplexität
KIA1 – Zuständigkeiten
Die untersuchten Vorgehensmodelle unterscheiden sich in der Art und Weise wie sie
Rollen und Zuständigkeiten vorgeben. Lediglich drei Vorgehensmodelle geben Rollen
explizit vor, wobei sich diese Vorgehensmodelle in der Anzahl der vorgegebenen Rollen
nochmals deutlich unterscheiden. Das V-Modell XT gibt 35 verschiedene Rollen vor,
bei Scrum sind es drei Rollen und bei den klinischen Pfaden entsprechen die Rollen
den beteiligten Berufsgruppen wie z.B. Ärzte und Pflege. Das AEP und die VDI Richtli-
nie 2221 geben keine Rollen vor und unterstützen auch keine festgelegten Rollen im
Vorgehensmodell. Bei Kanban und dem PMBOK Guide lassen sich Rollen individuell
festlegen, d.h. sie sind nicht vom Vorgehensmodell vorgegeben, allerdings werden die
selbst festgelegten Rollen von den Vorgehensmodellen unterstützt. Dabei existieren in
einer Organisation typischerweise organisatorische Rollen und organisatorische Ein-
heiten. Diese können sich von den projektspezifischen Rollen der Vorgehensmodelle
unterscheiden, oder aber auch übereinstimmen. Die Vorgehensmodelle, die Rollen un-
terstützen, können die organisatorischen Rollen berücksichtigen bzw. verwenden, wenn
keine expliziten Rollen vom Vorgehensmodell vorgegeben werden und eigene Rollen
128
5.8 Vergleich der Vorgehensmodelle
definierbar sind (siehe Kanban und PMBOK Guide). Die Werteverteilung des Aspekts
Zuständigkeiten ist in Abbildung 5.28 dargestellt.
Abbildung 5.28: Werteverteilung der Zuständigkeiten
KIA2 – Wissenstätigkeit
Auffällig ist, dass in jedem untersuchten Vorgehensmodell die Wissenstätigkeit Wissens-
anwendung durchgeführt wird (siehe Abbildung 5.29). Dabei setzen die Wissensarbeiter
ihr vorhandenes Wissen und ihre Erfahrung ein, um Probleme zu lösen und Aufgaben
zu bearbeiten. Bei den Vorgehensmodellen bei denen viel Wert auf die Dokumentation
gelegt wird, wird außerdem zusätzlich die Wissenstätigkeit Wissenserzeugung durchge-
führt. Dies sind die Vorgehensmodelle AEP, PMBOK Guide, VDI Richtlinie 2221 und das
V-Modell XT.
Abbildung 5.29: Werteverteilung der Wissenstätigkeit
KIA3 – Prozessdauer
Die Vorgehensmodelle unterscheiden sich in der dem wissensintensiven Prozess zu-
grunde liegenden Prozessdauer (siehe Abbildung 5.30). So sind die Vorgehensmodelle
Kanban und PMBOK Guide flexibel genug, um alle der drei Prozessdauern kurz, mittel,
lang zu unterstützen. Das AEP dagegen ist nur für eine lange Prozessdauer geeignet,
klinische Pfade nur für kurze Prozesse. Die Vorgehensmodelle Scrum, VDI Richtlinie
129
5 Einordnung und Vergleich von Vorgehensmodellen
2221 und V-Modell XT sind eher für mittlere bis lange Prozessdauern ausgelegt. Siehe
zur Verteilung der Werte Abbildung 5.30
Abbildung 5.30: Werteverteilung der Prozessdauer
KIA4 – Sichtenmodell
Von den untersuchten Vorgehensmodellen unterstützen vier Vorgehensmodelle zumin-
dest teilweise ein Sichtenmodell (siehe Abbildung 5.31). Lediglich das V-Modell XT bietet
unterschiedliche Sichten auf das Modell mithilfe der offiziellen V-Modell XT Dokumen-
tation. Dort sind die unterschiedlichen Kapitel an die Bedürfnisse der verschiedenen
Rollen ausgerichtet und stellen deshalb nur jene Informationen dar, die für die jeweilige
Rolle von Bedeutung sind. Die Vorgehensmodelle Kanban, klinische Pfade und PMBOK
Guide setzen das Sichtenmodell teilweise um. Kanban visualisiert z.B. den Projektfluss
mithilfe des Kanban-Boards und ermöglicht so den verschiedenen Projektbeteiligten
unterschiedliche Sichten auf das Projekt. Klinische Pfade stellen teilweise Informations-
blätter für Patienten bereit, um sie über ihren Behandlungsverlauf zu informieren. Beim
PMBOK Guide sind die verschiedenen Aufgaben in 12 Wissensgebiete unterteilt, die je
einer Rolle zugeordnet werden können.
Abbildung 5.31: Werteverteilung des Sichtenmodells
130
5.8 Vergleich der Vorgehensmodelle
KIA5 – Lebenszyklus Abdeckung
Die Orientierungsphase wird von den Vorgehensmodellen V-Modell XT, Kanban, AEP
und dem PMBOK Guide abgedeckt. Das Erstellen von Vorlagen zur Unterstützung von
Wissensarbeitern wird in drei Vorgehensmodellen unterstützt. Bei klinischen Pfaden
können Dokumentationsvorlagen erstellt werden, beim PMBOK Guide können Doku-
mentvorlagen für die verschiedenen Projektphasen erstellt werden und beim V-Modell
XT können ebenfalls Dokumentationsvorlagen angelegt werden. Die gemeinsame Be-
arbeitungsphase wird von allen Vorgehensmodellen zumindest teilweise unterstützt.
Die Phase Auswertung der Datensätze zur Verbesserung der Vorlagen wird nur bei
klinischen Pfaden durchgeführt. Auffällig ist, dass kein Vorgehensmodell den kompletten
Lebenszyklus eines wissensintensiven Prozesses abdeckt (siehe Abbildung 5.32). Die
Vorgehensmodelle V-Modell XT, klinische Pfade und der PMBOK Guide unterstützen
allerdings drei der vier Lebenszyklus Phasen.
Abbildung 5.32: Werteverteilung der Lebenszyklus Abdeckung
KIA6 – Kommunikationsformen
Nur die Vorgehensmodelle, die hauptsächlich in der Softwareentwicklung eingesetzt
werden, also Kanban, Scrum und das V-Modell XT, machen Vorgaben zur Kommuni-
kation. Bei Scrum und Kanban gibt es ein tägliches Meeting des Teams, bei Scrum
das sog. Daily Scrum bzw. bei Kanban das sog. Daily Standup. Außerdem werden
bei Scrum am Anfang und am Ende eines Sprints Planungsmeetings abgehalten. Das
V-Modell XT gibt ebenso vor, dass am Anfang und Ende eines Projektes Meetings mit
allen Beteiligten abgehalten werden sollen. Außerdem gibt es beim V-Modell XT ein
131
5 Einordnung und Vergleich von Vorgehensmodellen
regelmäßiges Treffen des Lenkungsausschusses, der über den weiteren Projektverlauf
entscheidet. Die genaue Verteilung der Werte ist in Abbildung 5.33 zu finden.
Abbildung 5.33: Werteverteilung der Kommunikationsformen
KIA7 – Zielspezifikation
Alle Vorgehensmodelle haben gemeinsam, dass sie ein Gesamtziel vorgegeben haben
(siehe Abbildung 5.34). Zusätzlich dazu unterstützen alle Vorgehensmodelle, außer
Kanban, Meilensteine. Eigene Ziele lassen sich jedoch nur bei Scrum und dem V-
Modell XT festlegen. Bei Scrum kann dabei die Reihenfolge der Meilensteine individuell
ausgewählt werden, da sich das Team selbst die Anforderungen aussucht, die im
kommenden Sprint umgesetzt werden sollen.
Abbildung 5.34: Werteverteilung der Zielspezifikation
KIA8 – Qualitätssicherungsmaßnahmen
Die VDI Richtlinie gibt keine Qualitätssicherungsmaßnahmen vor, obwohl dies ein
wichtiges Werkzeug zur Kontrolle, ob die Anforderungen erfüllt werden, ist. Dies ist
ersichtlich, da fünf der sieben untersuchten Vorgehensmodelle Tests in der Form von
z.B. einer Eigenprüfung durch einen Wissensarbeiter vorschreiben. Zusätzlich schreiben
fünf Vorgehensmodelle eine Prozessanalyse zur stetigen Verbesserung der Abläufe vor.
132
5.8 Vergleich der Vorgehensmodelle
Vier Vorgehensmodelle setzen auf die Evaluierung der Ergebnisse z.B. durch die stetige
inhaltliche und formale Überprüfung der erzeugten Artefakte und kontrollieren somit die
Qualität der Ergebnisse. Siehe zur Verteilung der Werte Abbildung 5.35
Abbildung 5.35: Werteverteilung der Qualitätssicherungsmaßnahmen
KIA9 – Wissensdokumentation
Bei den agilen Vorgehensmodellen Kanban und Scrum nimmt die Dokumentation nur
einen geringen Stellenwert ein, da die Dokumentation nicht explizit vom Vorgehens-
modell vorgegeben wird. Bei den Vorgehensmodell V-Modell XT und PMBOK Guide
hingegen sind sehr viele Artefakte zu erzeugen und dadurch entsteht ein hoher Dokumen-
tationsaufwand, der durch das Vorgehensmodell induziert wird. Die Vorgehensmodelle
VDI Richtlinie 2221, AEP und klinische Pfade besitzen einen mittleren Dokumentations-
aufwand, da deutlich weniger Artefakte anzulegen sind als beim V-Modell XT und dem
PMBOK Guide, aber mehr als bei den Vorgehensmodellen Scrum und Kanban. Die
genaue Verteilung des Aspekts Wissensdokumentation ist in Abbildung 5.36 dargestellt.
Abbildung 5.36: Werteverteilung der Wissensdokumentation
KIA10 – Problemkomplexität
Fünf der sieben Vorgehensmodelle sind für alle Problemkomplexitätsklassen einsetzbar
(siehe Abbildung 5.37). Diese Vorgehensmodelle haben alle Vorgehen zum Beherrschen
133
5 Einordnung und Vergleich von Vorgehensmodellen
der Problemkomplexität, z.B. durch das Teilen des Problems in Teilprobleme. Klinische
Pfade hingegen sind nur für Probleme mit niedriger oder mittlerer Komplexität geeignet,
da sich der Behandlungsablauf bei hochkomplexen Erkrankungen meist nicht standar-
disieren lässt und so kein klinischer Pfad formuliert werden kann. Das AEP lässt sich
dagegen nur für Probleme mit mittlerer oder hoher Komplexität einsetzen, da es ein
Modell speziell für das Bauwesen ist und Bauprojekte typischerweise eine hohe Komple-
xität aufweisen. Standard Bauwerke wie z.B. ein Standard-Einfamilienhaus entsprechen
dagegen einer mittleren Komplexität.
Abbildung 5.37: Werteverteilung der Problemkomplexität
134
6
Diskussion
In Kapitel 5.8 wurden die verschiedenen Vorgehensmodelle aus den unterschiedlichen
Domänen miteinander verglichen. In Kapitel 6.1 erfolgt nun eine qualitative Bewertung
der zuvor erhobenen Ergebnisse. In Kapitel 6.2 werden auf dieser Basis die Forschungs-
fragen aus Kapitel 1.2 aufgegriffen und beantwortet. Anschließend werden die Ergeb-
nisse dieser Arbeit in Kapitel 6.3 in den Kontext verwandter Arbeiten eingeordnet und
deren Auswirkungen dargestellt.
6.1 Qualitative Bewertung der Ergebnisse
In diesem Kapitel werden die Ergebnisse des in Kapitel 5.8 durchgeführten Vergleichs
bewertet und näher erläutert.
135
6 Diskussion
GA1 – Phasenabdeckung
Anforderungen werden in den meisten Vorgehensmodellen definiert, um ein Ziel näher
zu definieren, das final erreicht werden soll. Dadurch wird am Anfang des Prozesses der
Soll-Zustand festgelegt und im Laufe des wissensintensiven Prozesses wird versucht,
vom Ist-Zustand in den Soll-Zustand überzugehen. Dabei geben viele der Vorgehens-
modelle einen Ablauf in ähnlicher Form vor. Am Anfang wird in einer Analysephase das
Problem untersucht und Ziele in Form von Anforderungen festgelegt. Anschließend folgt
entweder eine Entwurfsphase, in der Möglichkeiten gesucht werden, um das Ziel zu
erfüllen, oder die Entwicklungsphase, in der die festgelegten Anforderungen umgesetzt
werden. Dieser Ablauf, also Analyse
→
Entwurf
→
Entwicklung, hilft den Wissensarbei-
tern die Komplexität der Problemstellung zu beherrschen, indem die Tätigkeiten geordnet
ablaufen. Dieser geordnete Ablauf ist im idealtypischen Ablauf wissensintensiver Pro-
zesse wiederzufinden (siehe Kapitel 2.4). So wird zuerst das Problem analysiert und die
Ziele festgelegt. Anschließend werden passende Lösungsmöglichkeiten gesucht und
Entwürfe angefertigt. Abschließend werden die Anforderungen in ein Prozessergebnis
umgesetzt. Das Erbringen einer Dienstleistung, wie z.B. bei klinischen Pfaden, fällt
ebenfalls unter dieses Schema. Am Anfang findet eine Analyse der Problemstellung statt.
Anschließend wird nach einer Problemlösung gesucht und die Dienstleistung erbracht.
Der idealtypische Ablauf wissensintensiver Prozesse ist ebenfalls in Phasen gegliedert,
um eine bessere Strukturierung des wissensintensiven Prozesses zu erreichen.
GA2 – Prozessabdeckung
Die Produktentwicklung ist der am meisten unterstützte Subprozess der Vorgehens-
modelle, da die untersuchten wissensintensiven Prozesse meist die Entwicklung von
Produkten zum Ziel haben. Die Subprozesse Qualitätssicherung und Benchmarking sind
sehr häufig vertreten, da die Erfüllung der festgelegten Anforderungen das Hauptziel der
Projekte darstellt. Durch Qualitätssicherungsmaßnahmen wird überprüft, ob die Anfor-
derungen erfüllt werden. Der idealtypische Ablauf wissensintensiver Prozesse (siehe
Kapitel 2.4) sieht ebenfalls eine Qualitätssicherung zur Kontrolle der Ergebnisse vor.
Mithilfe des Benchmarkings lässt sich feststellen, welchen Erfüllungsgrad die Ergebnisse
136
6.1 Qualitative Bewertung der Ergebnisse
besitzen, d.h. das Benchmarking liefert Messgrößen für den Erfüllungsgrad. Damit lässt
sich u.a. die verbleibende Projektdauer besser abschätzen. Das Projektmanagement
wird ebenfalls von vielen Vorgehensmodellen explizit unterstützt. Dies liegt daran, dass
die Steuerung und Verwaltung der Projekte ein wichtiger Aspekt ist, um einen geregelten
Ablauf gewährleisten zu können. Der Subprozess Wissensmanagement wird lediglich
von einem Vorgehensmodell unterstützt. Das Wissensmanagement ist allerdings ein Sub-
prozess, der die Wissensarbeiter in ihrer Arbeit langfristig unterstützen kann [
MKR13
].
Die Ursache, warum nur ein Modell das Wissensmanagement unterstützt, könnte sein,
dass das Wissensmanagement eine eigene, neuartige Disziplin darstellt, durch die ein
hoher Aufwand und hohe Kosten durch Fachpersonal entstehen würde.
GA3 – Abstraktionsstufe
Zur Steuerung des Vorgehens sind nicht immer traditionelle Vorgehensmodelle nötig.
Rahmenwerke und Methodensammlungen können ebenfalls einen wissensintensiven
Prozess unterstützen. Der Unterschied zwischen einem Vorgehensmodell und Rahmen-
werken oder Methodensammlungen liegt in der Modellkomplexität und der Festlegung
des Ablaufs. Während ein Vorgehensmodell meist viele Vorgaben macht und damit
den Ablauf im Vergleich detaillierter festlegt, sind den Wissensarbeitern bei Rahmen-
werken und Methodensammlungen meist viele Freiheiten überlassen, da diese den
Ablauf nur schemenhaft regeln und wenige Vorgaben machen. Dadurch bekommen die
Wissensarbeiter mehr Eigenverantwortung zugesprochen.
GA4 – Detaillierungsgrad
Die Vorgehensmodelle besitzen meist keinen atomaren Formalisierungsgrad, da es in
der Natur der wissensintensiven Prozesse liegt, dass diese nicht vorhersehbar sind und
damit der Ablauf emergent ist [
MR14
]. Somit kann kein Vorgehensmodell, das einen
wissensintensiven Prozess unterstützen soll, jeden kleinen Schritt im Ablauf beschrieben
und im Vorhinein festlegen, da dies nicht der Charakteristik wissensintensiver Prozesse
entspricht. Somit können Vorgehensmodelle lediglich den Ablauf modellhaft und abstra-
137
6 Diskussion
hierend beschreiben und Richtlinien festlegen, also den Formalisierungsgrad universell
oder weltlich annehmen.
GA5 – Branchenfokus
Der Großteil der Vorgehensmodelle ist an keine spezielle Branche gebunden und somit
branchenunabhängig, da sie allgemeine Abläufe beschreiben. Dies spricht dafür, dass
die Vorgehensmodelle für unterschiedliche wissensintensive Prozesse nutzbar sind. Im
Gegensatz zu den Vorgehensmodellen sind wissensintensive Prozesse immer an eine
bestimmte Branche gebunden [MKR13].
GA6 – Vorgehensweise
Vier der untersuchten Vorgehensmodelle verwenden nicht mehr die traditionelle se-
quentielle Vorgehensweise. Stattdessen werden iterative Vorgehensweisen, wie das
evolutionäre oder das inkrementelle Vorgehen eingesetzt. Dabei werden in mehreren
Iterationszyklen die Phasen mehrmals durchlaufen. Der idealtypische Ablauf wissensin-
tensiver Prozesse (siehe Kapitel 2.4) weist ebenfalls eine inkrementelle Vorgehensweise
auf. Die Phasen können dabei beliebig oft durchlaufen werden. Dies entspricht den
Iterationszyklen bei evolutionären bzw. inkrementellen Vorgehensmodellen. Durch die
Iterationszyklen findet eine ständige Überprüfung und Weiterentwicklung der Arbeitser-
gebnisse statt. Des Weiteren wird die Komplexität der Problemstellung eingeschränkt,
da das Gesamtproblem durch die stetige Weiterentwicklung in einfacher umsetzbare Teil-
probleme zerlegt wird. Wird dagegen ein sequentielles Vorgehen eingesetzt, so könnte
das Übersehen eines Fehlers oder die Nichtbeachtung einer Anforderung schwerwie-
gende Folgen für den weiteren Projektverlauf nach sich ziehen. Wird das Problem erst in
späteren Phasen identifiziert, so müssen weitreichende Änderungen am Arbeitsergebnis
vorgenommen werden, um das Problem zu beheben. Dies resultiert in erhöhten Kosten
und einer verspäteter Fertigstellung des Arbeitsergebnisses.
138
6.1 Qualitative Bewertung der Ergebnisse
GA7 – Prozesssteuerung
Der Großteil der Vorgehensmodelle macht Prozesssteuerungsentscheidungen von den
Produkten abhängig. Dies basiert auf der Tatsache, dass die Vorgehensmodelle einge-
setzt werden, um die Entwicklung von Produkte zu begleiten/unterstützen. Somit ist es
einleuchtend, dass Entscheidungen über den Projektfortschritt anhand der erhobenen
Anforderungen bzw. der Qualität der Ergebnisse getroffen werden. Lediglich Kanban legt
den Fokus auf die Fertigstellung der Aktivitäten. Dies lässt sich mit der agilen Denkweise
„stop starting, start finishing“ erklären. Hierbei liegt der Fokus darauf nicht zu viele
Aufgaben gleichzeitig erledigen zu wollen. Stattdessen soll eine Aufgabe abgeschlossen
werden, bevor eine andere neu angefangen wird, d.h. die Wissensarbeiter sollen sich
auf eine Aufgabe konzentrieren, um produktiver zu arbeiten. Gibt es keine Limitierung
des Work in Progress, so können Aufgaben stark verzögert werden, weil die Bearbeitung
gestartet, aber nie fertiggestellt wurde. So könnte ein Wissensarbeiter eine Aufgabe
beginnen und während der Bearbeitung auf ein Problem stoßen, das er nicht sofort
beheben kann. Statt sich mit der Behebung des Problems zu beschäftigen, wählt der
Wissensarbeiter eine neue Aufgabe und bearbeitet diese. Dadurch kann die angefan-
gene Aufgabe in Vergessenheit geraten und erst sehr spät wieder aufgegriffen werden.
Durch die Limitierung des Work in Progress wird genau dieses Problem verhindert, da
sich nur wenige Aufgaben gleichzeitig in Bearbeitung befinden dürfen.
GA8 – Prozessergebnis
Da viele Vorgehensmodelle recht allgemein gehalten sind, ist es möglich, sie für ver-
schiedene wissensintensive Prozesse einzusetzen und somit letztlich verschiedene
Prozessergebnisse zu erhalten. Allerdings sehen die meisten Vorgehensmodelle Pro-
dukte als das Hauptprozessergebnis vor.
GA9 – Modellarchitektur
Die Prozessarchitektur unterscheidet sich von Vorgehensmodell zu Vorgehensmodell.
So ist es möglich, eine Mischform aus sukzessiver und paralleler Abfolge zu unterstützen
139
6 Diskussion
oder aber nur eine Form der Abfolge. Die Mischform hat den Vorteil, dass z.B. in der
Analysephase das Problem als Ganzes analysiert wird. In der darauffolgenden Phase
wird dann das Gesamtproblem in mehrere Teilprobleme aufgeteilt, um die Komplexität
des Problems zu verringern. Die Bearbeitung der Teilprobleme erfolgt anschließend
parallel. Das Gesamtergebnis setzt sich schließlich aus den Teilergebnissen zusammen
[
Kri87
]. Die Aufteilung des Gesamtproblems in Teilprobleme wird beispielsweise von der
VDI Richtlinie 2221 umgesetzt.
GA10 – Spezialisierbarkeit
Jedes der Vorgehensmodelle lässt sich mit mehr oder weniger Aufwand an eine andere
Domäne anpassen. Die allgemeinen Vorgehensmodelle Scrum und Kanban können
ohne größere Anpassungen des Vorgehensmodells in anderen Domänen eingesetzt wer-
den. Speziellere Vorgehensmodelle, wie z.B. das V-Modell XT, benötigen Anpassungen
an die entsprechende Domäne. Allerdings ist es bei manchen Vorgehensmodellen, wie
z.B. dem AEP, nicht sinnvoll, diese in einer anderen Domäne einzusetzen, da bestimm-
te Aspekte der neuen Domäne eventuell nicht unterstützt werden. Allerdings lassen
sich bestimmte Methoden, wie z.B. die Kontrolle des Zielerreichungsgrads, aus den
Vorgehensmodellen in anderen Domänen einsetzen.
GA11 – Modellkomplexität
Die meisten Vorgehensmodelle besitzen eine niedrige oder mittlere Modellkomplexi-
tät und lassen sich deswegen relativ schnell im Unternehmen einführen, da sie leicht
verständlich für die Mitarbeiter sind und meist keine großen strukturellen Änderungen
benötigen. Sehr umfangreiche Vorgehensmodelle, wie z.B. das V-Modell XT oder der
PMBOK Guide, machen sehr viele Vorgaben und benötigen eine entsprechende Un-
ternehmensstruktur mit klar definierten Zuständigkeiten und Rollen. Deswegen ist die
Einführung des V-Modells XT schwieriger, da eventuell größere strukturelle Veränderun-
gen getätigt werden müssen.
140
6.1 Qualitative Bewertung der Ergebnisse
KIA1 – Zuständigkeiten
Die Hälfte der untersuchten Vorgehensmodelle gibt explizit Rollen und Zuständigkeiten
vor. Dadurch können Aufgaben immer einer Rolle, deren Inhaber Expertenwissen für die
Aufgabe besitzen, zugeteilt werden. Somit können Wissensarbeiter gezielter eingesetzt
werden und dadurch die Arbeitsabläufe effizienter gestaltet werden. Die Rollen dieser
Vorgehensmodelle können dabei von den Unternehmensrollen abweichen, d.h. Projek-
trollen können unabhängig der Unternehmensrollen besetzt werden. Bei Kanban und
dem PBMOK Guide können die Unternehmensrollen direkt in das Projekt übernommen
werden. Dadurch bleiben die Projekt- und Unternehmensrollen der Wissensarbeiter
identisch. Der Vorteil von vorgegebenen Rollen ist, dass für die entsprechenden Vorge-
hensmodelle ein geeignetes Rollenkonzept existiert und somit alle Verantwortlichkeiten
für bestimmte Aufgaben abgedeckt werden können. Werden Rollen selbst definiert,
so besteht die Gefahr, dass nur ein unzureichendes Rollenkonzept definiert wird und
wichtige Rollen für das Vorgehensmodell unbeachtet bleiben und somit nicht alle wichti-
gen Aufgaben abgedeckt werden. Vorgegebene Rollen sichern somit die vollständige
Abdeckung der im Vorgehensmodell beschriebenen Aufgaben und Zuständigkeiten.
KIA2 – Wissenstätigkeit
Die Wissenstätigkeit Wissensanwendung spielt in jedem Vorgehensmodell, welches
einen wissensintensiven Prozess unterstützt, die wichtigste Rolle, da die Wissensar-
beiter mit der Gesamtheit aus ihrem Wissen und ihrer Erfahrung Probleme lösen und
Wissensarbeit vollbringen. Außerdem ist die Wissenstätigkeit Wissenserzeugung in
vielen Vorgehensmodellen ein weiterer Schwerpunkt, da viele Vorgehensmodelle die
erzeugten Prozessergebnisse durch eine Dokumentation beschreiben. In der Dokumen-
tation wird ein Großteil des erzeugten expliziten Wissens aus dem Entwicklungsprozess
festgehalten, damit andere Wissensarbeiter oder Kunden einen Überblick über das
Ergebnis erhalten.
141
6 Diskussion
KIA3 – Prozessdauer
Der Großteil der Vorgehensmodelle ist für die Unterstützung von wissensintensiven Pro-
zessen mit einer mittleren bis langen Prozessdauer, also länger als drei Tage, ausgelegt.
Dies liegt daran, dass die Vorgehensmodelle die Analyse- und Entwicklungsphase evtl.
mehrmals durchlaufen, da das Produkt in jedem Entwicklungszyklus weiter detailliert
wird und die steigende Komplexität der Problemstellungen so beherrscht werden kann.
Dadurch entstehen Prozessdauern von mehr als drei Tagen. Kurze Prozessdauern von
unter drei Tagen werden von drei untersuchten Vorgehensmodellen unterstützt. Dies liegt
daran, dass wissensintensive Prozesse in der Regel zu komplex sind, um das Problem
innerhalb von drei Tagen zu lösen. Klinische Pfade stellen hier einen Sonderfall dar, da
die Behandlung der Patienten bei idealen Behandlungsergebnissen typischerweise in
einer kurzen Prozessdauer resultiert.
KIA4 – Sichtenmodell
Ein Sichtenmodell, welches relevante Informationen für eine bestimmte Rolle darstellt,
wird nur teilweise von den untersuchten Vorgehensmodellen umgesetzt. Dies liegt am all-
gemeinen Charakter der meisten Vorgehensmodelle, die keine speziellen Informationen
enthalten und somit nur das Vorgehensmodell als Ganzes darstellen. Um ein Sichten-
modell unterstützen zu können, müssen die beteiligten Rollen des Vorgehensmodells
bekannt sein, da ansonsten keine spezialisierten Sichten für unterschiedliche Rollen
angeboten werden können. Das heißt die Unterstützung eines Sichtenmodells hängt
eng mit der Vorgabe von Rollen und Zuständigkeiten zusammen. Wünschenswert ist die
Unterstützung eines Sichtenmodells, das den beteiligten Rollen nur Informationen über
das Vorgehensmodell und den wissensintensiven Prozess liefert, die für sie relevant
sind.
KIA5 – Lebenszyklus Abdeckung
Die typischen Phasen eines wissenintensiven Prozesses nach [
MKR13
] werden von
der Mehrzahl der Vorgehensmodelle unterstützt. Hierbei fällt auf, dass nur drei Vor-
142
6.1 Qualitative Bewertung der Ergebnisse
gehensmodelle die Erstellung von Vorlagen für Wissensarbeiter vorsehen, obwohl die
Wissensarbeiter dadurch wichtige Informationen für bestimmte Arbeitsschritte erhält.
Durch diese Art der Unterstützung kann sichergestellt werden, dass der Wissensarbeiter
eine Vorlage für seine Tätigkeit hat, die ihn bei seiner Aufgabe unterstützt und leitet.
Eine Auswertung der ausgefüllten Vorlagen wird nur bei klinischen Pfaden durchge-
führt. Dadurch sollen die Vorlagen weiterentwickelt und verbessert werden, um die
Wissensarbeiter noch besser unterstützen zu können. Allerdings unterstützt keines der
untersuchten Vorgehensmodelle den kompletten Lebenszyklus eines wissensintensiven
Prozesses. Die am wenigsten unterstützte Phase ist die Auswertung der Datensätze
und somit die Verbesserung und Archivierung der ausgefüllten Vorlagen.
KIA6 – Kommunikationsformen
Lediglich drei der untersuchten Vorgehensmodelle geben Vorgaben zur Kommunikation
der Wissensarbeiter vor. Dabei werden tägliche Meetings am häufigsten eingesetzt.
Dies hat den Vorteil, dass die Kommunikation direkt im Team stattfindet und jeder
Wissensarbeiter täglich über den Projektverlauf informiert wird. Somit kann auf evtl.
auftretende Probleme sehr schnell innerhalb des Teams reagiert werden. Regelmäßig
stattfindende Treffen, wie z.B. die Treffen des Lenkungsausschusses beim V-Modell XT,
ermöglichen ebenfalls eine schnelle Reaktionsmöglichkeit auf auftretende Probleme
und dienen der schnellen Problembeseitigung. Außerdem werden Meetings zu ent-
scheidenden Projektzeitpunkten, wie z.B. am Anfang oder nach der Fertigstellung eines
Projektes, abgehalten. Dadurch können Informationen über das bevorstehende bzw. das
abgeschlossene Projekt an alle Wissensarbeiter weitergegeben werden.
KIA7 – Zielspezifikation
Alle untersuchten Vorgehensmodelle geben ein Gesamtziel vor. Um das Gesamtziel
zu erreichen, werden von fast allen Vorgehensmodellen Meilensteine unterstützt. Da-
durch kann adäquat überprüft werden, ob die Ergebnisse die Anforderungen erfüllen.
Ist dies nicht der Fall, so müssen die Ergebnisse abgeändert oder ergänzt werden.
143
6 Diskussion
Dadurch ermöglichen fast alle Vorgehensmodelle wichtige Projektfortschrittsentschei-
dungen anhand der Meilensteine. Eigene Ziele werden nur bei zwei der untersuchten
Vorgehensmodelle unterstützt. Dadurch dass fast alle Vorgehensmodelle Meilensteine
unterstützen, ist die Definition von eigenen Zielen unnötig, da mithilfe der Meilensteine
bereits die wichtigsten Ergebnisse auf dem Weg zum Gesamtziel vorgegeben sind.
KIA8 – Qualitätssicherungsmaßnahmen
Der Großteil der Vorgehensmodelle unterstützen Tests, um die Funktionsweise der
Ergebnisse zu überprüfen. Somit dienen Tests zur Kontrolle, wie gut die Anforderun-
gen erfüllt wurden. Eine Prozessanalyse dient dazu den Ablauf des wissensintensiven
Prozesses stetig zu verbessern und somit dessen Effizienz und Qualität zu steigern.
Beim idealtypischen Ablauf wissensintensiver Prozesse (siehe Kapitel 2.4) werden eben-
falls Tests zur Überprüfung der Zielerreichung sowie eine Prozessanalyse zur stetigen
Verbesserung des Prozesses durchgeführt.
KIA9 – Wissensdokumentation
Die untersuchten Vorgehensmodelle unterscheiden sich in der Wissensdokumentation,
da die Dokumentation von den Vorgehensmodellen als unterschiedlich wichtig angese-
hen wird. So ist der Dokumentationsaufwand bei den schlanken, agilen Vorgehensmo-
dellen Scrum und Kanban gering, da bei der agilen Produktentwicklung das Produkt im
Mittelpunkt steht und die Dokumentation nur ein Nebenprodukt ist. Das V-Modell XT und
der PMBOK Guide stellen das andere Extrem mit einem hohen Dokumentationsaufwand
dar, da bei diesen Vorgehensmodellen viele zu erzeugende Artefakte vorgegeben sind.
KIA10 – Problemkomplexität
Fast alle untersuchten Vorgehensmodelle ermöglichen es wissensintensive Prozesse
mit allen drei Problemkomplexitäten zu unterstützen. Dadurch wird ersichtlich, dass
144
6.2 Beantwortung der Forschungsfragen
Vorgehensmodelle zur Unterstützung der Wissensarbeit geeignet sind, da selbst das
Lösen hochkomplexer Probleme durch die Vorgehensmodelle unterstützt werden kann.
6.2 Beantwortung der Forschungsfragen
In Kapitel 1.2 wurden zentrale Fragen gestellt, die mithilfe der Ergebnisse dieser Arbeit
nun in diesem Kapitel beantwortet werden sollen.
FF1: In wie weit sind etablierte Vorgehensmodelle domänenabhängig?
Wie unter dem Vergleichsaspekt Branchenfokus festgestellt wurde, sind die meisten
der untersuchten Vorgehensmodelle unabhängig von einer Domäne, da die meisten
Vorgehensmodelle sehr allgemeine Abläufe beschreiben und keine domänenspezifische
Informationen enthalten. Somit lassen sich diese Vorgehensmodelle in unterschiedli-
chen Domänen, wie z.B. Forschung oder Entwicklung einsetzen. Somit unterscheiden
sich Vorgehensmodelle von wissensintensiven Prozessen, da diese meist genau einer
Domäne zuzuordnen sind.
FF2: Gibt es Messgrößen, anhand derer bewertet werden kann, wie gut ein
Vorgehensmodell für einen wissensintensiven Prozess geeignet ist?
Es gibt geeignete Messgrößen, da es sich mithilfe vieler Punkte aus dem entwickelten
Vergleichs-Rahmenwerk aus Kapitel 3 bewerten lässt, wie gut ein Vorgehensmodell
für einen wissensintensiven Prozess geeignet ist. Vorraussetzung ist allerdings, dass
eine Analyse des Vorgehensmodells, sowie des wissensintensiven Prozesses vorliegt.
Wichtige Messgrößen sind hierbei Phasenabdeckung, Prozessabdeckung, Branchenfo-
kus, Prozessvorgehensweise, Prozesssteuerung, Prozessergebnis, Prozessarchitektur,
Zuständigkeiten, Wissenstätigkeit, Lifecycle Abdeckung, Kommunikationsformen, Ziels-
pezifikation, Qualitätssicherungsmaßnahmen, Wissensdokumentation und Problemkom-
plexität. Anhand dieser Messgrößen lässt sich ein Eignungsgrad für Vorgehensmodelle
145
6 Diskussion
entwickeln. Allerdings lässt sich nicht nur anhand der Messgrößen ableiten, ob ein
Vorgehensmodell für einen wissensintensiven Prozess geeignet ist, da dies auch von
den lokalen Bedingungen am Arbeitsplatz, wie z.B. der Erfahrung der Wissensarbeiter,
abhängt. Allerdings sind die Messgrößen ein guter Anhaltspunkt für die Bewertung und
Auswahl der Vorgehensmodelle.
FF3: Welchen Beitrag leisten Vorgehensmodelle zur Unterstützung der
Wissensarbeiter?
Vorgehensmodelle leisten einen großen Beitrag zur Unterstützung von Wissensarbeitern,
da sie für die unstrukturierte Wissensarbeit einen Ordnungsrahmen bereitstellen, der
die anfallenden Aufgaben und Tätigkeiten in Phasen gliedert. Die Phaseneinteilung
hilft den Wissensarbeitern ihre Arbeit mit anderen Wissensarbeitern zu koordinieren,
da der Ablauf dadurch berechenbarer wird und z.B. zum Abschluss einer Phase ein
Meilenstein erreicht werden muss. Ist dieser nicht erreicht, so muss die Phase weiter
oder wieder ausgeführt werden. Außerdem hilft die Einteilung des Projektes in Projekt-
phasen die Komplexität der Aufgabenstellung dadurch zu beherrschen, dass in jeder
Phase ein Teil der Problemlösung stattfindet und die Aufgaben hierfür in einer Phase
gruppiert sind. Zusätzlich zur nötigen Koordination der Wissensarbeiter erfüllen einige
Vorgehensmodelle auch den Bedarf an Kommunikation zwischen den Wissensarbeitern.
Durch tägliche oder wöchentlich stattfindende Meetings können die Wissensarbeiter
sich über den Projektverlauf und evtl. aufgetretene Probleme austauschen. Durch die
Koordination der Wissensarbeiter mithilfe der Phaseneinteilung sowie der vorgegebenen
Kommunikationsformen können die Wissensarbeiter effektiv und effizient an der Lösung
eines Problems zusammenarbeiten.
Viele Vorgehensmodelle bieten Maßnahmen zum Beschränken der Komplexität. Hierzu
wird z.B. die Problemstellung in einer Projektphase in mehrere Teilprobleme aufgeteilt
und anschließend gelöst. Dabei besitzen die Teilprobleme eine geringere Komplexität als
das Hauptproblem. Einige Vorgehensmodelle bieten auch die Möglichkeit bestimmte Vor-
lagen, z.B. in Form von Artefakten, wie z.B. Dokumentationsvorlagen oder Checklisten,
für die Wissensarbeiter anzufertigen und an der richtigen Stelle für diese zur Verfügung
146
6.3 Einordnung in verwandte Arbeiten
zu stellen. Dadurch erhalten die Wissensarbeiter Informationen über ihre Aufgabenstel-
lung, sowie einen Ordnungsrahmen, an dem sie sich während ihrer Tätigkeit orientieren
können. Eine weiter Maßnahme, die zur Unterstützung der Wissensarbeiter beiträgt,
ist das Verteilen der Aufgaben anhand der im Modell beschriebenen Rollen. Dadurch
können die Aufgaben effizienter bearbeitet werden, da sie immer Wissensarbeitern zu-
gewiesen werden, die Erfahrungen mit ähnlichen Problemstellungen haben. Schließlich
geben viele Vorgehensmodelle Qualitätssicherungsmaßnahmen vor. Dadurch ist eine
Kontrolle der Ergebnisse zwingend notwendig. Dies ermöglicht den Wissensarbeitern ei-
ne Kontrolle ihrer Arbeit, sowie die Überprüfung, ob die Anforderungen zufriedenstellend
umgesetzt wurden. Auffällig ist hierbei, dass der idealtypische Ablauf wissensintensiver
Prozesse (siehe Kapitel 2.4) die Wissensarbeiter auf ähnliche Weise unterstützt. Der
idealtypische Ablauf stellt ebenfalls einen in Phasen gegliederten Ordnungsrahmen für
die Wissensarbeit dar. Des Weiteren werden Qualitätssicherungsmaßnahmen in Form
von Tests und einer Prozessanalyse vorgegeben. Zusammenfassend unterstützen die
Vorgehensmodelle die Wissensarbeiter in der Steuerung der wissensintensiven Prozes-
se und ermöglichen einen geordneten Arbeitsablauf. Dabei weisen Vorgehensmodelle
viele Ähnlichkeiten mit dem idealtypischen Ablauf wissensintensiver Prozesse auf.
6.3 Einordnung in verwandte Arbeiten
In diesem Kapitel werden die gefundenen Ergebnisse in den Kontext verwandter Arbeiten
eingeordnet.
Das in [
FK07
] entworfene Vergleichs-Rahmenwerk für Vorgehensmodelle dient zur Un-
tersuchung verschiedener Vorgehensmodelle mit dem Ziel die jeweiligen Stärken und
Schwächen der Vorgehensmodelle herauszuarbeiten und diese zu vergleichen. Dabei
werden ähnliche Vergleichsaspekte wie in dieser Arbeit definiert. Allerdings besteht das
Vergleichs-Rahmenwerk lediglich aus acht Vergleichsaspekten. Somit ermöglicht das
in dieser Arbeit erstellte Vergleichs-Rahmenwerk eine detailliertere Analyse der Vorge-
hensmodelle und somit zusätzliche Vergleichsmöglichkeiten. Das in [
FK07
] vorgestellte
Vergleichs-Rahmenwerk untersucht ebenfalls allgemeine Aspekte der Vorgehensmo-
147
6 Diskussion
delle und ist somit zum Vergleich verschiedener Vorgehensmodelle aus verschiedenen
Domänen geeignet. Allerdings wird das Rahmenwerk nur zum Vergleich von Vorgehens-
modellen aus der Softwareentwicklung eingesetzt.
Das von [
Fil05
] vorgestelle Vergleichs-Rahmenwerk für Vorgehensmodelle fokussiert
sich ebenfalls auf Vorgehensmodelle aus der Softwareentwicklung. Viele spezifische
Aspekte der Softwareentwicklung wurden untersucht und daraus ein Vergleichs-Rahmenwerk
abgeleitet. Das in dieser Arbeit entwickelte Rahmenwerk zum Vergleich von Vorge-
hensmodellen lässt sich hingegen auf Vorgehensmodelle aus den unterschiedlichsten
Domänen anwenden, da es sehr allgemeine Aspekte untersucht und nicht näher auf
domänenspezifische Aspekte eingeht. Es erweitert das Vergleichsframework von [
Fil05
]
um weitere allgemeine Aspekte und lässt die spezifischen Aspekte außen vor. Der Fokus
auf die allgemeinen Aspekte eines Vorgehensmodells ist dabei ein vielversprechender
Ansatzpunkt für den Vergleich verschiedener Vorgehensmodelle aus verschiedenen
Domänen, wie aus der Beantwortung der Forschungsfrage FF1 klar wird. Darin ist
ersichtlich, dass sich Vorgehensmodelle domänenneutral einsetzen lassen, d.h. dass
diese nicht auf eine bestimmte Domäne beschränkt sind. Ein allgemeiner Vergleich ver-
schiedener Vorgehensmodelle gibt somit Aufschluss darüber, ob ein Vorgehensmodell
für eine entsprechende Domäne geeignet ist, ohne die domänenspezifischen Aspekte
zu berücksichtigen.
Zur Unterstützung wissensintensiver Prozesse ist der Einsatz von Vorgehensmodellen
sehr hilfreich, da Vorgehensmodelle ein wichtiges Hilfsmittel für Wissensarbeiter darstel-
len (siehe Kapitel 6.2). Durch ihren Einsatz kann die Komplexität der wissensintensiven
Prozesse eingegrenzt und die Arbeit der Wissensarbeiter vereinfacht werden, da sie von
den Vorgehensmodellen in unterschiedlicher Weise unterstützt werden. Vorgehensmo-
delle stellen dabei, wie in der Beantwortung der FF1 beschrieben, ein domänenunab-
hängiges Hilfsmittel dar und sind somit für verschiedene wissensintensive Prozesse, die
meist domänenabhängig sind, einsetzbar. Durch eine Vorabanalyse des wissensinten-
siven Prozesses mit verschiedenen vorgestellten Vergleichsaspekten kann festgestellt
werden, ob ein Vorgehensmodell für diesen wissensintensiven Prozess geeignet ist. Wie
in FF2 erläutert, liefert das entwickelte Vergleichsframework eine wertvolle Grundlage
148
6.3 Einordnung in verwandte Arbeiten
für die Entwicklung eines Eignungsgrades für Vorgehensmodelle bzgl. verschiedener
Messgrößen.
149
7
Zusammenfassung und Ausblick
In dieser Arbeit wurde eine Übersicht über verschiedene Vorgehensmodelle aus unter-
schiedlichen wissensintensiven Domänen gegeben. Des Weiteren wurde ein Vergleichs-
Rahmenwerk entwickelt, um die verschiedenen Vorgehensmodelle miteinander zu ver-
gleichen. Dabei stellte sich heraus, dass Vorgehensmodelle ein wichtiges und vielseiti-
ges Hilfsmittel zur Unterstützung von Wissensarbeitern in wissensintensiven Prozessen
darstellen. Vorgehensmodelle ermöglichen eine Ordnung der Prozessabfolge eines
wissensintensiven Prozesses in verschiedene Projektphasen. Außerdem bieten sie
unterschiedliche Methoden zur Unterstützung der Wissensarbeiter an, wie z.B. das
Erstellen von Vorlagen in Form von Dokumenten für verschiedene Aufgaben. Dies er-
möglicht es den Wissensarbeitern, effizienter zu arbeiten und bessere Ergebnisse zu
erzielen. Um einen wissensintensiven Prozess für Wissensarbeiter zu vereinfachen,
ist der Einsatz eines passenden Vorgehensmodells deswegen empfehlenswert. Dabei
stellt sich automatisch die Frage, wie gut ein Vorgehensmodell für einen bestimmten
151
7 Zusammenfassung und Ausblick
wissensintensiven Prozess geeignet ist. Diese Frage konnte in dieser Arbeit nicht im
Detail beantwortet werden, allerdings bietet das geschaffene Vergleichs-Rahmenwerk
eine gute Ausgangsbasis für weitere Untersuchungen. Wie in Kapitel 6.2 bereits an-
gesprochen, lassen sich die Aspekte GA1, GA2, GA5 - GA9, sowie KIA1, KIA2, KIA5
- KIA10 für die Bewertung der Eignung eines Vorgehensmodells zur Unterstützung
eines wissensintensiven Prozesses verwenden. In weiteren Arbeiten könnten diese
Bewertungsgrößen um weitere Aspekte erweitert werden und ein Eignungsgrad zur Ver-
wendung von Vorgehensmodellen entwickelt werden. Des Weiteren könnte untersucht
werden, welche Auswirkungen eine Unterstützung von Vorgehensmodellen in Business
Process Management Systemen auf die wissensintensiven Prozesse hat und ob die
Wissensarbeiter dadurch eine erhöhte Produktivität und Verringerung der Komplexität
feststellen können.
152
Abbildungsverzeichnis
2.1 Entstehung von Wissen nach [Hub05] . . . . . . . . . . . . . . . . . . . . 8
2.2 Ablauf eines idealtypischen, wissensintensiven Prozesses nach [Hub05] . 11
2.3 Lebenszyklus eines wissensintensiven Prozesses nach [MKR13] . . . . . 12
2.4 Vorgehensmodell für Software Engineering Projekt nach [Bre] . . . . . . . 15
3.1 Vorgehensmodell für die Durchführung dieser Arbeit . . . . . . . . . . . . 19
3.2 Veranschaulichung der Komplexitätsklassen wissensintensiver Prozesse . 35
3.3 Markierung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Darstellung gefundener allgemeiner Aspekte . . . . . . . . . . . . . . . . 37
3.5 Darstellung gefundener wissensintensive Aspekte . . . . . . . . . . . . . 38
4.1
Vorgehensbausteine eines V-Modells XT für das Systementwicklungspro-
jekt(AG)nach[BMI] .............................. 41
4.2 Kanban-Board nach [ita] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Scrum Prozess nach [Sei] . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 VDI Richtlinie 2221 nach [Ins] . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Kybernetischer Prozess nach [Gir10b] . . . . . . . . . . . . . . . . . . . . 48
4.6 Prinzip Klinischer Behandlungspfade nach [RK07] . . . . . . . . . . . . . 50
4.7
Ausschnitt des klinischen Pfads zur Implantation von Hüftendoprothesen
nach [KWEG+07]................................ 51
4.8 Interaktion der verschiedenen Prozessgruppen des [Pro00] . . . . . . . . 53
5.1 Allgemeine Aspekte des V-Modells XT . . . . . . . . . . . . . . . . . . . . 60
5.2 Rollenkonzept des V-Modells XT nach [BMI] . . . . . . . . . . . . . . . . . 62
153
Abbildungsverzeichnis
5.3 Auszug aus der Vorlage für das Lastenheft . . . . . . . . . . . . . . . . . 65
5.4 Wissensintensive Aspekte des V-Modell XT . . . . . . . . . . . . . . . . . 67
5.5 Allgemeine Aspekte von Kanban . . . . . . . . . . . . . . . . . . . . . . . 72
5.6 Wissensintensive Aspekte von Kanban . . . . . . . . . . . . . . . . . . . . 77
5.7 Allgemeine Aspekte von Scrum . . . . . . . . . . . . . . . . . . . . . . . . 82
5.8 Wissensintensive Aspekte von Scrum . . . . . . . . . . . . . . . . . . . . 87
5.9 Allgemeine Aspekte der VDI Richtlinie 2221 . . . . . . . . . . . . . . . . . 91
5.10 Wissensintensive Aspekte der VDI Richtlinie 2221 . . . . . . . . . . . . . 94
5.11 Allgemeine Aspekte von AEP . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.12 Wissensintensive Aspekte von AEP . . . . . . . . . . . . . . . . . . . . . 103
5.13 Allgemeine Aspekte von klinischen Pfaden . . . . . . . . . . . . . . . . . 108
5.14 Wissensintensive Aspekte von klinischen Pfaden . . . . . . . . . . . . . . 112
5.15 Allgemeine Aspekte des PMBOK Guides . . . . . . . . . . . . . . . . . . 117
5.16 Wissensintensive Aspekte des PMBOK Guides . . . . . . . . . . . . . . . 121
5.17 Werteverteilung der Phasenabdeckung . . . . . . . . . . . . . . . . . . . 122
5.18 Werteverteilung der Prozessabdeckung . . . . . . . . . . . . . . . . . . . 123
5.19 Werteverteilung der Abstraktionsstufe . . . . . . . . . . . . . . . . . . . . 124
5.20 Werteverteilung des Detaillierungsgrad . . . . . . . . . . . . . . . . . . . 124
5.21 Werteverteilung des Branchenfokus . . . . . . . . . . . . . . . . . . . . . 125
5.22 Werteverteilung der Vorgehensweise . . . . . . . . . . . . . . . . . . . . . 125
5.23 Werteverteilung der Prozesssteuerung . . . . . . . . . . . . . . . . . . . . 126
5.24 Werteverteilung des Prozessergebnisses . . . . . . . . . . . . . . . . . . 126
5.25 Werteverteilung der Modellarchitektur . . . . . . . . . . . . . . . . . . . . 127
5.26 Werteverteilung der Spezialisierbarkeit . . . . . . . . . . . . . . . . . . . . 127
5.27 Werteverteilung der Modellkomplexität . . . . . . . . . . . . . . . . . . . . 128
5.28 Werteverteilung der Zuständigkeiten . . . . . . . . . . . . . . . . . . . . . 129
5.29 Werteverteilung der Wissenstätigkeit . . . . . . . . . . . . . . . . . . . . . 129
5.30 Werteverteilung der Prozessdauer . . . . . . . . . . . . . . . . . . . . . . 130
5.31 Werteverteilung des Sichtenmodells . . . . . . . . . . . . . . . . . . . . . 130
5.32 Werteverteilung der Lebenszyklus Abdeckung . . . . . . . . . . . . . . . . 131
5.33 Werteverteilung der Kommunikationsformen . . . . . . . . . . . . . . . . . 132
154
Abbildungsverzeichnis
5.34 Werteverteilung der Zielspezifikation . . . . . . . . . . . . . . . . . . . . . 132
5.35 Werteverteilung der Qualitätssicherungsmaßnahmen . . . . . . . . . . . . 133
5.36 Werteverteilung der Wissensdokumentation . . . . . . . . . . . . . . . . . 133
5.37 Werteverteilung der Problemkomplexität . . . . . . . . . . . . . . . . . . . 134
155
Tabellenverzeichnis
3.1 Ausprägungen der Phasenabdeckung nach [Ger99] . . . . . . . . . . . . 21
3.2 Ausprägungen der Prozessabdeckung nach [Fil05] . . . . . . . . . . . . . 22
3.3 Ausprägungen der Abstraktionsstufe nach [Fil05] . . . . . . . . . . . . . . 23
3.4 Ausprägungen des Detaillierungsgrads nach [Chr92] . . . . . . . . . . . . 24
3.5 Ausprägungen des Branchenfokus nach [Fil05] . . . . . . . . . . . . . . . 24
3.6 Ausprägungen der Vorgehensweisen nach [Fil05] . . . . . . . . . . . . . . 25
3.7 Ausprägungen der Prozesssteuerung nach [Fil05] . . . . . . . . . . . . . 26
3.8 Ausprägungen der Prozessergebnisse . . . . . . . . . . . . . . . . . . . . 26
3.9 Ausprägungen der Modellarchitektur nach [NS99] . . . . . . . . . . . . . . 27
3.10 Ausprägungen der Spezialisierbarkeit nach [NS99] . . . . . . . . . . . . . 28
3.11 Ausprägungen der Modellkomplexität . . . . . . . . . . . . . . . . . . . . . 28
3.12 Ausprägungen der Zuständigkeiten . . . . . . . . . . . . . . . . . . . . . . 29
3.13 Ausprägungen der Wissenstätigkeiten . . . . . . . . . . . . . . . . . . . . 30
3.14 Ausprägungen der Prozessdauer . . . . . . . . . . . . . . . . . . . . . . . 30
3.15 Ausprägungen des Sichtenmodells nach [Ger99] . . . . . . . . . . . . . . 31
3.16 Ausprägungen der Lebenszyklus Abdeckung nach [MKR13] . . . . . . . . 32
3.17 Ausprägungen der Kommunikationsformen . . . . . . . . . . . . . . . . . 33
3.18 Ausprägungen der Zielspezifikation . . . . . . . . . . . . . . . . . . . . . . 33
3.19 Ausprägungen der Qualitätssicherungsmaßnahmen . . . . . . . . . . . . 34
3.20 Ausprägungen der Wissensdokumentation . . . . . . . . . . . . . . . . . 35
3.21 Ausprägungen der Problemkomplexität . . . . . . . . . . . . . . . . . . . 36
157
Literaturverzeichnis
[All13]
ALLIANCE, Scrum: The State of Scrum: Benchmarks and Guidelines /
Scrum Alliance. 2013. – Forschungsbericht
[Ber02]
BERTHOLD, Axel:
Der fertigungsorientierte Modellierer FERMOD
als Erweiterung des Konstruktionssystems WISKON
. Fachbereich
Maschinenbau, Universität Kassel, Dissertation, 2002
[BMI]
BMI:
V-Modell XT
.
http://www.cio.bund.de/Web/DE/
Architekturen-und-Standards/V-Modell-XT/vmodell_xt_
node.html. – Letzter Zugriff: 22.06.2015
[BR05]
BROY, Manfred ; RAUSCH, Andreas: Das neue V-Modell XT: Ein
anpassbares Modell für Software und Systems Engineering. In:
Informatik
Spektrum 28 (2005), Nr. 3, S. 220–229
[Bre]
BREITNER, Michael:
Vorgehensmodell
.
http://www.enzyklopaedie-
der-wirtschaftsinformatik.de/lexikon/is-management/
Systementwicklung/Vorgehensmodell/index.html
. – Letzter
Zugriff: 22.06.2015
[BW15]
BRECHNER, Eric ; WALETZKY, James:
Agile Project Management with
Kanban. Redmond : Microsoft Press, 2015
[Chr92]
CHROUST, Gerhard:
Modelle der Software-Entwicklung
. München :
Oldenbourg Wissenschaftsverlag, 1992
159
Literaturverzeichnis
[Dav05]
DAVENPORT, Thomas H.:
Thinking for a Living: How to Get Better
Performances And Results from Knowledge Workers
. Boston : Harvard
Business School Press, 2005
[DCMR15]
DICICCIO, Claudio ; MARRELLA, Andrea ; RUSSO, Alessandro: Knowledge-
Intensive Processes: Characteristics, Requirements and Analysis of
Contemporary Approaches. In:
Journal on Data Semantics
4 (2015), Nr.
1, S. 29–57
[DP00]
DAVENPORT, Thomas H. ; PRUSAK, Laurence:
Working Knowledge: How
Organizations Manage what They Know
. Boston : Harvard Business
School Press, 2000
[Epp11]
EPPING, Thomas:
Kanban für die Softwareentwicklung
. Springer Berlin
Heidelberg, 2011
[ERZ14]
EIGNER, Martin ; ROUBANOV, Daniil ; ZAFIROV, Radoslav:
Modellbasierte
virtuelle Produktentwicklung. Springer Berlin Heidelberg, 2014
[FF03]
FUNKAT, Anne-Kathrin ; FUNKAT, Gert:
Prozessbasiertes Knowledge
Engineering in medizinischen Problemdomänen
, Technische Universität
Illmenau, Dissertation, 2003
[Fil05]
FILSS, Christian:
Vergleichsmethoden für Vorgehensmodelle
. Institut
für Software – und Multimediatechnik, Technische Universität Dresden,
Diplomarbeit, 2005
[FK07]
FRITZSCHE, Martin ; KEIL, Patrick:
Kategorisierung etablierter
Vorgehensmodelle und ihre Verbreitung in der deutschen Software-
Industrie, Technische Universität München, Forschungsbericht, 2007
[GB03]
GIRMSCHEID, Gerhard ; BUSCH, Torsten: Risikomanagement in
Bauunternehmen - Projektrisikomanagement in der Angebotsphase. In:
Bauingenieur (2003), Nr. 12, S. 571–580
[Ger99]
IFIP-IFAC TASK FORCE ON ARCHITECTURES FOR ENTERPRISE
INTEGRATION: GERAM: Generalised Enterprise Reference Architecture
and Methodology. 1999. – Forschungsbericht
160
Literaturverzeichnis
[Gir10a]
GIRMSCHEID, Gerhard: Anforderungs-Engineering-Prozessmodell (AEP) -
Teil 1: Modellentwicklung und Zielentwicklungsprozess. In:
Bauingenieur
(2010), Nr. 85, S. 197–203
[Gir10b]
GIRMSCHEID, Gerhard: Anforderungs-Engineering-Prozessmodell (AEP) -
Teil 2: Anforderungsentwicklungsprozess und Zielerreichungs-Controlling.
In: Bauingenieur (2010), Nr. 85, S. 204–209
[Hel]
HELFER, Thomas:
Bausteine der Wissensarbeit: Wissensmanagement
- Vernetzung von Wissen - Interdisziplinäre Kommunikation
.
http://www.avbstiftung.de/fileadmin/public/Thomas_
Helfer_Wissensarbeit.pdf. – Letzer Zugriff: 07.08.2015
[Hub05]
HUBE, Gerhard:
Beitrag zur Beschreibung und Analyse von Wissensarbeit
.
Institut für Arbeitswissenschaft und Technologiemanagement, Universität
Stuttgart, Dissertation, 2005
[Ins] Entwicklungsprozess: Vorgehensmodell nach VDI 2221
.
http://www.optimus-spitzencluster.de/
entwicklungsprozessvorgehensmodellnachvdi.pdf
. – Letzter
Zugriff: 22.05.2015
[ita] Kanban
.
http://www.it-agile.de/wissen/methoden/kanban/
.
– Letzter Zugriff: 22.06.2015
[JG]
JAVORNIK, Marko ; GRASER, Franz:
Agile Entwicklungsmethoden:
Innovation, Geschwindigkeit und Agilität in der Softwareentwicklung
.
http://www.elektronikpraxis.vogel.de/themen/
embeddedsoftwareengineering/management/articles/
459084/. – Letzer Zugriff: 26.07.2015
[KBT06]
KRIER, Claude ; BUBLITZ, Rolf ; TÖPFER, Armin: Explorative
Einführung und Auswirkungen von Klinischen Pfaden. In:
Erfolgreiches
Changemanagement im Krankenhaus
. Springer Berlin Heidelberg, 2006,
S. 135–166
161
Literaturverzeichnis
[Kom14]
KOMUS, Ayelt:
Status Quo Agile. Zweite Studie zu Verbreitung und Nutzen
agiler Methoden, Hochschule Koblenz, Forschungsbericht, 2014
[Kri87]
KRICKHAHN, Reinhard:
Die Wissensrepräsentationssprache OPS5
.
Wiesbaden : Vieweg+Teubner Verlag, 1987
[Kro10]
KROENERT, Nils:
Anforderungs-Engineering im Bauwesen
,
Eidgenössische Technische Hochschule Zürich, Dissertation, 2010
[KWEG+07]
KIRSCHNER, S. ; WITZLEB, W.-C. ; EBERLEIN-GONSKA, M. ;
KRUMMENAUER, F. ; GÜNTHER, K.-P.: Klinische Pfade. In:
Der Orthopäde
36 (2007), Nr. 6, S. 516–522
[LK12]
LEOPOLD, Klaus ; KALTENECKER, Siegfried:
Kanban in der IT: Eine
Kultur der kontinuierlichen Verbesserung schaffen
. München : Carl Hanser
Verlag, 2012
[MKR13]
MUNDBROD, Nicolas ; KOLB, Jens ; REICHERT, Manfred: Towards a
System Support of Collaborative Knowledge Work. In:
Business Process
Management Workshops
Bd. 132, Springer Berlin Heidelberg, 2013, S.
31–42
[MR14]
MUNDBROD, Nicolas ; REICHERT, Manfred: Process-Aware Task
Management Support for Knowledge-Intensive Business Processes:
Findings, Challenges, Requirements. In:
18th IEEE International
Enterprise Distributed Object Computing Conference Workshops and
Demonstrations (EDOCW), 2014, S. 116–125
[Nor99]
NORTH, Klaus:
Wissensorientierte Unternehmensführung: Wertschöpfung
durch Wissen. Wiesbaden : Gabler-Verlag, 1999
[NS99]
NOAK, Jörg ; SCHIENMANN, Bruno: Objektorientierte Vorgehensmodelle
im Vergleich. In: Informatik Spektrum 22 (1999), S. 166–180
[Opi04]
OPITZ, Egbert: Zur Notwendigkeit, Einführung und dauerhaften Nutzung
klinischer Pfade. In: Pflege & Gesellschaft 9 (2004), S. 91–99
162
Literaturverzeichnis
[Pha07]
PHAM, Phuong-Tam:
Auswirkungen der Einführung klinischer Pfade
auf den Behandlungsverlauf, insbesondere Organisation, Aufwand und
Kosten, Universität des Saarlandes, Dissertation, 2007
[PKR+07]
PÜHSE, Gerald ; KÜTTNER, Tina ; RAUSCH, Ansgar ; WENKE, Andreas
; HERTLE, Lothar ; ROEDER, Norbert: „Clinical Pathway“ Radikale
Prostatektomie: Keine Kochbuchmedizin. In:
Deutsches Ärzteblatt
104
(2007), Nr. 45, S. 3088–3091
[PP11]
PLEWAN, Hans-Jürgen ; POENSGEN, Benjamin:
Produktive
Softwareentwicklung. Heidelberg : dpunkt.verlag GmbH, 2011
[Pro00] A guide to the project management body of knowledge (PMBOK guide)
.
Newton Square : Project Management Institute, Inc., 2000
[PS98]
PFIFFNER, Martin ; STADELMANN, Peter:
Wissen wirksam machen
. Bern :
Haupt Verlag, 1998
[RK07]
ROEDER, Norbert ; KÜTTNER, Tina:
Klinische Behandlungspfade
. Köln :
Deutscher Ärzte-Verlag, 2007
[RVU+09]
RONELLENFITSCH, Ulrich ; VARGAS HEIN, Ortrud ; UERLICH, Manfred ;
DAHMEN, Alfred ; TUSCHY, Silja ; SCHWARZBACH, Matthias: Klinische Pfade
als Instrument zur Qualitätsverbesserung in der perioperativen Medizin. In:
Perioperative Medizin 1 (2009), Nr. 3, S. 164–172
[Sch07]
SCHWABER, Ken:
Agiles Projekmanagement mit Scrum
. Unterschleißheim
: Microsoft Press Deutschland, 2007
[Sei]
SEIBERT, Martin:
Das agile Vorgehensmodell Scrum
.
https://infos.
seibert-media.net/display/Websoftware/Scrum
. – Letzer
Zugriff: 22.06.2015
[SS13a]
SCHWABER, Ken ; SUTHERLAND, Jeff: The Scrum Guide. (2013).
http:
//www.scrumguides.org/. – Letzer Zugriff: 26.07.2015
[SS13b]
STACKPOLE SNYDER, Cynthia:
User’s Manual to the PMBOK Guide
.
Hoboken : John Wiley & Sons, 2013
163
Literaturverzeichnis
[Ste04]
STEIN, Sebastian:
Emergenz in der Softwareentwicklung - bereits
verwirklicht oder Chance?
, Hochschule für Technik und Wirtschaft
Dresden, Diplomarbeit, 2004
[UDT+09]
UERLICH, Manfred ; DAHMEN, Alfred ; TUSCHY, Silja ; RONELLENFITSCH,
Ulrich ; EVESLAGE, Karin ; VARGAS HEIN, Ortrud ; TÜRK-IHLI, Gertrud
; SCHWARZBACH, Matthias: Klinische Pfade – Terminologie und
Entwicklungsstufen. In:
Perioperative Medizin
1 (2009), Nr. 3, S. 155–163
[VDI93]
VERBAND DEUTSCHER INGENIEURE (VDI): VDI 2221 Methodik zum
Entwickeln und Konstruieren technischer Systeme und Produkte. 1993. –
VDI Richtlinie
[VMS] Vorgehensmodelle in der Softwareentwicklung
.
http://www.
scrum-kompakt.de/grundlagen-des-projektmanagements/
vorgehensmodelle-in-der-softwareentwicklung/
. – Letzer
Zugriff: 09.07.2015
[WK08]
WEBER, Edward P. ; KHADEMIAN, Anne M.: Wicked Problems, Knowledge
Challenges, and Collaborative Capacity Builders in Network Settings. In:
Public Administration Review 68 (2008), Nr. 2, S. 334–349
164
Name: Simon Stöferle Matrikelnummer: 754157
Erklärung
Ich erkläre, dass ich die Arbeit selbstständig verfasst und keine anderen als die angegebenen
Quellen und Hilfsmittel verwendet habe.
Ulm,den .............................................................................
Simon Stöferle
