Ein Anpassungskonzept basierend auf Bausteinen für Quality Gates

Transcrição

Gottfried Wilhelm
Leibniz Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Software Engineering
Ein Anpassungskonzept basierend auf Bausteinen
für Quality Gates
Masterarbeit
im Studiengang Informatik
von
Christian Peucker
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Dr. Heribert Vollmer
Betreuer: Dipl.-Math. Thomas Flohr
Hannover, 11. Juni 2007
Danksagung
Ich bedanke mich bei Herrn Dipl.-Math. Thomas Flohr für
die hervorragende Betreuung meiner Masterarbeit.
Zusammenfassung
Quality Gates werden in Unternehmen zur Prüfung der
Prozesskonformität,
Risikokontrolle,
Projektkontrolle,
Synchronisation verschiedener Teilprojekte oder Qualitätssicherung
eingesetzt. Sie trennen einzelne Phasen der Softwareentwicklung
und überprüfen deren Ergebnisse mit Hilfe einer Checkliste. Sind
alle Formalitäten erfüllt, wird am Ende eines Gates entschieden, ob
das Projekt in die nächste Phase der Entwicklung eintreten kann.
Quality Gates werden jedoch häufig, abhängig vom aktuellen
Projekt, unterschiedlich verwendet. Daher müssen sie an die
konkreten Projekteigenschaften angepasst werden. Diese Anpassung wird „Tailoring“ genannt. Häufig basieren Quality Gates
jedoch in den Organisationen auf unterschiedlichen Referenzprozessen. Bei diesen Basis-Referenzprozessen, wie dem StageGate-Prozess von Cooper, dem V-Modell XT oder dem ABB-GateModell ist ebenfalls eine Anpassung erforderlich. Im Rahmen dieser
Arbeit wird deshalb ein Anpassungskonzept für Quality Gates
basierend auf Bausteinen entwickelt. Die Anpassung wird auf
Grundlage des in der Steuerungs- und Regelungstechnik
verwandten Fuzzy-Logik-Ansatzes durchgeführt. Ziel der Arbeit ist
ein Quality-Gate-Tailoring-Assistent (QGT-Assistent) in Form einer
Java-Anwendung, mit dessen Hilfe der Tailoring-Vorgang unterstützt
werden kann.
Inhaltsverzeichnis
1
Einleitung ....................................................................................................... 1
1.1
Motivation / Hintergrund ........................................................................... 1
1.2
Zielsetzung............................................................................................... 1
1.3
Gliederung................................................................................................ 2
2
Quality Gates in der Softwareentwicklung.................................................. 3
2.1
Begriffsdefinitionen................................................................................... 3
2.1.1
Software-Prozess.............................................................................. 3
2.1.2
Prozessmodell / Vorgehensmodell.................................................... 3
2.1.3
Rolle / Aktivität / Artefakt ................................................................... 4
2.2
Definition Quality Gate ............................................................................. 5
2.2.1
Was ist ein Quality Gate?.................................................................. 5
2.2.2
Die Quality-Gate-Sitzung .................................................................. 5
2.3
Quality-Gate-Konzept der Leibniz Universität Hannover .......................... 7
2.3.1
Quality-Gate-Prozess........................................................................ 7
2.3.2
Rollen, Artefakte und Aktivitäten ....................................................... 8
2.3.3
NetQGate.......................................................................................... 9
2.4
Stage-Gate-Prozess von Cooper ............................................................. 9
2.4.1
Stages............................................................................................... 9
2.4.2
Gates ................................................................................................ 9
2.4.3
Stage-Gate-Prozess........................................................................ 11
2.4.4
Die dritte Generation des Stage-Gate-Prozesses ........................... 13
2.5
V-Modell XT ........................................................................................... 15
2.5.1
Zielsetzung...................................................................................... 15
2.5.2
Aufbau............................................................................................. 16
2.5.3
Klassifizierung / Tailoring ................................................................ 18
2.6
Quality-Gate-Konzept von Pfeifer / Schmidt........................................... 20
2.7
ABB Gate Modell.................................................................................... 22
3
Quality-Gate-Metamodell ............................................................................ 25
3.1
Was ist ein Metamodell? ........................................................................ 25
3.1.1
Vorteile von Metamodellen.............................................................. 27
3.2
Konzeptionelles Metamodell für Quality Gates....................................... 27
3.2.1
Das konzeptionelle Metamodell im Überblick.................................. 28
3.2.2
Das konzeptionelle Metamodell im Detail ....................................... 29
3.2.3
Konzeptionelles Metamodell: Übersicht (Paketdarstellung) ............ 35
3.2.4
Konzeptionelles Metamodell: Proof-of-Concept .............................. 36
4
Tailoring von Softwareprozessen .............................................................. 38
4.1
Definition „Tailoring“ ............................................................................... 38
4.2
Ablauf ..................................................................................................... 38
4.3
Rollen beim Tailoring ............................................................................. 39
4.4
Tailoring basierend auf Bausteinen........................................................ 40
5
Das Quality-Gate-Tailoringkonzept............................................................ 42
5.1
Fuzzy Logik ............................................................................................ 42
5.1.1
Linguistische Terme und linguistische Variablen ............................ 43
5.1.2
Zugehörigkeitsfunktionen ................................................................ 43
5.1.3
Logische Operatoren auf unscharfe Mengen .................................. 44
5.1.4
Fuzzy-Controller.............................................................................. 45
5.1.5
Fuzzifizierung.................................................................................. 46
5.1.6
Fuzzy-Inferenz ................................................................................ 46
5.1.7
Defuzzifizierung .............................................................................. 50
5.2
Anwendung des Fuzzy-Ansatzes auf das Tailoring für Quality Gates.... 53
5.2.1
Gründe für den Einsatz der Fuzzy Logik beim Tailoring.................. 53
5.2.2
Quality-Gate-Tailoring am Beispiel.................................................. 54
5.2.3
Interpretation des Fuzzy-Ergebnisses (Filter) ................................. 60
5.2.4
Aufgaben der Tailoringrollen ........................................................... 60
5.2.5
Diskussion des Tailoring-Ansatzes ................................................. 61
5.3
Quality Improvement Paradigm (QIP) .................................................... 64
5.3.1
QIP-Zyklus ...................................................................................... 65
5.3.2
QIP-Bezug zum Tailoring ................................................................ 67
6
Realisierung................................................................................................. 68
6.1
Eingesetzte Software ............................................................................. 68
6.2
Aufbau und Vorgehen beim QGT-Assistenten ....................................... 68
6.3
Datenbankschema ................................................................................. 69
6.4
Beschreibung des Assistenten ............................................................... 70
6.4.1
Projektprofil angeben ...................................................................... 71
6.4.2
Tailoring-Konfiguration anpassen ................................................... 72
6.4.3
Tailoring-Gesamtergebnis anzeigen ............................................... 73
6.4.4
Bearbeitung der Bewertungen aus der Datenbank ......................... 74
7
Zusammenfassung & Ausblick .................................................................. 79
7.1
Schwierigkeiten ...................................................................................... 79
7.2
Ausblick & Erweiterungsmöglichkeiten................................................... 79
7.3
Bewertung und Fazit .............................................................................. 80
8
Anhang ......................................................................................................... 82
8.1
Verwendete Kriterien und Projektmerkmale im QGT-Assistenten.......... 82
8.2
Literaturverzeichnis ................................................................................ 89
8.3
Abbildungsverzeichnis ........................................................................... 93
8.4
Tabellenverzeichnis ............................................................................... 95
8.5
Formelverzeichnis .................................................................................. 95
8.6
Inhalt der CD-ROM ................................................................................ 96
8.6.1
Installation des QGT-Assistenten.................................................... 96
8.6.2
Installation von Apache Derby zur Nutzung in Eclipse .................... 97
8.7
Aufgabenstellung ................................................................................... 98
8.8
Erklärung................................................................................................ 99
Thema: Ein Anpassungskonzept basierend auf Bausteinen für Quality Gates
1 Einleitung
1.1 Motivation / Hintergrund
Im Softwareentwicklungsprozess werden viele Fehler oft zu spät erkannt. Diese
späte Erkennung führt zu Behebungskosten, die exponentiell höher sind, als die
Kosten, die bei frühzeitiger Erkennung und Behebung der Fehler angefallen
wären. Daher werden Quality Gates in Organisationen oft zur Prüfung der
Prozesskonformität, Risikokontrolle, Projektkontrolle, Synchronisation verschiedener Teilprojekte oder Qualitätssicherung eingesetzt. Sie überprüfen
zwischen den einzelnen Phasen der Softwareentwicklung formal die Ergebnisse
der vorhergehenden Phase und entscheiden in einer Sitzung über den Fortgang
des Projektes.
Quality Gates werden jedoch häufig abhängig vom aktuellen Projekt verschieden
verwendet. Daher müssen sie auf die konkreten Projekteigenschaften angepasst
werden. Diese Anpassung wird „Tailoring“ genannt. Häufig basieren Quality Gates
jedoch in den Organisationen auf unterschiedlichen Referenzprozessen. Bei
diesen Basis-Referenzprozessen, wie dem Stage-Gate-Prozess von Cooper, dem
V-Modell XT oder dem ABB-Gate-Modell, ist ebenfalls eine Anpassung erforderlich.
Unterstützende Software, die speziell bei der Anpassung von Quality Gates helfen
kann, ist nur wenig vorhanden (z.B. V-Modell XT). In Unternehmen werden, wenn
überhaupt, klassische Projektmanagement-Werkzeuge zur Unterstützung von
Quality-Gate-Vorgängen verwendet.
1.2 Zielsetzung
Ziel dieser Arbeit ist die Erstellung eines Anpassungskonzeptes für Quality Gates.
Die Anpassung (Tailoring) der Quality Gates soll dabei an ein konkretes Projekt
erfolgen und benötigt dafür folgende vier Aspekte:
•
•
•
•
einen Referenzprozess (z.B. Stage-Gate-Prozess von Cooper),
ein Projektprofil,
Tailoring-Regeln und
Erfahrungen.
Zur Durchführung des Tailorings müssen Quality Gates zerlegt werden. Dazu wird
häufig das Bausteinprinzip, wie es z.B. im V-Modell XT zu finden ist, verwendet.
Ein Prozess wird dabei in verschiedene unabhängige Komponenten zerlegt, die
dann je nach Projektprofil und Tailoring-Regeln in dem angepassten Prozess
verwendet werden oder nicht. Im Rahmen dieser Arbeit wird zunächst ein
konzeptionelles Metamodell erstellt, welches aus der Literatur bekannte
Referenzprozesse darstellen kann.
Auf dieser Grundlage soll entsprechend ein Konzept für einen TailoringAlgorithmus für Quality Gates angefertigt werden. Verwendet wird dazu der in der
Steuerungs- und Regelungstechnik verwandte Ansatz der Fuzzy-Logik.
Masterarbeit: Christian Peucker
Seite 1
Anschließend soll dieser Anpassungs-Algorithmus in Form einer Java-SwingAnwendung implementiert werden.
Grundlegendes Ziel dieser Arbeit ist es also, sich von Quality-Gate-Prozessen in
„Einheitsmaßen“ zu lösen, und sich flexibleren Varianten von Prozessen, die an
die Erfordernisse des aktuellen Projektes angepasst werden können,
zuzuwenden.
1.3 Gliederung
Im zweiten Kapitel werden zunächst Begriffe definiert, die im Laufe der Arbeit
Verwendung finden. Es führt das Quality-Gate-Konzept ein, erläutert die
Einsatzmöglichkeiten in der Softwareentwicklung und bildet somit die Grundlage
für alle weiteren Kapitel. Ferner werden fünf Quality-Gate-Prozessmodelle
vorgestellt und beschrieben: das Quality-Gate-Konzept der Universität Hannover,
der Stage-Gate-Prozess von Cooper, das V-Modell XT, das Quality-Gate-Konzept
von Pfeifer/Schmidt und das ABB Gate Modell.
Aufbauend auf dem zweiten wird im dritten Kapitel, nach einer kurzen Definition
des Konzepts der Metamodellierung, ein Quality-Gate-Metamodell eingeführt.
Dieses Metamodell ist ein allgemeines Modell, aus dem Quality-Gate-Konzepte
abgeleitet werden können. Dabei werden die einzelnen Bausteine des Modells
erläutert. Die Ableitung eines Prozessmodells auf Grundlage des Metamodells
wird anschließend als Beispiel für den Stage-Gate-Prozess von Cooper durchgeführt.
Das vierte Kapitel dient der Einführung des Begriffes „Tailoring“. Es wird ein
Referenzmodell für das Tailoring mit dessen Bestandteilen vorgestellt. Außerdem
wird beschrieben auf welche Weise das Tailoring in den einzelnen Bausteinen des
Metamodells vollzogen werden kann. Weiterhin folgt eine Beschreibung
derjenigen Rollen, die am Tailoring beteiligt sind.
Innerhalb des fünften Kapitels wird das verwendete Quality-Gate-Tailoringkonzept
basierend auf Fuzzy-Logik dargelegt. Anfangs wird beschrieben, wie und in
welchen Bereichen Fuzzy-Logik eingesetzt wird. Es wird erläutert, wie ein FuzzyController aufgebaut ist und welche Schritte nötig sind, um Berechnungen mit Hilfe
der Fuzzy-Logik durchführen zu können. Der Fuzzy-Logik-Ansatz wird dann
anhand von Beispielen auf das Tailoring von Quality Gates übertragen und
bewertet. Am Ende des Kapitels wird auf das „Quality Improvement Paradigm“
eingegangen, welches eine Methode zur kontinuierlichen Qualitätsverbesserung
darstellt.
Kapitel 6 beschäftigt sich mit der Realisierung eines Assistenten in Form einer
Java Anwendung. Diese Anwendung setzt den im Kapitel 5 vorgestellten TailoringAnsatz um. Weiterhin ist das verwendete Datenbankschema und die
Funktionsweise des Assistenten Inhalt des sechsten Kapitels.
Im siebten Kapitel werden zunächst bei der Bearbeitung der Arbeit aufgetretene
Schwierigkeiten
aufgezeigt.
Anschließend
wird
erläutert,
welche
Erweiterungsmöglichkeiten bestehen. Die Arbeit endet mit einer abschließenden
Bewertung und einem Fazit.
Seite 2
2 Quality Gates in der Softwareentwicklung
Häufig stehen Unternehmen unter großem Zeit- und Erfolgsdruck. Aus diesem
Grund benötigen sie einen „generellen“ Prozess, der das jeweilige Projekt regelt
und beschleunigt. Das Quality-Gate-Konzept ist ein adäquates Mittel, um diese
Ziele zu erreichen.
Im folgenden Abschnitt werden zunächst einige Begriffe erläutert, die in späteren
Kapiteln Verwendung finden. Anschließend folgt eine Definition für Quality Gates
und der grundlegende Aufbau einer Quality-Gate-Sitzung an einem Beispiel.
Ferner werden verschiedene Prozessmodelle vorgestellt und erläutert. Dabei kann
es in einigen Modellen zu Überschneidungen kommen, da Quality-Gate-Prozesse
vom Grundaufbau sehr ähnlich sind.
2.1 Begriffsdefinitionen
In diesem Abschnitt wird erläutert, wie man einen Software-Prozess definiert und
was unter einem Vorgehensmodell zu verstehen ist. Ferner werden die Begriffe
„Rolle“, „Aktivität“ und „Artefakt“ eingeführt.
2.1.1 Software-Prozess
Kruchten [29] definiert einen Software-Prozess als einen Ablauf, der definiert,
„Wer Was Wann Wie tut“. Oft wird der Begriff verkürzt auch „Prozess“ genannt.
2.1.2 Prozessmodell / Vorgehensmodell
Nach Helmut Balzert [2] soll jede Softwareentwicklung in einem festgelegten
organisatorischen Rahmen erfolgen. Ein Prozessmodell - auch Vorgehensmodell
genannt - beschreibt einen solchen Rahmen.
In ihm wird festgelegt, welche Aktivitäten in welcher Reihenfolge von welchen
Personen erledigt werden, welche Ergebnisse (im Allgemeinen Artefakte genannt)
dabei entstehen und wie diese in der Qualitätssicherung überprüft werden.
Der Begriff „Vorgehensmodell“ wird in Wikipedia [40] folgendermaßen definiert:
„Ein Vorgehensmodell gliedert den Prozess des Organisierens in
verschiedene, strukturierte Phasen, denen wiederum entsprechende
Methoden und Techniken der Organisation zugeordnet sind. Aufgabe
eines
Vorgehensmodells
ist
es,
die
allgemein
in
einem
Gestaltungsprozess auftretenden Aufgabenstellungen und Aktivitäten in
ihrer logischen Ordnung darzustellen.“
Seite 3
2.1.3 Rolle / Aktivität / Artefakt
Im Folgenden sollen kurz die Begriffe Rolle, Aktivität und Artefakt definiert werden.
Rolle
Rollen repräsentieren das „Wer“ des Prozesses. Sie beschreiben, wie sich
Personen verhalten sollen und deren Verantwortlichkeiten und Aufgaben.
Aktivität
Aktivitäten sind die von einer Rolle auszuführenden Tätigkeiten. Ihre
grundlegenden Aufgaben liegen in der Beschreibung, „Wie“ Artefakte zu erstellen
oder zu bearbeiten sind.
Artefakt
Definition des Fraunhofer IESE [13]:
„Artefakte sind Ergebnisse im Projekt. Da es bei der Verwendung der
Begriffe Dokument, Objekt, Element, ... zu Verwechslungen kommen
kann, wird der Begriff Artefakt als generelle Bezeichnung für alle Typen
von Ergebnissen im Projekt verwendet. In Abgrenzung zum generelleren
Begriff Konfigurationselement, bezeichnen Artefakte keine Werkzeuge,
sondern ausschließlich die Ergebnisse.“
Artefakte werden durch die Ausführung einer Aktivität einer bestimmten Rolle
erstellt, geändert oder genutzt. Sie stellen das „Was“ im Software-Prozess dar.
Artefakte dienen einerseits als Input, andererseits als Output einer Aktivität, und
können die verschiedensten Formen annehmen, wie z.B. Reports, Quellcodes,
Vorlagen und andere.
Abbildung 1 (nach Cossentino et al [5]) stellt die drei beschriebenen Begriffe noch
einmal graphisch als Modell dar.
Abbildung 1: Modell für Rolle, Aktivität und Artefakt
Seite 4
2.2 Definition Quality Gate
Bevor auf spezielle Prozesse eingegangen wird, soll zunächst die Frage geklärt
werden, was Quality Gates sind und wozu sie in der Softwareentwicklung
verwendet werden. Anschließend wird erläutert, wie eine Quality Gate Sitzung
aufgebaut ist.
2.2.1 Was ist ein Quality Gate?
Quality Gates werden vorwiegend in Projekten eingesetzt, um ein Mindestmaß an
Qualität sicherzustellen. Sie trennen einzelne Phasen der Softwareentwicklung
und überprüfen die Ergebnisse bzw. die Leistungen aus diesen Phasen. Deshalb
werden Projekte durch Quality Gates besser strukturiert und das Risiko des
Scheiterns eines Projektes wird minimiert.
In den einzelnen Phasen gibt eine Deadline an, bis zu welchem Zeitpunkt die
Ergebnisse bzw. Dokumente abgegeben werden müssen. Anschließend folgt eine
Quality-Gate-Sitzung, die im nächsten Abschnitt beschrieben wird. Zu jedem Gate
existiert eine Checkliste, die festlegt, welche Anforderungen erfüllt sein müssen,
um in die nächste Phase eintreten zu können. Auf Grundlage der Checkliste wird
dann entschieden, ob das Quality Gate bestanden wird oder nicht.
Ein Ziel eines Quality Gates ist die Sicherstellung einer Mindestqualität. Durch die
Aufteilung des gesamten Prozesses in einzelne Phasen kann bei Nichtbestehen
eines Gates in eine frühere Phase zurückgesprungen werden, um dort
Nachbesserungen vornehmen zu können. Quality Gates bilden die Grundlage für
die Entscheidung, ob ein Projekt weitergeführt werden soll oder nicht. Projekte, die
sich als wenig sinnvoll erweisen, können somit frühzeitig abgebrochen werden.
Vorteilhaft ist weiterhin die erwähnte Deadline, da diese das Projekt zeitlich
begrenzt und damit einen gewissen Zeitdruck erzeugt.
2.2.2 Die Quality-Gate-Sitzung
Die Quality-Gate-Sitzung ist ein Treffen zwischen den Teammitgliedern, deren
Teamleitern und den Entscheidungsträgern (oft auch Gatekeeper genannt), die die
Prüfung der Dokumente vornehmen. Das Treffen findet in der Regel ein oder zwei
Tage nach der Deadline statt, so dass die Gatekeeper die Dokumente bereits
vorliegen haben. Die folgende Abbildung stellt als Beispiel die Struktur der QualityGate-Sitzung dar, wie sie beim Softwareprojekt der Universität Hannover
vollzogen wird.
Seite 5
deliverables
demands
checklist
Collect
documents
guides
QG Session
stop
improve
deliverables
protocol
can pass
(no flaws)
can pass
(minor flaws)
failed
(major flaws)
correct flaws
Next Phase
Abbildung 2: Quality-Gate-Prozess
In einer Quality-Gate-Sitzung werden zum einen die fertig gestellten Dokumente
und zum anderen die Checkliste benötigt. Die Gatekeeper überprüfen die
Dokumente anhand der Checkliste Punkt für Punkt und treffen am Ende der
Sitzung eine Entscheidung. Die Entscheidung kann hinsichtlich der speziellen
Prozesse, die in den folgenden Abschnitten erläutert werden, unterschiedlich
ausfallen. Dabei kann es beispielsweise folgende Ausgänge geben:
•
•
•
die Dokumente haben alle Anforderungen auf der Checkliste erfüllt und das
Projekt kann in die nächste Projektphase eintreten (no flaws)
einige der Checklistenpunkte wurden nicht erfüllt, aber das Projekt kann mit
Korrekturauflagen in die neue Phase eintreten (minor flaws)
die Dokumente erfüllen die Anforderungen nicht und das Team muss
nachbessern, um das Gate in einer neuen Sitzung zu bestehen (major
flaws)
Ein Quality Gate wird endgültig nicht bestanden und das Projekt wird gestoppt,
wenn das Team das Gate mehrmals nicht besteht. Während der Sitzung wird
kontinuierlich Protokoll geführt. Es wird protokolliert, welches Team an der Sitzung
teilgenommen hat, wann die Sitzung stattfand, welche Checklistenpunkte erfüllt
worden sind und ob das Gate bestanden wurde.
Seite 6
2.3 Quality-Gate-Konzept der Leibniz Universität Hannover
Der erste Quality-Gate-Ansatz stützt sich auf ein Modell, welches in der Universität
Hannover im Fachgebiet „Software Engineering“ entwickelt wurde und speziell für
den Einsatz in der Softwareentwicklung konzipiert ist. Das Modell wird dort
innerhalb eines Softwareprojekts eingesetzt, um den Studenten die Konzepte des
Quality-Gate-Ansatzes näher zu bringen und reale Bedingungen in der
Softwareentwicklung zu simulieren.
In diesem Ansatz wird die grundlegende Struktur von Quality Gates mit Phasen
und Gates berücksichtigt. In den folgenden Abschnitten wird beschrieben, wie der
Referenzprozess aufgebaut ist und wie ein konkreter Prozess aussehen kann.
Weiterhin werden die an dem Prozess beteiligten Rollen und deren Aktivitäten
näher erläutert. Am Ende folgt eine kurze Beschreibung des an der Universität
Hannover entwickelten Tools „NetQGate“, welches die Softwareentwicklung mit
Hilfe von Quality Gates unterstützt.
2.3.1 Quality-Gate-Prozess
Der Quality-Gate-Referenzprozess wird in der Abbildung 3 abgebildet:
Revise activity
[conditional go]
[conditional go]
[go]
Phase 1
Revise activity
[stop]
[major rework]
[go]
[go]
Phase 2
Phase N
[stop]
[stop]
[major rework]
[major rework]
Abbildung 3: Quality-Gate-Referenzprozess [12]
Der Referenzprozess besteht aus N Phasen und N Gates, die jeweils auf eine
Phase folgen. Wird eine Phase beendet, so wird sie anhand eines Quality Gates
bewertet. Dabei wird eine Quality-Gate-Sitzung abgehalten, die zu unterschiedlichen Ergebnissen führen kann.
Wenn alle Anforderungen erfüllt sind ([go]-Zweig), gilt das Projekt als bestanden
und tritt in die nächste Phase ein. Bei nicht vollständiger Erfüllung muss zusätzlich
nachgebessert werden ([conditional go]). Sind größere Mängel vorhanden, wird
die vorherige Phase wiederholt ([major rework]) oder aber das Projekt wird
endgültig gestoppt ([stop]). Ansonsten müssen in der folgenden Phase neue
Anforderungen erfüllt werden. Sind N Phasen erfolgreich beendet worden, so
endet das Projekt.
Abbildung 4 zeigt einen konkreten Quality-Gate-Prozess als Beispiel, in dem der
Referenzprozess an die gegebenen Projektbedingungen angepasst wurde. Diese
Anpassung wird auch „Tailoring“ genannt und in einem späteren Kapitel näher
erläutert. Der Prozess besteht aus drei Phasen und drei Gates. Die Anpassung
besteht darin, dass in diesem Fall das Weiterkommen bei geringen Mängeln
Seite 7
entfällt. Ein Bestehen der Phase kann nur erreicht werden, wenn auch alle
Anforderungen komplett erfüllt wurden.
[go]
Spezifikation
Coding
[stop]
[major rework]
[go]
[go]
Design
[stop]
[stop]
[major rework]
[major rework]
Abbildung 4: Ein konkreter Quality-Gate-Prozess [12]
Die Vorteile des Quality-Gate-Prozesses liegen besonders in der Einfachheit, da
formale Überprüfungen leicht vorgenommen und Checklisten auch von unerfahrenen Gatekeepern verwendet werden können.
2.3.2 Rollen, Artefakte und Aktivitäten
In dem Quality Gate Prozess können vier Rollen identifiziert werden: Team Expert,
Team Quality Agent, Gatekeeper und das Quality Management. Die Aufgaben
bzw. Aktivitäten der jeweiligen Rolle werden in der folgenden Tabelle dargestellt:
Rolle
Team Expert
(TE)
Person / Abteilung
• Mitglied des Teams
Team Quality
Agent (TQA)
•
•
Quality Agent des
Teams
ansonsten der
Teamleiter
Aufgaben / Aktivitäten
• ist bei der Quality GateSitzung anwesend
• besitzt Einspruchsrecht
•
•
•
•
•
Gatekeeper
•
•
•
Quality
Management
(QM)
•
•
stellt die Qualität der
Dokumente vor Abgabe sicher
bestimmt die TE
gibt die richtigen Dokumente
zum richtigen Zeitpunkt ab
ist bei der Quality GateSitzung anwesend
hat Einspruchsrecht
Quality Agent eines
anderen Teams
Delegierter Quality
Agent vom Quality
Management
Stakeholder
•
•
prüft die Dokumente
fällt in der Quality GateSitzung Entscheidung über
Fortgang des Projektes
Klassisches
Qualitätsmanagement
ansonsten
Gatekeeper
•
konfiguriert und maßschneidert
den Quality-Gate-Prozess
bestimmt die Gatekeeper
sammelt Managementdaten
•
•
Tabelle 1: Rollen und Aktivitäten beim Quality Gate
Zusätzlich zu den Rollen und deren Aufgaben gibt es im Quality-Gate-Prozess
noch drei verschiedene Artefaktklassen: Deliverables (Ergebnisse / Leistungen),
Checklisten und Protokolle. Die Deliverables sind im Normalfall einfache
Dokumente. Die Checklisten bestehen aus Aspekten, die die Deliverables
Seite 8
überprüfen, wogegen die Protokolle die getroffenen Entscheidungen und Ergebnisse in einem Quality Gate dokumentieren.
2.3.3 NetQGate
Im Rahmen einer Bachelorarbeit an der Universität Hannover von Jens Greive [16]
wurde die Webanwendung „NetQGate“ entwickelt. Diese Anwendung wurde
erstellt, um die aufwändigen realen Quality-Gate-Sitzungen virtuell zu
unterstützen. Dabei ist das System so aufgebaut, dass geforderte Dokumente bis
zu einer bestimmten Deadline von den Team-Mitgliedern im System abgelegt und
Checklisten zum Überprüfen der Dokumente von dem Quality-Management
erstellt und verwendet werden können. Mit diesem Tool sollen die ebenfalls
aufwändigen Terminabsprachen zwischen allen Beteiligten und der Aufwand der
Betreuer reduziert werden.
In einer späteren Masterarbeit von Daniel Scholz [33] wurden dann Erweiterungen
zum vorigen NetQGate-Konzept, wie z.B. das Tailoring (Anpassen) von
Checklisten auf das jeweilige Projektprofil, hinzugefügt.
2.4 Stage-Gate-Prozess von Cooper
Ein weiteres Modell, welches Quality Gates in der Softwareentwicklung umsetzt,
ist der Stage-Gate-Prozess von Robert G. Cooper [4]. Es ist ein konzeptionelles
und operatives Modell, um Produkte von der Idee bis zur Einführung leiten und
kontrollieren zu können. Ziel des Prozesses ist die Verbesserung der Effektivität
und Effizienz und die Risikominimierung bei der Entwicklung eines neuen
Produktes. Der Stage-Gate-Prozess besteht aus so genannten „Stages“ und
„Gates“, die im Folgenden näher erläutert werden sollen.
2.4.1 Stages
Beim Stage-Gate-Prozess wird der Entwicklungsprozess in eine vorher festgelegte
Anzahl von „Stages“ eingeteilt. Jedes Stage besteht aus parallelen Aktivitäten, die
von Menschen aus verschiedenen funktionalen Bereichen des Unternehmens
durchgeführt werden. Ein Stage ist somit vergleichbar mit einer Phase im
Entwicklungsprozess. In jeder der Phasen werden Leistungen und Ergebnisse
erzielt, die wichtig sind, um in folgende Phasen eintreten zu können. Im Normalfall
ist jede Phase teurer als die Vorige, daher kann der Prozess als inkrementell
angesehen werden.
2.4.2 Gates
Vor den einzelnen Stages kontrollieren so genannte „Gates“ den Prozess. Sie
werden in Meetings abgehalten und dienen als Entscheidungs- und
Qualitätskontrollpunkte, bei denen entschieden wird, ob das Eintreten in eine neue
Phase (Stage) ermöglicht wird oder nicht. Dieser Entscheidungspunkt wird in der
Literatur auch oft „go/kill“-Entscheidungspunkt genannt, da er sowohl für die
Weiterführung, aber auch für das Abbrechen eines Projektes verantwortlich sein
kann. Damit die Entscheidungen auch sinnvoll und angemessen sind, müssen
Gates gut strukturiert sein. Dafür benötigt man laut Cooper folgende
Hauptkomponenten:
Seite 9
1. Ergebnisse/Leistungen (engl. Deliverables)
Die Ergebnisse bzw. Leistungen werden im Voraus für jedes Gate definiert. Sie
beinhalten die Ergebnisse, die das Team und der Projektleiter während der
entsprechenden Entwicklungsphase erzielen und dann beim nächsten Gate
vorlegen müssen. Die Aktivitäten des Teams in einer Phase (Stage) müssen sich
daher genau auf diese Ergebnisse beziehen. Die Liste von Ergebnissen für ein
Gate ist die Menge an Zielen für das Team.
2. Kriterien (engl. Criteria)
Damit die Entscheidungsträger (Gatekeeper) sinnvolle Entscheidungen treffen
können, werden Kriterien zur Beurteilung benötigt. Die Kriterien überprüfen die
abgegebenen Ergebnisse und Leistungen des Teams. Daher müssen sie für die
beteiligten Personen einsehbar und verständlich formuliert sein, damit die
Erwartungen für die jeweilige Phase geklärt sind. Die Kriterien sind für gewöhnlich
in Checklisten formuliert, die von den Gatekeepern überprüft werden. Dabei gibt
es Kriterien, die bei jedem Gate verwendet werden, aber auch Kriterien, die von
Gate zu Gate verschieden sind. Desweiteren werden Kriterien in „must-meet“- und
„should-meet“-Kriterien unterschieden. „Must-meet“-Kriterien müssen bei der
Überprüfung erfüllt sein und können bei Nicht-Erfüllung ein Stoppen des Projektes
verursachen. „Should-meet“-Kriterien hingegen sind erwünschte Eigenschaften
des Projekts, jedoch ist ein „Nein“ noch kein kill-Kriterium.
3. Outputs
Outputs enthalten zum einen die Ergebnisse und Entscheidungen des GateMeetings und zum anderen einen Plan, der vorgibt, was als Nächstes zu tun ist
und welche Leistungen bis zum nächsten Gate erbracht werden sollen. Diese
Outputs dienen dazu, das Resultat des Gates deutlich festzulegen. Beim StageGate-Prozess gibt es vier mögliche Entscheidungen aus einem Gate-Meeting:
• „Go“: Das Projekt kann in die nächste Phase eintreten und die benötigten
Ressourcen wurden von den Gatekeepern festegelegt.
• „Kill“: Das Projekt wird gestoppt und es soll keine weitere Arbeit investiert
werden.
• „Hold“: Das Projekt hat das Gate erfolgreich bestanden, aber es stehen
nicht die nötigen Ressourcen zur Verfügung, da diese anderen Projekten
zugeordnet sind. Es wird solange zurückgestellt, bis wieder genügend
Ressourcen vorhanden sind.
• „Recycle“: Das Gate wurde nicht erfolgreich passiert, aber es darf
nachgebessert werden, indem man die Phase wiederholt und besser auf
die geforderten Leistungen eingeht.
Am Ende eines Gates gibt es auf jeden Fall eine Entscheidung, da es keine
Möglichkeit gibt, diese aufzuschieben.
Mit Hilfe der Darstellung in Abbildung 5 kann man die drei Hauptkomponenten
eines Gates in Zusammenhang bringen.
Deliverables
Criteria
Outputs
Abbildung 5: Zusammenhang der Gate-Komponenten
Seite 10
Die Leistungen (Deliverables) werden mit Hilfe von Kriterien überprüft. Anhand
dieser Kriterien (Criteria) wird eine Entscheidung getroffen, die zu Ergebnissen in
Form von Outputs führen.
2.4.3 Stage-Gate-Prozess
Der Stage-Gate-Prozess ist ein Prozess, der nicht strikt auf die Entwicklung von
Software festgelegt ist, sondern für jede Art von Produktentwicklungen konzipiert
wurde. Abbildung 6 stellt einen typischen Stage-Gate-Prozess dar.
Discovery
Driving new Products to Market
Idea Screen
Gate 1 Second
Screen
Stage 1
Scoping
Gate 2
Go To
Development
Stage 2
Build
Business Case
Gate 3
Go To
Testing
Stage 3
Development
Gate 4
Go To
Launch
Stage 4
Testing &
Validation
Gate 5
Stage 5
Launch
Post-Launch
Review $
Abbildung 6: Stage-Gate-Prozess von Cooper
Die einzelnen Stages und Gates in der Abbildung werden nun näher erläutert:
Discovery Stage
Gute Ideen sind der Ausgangspunkt für die Entwicklung eines erfolgreichen
Produktes. Deshalb ist diese Phase zu Anfang des Stage-Gate-Prozesses wichtig
für alle Folgenden. Das Ziel dieser Phase ist es, den Markt auf Chancen und
Möglichkeiten zu untersuchen, um ein neues Produkt gewinnbringend unterzubringen.
Gate 1: Idea Screen
In diesem Gate wird entschieden, ob die Produkt-Idee gut genug ist, um auf dem
Markt zu bestehen. Bei einer „go“-Entscheidung wird das Projekt an dieser Stelle
geboren. In diesem Gate werden außerdem die „must-meet“ und „should-meet“
Kriterien festgelegt, welche sich z.B. mit der Nutzbarkeit und strategischen
Anpassung befassen. Finanzielle Kriterien werden in diesem Gate noch nicht
betrachtet.
Stage 1: Scoping
In dieser Phase liegt der Blickpunkt auf dem Ermitteln von technischen
Projektdetails. Außerdem steht eine vorausgehende Marktbeurteilung im
Vordergrund, in der z.B. Recherchen und Gespräche mit Schlüsselkunden
Seite 11
stattfinden. Ziel dieser Phase ist die Ermittlung von Marktgröße, Marktpotential
und eine erste oberflächliche Finanzierungsanalyse.
Gate 2: Second Screen
Das Second-Screen-Gate kann als eine Wiederholung des Gate 1 angesehen
werden, da das Projekt mit Hilfe von zusätzlich gewonnenen Informationen neu
bewertet wird. Die in Gate 1 festgelegten Kriterien werden noch einmal überarbeitet und neue Kriterien werden hinzugefügt. Wird das Gate erfolgreich
bestanden, so kommt das Projekt in eine aufwändigere Phase.
Stage 2: Building the Business Case
Stage 2 öffnet die Tür zur Entwicklung des Produktes und legt die
Produktdefinition fest. In dieser Phase werden der Zielmarkt, die Beschreibung
des Produktkonzepts, die Spezifikation, die Produktvorteile und die Festlegung der
Produktfeatures definiert. Die User-Requirements werden dabei auf technische
Realisierbarkeit untersucht. Ein erster Prototyp kann, falls erwünscht, erstellt
werden. Abschließend sollte ein detaillierter Finanzierungs- und Projektplan
festgelegt werden.
Gate 3: Go to Development
Dieses Gate ist das letzte Gate vor der eigentlichen Entwicklung des Produktes.
Somit ist es der letzte Entscheidungspunkt, an dem das Projekt gestoppt werden
kann, bevor die kostenintensiven Phasen bearbeitet werden. Außerdem werden
in dem Gate 3 die Produktdefinitionen festgehalten und das Team inkl. Teamleiter
festgelegt.
Stage 3: Development
Die Entwicklungsphase beschäftigt sich mit der Realisierung des
Entwicklungsplans und der physischen Entwicklung des Produktes. Daher ist
diese länger als die Vorherigen. Um dennoch eine Kontrolle über erzielte
Ergebnisse zu erhalten und die Phase in überschaubarere Teile zu splitten,
können Meilensteine eingesetzt werden. Diese sind jedoch nicht gleichzusetzen
mit Gates, da sie keine „go/kill“-Entscheidungen beinhalten. Am Ende der Phase
steht als Ergebnis ein getesteter Prototyp des Produktes zur Verfügung. Weiterhin
kann der Prototyp auch an potentielle Kunden weitergeleitet werden, um
entsprechendes Feedback zu erhalten. Ein neuer Finanzplan kann hier ebenfalls
festgelegt werden.
Gate 4: Go to Testing
In diesem Gate wird überprüft, ob alle Leistungen des erstellten Produkts
qualitätsbewusst durchgeführt wurden und konsistent mit der Spezifikation sind.
Außerdem wird untersucht, ob sich das Projekt noch im Finanzplan bewegt.
Stage 4: Testing and Validation
Hier wird die komplette Produktrealisierung genauer unter die Lupe genommen,
indem Tests und Validierungen durchgeführt werden. Zu der Produktrealisierung
gehört einerseits das Produkt selbst und andererseits der Produktionsprozess und
die Kundenakzeptanz. Stage 4 dient außerdem der Marktanalyse, indem
Markttests mit dem Produkt durchgeführt werden.
Seite 12
Gate 5: Go to Launch
Dieses letzte Gate öffnet das Tor zur Einführung des Produktes auf dem Markt
und dessen Produktion. Dabei werden speziell die gewonnenen Ergebnisse und
Informationen aus der Testing- and Validation-Phase analysiert. Es wird
beispielsweise geprüft, wie der zu erwartende Gewinn zu beurteilen ist und ob die
Markteinführungspläne angemessen sind.
Stage 5: Launch
Die letzte Phase ist die Einführungsphase und bezieht die Durchführung des
Marketingeinführungs- und Produktionsplans ein. Nach Cooper ist das Risiko an
dieser Stelle des Prozesses jedoch gering, wenn alle vorherigen Phasen und
Gates eingehalten wurden.
Post-Launch Review
Einige Zeit nach der Markteinführung des Produkts folgt das „Post-Launch
Review“. In dieser Phase wird das Projekt beendet und z.B. analysiert, wie sich
das Produkt auf dem Markt durchgesetzt hat, welche Kosten dadurch entstanden
sind und wie die Prozessdurchführung im Projekt geklappt hat. Die daraus
gewonnenen Informationen können dann als Prozessweiterentwicklung für
zukünftige Projekte verwendet werden.
2.4.4 Die dritte Generation des Stage-Gate-Prozesses
Der bisher beschriebene Prozess stellte die zweite Generation des Stage-GateProzesses dar, der heutzutage große Verwendung findet. Die erste Generation
tauchte schon 1960 als „phased review process“ auf, welcher stark technikbezogen war. Nach jeder Phase wurde ein aufwändiges Review durchgeführt, um
zu überprüfen, ob die Aufgaben auch richtig erfüllt wurden.
Stage-Gate-Prozesse sind jedoch so aufgebaut, dass sie ständig weiterentwickelt
werden können. Cooper stellt daher noch eine dritte Generation vor, welche den
Prozess beschleunigt. Sein Konzept besteht aus sechs fundamentalen „F’s“, die
im Folgenden näher erläutert werden sollen.
Flexibility
Der Prozess soll möglichst flexibel gestaltet werden, um sich so gut wie möglich
an die gegebene Projektsituation anpassen zu können. So können Phasen und
Gates ausgelassen, gesplittet, kombiniert oder hinzugefügt werden. Dabei kann
das Risiko-Level einen ausschlaggebenden Hinweis geben, ob ein größerer oder
kleinerer Prozess benötigt wird. Bei kleinen Projekten mit geringerem Risiko
könnte ein schlankerer Prozess mit kombinierten Phasen und Gates sinnvoll sein,
um den Prozess zu beschleunigen. Bei großen Projekten sollte ggf. ein größerer
Prozess eingesetzt werden, um bestmögliche Qualität zu gewährleisten.
Fuzzy Gates
Der Begriff Fuzzy in diesem Zusammenhang kann mit “Fuzzy Logic” aus der
Mathematik verglichen werden. Auf den Stage-Gate-Prozess angewandt können
bspw. die Entscheidungen in den Gates nicht nur binäre Werte, also erfüllt oder
nicht erfüllt, sondern auch Status dazwischen annehmen. So kann ein Gate
bestanden werden, wenn auch nicht alle Leistungen erfüllt worden sind, aber der
Grad an Erfüllung über einem bestimmten Schwellenwert liegt. Die nicht erfüllten
Seite 13
Leistungen können dann in der nachfolgenden Phase „nebenbei“ bearbeitet
werden. Der Begriff „Fuzzy“ wird in dem Kapitel 5.1 noch näher erläutert.
Fluidity
“Fluidity” meint, dass der Prozess weichere Übergänge zwischen den Phasen
bekommen soll. Um einen fließenden Übergang zu erreichen, werden Aktivitäten
aus der nächsten Phase schon begonnen, bevor die Vorherige beendet wurde.
Lange Bearbeitungszeiten für bestimmte Aktivitäten können so schon in der Phase
zuvor begonnen werden. Die einzelnen Phasen können sich somit an einigen
Stellen überlappen. Dieser Ansatz ist ähnlich zu dem Fuzzy-Ansatz, in dem einige
Aktivitäten in die nachfolgende Phase verschoben werden können.
Focus
Das Fokus-Konzept bedeutet, dass man bei vielen Projekten Priorisierungen
vornehmen muss, indem man bessere Projekte bevorzugt. Schwache Projekte
werden an den Gates aussortiert und die Ressourcen können so diesen
profitableren Projekten zugeordnet werden.
Facilitation
Für Erleichterung während des Stage-Gate-Prozesses kann ein spezieller
Prozess-Manager sorgen, der sicherstellt, dass der Prozess effizient und effektiv
arbeit. Er moderiert jede Gate-Sitzung, agiert als eine Art Schiedsrichter und stellt
sicher, dass die Gatekeeper die Regeln befolgen. Außerdem soll er die ProjektTeams unterstützen und für Prozessverbesserung sorgen. Gerade bei großen
Firmen ist dies ein full-time Job und sollte somit immer von einer Person
durchgeführt werden, die Überblick über alle Projekte besitzt.
Forever Green
Die Idee hier ist, dass der Stage-Gate-Prozess immer wieder weiterentwickelt
werden muss. Ein Problem z.B. ist es, dass Projekt-Mitglieder nicht immer zur
selben Zeit am selben Ort sein können, um ein Gate-Meeting abzuhalten. Dafür
kann eine web-basierte Softwarelösung gefunden werden, die die Kommunikation
zwischen den Mitgliedern unterstützt. Das bereits erwähnte NetQGate stellt eine
solche Softwarelösung dar.
Seite 14
2.5 V-Modell XT
Das V-Modell [24] ist ein Vorgehensmodell zum Planen und Durchführen von
Projekten. Dabei definiert es die in einem Projekt zu erstellenden Ergebnisse und
beschreibt die konkreten Vorgehensweisen, mit denen die Ergebnisse erarbeitet
werden. Außerdem werden die Verantwortlichkeiten innerhalb des Projekts
festgelegt. Es regelt also detailliert „Wer“ „Wann“ „Was“ in einem Projekt zu tun
hat.
Das V-Modell hat militärischen Ursprung und wurde erstmals 1993 im Sinne einer
„zivilen“ Fassung von der KBSt 1 erstellt. Aufgrund von neuen Softwareentwicklungsansätzen wurde 1997 eine Überarbeitung des Modells mit dem
Namen „V-Modell 97“ veröffentlicht, welches seitdem für jegliche Softwareentwicklung in der Bundesregierung zur Anwendung empfohlen wurde.
Das derzeitig aktuelle V-Modell XT wurde 2005 im Zuge von neuen Erkenntnissen
in der Softwareentwicklung erstellt. XT steht dabei für Extreme Tailoring, welches
die Möglichkeit der Anpassung an verschiedene Projekte und Organisationen
ermöglicht. Das Tailoring des V-Modells stellt ein Hauptkonzept des neuen
Modells dar und wird in einem späteren Abschnitt näher erläutert.
2.5.1 Zielsetzung
Die Durchführung des V-Modell XT verfolgt nachstehende Ziele:
•
Projektrisiken werden minimiert, indem das Modell standardisierte
Vorgehensweisen vorgibt, zugehörige Ergebnisse beschreibt und die
verantwortlichen Rollen festlegt. Dadurch wird die Planbarkeit des
Prozesses verbessert und die Projekttransparenz erhöht. Risiken werden
so schnell erkannt und können durch Steuerungsmaßnahmen eingedämmt
werden.
•
Das V-Modell XT stellt eine Verbesserung und Gewährleistung von Qualität
sicher. Durch definierte Zwischenergebnisse kann die Qualität schon
frühzeitig überprüft werden. Die Überprüfung kann durch die
Vereinheitlichung leichter und verständlicher durchgeführt werden.
•
Durch die Anwendung des V-Modells lassen sich der Aufwand und die
Kosten, die bei der Herstellung, dem Betrieb und der Pflege eines Systems
entstehen, besser einschätzen und steuern. Das Projekt ist somit
kalkulierbar und Kostenrisiken wird vorgebeugt.
•
Durch das festgelegte Modell wird die Kommunikation zwischen allen
Beteiligten verbessert. Bestandteile und Begrifflichkeiten werden durch das
V-Modell definiert und können so Reibungsverluste reduzieren.
1
KBSt: Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der
Bundesverwaltung
Seite 15
2.5.2 Aufbau
Der Aufbau wurde mit der Einführung des V-Modell XT grundlegend verbessert.
Um die Anpassbarkeit an konkrete Projekte mit speziellen Projekteigenschaften zu
gewährleisten, wurde das V-Modell in einzelne Bausteine zerlegt. Vordefinierte
Ablaufrahmen beschreiben, welche dieser Bausteine in einer konkreten
Projektkonstellation zum Einsatz kommen und in welcher Reihenfolge die
Ergebnisse zu erarbeiten sind.
Für die Struktur des V-Modells XT sind folgende Elemente von Bedeutung:
• Projekttypen
• Vorgehensbausteine
• Projektdurchführungsstrategien
• Entscheidungspunkte
Die einzelnen Elemente sollen nun näher erläutert werden:
Projekttypen
Nicht jedes Projekt läuft nach dem gleichen Schema ab. Daher muss ein Projekt
anhand der Projekteigenschaften in Projekttypen klassifiziert werden. Die
wichtigsten Merkmale zu einem Projekt sind der Projektgegenstand und die
Projektrolle.
Bei dem Projektgegenstand wird dabei zwischen Systementwicklung und
Einführung/Pflege eines organisationsspezifischen Vorgehensmodells unterschieden. Im Fall der Systementwicklung kann man aus fünf Systemtypen wählen
(siehe Abbildung 7).
Abbildung 7: Von den Projektmerkmalen zur Projektdurchführungsstrategie
Seite 16
Die Projektrollen lassen sich in drei Klassen einteilen. Die erste Projektrolle ist
AG/AN, in der genau ein V-Modell-Projekt durchgeführt wird. In der Projektrolle
AG wird die Systemerstellung auf Grundlage von festgelegten Anforderungen an
einen oder mehrere Auftraggeber vergeben. In der letzten Klasse AN wird ein
Systementwicklungsprojekt auf Basis der vom Auftraggeber festgelegten
Anforderungen durchgeführt.
Aus dem Projektgegenstand und der Projektrolle ergeben sich dann vier mögliche
Projekttypen: Systementwicklungsprojekt AG, AN oder AG/AN und die Einführung
und Pflege eines organisationsspezifischen Vorgehensmodells.
Vorgehensbausteine
Die wesentlichen Inhalte des V-Modells sind in den modularen, aufeinander
aufbauenden Vorgehensbausteinen enthalten. Ein Vorgehensbaustein deckt eine
konkrete Aufgabenstellung ab, die während eines Projekts auftreten kann.
Innerhalb der Aufgabenstellung werden die zu erbringenden Produkte, die dafür
benötigten Aktivitäten und die mitwirkenden Rollen festgelegt. Jedes Produkt wird
von genau einer Aktivität erstellt, die jedoch in Teilaktivitäten aufgeteilt werden
kann. Eine Rolle kapselt eine Menge von Aufgaben und Verantwortlichkeiten, die
zu Beginn des Projekts einzelnen Personen zugeordnet werden. Jeder einzelne
Vorgehensbaustein ist in sich geschlossen und kann so einheitlich verwendet
werden.
Projektdurchführungsstrategien
Eine Projektdurchführungsstrategie definiert einen grundlegenden Rahmen für die
geordnete und nachvollziehbare Durchführung eines Projektes. Dabei bietet das
V-Modell für jeden Projekttyp mindestens eine geeignete Strategie an. Die
Strategie legt das „Wann“, d.h. die Reihenfolge der zu erstellenden Produkte bzw.
durchzuführenden Aktivitäten, fest.
Abbildung 7 zeigt die elf verschiedenen Produktdurchführungsstrategien, die im VModell zur Verfügung gestellt werden. Auf die einzelnen Strategien soll jedoch
nicht weiter eingegangen werden.
Entscheidungspunkte
Mit Hilfe der Produktdurchführungsstrategie wird die Reihenfolge der im Projekt zu
erreichenden Projektfortschrittsstufen vorgegeben. Jede dieser Stufen ist durch
einen Entscheidungspunkt markiert und zeigt den aktuellen Stand des Projektes.
Ein Entscheidungspunkt wird im Zusammenhang vom V-Modell als Meilenstein im
Projektablauf betrachtet. In Hinsicht auf Quality Gates stellen die
Entscheidungspunkte jedoch eher Gates dar. Für jeden Entscheidungspunkt im VModell ist eine Menge von Produkten definiert, die am Ende der Stufe fertig
gestellt sein müssen. Anhand der Produkte entscheidet das Management, ob die
Stufe als erfolgreich bewertet wird und das Projekt in die nächste Projektphase
eintreten darf.
Mit einer Projektdurchführungsstrategie besteht also die Möglichkeit,
Entscheidungspunkte in eine Ablaufreihenfolge zu bringen. Hierbei können
insbesondere
• Zyklen vorgegeben werden, d.h. es werden mehrmals die selben
Entscheidungspunkte durchlaufen,
Seite 17
•
•
mehrmals dieselben Entscheidungspunkte an unterschiedlichen Stellen in
der Projektdurchführungsstrategie verwendet werden und
parallele Abläufe durchgeführt werden.
Die Entscheidungspunkte legen zusammen mit den Produktdurchführungsstrategien das „Wann“ und „Was“ fest, d.h. wann welche Produkte fertig gestellt
sein müssen.
Abbildung 8: Entscheidungspunkte im V-Modell XT
Abbildung
8
zeigt
alle
im
V-Modell
grundlegend
vorgesehenen
Entscheidungspunkte. Anhand konkreter Projektmerkmale, des Projekttyps und
daraus resultierender Strategie wird das in der Abbildung dargestellte Modell
angepasst. Die Anpassung bzw. das Tailoring wird im folgenden Abschnitt
erläutert.
2.5.3 Klassifizierung / Tailoring
Das V-Modell XT ist so konzipiert worden, dass es in möglichst vielen
Projektkonstellationen anwendbar ist. Daher ist es notwendig, dass es an die
konkreten Projektbedingungen angepasst werden kann. Diese Anpassung
(Tailoring) kann der Anwender des Modells anhand der Angabe von
Projektmerkmalen vornehmen. Zu diesem Zweck wurde für das V-Modell XT
eigens ein Projektassistent entwickelt, der den Anwender beim Tailoring
unterstützt.
Abbildung 9: V-Modell XT Projektassistent - Projekttyp
Seite 18
Abbildung 10: V-Modell XT Projektassistent – Anwendungsprofil
Wie in Abbildung 9 und Abbildung 10 dargestellt, wird das Projekt zunächst
anhand einer Liste mit vorgegebenen Projektmerkmalen charakterisiert. Das
komplette Anwendungsprofil legt automatisch den Projekttyp fest. Für jeden
Projekttyp gibt es verpflichtend und optional zu verwendende Vorgehensbausteine. Das Tailoring liefert am Ende eine oder mehrere Projektdurchführungsstrategien zur Auswahl, von denen der Anwender eine einzelne
oder eine Kombination auswählen kann. Dies wird in der Literatur im
Zusammenhang des V-Modells oft „statisches Tailoring“ genannt, da hier eine
feste Strategie festgelegt wird.
Zusätzlich können jedoch während der Projektlaufzeit Vorgehensbausteine
hinzugefügt bzw. entfernt werden. Ausnahmen sind dabei die verpflichtenden
Bausteine. Dieser Vorgang wird „dynamisches Tailoring“ genannt.
Abbildung 11: V-Modell XT - Tailoring-Metamodell
Seite 19
Abbildung 11 zeigt das allgemeine Tailoring-Metamodell des V-Modell XT. Dabei
wird für jeden Projekttyp dargestellt, welche Vorgehensbausteine verpflichtend
oder optional und welche Projektdurchführungsstrategien möglich sind. Ein
Projekttyp besteht aus bestimmten Auswahlkriterien, die durch Werte in den
Projektmerkmalen charakterisiert werden. Ebenso wird die Anwendbarkeit von
Vorgehensbausteinen und Projektdurchführungsstrategien durch konkrete Werte
bestimmt.
2.6 Quality-Gate-Konzept von Pfeifer / Schmidt
Das Quality-Gate-Konzept von Pfeifer/Schmidt [31] stellt eine Vorgehensweise
des Projektmanagements für die Entwicklung von softwareintensiven Systemen
dar. Mit diesem Konzept sollen eine höhere Produktqualität erreicht und Kosten,
vor allem bei der Systemintegration, eingespart werden.
Pfeifer/Schmidt möchten mit ihrem Konzept insbesondere verhindern, dass durch
mangelnde Synchronisation der Projektergebnisse während der Projektphasen
Fehler und Unklarheiten in spätere Phasen verschleppt werden. Diese Fehler
werden meist bei der Integration zum Gesamtsystem offenbart und sind nur mit
großem Aufwand zu korrigieren. Darum sind die frühen Phasen von größter
Bedeutung für den Erfolg des Projekts. Durch die Einführung eines Modells soll
dem Projekt eine klare Struktur gegeben werden.
Abbildung 12: Synchronisation durch Quality Gate nach Pfeifer/Schmidt
Abbildung 12 zeigt einen Teil eines technischen Prozesses, in dem es mehrere
Entwicklungsstränge gibt. In diesem Beispiel benötigt das Produkt Entwicklungen
aus der Mechanik, Elektronik und der Software. Die Stränge driften innerhalb der
einzelnen Phasen auseinander. Dieser Effekt ist jedoch gewollt, da dadurch
kreative Freiräume entstehen, die für optimale Lösungen genutzt werden können.
Das Quality Gate stellt dabei ein Messpunkt dar, an dem bei Phasenbeginn
definierte Zwischenergebnisse überprüft werden. Außerdem sorgt ein Gate für die
Zusammenführung der Entwicklungsstränge, damit diese nicht zu weit
auseinander driften. Die Bewertung erfolgt, wie bereits in den anderen QualityGate-Modellen mit Hilfe von Checklisten. Ein Projekt kann nur dann weitergeführt
werden, wenn das Gate die Freigabe erteilt.
Seite 20
Abbildung 13: Quality-Gate-Plan nach Pfeifer/Schmidt
In Abbildung 13 ist der komplette Entwicklungsprozess eines technischen Systems
beispielhaft dargestellt. Dabei wird der Prozess in 6 Phasen, die jeweils durch
Quality Gates unterteilt werden, aufgeteilt. Neu in diesem Zusammenhang sind die
Synchronisationspunkte in den einzelnen Phasen. Diese können je nach Bedarf
und Projektgegebenheit neben den Quality Gates definiert werden, um
Zwischenergebnisse zu synchronisieren. Sie dienen außerdem der Bewertung des
Projektfortschritts und werden oft als Previews bezeichnet, da sie eine Projektion
auf das kommende Quality Gate darstellen.
Für den Erfolg eines Projekts sind nach Pfeiffer/Schmidt klar definierte messbare
Ziele, die systematische Synchronisation von Zwischenergebnissen und eine
kontinuierliche Fortschrittsbewertung von zentraler Bedeutung. Abbildung 14 zeigt
eine dafür erarbeitete 4-stufige Vorgehensweise, die in jeder Projektphase zu
durchlaufen ist.
Abbildung 14: 4-stufige Quality-Gate-Vorgehensweise von Pfeiffer/Schmidt
1
Nach dem Durchschreiten des vorhergehenden Gates müssen die
Ergebnisse, die am Ende dieser Phase vorliegen sollen, möglichst
feingranular definiert werden. Dazu werden messbare Erfüllungskriterien
festgelegt und innerhalb einer Checkliste dokumentiert.
2
Im 2. Schritt wird die Planung für die Phase hinsichtlich
durchzuführender Aufgaben, Kompetenzen, Verantwortlichkeiten und
einzusetzender Entwicklungsmethoden vorgenommen. Außerdem
werden Synchronisationspunkte festgelegt.
3
Der 3. Schritt befasst sich mit der Durchführung der geplanten
Ergebnisse aus dem zweiten Schritt. Während der Durchführung wird
die Reife der Ergebnisse von den Entwicklern selbst anhand der
Checkliste bewertet.
Seite 21
4
Im abschließenden Schritt erfolgt die Abnahme der Ergebnisse, die mit
Hilfe eines Quality-Gate-Reviews durchgeführt wird. Die Bewertung
erfolgt mit Hilfe der Checkliste.
Pfeifer/Schmidt legen in ihrem Modell ebenso dar, dass es in dem Entwicklungsprozess sinnvoll ist, weitere technische Reviews durchzuführen mit dem Ziel, auf
inhaltlicher Ebene Mängel oder Fehler zu finden.
2.7 ABB Gate Modell
ABB steht für Asea Brown Boveri und ist ein Konzern der Elektrotechnik mit Sitz in
Zürich. Der Konzern hat ein Modell für eigene Zwecke konzipiert, welches auf die
eigenen Erfahrungen in der Produktentwicklung zurückgreift.
Das ABB Gate Modell definiert acht Gates, in denen Geschäftsentscheidungen
getroffen werden. Das Modell kann in verschiedenen Entwicklungstypen eingesetzt werden, z.B. bei der Softwareentwicklung, Hardwareentwicklung, aber
auch im Marketing.
Im Gegensatz zu den bisher beschriebenen Modellen definiert das ABB Gate
Modell keine Phasen bzw. Stages. Trotzdem orientiert es sich am Stage-GateProzess von Cooper. Es setzt voraus, dass das gewählte SDLM (Software
Business Lifecycle Model) die benötigten Phasen beinhaltet. Dabei stellen die
Ergebnisse aus den Aktivitäten während der Entwicklung die nötigen
Informationen für das jeweilige Gate zur Verfügung.
Gate
Name des Gates
Start Project
Start Project Planning
Start Execution
Confirm Execution
Start Introduction
Release Product
Close Project
Retrospective Investigation
Abbildung 15: Gates im ABB Gate Modell [6]
Seite 22
Abbildung 15 stellt die einzelnen Gates des ABB-Gate-Modells dar. In den ersten
sechs Gates (0 bis 5) wird durch Entscheidungspunkte festgelegt, ob die
Entwicklung fortgeführt werden soll oder nicht. Gate 6 und 7 werden verwendet,
um das Entwicklungsprojekt zu beenden und Erfahrungen zu sammeln.
In der folgenden Tabelle 2 soll nun auf die einzelnen Gates näher eingegangen
werden:
Gate 0
Der Input für Gate 0 besteht aus einer Durchführbarkeitsstudie und
einer Marktanalyse, die Chancen, Wettbewerber und Risiken
analysiert.
Gate 1
Am Gate 1 wird der Rahmen für die Entwicklung abgesteckt. Dabei
werden z.B. die Funktionen und Features des Produkts definiert, die
für die Planung des Projekts zum Nutzen sein können.
Gate 2
Am Gate 2 wird das Projekt geplant, indem Requirements,
Leistungen, Zeit- & Kostenabschätzungen, Prozeduren für die
Qualitätserhaltung, Risikomanagement usw. besprochen und
definiert werden.
Gate 3
Am Gate 3 sollen alle größeren Risiken festgestellt und die
technischen Lösungen erarbeitet werden.
Gate 4
Am Gate 4 werden alle geforderten Funktionen und Features
implementiert. Das Produkt soll anschließend für den Test auf dem
Markt bereit sein.
Gate 5
Am Gate 5 soll das Produkt fertig für den Markt bereit stehen.
Gate 6
Am Gate 6 soll die Entwicklung beendet sein und das Produkt an die
Produktion weitergegeben werden.
Gate 7
Am Gate 7 wird das Projekt ausgewertet und überprüft, in welcher
Weise dieses erfolgreich auf dem Markt positioniert werden kann.
Tabelle 2: Beschreibung der Gates des ABB-Gate-Modells
Beim ABB Gate Modell gibt es zwei verschiedene Rollen: Gate Owner und Gate
Assessor. Der Gate Owner ist die Person, die die Verantwortung und Autorität hat,
zu entscheiden, ob ein Produkt entwickelt wird oder nicht. Weiterhin ist er für die
Finanzierung des Projektes und die Verfügbarkeit der benötigten Ressourcen
zuständig. Die Hauptaufgaben des Gate Assessor bestehen darin, das Produkt im
Interesse des Gate Owners zu überprüfen und das Ergebnis der Beurteilung in
einer Gate Sitzung zu verkünden. Der Gate Assessor wird vom Gate Owner
benannt. Dabei wird im Normalfall eine Person ernannt, die nicht Teil des
Projektes ist, um Objektivität zu gewährleisten.
Der Prozess, der am Gate ausgeführt wird, besteht aus zwei Aktivitäten. Zum
einen aus der Gate-Beurteilung und zum anderen aus der Gate-Sitzung. Für die
Beurteilung werden die erstellten Dokumente, eine Checkliste und Interviews mit
den Projekt-Stakeholdern benötigt. Die Beurteilung selbst kann sich dann über
Seite 23
einen längeren Zeitraum, z.B. eine Woche, erstrecken. Als Ergebnis des Gates
wird ein Bericht erstellt, der sich auf die Checklistenpunkte des aktuelles Gates
bezieht. Dieser Bericht wird allen Beteiligten des Gate-Meetings schon vor der
Sitzung zur Verfügung gestellt, damit diese sich vorbereiten können. In der GateSitzung wird entschieden, ob das Projekt weitergeführt, gestoppt, erstmal
angehalten oder die vorige Phase wiederholt werden soll. Anschließend werden
alle Stakeholder über die Entscheidung informiert.
Seite 24
3 Quality-Gate-Metamodell
In diesem Abschnitt wird ein konzeptionelles Metamodell für Quality Gates
eingeführt. Zuvor muss jedoch definiert werden, was genau ein Metamodell ist und
welche Vorteile durch die Metamodellierung entstehen.
3.1 Was ist ein Metamodell?
Bevor auf ein spezielles Metamodell für Quality Gates eingegangen werden kann,
muss geklärt werden, was ein Metamodell ist und wozu es in der Softwareentwicklung verwendet werden kann. Nach Wikipedia [40] ist ein Meta-Modell
folgendermaßen definiert:
„Modelle, die beschreiben, wie Modelle gebaut werden, nennt man
Metamodelle“
Ein Metamodell beschreibt ein Modell selbst, indem es die Elemente des Modells
und ihre Zusammenhänge untereinander aufzeigt. Das Metamodell ist Teil der 4Schichten-Metamodellarchitektur, die in Abbildung 16 dargestellt wird.
Abbildung 16: 4-Schichten-Metamodellarchitektur nach Stahl/Völter [36]
Die 4-Schichten-Architektur ist ein Standard der Object Management Group
(OMG 2 ) und legt eine Modellhierarchie fest, die die einzelnen Modellarten
definiert. Sie ist z.B. zentral für das Verständnis der Unified Modeling Language
(UML). Dabei besteht die 4-Schichten-Architektur aus folgenden Elementen:
M3: Meta-Metamodell
Dies ist die Infrastruktur der Metamodellarchitektur und definiert die Sprache
zur Spezifikation von Metamodellen. Prinzipiell lassen sich weitere Schichten
oberhalb des Meta-Metamodells definieren, jedoch wird dies nicht durch eine
M4-Schicht beschrieben. Stattdessen hat OMG festgelegt, dass alle
2
OMG (Object Management Group), www.omg.org
Seite 25
Modellierungskonstrukte der M3-Schicht als Instanzen von sich selbst definiert
werden.
M2: Metamodell
Das Metamodell ist eine Instanz des Meta-Metamodells und definiert die
Sprache zur Beschreibung der Modelle. Diese Schicht ist z.B. das zentrale
Element der UML.
M1: Modell
Das Modell ist eine Instanz des Metamodells und definiert die Sprache zur
Beschreibung der Domäne.
M0: Objekte
Objekte sind eine Instanz des Modells und beschreiben die Ausprägungen
einer bestimmten Domäne.
Die 4-Schichten-Architektur anhand eines Beispiels:
Abbildung 17: Beispiel für 4-Schichten-Architektur [14]
In der Abbildung 17 kann man nun gut erkennen, wie die einzelnen Schichten in
der 4-Schichten-Architektur konkret aussehen können. Die oberste Ebene
beschreibt die Oberklasse der Metamodelle, indem sie alle Instanzen
zusammenfasst. In der Ebene M2 werden Instanzen vom Meta-Metamodell
gebildet, die aus einer Klasse, einer Assoziation und einem Attribut bestehen.
Schicht M1 wird dann noch konkreter, indem eine Klasse „Person“ mit dem Attribut
„name“ und eine Klasse „Auto“ mit dem Attribut „typ“, die über eine Assoziation
verbunden sind, erstellt wird. In der untersten Ebene M0 werden nun spezielle
Ausprägungen der aus dem Modell festgelegten Instanzen dargestellt und durch
eine Assoziation verbunden: Eine Person mit dem Namen „Alex“ und ein Auto vom
Typ „Golf“.
Seite 26
3.1.1 Vorteile von Metamodellen
Metamodelle haben einige Vorteile, die im Folgenden näher erläutert werden
sollen.
Beim Modellieren eines Sachverhaltes ist nicht nur das am Ende erstellte Modell
selbst entscheidend, sondern auch das während des Modellierungsprozesses
aufgebaute Verständnis spielt eine große Rolle. So kann es vorkommen, dass
Dinge, die zuvor nicht intuitiv klar waren, dadurch deutlicher werden oder aber
Probleme durch das Metamodell erst aufgedeckt werden, an die keiner zuvor
gedacht hat.
Ein zweites Argument kann in der besseren Vergleichbarkeit von Metamodellen
gesehen werden, da Metamodelle eine abstrakte Syntax verwenden, um Modelle
einheitlich zu beschreiben.
3.2 Konzeptionelles Metamodell für Quality Gates
In dem vorigen Kapitel hat man bereits gesehen, dass es eine Menge an QualityGate-Ansätzen in der Softwareentwicklung gibt. Diese Ansätze sind von den
Grundzügen sehr ähnlich aufgebaut. An einigen Stellen jedoch unterscheiden sie
sich, indem sie zwar das gleiche meinen, aber andere Begriffe für den gleichen
Sachverhalt verwenden.
Im Folgenden soll nun ein konzeptionelles Metamodell für Quality Gates
vorgestellt werden, welches das Problem der unterschiedlichen Terminologie
aufgreifen und lösen soll. Dabei wurden zum einen die Prozesse aus dem vorigen
Kapitel, aber auch Prozesse, die speziell in Firmen eingesetzt werden, aber an
dieser Stelle aus Anonymitätsgründen nicht näher erläutert werden dürfen, als
Grundlage verwendet. Das daraus entwickelte Metamodell stellt sozusagen die
M2-Ebene in der 4-Schichten-Metamodellarchitektur dar. Die einzelnen QualityGate-Ansätze befinden sich eine Ebene unter der Metamodellschicht auf Ebene
M1 und sind als Instanzen der M2-Schicht anzusehen.
Bei dem Metamodell handelt es sich um ein konzeptionelles Modell.
Konzeptionelle Modelle repräsentieren allgemeines Wissen über die Realität und
werden verwendet, um konkrete Konzepte innerhalb einer bestimmten Domain
darzustellen. Das Modell selbst beinhaltet einzelne Sachverhalte und
Informationen, zwischen denen Relationen bzw. Assoziationen bestehen.
Das konzeptionelle Metamodell für Quality Gates wird mit Hilfe eines UMLKlassendiagramms dargestellt. Dabei wird ein Konzept mit Hilfe einer Klasse
beschrieben, welche das Stereotyp «Konzept» besitzt. Relationen können somit
durch UML mit Assoziationen, Generalisierungen und ähnlichem visualisiert
werden.
Zunächst soll nun das Modell im Überblick vorgestellt und die Relationen zwischen
den einzelnen Klassen anschließend näher erläutert werden.
Seite 27
3.2.1 Das konzeptionelle Metamodell im Überblick
«Konzept»
Protokoll
«Konzept»
Checkliste
«Konzept»
Projektvertreter
*
1
«Konzept»
Lieferant
1..*
besteht
aus
ist
beteiligt
«Konzept»
Kriteriendefinition
1..*
1..*
liefert
«Konzept»
Kriterium
wird erstellt
1..*
1..*
1
beinhaltet
*
1 «Konzept»
Gate Review
1
wird durchgeführt in
1..*
1
1
1..*
1
1
«Konzept»
Entscheidungsfindung
«Konzept»
Ergebnis
1
«Konzept»
Ziel
1
1
1
1
1
«Konzept»
Gate
1..*
1
besteht aus
«Konzept»
Gate Netzwerk
1
*
«Konzept»
Vorbedingung
ist verantwortlich
ist
beteiligt
1..*
«Konzept»
Gate Manager
1
erstellt
ist
beteiligt
«Konzept»
Handlungsempfehlung
1..*
1
erstellt
1
1
1
1..*
0..*
«Konzept»
Ressource
«Konzept»
0..* Entscheidung
1..*
gibt frei
«Konzept»
go-Entscheidung
«Konzept»
hold-Entscheidung
1
fällt
«Konzept»
conditional-goEntscheidung
1..*
1..*
«Konzept»
Gatekeeper
«Konzept»
kill-Entscheidung
1..*
1
«Konzept»
Gate Status
prüft
«Konzept»
repeat-GateEntscheidung
Abbildung 18: Das konzeptionelle Metamodell für Quality Gates
In dem konzeptionellen Metamodell aus der Abbildung 18 wird das Konzept der
Anpassung (bzw. Tailoring) nicht berücksichtigt. Die Anpassung steht in Relation
zu vielen Klassen des Modells und würde der Übersichtlichkeit des Metamodells
schaden. Deshalb wird das beschriebene Metamodell im nächsten Abschnitt in
Pakete eingeteilt und detailliert beschrieben. Anschließend werden die
Beziehungen der Pakete zum Paket „Anpassung“ dargestellt.
Seite 28
3.2.2 Das konzeptionelle Metamodell im Detail
Paket „Struktur“
Abbildung 19 zeigt das Paket „Struktur“ mit dem Ausschnitt der Metamodellierung
für das einzelne Gate. Das Gate selbst stellt den Mittelpunkt der Modellierung dar.
1
«Konzept»
Ziel
1
1
1
«Konzept»
Vorbedingung
«Konzept»
Gate
1..*
1
besteht aus
«Konzept»
Gate Netzwerk
1
ist verantwortlich
1..*
«Konzept»
Gate Manager
1
erstellt
1
«Konzept»
Gate Status
Abbildung 19: Metamodell Paket: „Struktur“
Zunächst einmal ist die Rolle des Gate Managers direkt am Gate beteiligt. Der
Gate Manager ist der Kopf des Gates und verantwortlich für die Überwachung und
Erstellung des Gate Status und der rechtzeitigen Einhaltung der Gate
Anforderungen. Er beruft das Gate Review ein und fungiert als dessen Moderator.
Dabei ist er zuständig für die Verteilung der nötigen Dokumente und den
reibungslosen Ablauf des Reviews.
Der Gate Status stellt den aktuellen Zustand des Gates dar. Er gibt z.B. an, ob
sich das Gate noch innerhalb der Entscheidungsfindung befindet oder diese
bereits abgeschlossen ist.
Ein Gate besteht weiterhin aus einer Vorbedingung und einem Ziel. Die
Vorbedingung muss erfüllt sein, damit überhaupt in das Gate eingetreten werden
kann. Das Einreichen der benötigten Dokumente könnte beispielsweise eine
Vorbedingung sein. Jedes Gate hat außerdem ein Ziel, welches zum Ende des
Gates erreicht werden soll. Über das Erreichen des Ziels wird innerhalb des Gate
Reviews durch die Überprüfung der Ergebnisse entschieden.
Das Gate Netzwerk besteht aus einem oder mehreren Gates. Dadurch können mit
Hilfe des Metamodells konkrete Prozesse mit unterschiedlicher Anzahl Gates
modelliert werden. Auch deren Reihenfolge und Häufigkeit der Verwendung kann
unterschiedlich aussehen.
Seite 29
Paket „Entscheidung“
Abbildung 20 betrachtet nun näher das Paket „Entscheidung“ mit dem Gate
Review und der Entscheidungsfindung. Das Gate Review stellt, wie bereits
erwähnt, das Gate Meeting dar, in dem eine formale Prüfung der Ergebnisse aus
der vorigen Softwareentwicklungsphase stattfindet.
«Konzept»
Protokoll
«Konzept»
Projektvertreter
*
1
ist
beteiligt
wird erstellt
1
beinhaltet
1
*
«Konzept»
Gate Review
1
«Konzept»
Abbildung 20: Metamodell Paket: „Entscheidung”
Am Gate Review beteiligt sind die jeweiligen Projektvertreter. Als Projektvertreter
werden z.B. die Team Experts und die Team Quality Agents angesehen. Die
Team Experts sind Mitglieder des Entwicklungsteams und haben somit die
Erfüllung von Requirements und die Erstellung von Ergebnissen zur Aufgabe. Sie
sind bei der Sitzung anwesend und haben ein Einspruchsrecht. Die Team Quality
Agents sind die Teamleiter und stellen die Qualität der Ergebnisse vor ihrer
Abgabe sicher. Sie geben die Dokumente rechtzeitig ab und können die Team
Experts benennen. Während der Sitzung können die Team Quality Agents
ebenfalls Einspruch einlegen.
Innerhalb des Gate Reviews findet der Prozess der Entscheidungsfindung statt.
Während der Entscheidungsfindung können verschiedene Verfahren eingesetzt
werden, die diese unterstützen.
Zum einen können Checklisten eingesetzt werden, die Kriterien in Form von
Fragen enthalten und mit dessen Hilfe die Ergebnisse überprüft werden. Solch
eine Frage kann dann mit „Ja“ oder „Nein“ beantwortet werden. Eine Möglichkeit
der Entscheidungsfindung könnte z.B. sein, zuvor festzulegen, wie viel Fragen mit
„Ja“ beantwortet werden müssen, um das Gate zu bestehen. Dieser Ansatz ist
jedoch problematisch, da einige Kriterien wichtiger sind als andere und eine
Gewichtung von Nöten wäre.
Ein anderes Verfahren ist die Nutzung eines Scoring-Modells. Beim ScoringModell werden die Kriterien anhand von Beurteilungsskalen bewertet. Beispiele
sind numerische Skalen von 0-10 oder Skalen in der Form von „sehr gut“ bis „sehr
schlecht“, die jedoch wieder in numerische Werte konvertiert werden können. Der
Vorteil liegt in der feineren Bewertung von Kriterien.
Seite 30
Um die Vorteile der einzelnen Verfahren zu nutzen, bietet es sich an, beide zu
verbinden. Bei den „must-meet“-Kriterien, die erfüllt sein müssen, können
Checklisten verwendet werden. Dabei müssen bei der Überprüfung alle Kriterien
mit „Ja“ beantwortet werden. Bei den „should-meet“ Kriterien verwendet man ein
Scoring-Modell. Die einzelnen Kriterien sollten nur noch nach Wichtigkeit
gewichtet werden, um am Ende mit den Werten aus der Skala und der
Gewichtung eine Gesamtbewertung berechnen zu können. Ein zuvor festgelegter
Schwellenwert, der für das Bestehen des Gates erreicht werden muss, kann somit
die Entscheidungsfindung unterstützen.
Während des Gate Reviews wird ein Protokoll erstellt, in dem aufgezeichnet wird,
wer am Review zu welchem Zeitpunkt teilgenommen hat. Außerdem wird
festgehalten, welche Prüfkriterien erfüllt worden sind und wie die Entscheidung der
Gatekeeper ausgefallen ist. Das Protokoll kann von allen Beteiligten eingesehen
werden, um Missverständnissen entgegenzuwirken und nachträglichen
Diskussionen vorzubeugen.
Paket „Steuerung“
Im Paket „Steuerung“ werden die verschiedenen Möglichkeiten der Entscheidung
in einem Gate Review beschrieben.
«Konzept»
Handlungsempfehlung
1..*
1
erstellt
1
1
0..*
«Konzept»
Ressource
1..*
0..1 «Konzept»
gibt frei Entscheidung
«Konzept»
go-Entscheidung
«Konzept»
hold-Entscheidung
1
fällt
«Konzept»
conditional-goEntscheidung
1..*
«Konzept»
Gatekeeper
«Konzept»
kill-Entscheidung
«Konzept»
repeat-GateEntscheidung
Abbildung 21: Metamodell Paket: „Steuerung“
An der Entscheidung beteiligt sind ein oder meist mehrere Gatekeeper. Die
Gatekeeper spielen innerhalb eines Gates die größte Rolle. Wie man bereits in
den einzelnen Konzepten der Quality Gates sehen konnte sind sie vor allem für
die Überprüfung der Dokumente bzw. Ergebnisse zuständig. Ein Gatekeeper kann
gleichzeitig auch Team Quality Agent eines anderen Teams, Qualitätsbeauftragter
vom Management oder auch Stakeholder sein. Die Gatekeeper treffen in dem
Gate Review eine Entscheidung über den Fortgang des Projektes. Dabei gibt es
folgende Möglichkeiten:
•
Die go-Entscheidung wird getroffen, wenn bei der Überprüfung der
Dokumente bzw. Ergebnisse alle Ziele und Kriterien der Checkliste erfüllt
worden sind. Das Projekt kann somit in die nächste Phase der Software-
Seite 31
entwicklung eintreten und bekommt neue Vorbedingungen für das nächste
Gate.
•
Eine hold-Entscheidung bedeutet, dass zwar alle Kriterien für das
Weiterkommen erfüllt worden sind, aber das Projekt zunächst zurückgestellt
wird. Diese Entscheidung kann beispielsweise auftreten, wenn es noch
andere Projekte gibt, die eine höhere Priorität besitzen und somit vorgezogen
werden, oder aber nicht mehr genügend Ressourcen für das Projekt zur
Verfügung stehen.
•
Die conditional-go-Entscheidung wird verwendet, wenn zwar einige Kriterien
nicht erfüllt wurden, diese aber nicht von immenser Wichtigkeit sind. Diese
Anforderungen müssen aber nachgeliefert werden und werden beim
nächsten Gate erneut überprüft.
•
Wenn für den Fortgang des Projektes wichtige Kriterien nicht erfüllt wurden,
gilt das Gate als nicht bestanden und die vorherige Phase muss wiederholt
werden. Diese Entscheidung nennt man repeat-Entscheidung. Nach der
Wiederholung der Phase werden die verbesserten Ergebnisse in einem
neuen Gate nochmals überprüft und bewertet.
•
Für den Fall, dass ein Gate mehrmals nicht bestanden wurde, kann das
Projekt mit Hilfe der kill-Entscheidung durch die Gatekeeper endgültig
gestoppt werden. Weitere Gründe für das Stoppen des Projekts sind fehlende
finanzielle Mittel oder aber wenn das Projekt nicht mehr die Zielsetzung des
Unternehmung verfolgt.
Die Klasse „Ressource“ beschreibt, dass im Fall des erfolgreichen Bestehens des
Gates durch eine positive Entscheidung, Ressourcen für die nächste Phase
freigegeben werden. Ressourcen sind z.B. Mitarbeiter, die Zeit in das Projekt
investieren oder aber auch finanzielle Mittel, die die Weiterführung des Projekts
erst möglich machen. Ein ähnlicher Ansatz wird bei Cooper durch den Begriff
„Priorisierung“ verfolgt, der besagt, dass das aktuelle Projekt eine Priorität im
Vergleich zu allen anderen laufenden Projekten bekommt. Auf dessen Basis wird
entschieden, welche Ressourcen im Projekt eingesetzt werden.
Nach einer Entscheidung werden Handlungsempfehlungen erstellt und an die
beteiligten Rollen weitergegeben. Sie beinhalten Aufgaben, Tipps und Vorgaben
für das weitere Vorgehen innerhalb des Projekts. Handlungsempfehlungen können
auch gegeben werden, wenn z.B. eine repeat-Entscheidung gefällt wurde und das
Gate wiederholt werden muss.
Paket „Inhalt“
Abbildung 22 zeigt das Paket „Inhalt“. Dort wird speziell die Modellierung des
Kriteriums und dessen Verbindung zu dem Gate und dem Ergebnis dargestellt.
Diese Beziehung kann als Dreierbeziehung angesehen werden, da im Gate mit
Hilfe einer Menge von Kriterien die abgegebenen Ergebnisse untersucht werden.
Dafür sind mindestens ein Ergebnis und ein Kriterium erforderlich. Im Normalfall
werden jedoch viele Ergebnisse mit Hilfe von vielen Kriterien untersucht.
Seite 32
Eine Menge von Kriterien bildet eine Checkliste, die zur Überprüfung von den
Gatekeepern verwendet wird. Dabei muss die Checkliste mindestens ein Kriterium
beinhalten. Die Kriteriendefinition stellt die Aktivität zur Bestimmung von
relevanten Prüfkriterien und einzuhaltenden Schwellwerten dar.
«Konzept»
Checkliste
besteht
aus
«Konzept»
Kriteriendefinition
«Konzept»
Lieferant
1..*
1..*
1..*
liefert
«Konzept»
Kriterium
1..*
1..*
1..*
«Konzept»
Ergebnis
1
«Konzept»
Struktur::Gate
1..*
«Konzept»
Steuerung::Gatekeeper
prüft
1..*
Abbildung 22: Metamodell Paket: „Inhalt“
Für die Prüfung der Ergebnisse ist, wie schon bereits zuvor erwähnt, der Gatekeeper zuständig.
An dem Ergebnis ist noch die Rolle der Lieferanten beteiligt. Die Lieferanten sind
sozusagen diejenigen, die das Dokument oder das Ergebnis erstellen. Für die
fristgerechte Abgabe der Ergebnisse ist der Team Quality Agent verantwortlich.
Paket „Anpassung“
pflegt
«Konzept»
Gate Management 1..*
0..1
«Konzept»
Regelwerk
1
1
bedient sich aus
1
mit
Hilfe
von
1
«Konzept»
Tailoring
1
basiert auf
1
1
1
«Konzept»
1 Projektmetamodell
nimmt
vor
1
«Konzept»
Prozesstailorer
Abbildung 23: Metamodell Paket: „Anpassung“
Seite 33
Abbildung 23 stellt das Paket „Anpassung“ dar. Die Modellierung des Tailorings ist
in der Übersicht am Anfang des Kapitels noch nicht berücksichtigt und wird nun in
diesem Paket näher erläutert.
Das Projektmetamodell stellt die Basis für das Tailoring dar und enthält
Informationen über das jeweilige Projekt. Diese Informationen dienen als
Eingabeparameter, auf dessen Grundlage eine Anpassung an die spezifischen
Projektmerkmale vorgenommen wird.
Die Anpassung wird mit Hilfe eines Regelwerks durchgeführt. Das Regelwerk
kann sowohl Regeln, als auch Bewertungen umfassen, die mit den
Projektinformationen verglichen werden. Bewertungen von Kriterien geben an, in
welchen speziellen Projekten es sinnvoll ist diese Kriterien einzusetzen. Sie gehen
z.B. der Frage nach, ob Kriterien eher bei kleinen Projekten sinnvoll oder doch nur
in großen Projekten einsetzbar sind.
Am Tailoring-Konzept sind zwei Rollen beteiligt: Prozesstailorer und das Gate
Management. Das Gate Management ist für die Erstellung und Pflege des
Regelwerkes zuständig. Es legt Regeln und Bewertungen anhand von
Erfahrungen aus vorherigen Projekten fest. Der Prozesstailorer ist für das
Anpassen des Prozesses an das jeweilige Projekt zuständig. Grundlage für die
Anpassung ist das Regelwerk.
Paketabhängigkeiten
In Abbildung 24 werden nun die Abhängigkeiten zwischen den einzelnen Paketen
dargestellt. Die Pakete „Inhalt“, „Struktur“, „Steuerung“ und „Entscheidung“ sind
alle abhängig vom Paket „Anpassung“, da eine Anpassung in allen Paketen
vorgenommen werden kann.
Inhalt
Struktur
Anpassung
Steuerung
Entscheidung
Abbildung 24: Paketabhängigkeiten zum Tailoring
Beispielsweise kann eine Anpassung der Checkliste aus dem Paket „Inhalt“
vorgenommen werden, indem nur Kriterien in die Checkliste aufgenommen
werden, die auch für das spezielle Projekt relevant sind. Eine Anpassung kann
auch im Paket „Entscheidung“ bei dem Protokoll oder den Projektvertretern
erfolgen. Beispielsweise kann die Größe des Projekts entscheiden, wie viel und
welche Art von Projektvertretern bei einem Prozess eingesetzt werden sollen und
Seite 34
wie genau das Protokoll auszusehen hat. Weiterhin kann auch die Anzahl der
eingesetzten Gatekeeper aus dem Paket „Struktur“ anhand der Projektgröße
festgemacht werden. Weitere Tailoringmöglichkeiten werden im Kapitel 4.4
diskutiert.
3.2.3 Konzeptionelles Metamodell: Übersicht (Paketdarstellung)
An dieser Stelle erscheint, der Vollständigkeit halber, erneut die Darstellung des
konzeptionellen Metamodells als Übersicht. In diesem Fall jedoch mit der
richtigen, dafür aber etwas unübersichtlichen Darstellung, mit Angabe der
Paketnamen vor den Klassennamen.
Weiterhin ist jedoch das Paket „Anpassung“, wie zuvor begründet, nicht integriert.
«Konzept»
Entscheidung::Protokoll
«Konzept»
Inhalt::Checkliste
«Konzept»
Entscheidung::Projektvertreter
*
1
besteht
aus
1
1
liefert
1..*
*
«Konzept»
Entscheidung:: 1
Gate Review
1
«Konzept»
Entscheidung::
1..*
«Konzept»
Inhalt::Kriterium
wird erstellt
beinhaltet
1..*
1..*
ist
beteiligt
1
«Konzept»
«Konzept»
Inhalt::Kriteriendefinition Inhalt::Lieferant
1..*
«Konzept»
1..*
Inhalt::Ergebnis
wird durchgeführt in
1..*
1
1
1
«Konzept»
Struktur::Ziel
1
1
1
1
1..*
1
«Konzept»
«Konzept»
Struktur::Gate Netzwerk
besteht aus
Struktur::Gate
*
«Konzept»
Struktur::Vorbedingung
1
1
ist verantwortlich1..*
«Konzept»
Struktur::Gate Manager
1
erstellt
ist
beteiligt
«Konzept»
Steuerung::Handlungsempfehlung
ist
beteiligt
1
«Konzept»
Struktur::Gate Status
1..*
1
erstellt
«Konzept»
Steuerung::
Ressource
1
1
1
0..*
«Konzept»
1..*
0..*
1
gibt frei Steuerung::Entscheidung
«Konzept»
Steuerung::
go-Entscheidung
«Konzept»
Steuerung::
hold-Entscheidung
1..*
fällt
«Konzept»
Steuerung::conditional-goEntscheidung
1..*
«Konzept»
1..*
Steuerung::Gatekeeper
«Konzept»
Steuerung::
kill-Entscheidung
1..*
prüft
«Konzept»
Steuerung::repeat-GateEntscheidung
Abbildung 25: Konzeptionelles Metamodell (Paketübersicht)
Seite 35
3.2.4 Konzeptionelles Metamodell: Proof-of-Concept
Anhand der folgenden Tabelle 3 soll nun als Beispiel der Stage-Gate-Prozess von
Cooper mit Hilfe des zuvor beschriebenen Metamodells abgebildet werden. Die
einzelnen Bausteine werden in der Tabelle nach dem jeweiligen Paket aufgeführt.
Es wird außerdem beschrieben, ob dieser Baustein im Stage-Gate-Prozess von
Cooper verwendet wird oder ob ggf. eine andere Bezeichnung Verwendung findet.
Die letzte Spalte gibt die Bewertung (Bew.), d.h. den Grad der Ausgestaltung,
visuell wieder. Die verwendeten Symbole haben folgende Bedeutung:
“nicht ausgestaltet”: der Baustein ist nicht im Stage-Gate-Prozess
von Cooper berücksichtigt bzw. beschrieben
“teilweise ausgestaltet”: der Baustein ist nicht vollständig im StageGate-Prozess von Cooper berücksichtigt, d.h., dass Teile innerhalb
des Bausteins nicht einbezogen sind
“ausgestaltet“: der Baustein wird synonym oder mit einer anderen
Bezeichnung im Stage-Gate-Prozess von Cooper verwendet
Steuerung
Struktur
Paket Baustein
Stage-Gate-Prozess von Cooper
Bew.
Gate
wird synonym verwendet
Gate Netzwerk
Cooper beschreibt ein Modell mit fünf Gates,
es sind jedoch auch mehr oder weniger
möglich
Gate Manager
die Aufgabe des Gate-Managers übernimmt
der Projektleiter
Gate Status
Vorbedingung
nicht explizit erwähnt
Ziel
die Liste an zu erreichenden Ergebnissen für
ein Gate ist die Menge an Zielen für ein
Team
Gatekeeper
überprüft Ergebnisse (bei Stage-Gate
“Deliverables”
genannt)
anhand
von
Checklisten
Ressource
die
Ressourcen
werden
Gatekeepern festgelegt
Handlungsempfehlung
•
Entscheidung
•
•
von
den
die go-, hold- und kill-Entscheidung wird
synonym verwendet
conditional-go-Entscheidung ist nicht
vorhanden (bei kleineren Fehlern muss
Gate wiederholt werden)
reapeat-Gate-Entscheidung
wird
„recycle-Entscheidung” genannt
Seite 36
Entscheidung
Inhalt
Checkliste
vorhanden (Liste von Kriterien)
Kriterium
vorhanden (“Criteria” genannt), unterteilt in
“must-meet”- und “should-meet”-Kriterien
Kriteriendefinition
Ergebnis
“Deliverables” genannt
Lieferant
die Aufgabe des Lieferanten übernehmen
das Team und der Projektleiter
Gate Review
“Gate-Meeting” genannt
die Entscheidungsfindung findet während
des Gate-Meetings durch die Gatekeeper
statt
Protokoll
Projektvertreter
Projektvertreter sind aufgeschlüsselt
„Team“ und „Projektleiter“
in
Anpassung
Tailoring
Projektmetamodell
Regelwerk
nicht vorhanden
Gate Management
Prozesstailorer
Tabelle 3: Proof-of-Concept am Beispiel des Stage-Gate-Prozesses
Seite 37
4 Tailoring von Softwareprozessen
Kapitel 4 beschäftigt sich näher mit dem Begriff „Tailoring“, speziell im
Zusammenhang mit Softwareprozessen. Dabei wird nicht nur auf den Begriff des
Tailorings selbst, sondern auch auf den Ablauf und die am Tailoring beteiligten
Rollen eingegangen. Am Ende wird dargestellt, wie in den einzelnen Bausteinen
das Tailoring aussehen kann.
Einige der folgenden Definitionen und Beschreibungen sind an Jan Ittner
angelehnt, der sich innerhalb seiner Dissertation [19, 20] mit dem Thema
„Tailoring“ beschäftigt hat.
4.1 Definition „Tailoring“
Wie man bereits im zweiten Kapitel dieser Arbeit erkennen konnte, gibt es
verschiedene Quality-Gate-Konzepte. Oft entscheidet man sich unternehmensintern für einen dieser Ansätze oder verwendet einen Eigenen. Was passiert
jedoch, wenn das verwendete Konzept nicht zu einem bestimmten Projekt passt?
Das Ziel ist es also, sich von Prozessen in „Einheitsmaßen“ zu lösen, und sich
flexibleren Varianten von Prozessen zuzuwenden, die an die Erfordernisse des
aktuellen Projekts angepasst werden können. Diese Art der Anpassung wird auch
„Tailoring“ genannt.
Definition „Prozess-Tailoring“ (nach Jan Ittner [19, 20]):
„Prozess-Tailoring ist das Anpassen eines Prozessmodells zur Erstellung
einer Prozessbeschreibung, die für ein spezielles Projekt geeignet ist.“
Das Tailoring kann als Konfigurationsaufgabe angesehen werden. So, wie ein
Schneider (engl. tailor) einen Anzug auf seinen Träger anpasst, bedeutet das
Zurechtschneidern eines Prozesses, ihn passend für das aktuelle Projekt zu
machen. Kein Schneider denkt sich für jeden Anzug ein neues Schnittmuster aus,
sondern verwendet Bestehende und gleicht sie den Maßen des Kunden an. Beim
Prozesstailoring wird ähnlich vorgegangen, indem ein allgemeines Prozessmodell
an ein Projekt angepasst wird.
4.2 Ablauf
Referenzprozess
Projekt-Informationen
Tailoring-Regeln
Tailoring des Prozesses
Projektspezifischer
Prozess
Erfahrungen
Abbildung 26: Tailoring eines projektspezifischen Prozesses
Seite 38
Die Abbildung 26 zeigt den generellen Ablauf beim Tailoring eines Prozesses.
Für die Anpassung werden mehrere Eingaben benötigt:
• Referenzprozess,
• Projekt-Informationen,
• Tailoring-Regeln und
• Erfahrungen.
Der Referenzprozess gibt einen Prozess vor, auf dessen Grundlage Anpassungen
vorgenommen werden sollen. Referenzprozesse können z.B. die in Kapitel 2
beschriebenen Quality Gate Prozesse, wie der Stage-Gate-Prozess von Cooper
oder das V-Modell XT sein.
Um eine projektspezifische Anpassung durchführen zu können, werden
Informationen über das Projekt selbst benötigt. Dabei sind z.B. die Projektgröße,
eingesetzte Technologien innerhalb des Projekts oder der Projekttyp wichtige
Daten für das Tailoring.
Tailoring-Regeln sind ebenfalls ein wichtiger Bestandteil. Sie enthalten Wissen
von Personen, die genügend Erfahrungen mit Prozessen haben, welche unter
verschiedenen Projektkonstellationen zum Einsatz gekommen sind. Auf Grundlage dieses Wissens wird die Anpassung des Projektes durchgeführt.
Ein weiterer wichtiger Eingabeparameter sind Erfahrungen, die bei
vorhergehenden Projekten und Prozessen gesammelt wurden und somit als neue
Informationen oder auch Tailoring-Regeln in den neuen Prozess mit einfließen
können. Auf diese Weise entsteht ein qualitäts- und prozessverbessernder
Erfahrungskreislauf. Auf einen speziellen Erfahrungskreislauf – dem Quality
Improvement Paradigm (QIP) – wird in Kapitel 5.3 genauer eingegangen.
Auf Grundlage der Eingabeinformationen wird dann das Tailoring des Prozesses
vorgenommen. Dabei kann der Referenzprozess durch Verändern, Entfernen und
Hinzufügen von Aktivitäten oder Artefakten an den Prozess angepasst werden. Es
ist jedoch denkbar, dass nicht alle Aktivitäten und Artefakte verändert werden
dürfen. Als Ausgabe bekommt man dann einen projektspezifisch angepassten
Prozess.
4.3 Rollen beim Tailoring
Das Tailoring eines Prozesses ist eine schwierige Aufgabe, da es viele komplexe
Standardprozessmodelle gibt. Noch schwieriger wird es, wenn keine ausreichende
Erfahrung mit Prozessmodellen vorliegt. Für das Prozesstailoring werden daher
zwei Wissensquellen benötigt, die durch zwei Rollen beschrieben werden.
Zum einen gibt es die Rolle des Gate Managements, die auch häufig als
Prozessmodellierer bezeichnet wird. Diese besitzt langfristiges Wissen über
Prozesse und kann daher einschätzen, wann verschiedene Praktiken und
Werkzeuge für das aktuelle Projekt angemessen sind oder nicht. Das Gate
Management besitzt also die nötige Erfahrung, um Tailoring-Regeln aufzustellen.
Die Erfahrung wächst dabei mit jeder Projektdurchführung.
Seite 39
Die andere Wissensquelle, der Prozesstailorer, weist kurzfristiges Wissen über
den Kontext und die Beschaffenheit des aktuellen Projekts auf. Er stellt die
Projekt-Informationen als Eingabeparameter für das Prozesstailoring zur
Verfügung. Im Gegensatz zum Gate Management muss der Prozesstailorer nicht
über eine so große Erfahrung verfügen.
4.4 Tailoring basierend auf Bausteinen
Tabelle 4 zeigt exemplarisch, welche Möglichkeiten des Tailorings je nach
Projekteigenschaft in einzelnen Bausteinen bestehen können. Dabei können
Bausteine entweder komplett weggelassen werden oder aber die Anpassung wird
innerhalb des Bausteins selbst vorgenommen.
Paket Baustein
Struktur
Gate
Netzwerk
Tailoringmöglichkeiten
Beim Gate Netzwerk kann die Anzahl der im Netzwerk
enthaltenen Gates angepasst werden. Außerdem kann
man, wie beim V-Modell XT, unterschiedliche
Durchführungsstrategien für ein Gate wählen.
Die Wahl des Gate Managers kann sich nach seinem
Know-How und seiner Erfahrung richten. Dabei könnte
z.B. das Wissen über eingesetzte Technologien
Gate Manager
entscheidend sein. Außerdem können seine Aufgaben
bei größeren Projekten auf mehrere Personen aufgeteilt
werden.
Vorbedingung
Ziel
Die Größe und Wichtigkeit des Projekts können
ausschlaggebend dafür sein, ob für ein Gate mehrere
oder ob überhaupt Vorbedingungen und Ziele benötigt
werden.
Entscheidung
Nicht alle Entscheidungen sind auch in jedem
Projektzusammenhang sinnvoll. So können einzelne
Entscheidungs-Bausteine beim Quality Gate ausgelassen
werden. Z.B. kann die „conditional-go-Entscheidung“
entfallen, wenn man verhindern möchte, dass Gates auch
mit kleineren Fehlern in die nächste Phase des Projektes
eintreten dürfen. Jedoch ist auch die Anpassung
innerhalb einer Entscheidung möglich, indem bspw. bei
der go-Entscheidung der Toleranzschwellenwert der
Entscheidung bestimmt wird. Liegt der Schwellenwert
hoch, so ist das Eintreten in die nächste Phase des
Projekts schwerer zu erreichen.
Steuerung
Gatekeeper
Bei der Rolle des Gatekeepers kann z.B. deren Anzahl
angepasst werden. Bei kleineren Projekten sind z.B.
weniger Gatekeeper erforderlich als bei größeren. Ferner
können auf Grundlage ihrer Erfahrungen Anpassungen
vorgenommen werden. Für manche Projekte reicht
eventuell auch ein Gatekeeper, der noch keinen großen
Erfahrungsschatz besitzt.
Seite 40
Kriterium
Bei den Kriterien kann hinsichtlich des Untersuchungsgegenstandes (Was soll überprüft werden?) getailored
werden. Dabei wird unterschieden, ob alle Dokumente
oder nur Teile davon und ob Aktivitäten und deren
Ergebnisse überprüft werden sollen.
Kriteriendefinition
Je nach Projekteigenschaften kann die Kriteriendefinition
ausführlich oder weniger ausführlich durchgeführt
werden. Einzelne Schritte bei der Definition von Kriterien
können dabei entfallen.
Lieferant
Bei der Lieferung des Ergebnisses durch den Lieferanten
kann unterschieden werden, auf welche Weise die
Lieferung durchzuführen ist. Dabei kann die Lieferung
z.B. online oder persönlich erfolgen.
Gate
Review
Beim Gate Review kann getailored werden, welche und
wie viele Personen an der Gate-Sitzung teilnehmen.
Weiterhin können einzelne Schritte bei der Durchführung
der Sitzung je nach Projekt durchgeführt werden oder
nicht. Bspw. kann ein Kickoff als einleitendes Treffen
projektspezifisch hilfreich sein, um grundsätzliche
Vorgehensweisen, Aufgabenverteilungen und einen
Zeitplan festzulegen.
Protokoll
Beim Protokoll kann dessen Genauigkeit angepasst
werden. Ist es notwendig alle Aktivitäten zu protokollieren
oder reicht es aus, die Entscheidungsfindung am Ende zu
dokumentieren? Außerdem kann in speziellen Situationen
ganz auf ein Protokoll verzichtet werden.
Projektvertreter
Auch die Erfahrung der Projektvertreter kann je nach
Projektkonstellation verschiedenartig benötigt werden.
Ferner
können
unterschiedliche
Profile
bzw.
Wissensbereiche der Projektvertreter benötigt werden.
Z.B.
erfordert
ein
Projekt
größeres
betriebswirtschaftliches Hintergrundwissen als ein anderes.
Entscheidung
Inhalt
Checkliste
Es kann eine allgemeine Checkliste erstellt werden, die
alle möglichen Kriterien enthält. Für ein spezielles Projekt
muss diese Checkliste angepasst werden. Als sinnvoll
erachtete Kriterien werden übernommen, als nicht
sinnvoll erachtete Kriterien dagegen nicht.
Tabelle 4: Tailoringmöglichkeiten bei den einzelnen Bausteinen
Seite 41
5 Das Quality-Gate-Tailoringkonzept
Dieses Kapitel stellt das im Verlauf dieser Masterarbeit verwendete
Tailoringkonzept dar. Zunächst werden die Grundlagen der Fuzzy-Logik
aufgezeigt. Mit Hilfe eines Beispiels wird dann erläutert, wie die Fuzzy-Logik beim
Tailoring von Quality Gates angewandt wird und welche Aufgaben den TailoringRollen zugeordnet werden. Eine anschließende Diskussion über den Ansatz soll
Probleme und Schwierigkeiten des Algorithmus aufdecken. Am Ende wird das
Quality Improvement Paradigm (QIP) eingeführt.
5.1 Fuzzy Logik
Der Mensch hat im Vergleich zur Maschine die Gabe, Gegenstände anhand
unsicherer bzw. unscharfer Informationen zu beschreiben und zu bestimmen.
Experten vertrauen somit bei Problemlösungen oft auf ihren Menschenverstand.
Ein Computer kann nicht mit Hilfe der „einfachen Logik“ und derartigen
Informationen arbeiten, da er genaue Daten benötigt, um Entscheidungen treffen
zu können.
Die „einfache Logik“ wird in der Literatur „Bool’sche Logik“ genannt. Die Bool’sche
Logik verwendet harte Unterscheidungen, indem jedes Element entweder Mitglied
der Menge (1 bzw. „wahr“) ist oder nicht (0 bzw. „falsch“). Mathematisch gesehen
wird also die Menge {0,1} abgebildet. Ein kleines Beispiel soll die Problematik der
Bool’schen Logik aufzeigen: Ein Fahrzeug ab 150 km/h wird als „schnell“ definiert.
Wie ist jedoch ein Fahrzeug mit 149 km/h zu bezeichnen? Mit Hilfe der Bool’schen
Logik ist dieses Fahrzeug als nicht schnell einzustufen. Der normale
Menschenverstand sagt uns aber, dass dieses Fahrzeug trotzdem noch „schnell“
ist. Dabei arbeiten wir mit unscharfen Ausdrücken, wie „etwas“, „ca.“, „sehr“ oder
„ein bisschen“. Mit Hilfe dieser Ausdrücke können anschließend unscharfe Regeln
aufgestellt werden.
Beispiel für eine Regel:
„Wenn es ein bisschen zu kalt ist, muss die Heizung ein wenig stärker aufgedreht
werden“
Diese Form von Regeln kann der Computer jedoch nicht verstehen.
Zur Lösung dieses Problems hat L. A. Zahdeh, ein Professor für Elektrotechnik an
der University of California, bereits 1965 die Fuzzy-Set-Theorie entwickelt. Etwas
später wurde für diese Theorie dann der Begriff „Fuzzy Logik“ von George P.
Lakoff eingeführt. Die Fuzzy Logik erweitert die zweiwertige Bool’sche Logik auf
das Intervall [0,1], wodurch auch Werte zwischen 0 und 1 angenommen werden
können.
In der Abbildung 27 kann man den Vergleich von Bool’scher und Fuzzy Logik
anhand von Untermengen darstellen. In der linken Grafik kann man erkennen,
dass die Fuzzy-Untermenge die Bool’sche um Elemente erweitert. Die rechte
Grafik deutet an, dass Fuzzy-Werte auch Werte zwischen 0 und 1 annehmen
können. Beim Fahrzeug-Beispiel können nun Fahrzeuge, die 149 km/h schnell
fahren z.B. als „fast schnell“ bezeichnet werden.
Seite 42
Abbildung 27: Vergleich Bool'scher- und Fuzzy-Untermengen
Die Fuzzy Logik wird in der Praxis im Bereich der Steuerungs- und
Regelungstechnik verwendet. Aus diesem Grund werden im Folgenden die
Konzepte der Fuzzy Logik als Einstieg anhand einer Heizungssteuerung
beispielhaft dargestellt.
5.1.1 Linguistische Terme und linguistische Variablen
Eine linguistische Variable ist eine Variable, deren Werte durch sprachliche
Begriffe festgelegt sind. Die Menge der möglichen Werte der linguistischen
Variablen werden als Terme bezeichnet.
Beispiel:
Linguistische Variable
Temperatur
Linguistische Terme
• eiskalt
• kalt
• lauwarm
• heiß
5.1.2 Zugehörigkeitsfunktionen
Zugehörigkeitsfunktionen sind Funktionen, die auf das Intervall [0,1] abbilden. Sie
definieren den Wert, der einem linguistischen Term zugewiesen wird.
Abbildung 28: Zugehörigkeitsfunktion in der Bool'schen Logik
In der Abbildung 28 ist eine Zugehörigkeitsfunktion für die Heizungssteuerung in
der Bool’schen Logik dargestellt. Man kann gut erkennen, dass z.B. die
Raumtemperatur von 10°C nicht zu der Menge des linguistischen Terms „warm“,
dafür aber zur Menge des Terms „kalt“ gehört.
Seite 43
Abbildung 29: Zugehörigkeitsfunktion in der Fuzzy Logik
Die Zugehörigkeitsfunktion in der Fuzzy Logik lässt sich wie in Abbildung 29
darstellen. Nun können auch Werte zwischen 0 und 1 angenommen werden. Bei
16°C ist die Außentemperatur zu y=0.5, d. h. 50%, kalt und zu 50% warm.
Üblich bei der Erstellung von Zugehörigkeitsfunktionen sind Trapez-, Dreiecksund Singleton-Funktionen, die in der nachfolgenden Abbildung dargestellt sind.
Abbildung 30: Übliche Zugehörigkeitsfunktionen
Erlaubt sind jedoch alle Funktionen, die auf das Intervall [0,1] abbilden.
5.1.3 Logische Operatoren auf unscharfe Mengen
So wie bei den scharfen Mengen sind auch bei unscharfen Mengen folgende
Operationen möglich:
• Vereinigung
• Durchschnitt
• Komplement
Die folgende Abbildung 31 stellt zwei Funktionen dar, die jeweils einen
linguistischen Term repräsentieren.
Abbildung 31: Fuzzy-Funktionen A und B
Diese beiden Funktionen können nun mit Hilfe der Operationen miteinander
verknüpft werden:
Seite 44
Für die Vereinigung gilt, dass Funktion
C = A ODER B ist.
mathematisch:
fC = f A∨ B = max( f A , f B )
Für den Durchschnitt gilt, dass Funktion
C = A UND B ist.
mathematisch:
fC = f A∧ B = min( f A , f B )
Für das Komplement gilt, dass Funktion
C = NICHT (A ODER B)
mathematisch:
f C = f A∨ B = 1 − max( f A , f B )
Tabelle 5: Logische Operatoren auf unscharfen Mengen
5.1.4 Fuzzy-Controller
Bei einem Fuzzy-Controller handelt es sich um ein System, dass nicht, wie es
vermuten lässt, mit unsicheren, sondern mit scharfen Informationen arbeitet. Der
Fuzzy-Controller baut jedoch auf Fuzzy Logik auf. Abbildung 32 zeigt einen FuzzyController.
Abbildung 32: Aufbau eines Fuzzy-Controllers
Ein Fuzzy-Controller besteht aus den folgenden drei Schritten:
• Fuzzifizierung
• Fuzzy-Inferenz
• Defuzzifizierung
Seite 45
Das Fuzzy-System erhält einen scharfen Eingangswert (z.B. Temperatur) und
liefert einen scharfen Ausgangswert zurück. Im Kern des Controllers – der FuzzyInferenz – wird mit unscharfen Informationen und einer Regelbasis gearbeitet.
Daher sind zuvor eine Fuzzifizierung und anschließend eine Defuzzifizierung
nötig, um scharfe Werte in Fuzzy-Werte und umgekehrt umzurechnen.
In den folgenden Kapiteln soll nun genauer auf die einzelnen Schritte des FuzzyControllers eingegangen werden. Die Beschreibungen werden durch das Beispiel
der Heizungssteuerung gestützt.
5.1.5 Fuzzifizierung
Der erste Schritt des Fuzzy-Controllers besteht in der Fuzzifizierung der scharfen
Eingangswerte. Fuzzifizierung bezeichnet die Zuordnung der Eingangswerte zu
den Fuzzy-Mengen mit Hilfe der Zugehörigkeitsfunktion.
Beispiel:
In der Abbildung 33 ist die Zugehörigkeitsfunktion für die Temperaturregelung
eines Heizungsventils dargestellt. Diese ordnet Raumtemperaturwerten
linguistische Terme zu, die zu einem bestimmten Grad erfüllt sind.
Abbildung 33: Fuzzifizierung der Eingangswerte
Nehmen wir nun eine Raumtemperatur von 17°C an. Somit bekommt man zu
dieser Temperatur die Fuzzy-Messwerte: 0.25 „kalt“ und 0.75 „warm“. D.h. also,
dass die Temperatur zu 25% kalt und zu 75% warm ist.
Diese Messwerte werden anschließend in der Fuzzy-Inferenz verwendet.
5.1.6 Fuzzy-Inferenz
Die Fuzzy-Inferenz bildet den Kern des Fuzzy-Controllers. Dabei werden spezielle
Fuzzy-Regeln verwendet, um mit unscharfen Informationen arbeiten zu können.
Wenn man nicht spezielle Fuzzy-Regeln aufstellen würde, müsste man Regeln für
alle Eingabewerte erstellen. Dies ist jedoch in vielen Fällen nicht möglich. Alle
Fuzzy-Regeln zusammen bilden dann die Regelbasis. Die Regeln haben
folgenden Aufbau:
WENN <Fuzzy Aussage> DANN <Fuzzy Aussage>
Dabei bezeichnet die erste Fuzzy Aussage im „WENN“-Teil die Prämisse bzw. den
Zustand und die zweite Aussage im „DANN“-Teil die Konklusion bzw.
Schlussfolgerung.
Seite 46
Bevor man aber die Fuzzy-Regeln aufstellen kann, benötigt man eine zweite
Funktion, die die Output-Menge angibt. Diese ist wichtig, um Schlussfolgerungen
ziehen zu können.
In unserem Beispiel kann die Output-Funktion wie in der Abbildung 34 dargestellt
werden.
Abbildung 34: Funktion der Output-Menge in der Fuzzy-Inferenz
Die Funktion bezeichnet zwei Zustände: „kaum offen“ und „sehr offen“. Diese
geben prozentual an, wie weit das Heizungsventil geöffnet ist.
Nun können folgende Fuzzy-Regeln aufgestellt werden:
Regel 1:
Regel 2:
WENN Temperatur-ist-kalt
WENN Temperatur-ist-warm
DANN Heizventil-ist-sehr-offen
DANN Heizventil-ist-kaum-offen
Die Regeln verbinden auf diese Weise einzelne Funktionen aus der
Zugehörigkeitsfunktion (s. Abbildung 33) mit einzelnen Funktionen aus der OutputMenge (s. Abbildung 34). Für unseren Menschenverstand sind diese Regeln auch
intuitiv verständlich, denn wenn die Raumtemperatur als kalt bezeichnet wird,
dann muss die Heizung höher gestellt werden. Bei warmer Raumtemperatur muss
sie dementsprechend verringert werden.
Nun müssen die Fuzzy-Regeln, die die Funktionen miteinander verbinden, noch in
Bezug zu dem Ergebnis aus der Fuzzifizierung gebracht werden. Dieser Vorgang
wird Implikation genannt. Dabei gibt es mehrere Verfahren, von denen zwei an
dieser Stelle näher erläutert werden.
Mamdani-Implikation
Die meist verwendete Methode ist die Mamdani-Implikationen, die auch häufig als
„Max / Min“-Methode bezeichnet wird. Bei dieser Methode geht man davon aus,
dass die Konklusion maximal den Zugehörigkeitsgrad der Prämisse hat. Anders
ausgedrückt heißt das, dass die ermittelten Werte aus der Fuzzifizierung auf die
Funktion der Output-Menge abgetragen werden.
In der Abbildung 35 wird der Vorgang der Mamdani-Implikation näher erläutert.
Seite 47
Abbildung 35: Mamdani-Implikation
Auf der linken Seite der Grafik kann man noch einmal die
Zugehörigkeitsfunktionen für „kalt“ und „warm“ und deren Werte bei einer
Raumtemperatur von 17°C erkennen. Zur Erinnerung: Die Funktion „kalt“ hat den
Wert 0.25 und die Funktion „warm“ hat den Wert 0.75 angenommen.
Diese Werte werden nun mit Hilfe der Regeln auf die jeweilige Output-Funktion
übertragen. Regel 1 verbindet die Zugehörigkeitsfunktion „kalt“ mit der OutputFunktion „sehr offen“. Durch die Übertragung des y-Wertes 0.25 auf die OutputMenge erhält man die rot dargestellte Fläche, die durch die Schnittpunkte mit der
Output-Funktion festgelegt wird. Gleichermaßen kann man die Regel 2 anwenden,
die die Zugehörigkeitsfunktion „warm“ mit der Output-Funktion „kaum offen“
verbindet. Bei dem ermittelten Wert von 0.75 ergibt sich die blau dargestellte
Fläche des Graphen.
Im anschließenden Schritt bietet sich intuitiv an, beide Funktionen mit Hilfe des
ODER-Operators zu vereinigen. Die Vereinigung der Funktionen zeigt Abbildung
36.
Abbildung 36: Konklusionsmenge zweier Regeln durch Mamdani-Implikation
Die resultierende Funktion ist das Ergebnis der Fuzzy-Inferenz. In diesem Beispiel
wurden zwei Regeln verwendet. An dieser Stelle soll aber auch kurz dargestellt
werden, dass es möglich ist, eine derartige Funktion aus beliebig vielen Regeln zu
erstellen. Dabei können die Regeln außerdem auch noch mehrere Prämissen
beinhalten, die dann mit der Verknüpfung „UND“ oder aber „ODER“ verbunden
Seite 48
sind. Bei der UND-Verknüpfung wird dann das Minimum der jeweiligen
Eingabewerte der Prämissen auf die Output-Funktion übertragen. Bei der ODERVerknüpfung wird stattdessen das Maximum verwendet.
Eine Regel mit zwei Prämissen und einer Konklusion könnte so aussehen:
WENN Temperatur-ist-kalt UND Luftfeuchtigkeit-ist-gering
DANN Heizventil-ist-weit-offen
Die Implikation würde dann folgendermaßen aussehen:
„Feuchtigkeit“
„Temperatur“
1
1
0.5
1
„sehr offen“
MIN
„kalt“
0.5
0.5
„gering“
0
20 °C
14
17°C
0
20
40
%
50
100 %
23%
Abbildung 37: Mamdani-Inferenz mit zwei Prämissen
Der höhere y-Wert der Luftfeuchtigkeit wird aufgrund der UND-Verknüpfung nicht
verwendet, sondern nur, wenn die Prämissen mit ODER verknüpft werden.
Larsen’s Implikation
An Stelle der Mamdani-Implikation kann auch die Larsen’s Implikation verwendet
werden. Diese Implikation wird häufig als „Max / Prod“-Methode bezeichnet, da die
Output-Funktion, im Gegensatz zur Mamdani-Implikation, mit dem aus der
Fuzzifizierung gewonnenen y-Wert multipliziert wird.
Abbildung 38 zeigt die Larsen’s Implikation und dessen Unterschied zur MamdaniImplikation.
Abbildung 38: Larsen's Implikation
Seite 49
Dadurch ändert sich die Konklusionsmenge entsprechend der Abbildung 39.
Abbildung 39: Konklusionsmenge durch Larsen’s Implikation
Man kann sehen, dass sich in diesem Beispiel die resultierende Funktion im
Vergleich zur Mamdani-Implikation nur leicht unterscheidet.
5.1.7 Defuzzifizierung
Das Resultat der Fuzzy-Inferenz muss im letzten Schritt in einen scharfen
Ausgangwert zurückgeführt werden. Dieser Vorgang wird als „Defuzzifizierung“
bezeichnet. Es gibt eine Reihe von Defuzzifizierungs-Methoden, deren Basis
empirische Ergebnisse und heuristische Methoden bilden. Im Folgenden soll aber
nur auf die Wichtigsten eingegangen werden.
Die ersten drei Methoden betrachten die Maxima der Ergebnisfunktion aus der
Fuzzy-Inferenz, d. h. diejenigen Zugehörigkeitsfunktionen, die den größten in der
Fuzzifizierung ermittelten y-Wert haben. Die Methoden unterscheiden sich
folgendermaßen:
Left of Maximum (LoM)
Mean of Maximum (MoM)
Right of Maximum (RoM)
bezeichnet das ganz links liegende Maximum
bezeichnet das in der Mitte liegende Maximum
bezeichnet das ganz rechts liegende Maximum
Abbildung 40: Left-, Mean- und Right-of-Maximum-Methode
Anhand der Abbildung kann man die Unterschiede der Methoden genau erkennen.
Als scharfen Ausgangswert bekommt man im Falle der „Left of Maximum“–
Methode als Ergebnis, dass man bei einer Raumtemperatur von 17°C das
Heizungsventil zu 10% öffnen soll. Bei der „Mean of Maximum“-Methode beträgt
der Ausgangswert 27% und bei der „Right-of-Maximum“-Methode bereits 44%. An
diesem Beispiel kann man sehen, dass die Wahl einer dieser Methoden schon
große Ergebnisunterschiede hervorruft. Ein Nachteil ist außerdem, dass nur die
Maxima der Gesamtfunktion betrachtet werden ohne zu prüfen, wie die restliche
Funktion aufgebaut ist. Dadurch, dass in den meisten Fällen nur eine OutputMasterarbeit: Christian Peucker
Seite 50
funktion und damit auch nur eine Regel betrachtet wird, kommt man oft zu
ungenauen Ergebnissen. Vorteil dieser Methoden ist die leichte Berechnung.
Aus diesen Gründen wird in den meisten Fällen eine genauere Methode
angestrebt. Eine dieser Methoden ist die „Schwerpunktmethode“, die in der
Literatur auch als „Center-of-Gravity“ (CoG) bezeichnet wird. Die Schwerpunktmethode berechnet den Flächenschwerpunkt der Ergebnisfunktion.
Abbildung 41 stellt die Center of Gravity – Methode beispielhaft dar.
Abbildung 41: Schwerpunktmethode bzw. "Center of Gravity" (CoG)
Wie man sieht, erhält man als Ergebnis den scharfen Ausgangswert von 38%. Der
entscheidende Nachteil dieser Methode ist die Berechnung des Schwerpunktes.
Für die Berechnung muss die Fläche unter der Funktion mit Hilfe von Integralen
bestimmt werden. Die Bestimmung der Funktion und der Fläche ist jedoch sehr
aufwendig. Gerade bei komplizierteren Funktionen ist der Aufwand der Ermittlung
sehr groß. Daher soll an dieser Stelle nicht näher darauf eingegangen werden. Ein
weiterer Nachteil der Methode ist, dass z.B. bei sich stark überlappenden Flächen
die Berechnung der Ergebnisfunktionen ungenau ist.
Stattdessen soll nun die „Center-of-Maximum“-Methode genauer erläutert
werden. Bei dem Center-of-Maximum-Verfahren werden die Mean-of-MaximumWerte der einzelnen beteiligten Output-Funktionen ermittelt und entsprechend
gewichtet. Anschließend wird deren Mittel berechnet. Um sich eine genauere
Vorstellung machen zu können, soll das Verfahren Schritt für Schritt anhand der
Abbildung 42 erklärt werden.
Abbildung 42: Center-of-Maximum-Methode (CoM)
Zunächst einmal müssen die MoM’s der beteiligten Output-Funktionen berechnet
werden. In unserem Beispiel gibt es folgende zwei MoM’s:
x1 = 27 und x2 = 73
Seite 51
Diese Werte werden jeweils nun mit der „Höhe“ der Maxima, also den ermittelten
y-Werten, gewichtet. Dort bekommen wir die α -Gewichtungen:
α1 = 0.75 für das MoM x1 ,
α 2 = 0.25 für das MoM x2
Die ermittelten gewichteten MoM’s werden aufsummiert und anschließend über
die Summe der α -Werte normiert.
Allgemein sieht die zugehörige mathematische Formel folgendermaßen aus:
r
CoM =
α k ⋅ xk
∑
k =1
r
αk
∑
k =1
Formel 1: Berechnungsformel des Center of Maximum
mit r: Anzahl der Output-Funktionen.
Im Beispiel erhält man folgende Berechnung:
CoM =
0.75 ⋅ 27 + 0.25 ⋅ 73
= 38.5
0.75 + 0.25
Als scharfen Ausgangswert erhält man also das, wie in der Abbildung 42 auch
dargestellte, Center of Maximum von 38,5%. Wie man am Ergebnis erkennen
kann liegt dieser Wert in diesem Fall nicht weit entfernt von dem ermittelten Wert
aus der Schwerpunktmethode. Die Berechnung ist jedoch viel leichter durchzuführen.
Zur Bewertung der Defuzzifizierungs-Methoden soll Tabelle 6 als Übersicht
dienen:
RechenVorteile
Nachteile
aufwand
Left of Maximum
• leicht zu berechnen
• liefert in den meisten
sehr
Mean of Maximum
Fällen ungenaue
niedrig
Werte
Right of Maximum
Center of Gravity
• liefert oft gute Werte • Flächenberechnung
sehr aufwendig
• ungenau, wenn viele
hoch
Überlappungen
vorhanden sind
Center of
• liefert gute
Maximum
niedrig
Ergebnisse
Tabelle 6: Bewertung der Defuzzifizierungs-Methoden
Seite 52
5.2 Anwendung des Fuzzy-Ansatzes auf das Tailoring für Quality
Gates
In diesem Abschnitt der Arbeit soll zunächst dargestellt werden, warum der FuzzyLogik Ansatz für das Tailoring von Quality Gates eingesetzt werden kann. Nach
der Begründung folgt ein Beispiel, welches speziell auf Quality Gates bezogen ist.
Dieses Beispiel zeigt, wie das Tailoring auch später im Programm vollzogen wird.
Anschließend werden Probleme aufgezeigt, die beim Tailoring auftreten können,
und welche Aufgaben den beteiligten Rollen zugeordnet werden.
5.2.1 Gründe für den Einsatz der Fuzzy Logik beim Tailoring
Im vorigen Kapitel wurde die Fuzzy-Logik mit dessen Konzepten eingeführt. Die
Fuzzy-Logik wird in der Praxis im Bereich der Steuerungs- und Regelungstechnik
verwendet. An dieser Stelle soll nun geklärt werden, warum die Fuzzy-Logik auch
beim Tailoring von Quality Gates hilfreich sein kann.
Wie schon beim Fuzzy-Konzept erwähnt, gehört ein Element in der klassischen
Mengenlehre entweder zu einer Menge oder nicht. Dieser Ansatz entspricht der
Bool’schen Logik. Das Problem dabei ist die dadurch vorhandene Schärfe. Ein
kleines Beispiel soll die Problematik unterstützen:
Es soll eine Software erstellt werden, die ein Budget von 20.000 € nicht
überschreiten soll. In der Bool’schen Logik wäre die Lösung einfach: falls die
aktuellen Kosten der Software gleich oder unter 20.000 € liegen wird das Projekt
weiterhin durchgeführt, wenn jedoch die Kosten die 20.000 €-Marke überschreiten,
muss das Projekt eingestellt werden. Wie ist es jedoch zu bewerten, wenn ein
Projekt am Ende 20.001 € benötigt? Würde man das Projekt in der Realität wegen
einem Euro nicht trotzdem durchführen? Die Fuzzy-Logik arbeitet, wie
beschrieben, mit unscharfen Mengen, so dass minimale Abweichungen nicht
gleich zum Ausschluss zu der Menge führen.
Diese Problematik kann nun auf das Tailoring von Quality Gates am Beispiel einer
Checkliste übertragen werden. Eine Checkliste beinhaltet Kriterien, deren
Verwendung jedoch nicht für jedes Projekt und Gate sinnvoll ist. Ein TailoringAlgorithmus muss eine Entscheidung treffen, welche Kriterien in einer speziellen
Projektkonstellation sinnvoll sind oder nicht, um eine optimale Checkliste erstellen
zu können. Verwendet der Algorithmus die Bool’sche Logik so können Kriterien
verworfen werden, obwohl sie eventuell doch sinnvoll gewesen wären. Deshalb ist
der Einsatz einer Fuzzy-Logik, die eine nicht so scharfe Entscheidung darstellen
kann, sinnvoller.
In Kapitel 4.4 wurde beschrieben, welche Möglichkeiten in den einzelnen
Bausteinen bestehen, um dort ein Tailoring vorzunehmen zu können. Es stellt sich
aber die Frage, ob die unscharfe Berechnung auch bei allen Bausteinen sinnvoll
ist. Wie bereits beschrieben, kann das Tailoring von Checklisten mit Hilfe des
Fuzzy-Ansatzes durchgeführt werden. Betrachtet man jedoch den Baustein „Gate
Netzwerk“, bei dem die Anzahl der enthaltenen Gates angepasst werden kann,
würde eine Bool’sche Betrachtungsweise ausreichen, da ein Gate entweder im
Netzwerk enthalten ist oder nicht. Bei Bausteinen, die eine Rolle beschreiben, wie
der Gatekeeper, die Projektvertreter oder der Gate Manager, bietet sich wiederum
der Fuzzy-Ansatz an, da z.B. die Erfahrung der Rollen unscharf betrachtet werden
Seite 53
kann. Wie sich aber noch im Verlauf der Arbeit zeigen wird, stellt die
unterschiedliche Betrachtungsweise kein Problem dar, weil sich mit Hilfe des
Fuzzy-Ansatzes auch bool’sche Funktionen realisieren lassen.
5.2.2 Quality-Gate-Tailoring am Beispiel
Nachdem die Verwendung des Fuzzy-Logik-Ansatzes motiviert wurde, soll nun ein
speziell auf Quality Gates ausgelegtes Beispiel erläutert werden. Dieses Beispiel
zeigt, was genau im Hintergrund des in dieser Arbeit erstellten TailoringAssistenten passiert, indem es den Algorithmus erläutert. Der Algorithmus und das
Beispiel verwenden die Methode der Mamdani-Implikation bei der Fuzzy-Inferenz,
da es sich hierbei laut Literatur um die meist verwendete Methode handelt. Bei der
anschließenden Defuzzifizierung wird die Center-of-Maximum-Methode angewandt, weil sie einerseits gute Ergebnisse liefert und andererseits wenig
Rechenaufwand benötigt.
Für die Darstellung des Algorithmus kann das Tailoring am Beispiel einer
Checkliste dargestellt werden. Voraussetzung für die Anpassung ist die Angabe
von Projekteigenschaften. Mit Hilfe dieser Projekteigenschaften wird dann ein
Kriterium bewertet. In diesem Beispiel werden zwei Projektmerkmale betrachtet.
Zum einen die Teamgröße des Projekts und zum anderen die Projektgröße.
Später im Assistenten gibt es weitere Merkmale, die ein Projekt beschreiben. Die
Teamgröße wird als Anzahl von Personen, die Projektgröße als „Lines of Code“
(LOC) angegeben. Den Merkmalen wird nun beispielhaft ein vom Prozesstailorer
angegebener Wert zugeordnet:
Teamgröße: 35 Personen
Projektgröße: 85.000 Zeilen 3 (LOC)
Nun wird ein einzelnes Kriterium der Checkliste darauf untersucht, ob es unter den
gegebenen Projekteigenschaften sinnvoll ist, dieses zur Checkliste hinzuzufügen
oder nicht. Das Kriterium heißt in diesem Fall:
„Das Layout der Dokumente ist konsistent“
1. Schritt: Fuzzifizierung (Teamgröße)
Zunächst wird das Projektmerkmal „Teamgröße“ betrachtet. Wie man in dem
Fuzzy-Logik Kapitel sehen konnte benötigt man dazu erst einmal eine
Zugehörigkeitsfunktion, die das jeweilige Projektmerkmal beschreibt. Die
Zugehörigkeitsfunktion für die Teamgröße ist in Abbildung 43 dargestellt.
Abbildung 43: Zugehörigkeitsfunktion für die Teamgröße
3
Das Beispiel beruht auf der Annahme eines kleinen bis mittelgroßen Unternehmens. Bei anderen
Unternehmensgrößen kann die Anzahl der LOC erheblich variieren.
Seite 54
Die Teamgröße besteht in diesem Fall aus drei linguistischen Termen: „klein“,
„mittel“ und „groß“, die mit Hilfe von Funktionen beschrieben werden. Eine
Besonderheit ist, dass die Funktion für den Term „groß“ für alle Werte größer
gleich 40 den Wert 1 annimmt. Betrachtet man nun den vom Prozesstailorer
angegebenen scharfen Eingangswert von 35 Teammitgliedern kann man die
folgenden y-Werte für die linguistischen Terme aus der Funktion durch die
Schnittpunkte ablesen:
„klein“ =
„mittel“ =
„groß“ =
0
0.3
0.5
2. Schritt: Fuzzy-Inferenz (Teamgröße)
Weiterhin benötigt man für die Bewertung des Kriteriums die Angabe der OutputFunktion (Abbildung 44) und die Regeln, die die Zugehörigkeitsfunktion und die
Output-Funktion miteinander verbinden. Diese Regeln sehen folgendermaßen
aus:
Regel 1: WENN Teamgröße = klein DANN Kriterium = nicht enthalten
Regel 2: WENN Teamgröße = mittel DANN Kriterium = evtl. enthalten
Regel 3: WENN Teamgröße = groß DANN Kriterium = enthalten
Abbildung 44: Output-Funktion für Teamgröße und Kriterium
In der Output-Funktion (Abbildung 44) sind die Funktionen für die Bewertung des
Kriteriums und des Merkmals „Teamgröße“ dargestellt. Außerdem im Graphen
enthalten sind die Flächen, die durch Übertragung der ermittelten y-Werte aus der
Zugehörigkeitsfunktion und durch die Mamdani-Implikation entstanden sind.
3. Schritt: Defuzzifizierung (Teamgröße)
Abbildung 45: Bewertung des Kriteriums nach der Teamgröße
Seite 55
Im letzten Schritt, der Defuzzifizierung, wird das Center of Maximum mit Hilfe der
Mean of Maxima der beiden Output-Funktionen gebildet (s. Abbildung 45).
Berechnung des Center of Maximum (nach Formel S.52):
CoM Teamgröße =
0.3 ⋅ 50 + 0.5 ⋅ 80
= 68
0.3 + 0.5
Aus dem Ergebnis kann gefolgert werden, dass das Kriterium bei einer
Teamgröße von 35 Personen zu 68% für die Projekt-Checkliste sinnvoll ist.
Nachdem das Kriterium an der Teamgröße bewertet wurde, muss in gleicher
Weise die Bewertung für die „Projektgröße“ vorgenommen werden.
1. Schritt: Fuzzifizierung (Projektgröße)
Die Zugehörigkeitsfunktion für dieses Merkmal besitzt fünf Funktionen, die die
Projektgröße von „sehr klein“ bis „sehr groß“ charakterisiert (Abbildung 46).
Abbildung 46: Zugehörigkeitsfunktion für die Projektgröße
Das Ablesen der Schnittpunkte für den scharfen Eingangswert von 85.000 Lines of
Code, die vom Prozess-Tailorer festgelegt wurden, mit den einzelnen Funktionen
ergibt folgendes Ergebnis:
„sehr klein“
„klein“
„mittel“
„groß“
„sehr groß“
=
=
=
=
=
0
0
0.25
0.5
0.5
2. Schritt: Fuzzy-Inferenz (Projektgröße)
Nun benötigt man wiederum Regeln, die die Zugehörigkeitsfunktionen mit den
Output-Funktionen des Kriteriums verbinden. Da es fünf linguistische Terme gibt,
werden dementsprechend auch folgende fünf Regeln aufgestellt:
Regel 1:
Regel 2:
Regel 3:
Regel 4:
Regel 5:
WENN
WENN
WENN
WENN
WENN
Projektgröße = sehr klein
Projektgröße = klein
Projektgröße = mittel
Projektgröße = groß
Projektgröße = sehr groß
DANN
DANN
DANN
DANN
DANN
Kriterium = sehr wenig
Kriterium = wenig
Kriterium = mittel
Kriterium = viel
Kriterium = sehr viel
Seite 56
Die Output-Funktion, die die Bewertung für das Kriterium anhand der Projektgröße
darstellt kann man in folgendem Graphen erkennen:
Abbildung 47: Output-Funktion für Projektgröße und Kriterium
In der Abbildung sind wieder die y-Werte aus dem Fuzzifizierungs-Schritt
abgetragen. Betroffen sind drei Output-Funktionen, die dann mit Hilfe der
Mamdani-Implikation drei Flächen (grau, grün und gelb) in dem Graphen bilden.
Die Flächen selbst überlappen sich zum Teil.
3. Schritt: Defuzzifizierung (Projektgröße)
Im letzten Schritt muss nun wieder ein scharfer Ausgangswert ermittelt werden.
Dadurch werden die Mean of Maxima der drei aus der Fuzzy-Inferenz ermittelten
Funktionen und anschließend das Center of Maximum berechnet (s. Abbildung
48).
Abbildung 48: Bewertung des Kriteriums nach der Projektgröße
Berechnung des Center of Maximum:
0.25 ⋅ 50 + 0.5 ⋅ 75 + 0.5 ⋅ 92,5
= 77
CoM Teamgröße =
0.25 + 0.5 + 0.5
Ergebnis der Berechnung ist, dass es zu 77% sinnvoll ist bei einer Projektgröße
mit 85.000 Lines of Code das Kriterium in die Checkliste aufzunehmen.
Gesamtergebnis
Aus den vorherigen Berechnungen hat man nun ein einzelnes Kriterium nach den
zwei Projektmerkmalen „Teamgröße“ und „Projektgröße“ bewertet. Die Ergebnisse
bzw. die Center of Maxima aus diesen Berechnungen müssen jetzt in eine
Gesamtbewertung einfließen. Dazu bildet man jedoch nicht einfach den Mittelwert
der beiden CoM’s, sondern man verwendet, wie zuvor in der Einzelberechnung,
die CoM-Formel (S. 52) mit den MoM’s und deren Gewichtung aus beiden
Merkmalen.
Seite 57
Abbildung 49 zeigt zunächst die resultierende Funktion aus der Fuzzy-Inferenz
beider betrachteten Merkmale.
Abbildung 49: Gesamtbewertung des Kriteriums nach Team- & Projektgröße
Dabei bilden insgesamt fünf MoM’s mit deren α -Gewichtungen die folgende
Berechnung:
0.25 ⋅ 50 + 0.5 ⋅ 75 + 0.5 ⋅ 92,5 + 0.3 ⋅ 50 + 0.5 ⋅ 80
CoM Teamgröße =
= 73, 44
0.25 + 0.5 + 0.5 + 0.3 + 0.5
Das Ergebnis kann nun derart interpretiert werden, dass das betrachtete Kriterium
zu ca. 73% bei einer Teamgröße von 35 Personen und Projektgröße von 85.000
Lines of Code für die Checkliste sinnvoll ist.
Wie man in der Abbildung 49 auch sehr gut an den gestrichelten Linien erkennen
kann, kommt es schon bei den beiden im Beispiel betrachteten Projektmerkmalen
zu erheblichen Überlappungen. Diese Überlappungen würden bei der Verwendung der Center-of-Gravity-Methode schon zu ungenaueren Ergebnissen
führen.
Dieses Beispiel zeigt, wie das Tailoring einer Checkliste anhand der Bewertung
eines Kriteriums durchgeführt werden kann. Für das Tailoring der gesamten
Checkliste müssen natürlich viel mehr Kriterien betrachtet und bewertet werden.
Ein zweites Beispiel soll darstellen, dass nicht nur das Tailoring einer Checkliste
möglich ist, sondern auch andere Tailoring-Bausteine angepasst werden können.
Es betrachtet die Rolle des Gatekeepers und zeigt eine Tailoringmöglichkeit auf,
die schon zuvor in Kapitel 4.4 beschrieben wurde. Beim Gatekeeper spielt die
Erfahrung im Umgang mit Projekten eine sehr große Rolle. So ist es gerade bei
großen Projekten mit entsprechend vielen Projektvertretern und zu überprüfenden
Dokumenten notwendig, einen erfahrenen Gatekeeper einzusetzen. Bei kleineren
Projekten können hingegen Erfahrungen gesammelt werden.
Der spätere Assistent behandelt das Tailoring beim Gatekeeper jedoch auf die
gleiche Weise, wie beim tailorn einer Checkliste. In diesem Fall jedoch verwendet
man Aussagen, die wie Kriterien behandelt werden. Für den Gatekeeper kann so
folgende Aussage formuliert werden:
„Der Gatekeeper muss über eine große Erfahrung verfügen“
Betrachten wir nun wieder die Projektgröße mit der Zugehörigkeitsfunktion aus
Abbildung 46 und dem Eingabewert von 85.000 Lines of Code. Die Schnittpunkte
der Funktion bleiben, wie zuvor:
Seite 58
„sehr klein“
„klein“
„mittel“
„groß“
„sehr groß“
=
=
=
=
=
0
0
0.25
0.5
0.5
Die Regeln ändern sich nur minimal, da sie auf die oben genannte Aussage
bezogen werden:
Regel 1:
Regel 2:
Regel 3:
Regel 4:
Regel 5:
WENN
WENN
WENN
WENN
WENN
Projektgröße = sehr klein
Projektgröße = klein
Projektgröße = mittel
Projektgröße = groß
Projektgröße = sehr groß
DANN
DANN
DANN
DANN
DANN
Aussage = sehr wenig
Aussage = wenig
Aussage = mittel
Aussage = viel
Aussage = sehr viel
Im Gegensatz zum ersten Beispiel ändert sich jedoch die Bewertung der Aussage
in Form der Output-Funktion.
Abbildung 50: Output-Funktion für das Tailoring beim Gatekeeper
Wie in Abbildung 50 dargestellt, erhält man nun durch Abtragen der y-Werte die
Schnittpunkte mit den Funktionen „mittel“, „viel“ und „sehr viel“.
Abbildung 51: Bewertung der Aussage nach der Projektgröße
Dabei entsteht wiederum eine Ergebnisfläche mit drei Mean-of-Maxima, die in
Abbildung 51 abgebildet sind. Auf diese wird nun die Formel zur Berechnung des
Center-of-Maximums (Formel 1) angewandt:
CoM Projektgröße =
0.25 ⋅ 63, 75 + 0.5 ⋅ 85 + 0.5 ⋅ 97,5
= 85, 75
0.25 + 0.5 + 0.5
Das Ergebnis sagt aus, dass für die gegebene Projektgröße der Gatekeeper zu
ca. 86% große Erfahrung besitzen sollte. Der Prozesstailorer kommt bei diesem
Ergebnis zu dem Schluss, dass es sinnvoll ist erfahrene Gatekeeper einzusetzen.
Seite 59
Auf diese Weise können nun alle möglichen Aussagen in allen Bausteinen
bewertet werden. Das Ergebnis gibt Aufschluss darüber, ob die Aussage in einer
bestimmten Projektkonstellation als sinnvoll erachtet wird.
5.2.3 Interpretation des Fuzzy-Ergebnisses (Filter)
Der Tailoring-Algorithmus, wie er zuvor anhand eines Beispiels erläutert wurde,
liefert als Ausgabe einen scharfen prozentualen Wert, der die Zugehörigkeit des
jeweiligen Kriteriums zum Quality Gate angibt. Doch was kann der Prozesstailorer
mit diesen Werten anfangen? Bei großen Werten an die 100% und kleinen Werten
gegen 0% ist die Entscheidung noch einfach zu treffen. Aber wie sind die anderen
Ergebnisse zu bewerten?
Diese Werte müssen also im letzten Schritt noch interpretiert werden. Dazu kann
ein bis zu 5-stufiger Filter mit Hilfe von Ampelfarben eingesetzt werden. Die
Ampelfarben signalisieren dem Prozesstailorer sofort visuell, ob ein Kriterium für
das Quality Gate als sinnvoll, als nicht sinnvoll oder als nicht ad hoc bewertbar
angesehen wird. Jeder Farbe wird ein prozentualer Bereich zugeordnet. Der
gängigste Filter besteht aus den bekannten Ampelfarben rot, gelb und grün. Da in
manchen Fällen ein 3-stufiger Filter zu ungenau ist, kann z.B. stattdessen ein 5stufiger eingesetzt werden. Dazu werden zusätzlich noch die Farben orange und
hellgrün verwendet. Beispielsweise kann folgender Filter festgelegt werden:
Farbe
rot
orange
gelb
hellgrün
grün
von
0%
30%
40%
60%
70%
bis
29%
39%
59%
69%
100%
Beispiel
Tabelle 7: Beispiel für einen Filter
Das Beispiel in der Tabelle 7 zeigt die Darstellung, die auch später im TailoringAssistenten verwendet wird. Der Tailorer erkennt auf den ersten Blick die farbliche
Einstufung des Kriteriums, kann aber trotzdem die genauen Ausgangswerte
erkennen und selbst eine Entscheidung treffen.
5.2.4 Aufgaben der Tailoringrollen
Im Kapitel 4.3 wurden die beim Tailoring beteiligten Rollen des Gate
Managements (bzw. Prozessmodellierers) und des Prozesstailorers bereits
beschrieben. Nachdem nun die Funktionalität des Tailoring-Algorithmus näher
erläutert wurde, können nun die Aufgaben für diese Rollen genauer spezifiziert
werden.
Aufgrund des Erfahrungsschatzes hat das Gate Management innerhalb des
Tailorings die Aufgabe die Tailoring-Regeln, d.h. die zur Bewertung eines
Kriteriums benötigten Funktionen, aufzustellen. Dazu gehören zum einen die
Zugehörigkeitsfunktionen für die Projektmerkmale und zum anderen die OutputFunktionen, die einem Kriterium für jedes Merkmal zugeordnet werden. Weiterhin
muss das Gate Management die Regeln erstellen, die beide Funktionen
miteinander verbinden. Die Aufstellung der Funktionen ist eine schwierige
Seite 60
Aufgabe, da man genau wissen muss, wie sich eine bestimmte Funktion auf die
Bewertung des Kriteriums bei einem speziellen Projektprofil auswirkt. Das Gate
Management benötigt daher fundiertes Wissen über die Funktionsweise des
Tailoring-Algorithmus. Außerdem ist ein gutes mathematisches Hintergrundwissen
von Vorteil. Einige Schwierigkeiten, die bei der Erstellung der Funktionen auftreten
können, werden im nächsten Abschnitt, bei der Diskussion des TailoringAnsatzes, dargestellt.
Der Prozesstailorer hat stattdessen eine leichtere Aufgabe zu bewältigen. Er
verwendet lediglich den Tailoring-Assistenten, um das Quality-Gate-Tailoring
durchzuführen, ohne genau wissen zu müssen, was im Hintergrund passiert.
Dabei muss der Tailorer die Charakteristika des aktuellen Projektes im TailoringAssistenten angeben. Nach dem Ausführen des Tailoring-Algorithmus besteht
eine weitere Aufgabe darin, unbewertete Kriterien nachträglich selbst zu bewerten.
Am Ende wird das Ergebnis in einer Übersicht angezeigt.
5.2.5 Diskussion des Tailoring-Ansatzes
In diesem Kapitel wird nun der beschriebene und durch Beispiele erklärte
Tailoring-Ansatz näher diskutiert. Dabei werden Hinweise, Probleme und
Schwierigkeiten des Fuzzy-Konzeptes erläutert und ggf. Lösungsansätze vorgeschlagen.
Das Mengen-Problem bei der Bestimmung von Funktionen
Das größte und schwerwiegendste Problem des Algorithmus ist die Bewertung der
Kriterien in Form von mathematischen Funktionen. Wie man an dem Beispiel für
das Fuzzy-Tailoring sehen konnte, benötigt man für die Bewertung eines
Kriteriums zum einen eine Zugehörigkeitsfunktion für jedes Projektmerkmal (z.B.
Projektgröße und Teamgröße). Zum anderen erfordert es für jedes Kriterium und
jeweils jedes Merkmal eine weitere Output-Funktion. Ein kleines Rechenbeispiel
soll die Problematik präziser darstellen:
Angenommen der Tailoring-Assistent besteht aus 15 Merkmalen. Nun soll eine
Checkliste, die insgesamt 30 Kriterien beinhaltet, getailored werden. Für das
Tailoring werden zunächst 15 Zugehörigkeitsfunktionen für die Projektmerkmale
beansprucht. Für die Bewertung jedes der 30 Kriterien benötigt man zusätzlich
15 ⋅ 30 = 450 Output-Funktionen. Insgesamt erfordert der Tailoring-Algorithmus
also 465 mathematische Funktionen, die vom Gate Management bzw.
Prozessmodellierer festgelegt werden müssen. Natürlich muss man
berücksichtigen, dass dieser Vorgang nicht in einem Schritt durchgeführt wird,
sondern sich über die Zeit hinweg aus den Erfahrungen mit Projekten ergibt.
Dabei muss man sich vor Augen führen, dass jedes zusätzlich eingefügte
Projektmerkmal 30 neue Outputfunktionen und eine Zugehörigkeitsfunktion
erfordert. Andersherum benötigt man beim Einfügen eines weiteren Kriteriums
immerhin 15 neue Outputfunktionen. Für diese Problematik gibt es leider keinen
nahe liegenden Lösungsansatz.
Seite 61
Das 100%-Bewertungs-Problem
Ein entscheidender Prüfstein für die Bewertung eines Kriteriums liegt in der
richtigen Wahl der entsprechenden Funktion. Schon kleine Änderungen an dem
Verlauf der Funktionen können in bestimmten Situationen großen Einfluss auf das
Ergebnis des Tailoring-Vorgangs besitzen. Gerade bei Kriterien einer Checkliste
kommt es vor, dass manche dieser Kriterien in jedem Quality Gate sinnvoll sind.
Daher muss man für diese eine Funktion angeben, die in jedem Fall eine 100%ige
Übereinstimmung als Ergebnis liefert. Aber wie sieht so eine Funktion aus?
Nehmen wir als Beispiel (Abbildung 52) die Funktionen aus dem Kapitel 5.2.2
(Quality-Gate-Tailoring am Beispiel) für die Teamgröße an.
Abbildung 52: Beispiel-Funktion für das 100%-Bewertungs-Problem
Die beiden Funktionen sind, wie im Beispiel, mit folgenden Regeln verbunden:
Regel 1: WENN Teamgröße = klein DANN Kriterium = nicht enthalten
Regel 2: WENN Teamgröße = mittel DANN Kriterium = evtl. enthalten
Regel 3: WENN Teamgröße = groß DANN Kriterium = enthalten
Man nimmt an, dass bei der Wahl von 50 Personen für die Teamgröße am Ende
eine Bewertung von 100% als Ergebnis herauskommen wird. Als Ergebnis
bekommt man jedoch eine Bewertung von 85%. Wie kommt es zu diesem
Ergebnis?
Zunächst einmal bekommt man, wie erwünscht, aus der Zugehörigkeitsfunktion
(obere Fkt.) für den scharfen Eingangswert von 50 den y-Wert 1 geliefert.
Überträgt man diesen auf die Bewertungs-Output-Funktion für das Kriterium
(untere Fkt.) erhält man schließlich die grüne Fläche als Ergebnisfläche. Auf diese
Fläche wird die Center-of-Maximum-Methode angewandt, die die Mitte der
Maxima ermittelt. Es wird also die Mitte zwischen 70 und 100, also genau 85
ermittelt.
Wie sieht nun aber eine Output-Funktion für das Kriterium aus, die in diesem Fall
100% liefern würde?
Seite 62
Abbildung 53: Lösungsfunktionen
Abbildung 53 stellt zwei mögliche Funktionen dar. Die linke Funktion zeigt einen
Singleton, der für alle ermittelten y-Werte aus der Zugehörigkeitsfunktion das
Ergebnis von 100% liefert. Für den Fall, dass ein Kriterium nie enthalten sein soll,
kann die Singleton-Funktion bei 0% verwendet werden. Die rechte Funktion
dagegen ergibt nur 100%, wenn der y-Wert den Maximal-Wert von 1 erreicht.
Ansonsten gibt es auch Abstufungen davor.
Das Problem bei der Darstellung von bool’schen Funktionen
Wie in der vorherigen Problemdiskussion gesehen, besteht die Möglichkeit, das
Ergebnis durch Singleton-Funktionen zu beeinflussen. Damit kann man z.B. von
vornherein festlegen, dass, unabhängig von der Teamgröße, das Ergebnis einen
bestimmten Wert hat. Wie kann man jedoch bool’sche Funktionen darstellen, die
aussagen, dass ein Kriterium bis zu einer Teamgröße von 24 Personen zu 0%
sinnvoll und ab 25 Personen zu 100% sinnvoll erscheinen soll?
Abbildung 54: Beispiel für die Darstellung einer bool'schen Funktion
Um das Beispiel darzustellen, muss die linke Funktion aus Abbildung 54 zur
Zugehörigkeitsfunktion hinzugefügt werden. Die Output-Funktion (rechte Fkt.) stellt
wieder einen Singleton bei 100% dar. Beide Funktionen müssen anschließend mit
Hilfe einer Regel verbunden werden. Der Assistent bekommt für Eingaben unter
25 Personen keinen y-Wert geliefert, da es keinen Schnittpunkt mit der Funktion
gibt. Der Assistent liefert als Ergebnis in diesem Fall 0%. Wenn Eingaben ab 25
Personen angegeben werden, erhält man den y-Wert von 1 und erhält durch
Übertragung auf die Output-Funktion als Ergebnis 100%.
Das Höhe-Problem
Bei der Erstellung von Output-Funktionen kann der Prozessmodellierer auch die
Höhe der einzelnen Funktionen festlegen. Abbildung 55 stellt die veränderte
Output-Funktion aus Abbildung 52 mit der halben Höhe dar.
Seite 63
Abbildung 55: Beispiel-Output-Funktion für Höhe-Problem
Die Veränderung der Höhe kann jedoch zu einem Problem führen. Wird ein y-Wert
größer 0.5 ermittelt (z.B. bei einer Teamgröße von 23 Personen), so kann kein
Schnittpunkt mit der Output-Funktion ermittelt werden. Der Algorithmus liefert in
solchen Fällen 0% als Ergebnis.
Wie in diesem Abschnitt gesehen, können bei der Erstellung der Funktionen einige
Probleme auftreten. Diese muss der Prozessmodellierer bei der Wahl der
Funktionen beachten, damit die Bewertung für die Kriterien auch wie gewünscht
interpretiert wird.
5.3 Quality Improvement Paradigm (QIP)
Im Kapitel 4 wurde beschrieben, dass die Erfahrung, die innerhalb eines jeden
Projektes gesammelt wird, zur Verbesserung des Tailoringprozesses eingesetzt
werden kann. Für den entstehenden Erfahrungskreislauf kann der QIP-Ansatz
verwendet werden.
Das Quality Improvement Paradigm (QIP) [27] ist ein Ansatz zur kontinuierlichen
Verbesserung und systematischen Durchführung von Software-Projekten. Das
QIP-Modell wurde von Victor Basili entwickelt und 1984 erstmals veröffentlicht. Es
beschreibt, wie Erfahrungen prozessbegleitend gesammelt, ausgewertet und
aufbereitet werden können, um sowohl für laufende als auch für nachfolgende
Projekte verbessernd eingesetzt zu werden.
Die Softwareentwicklung ist naturgemäß evolutionär und jede Projektumgebung ist
verschieden. Aus diesem Grund kann man Prozessverbesserung nur schwer
durch statistische Kontrolle erreichen. Das QIP geht von der Prämisse aus, dass
alle Projektumgebungen und zu erstellenden Produkte verschieden sind.
Das Ziel des QIP-Modells ist die Erfassung und Aufbereitung von positiven, aber
auch negativen Erfahrungen, die während eines Projektes gesammelt werden, um
die Auswertung der Erfahrungen in anderen Projektumgebungen wiederverwenden zu können. Der Ansatz der „wiederverwendbaren Erfahrungen“ ist
vergleichbar mit dem „Code Reuse“–Ansatz.
Seite 64
5.3.1 QIP-Zyklus
Das QIP-Modell beinhaltet zwei Feedback-Zyklen – der organisatorische und der
projektspezifische Zyklus. Abbildung 56 stellt beide Zyklen innerhalb des QIPModells näher dar.
Abbildung 56: Quality-Improvement-Paradigm-Zyklus [7]
Der kleinere, projektspezifische Feedback-Zyklus („project learning“) stellt
Informationen während der Ausführung eines Projektes bereit, die der
Projektkontrolle dienen. Diese Informationen sind nützlich, um auftretende
Probleme rechtzeitig erkennen zu können und unterstützen das Erreichen der
Projektziele.
Der größere, organisatorische Feedback-Zyklus („corporate learning“) enthält das
Feedback, das der gesamten Software-Organisation nach Beendigung des
Projektes zur Verfügung steht. Es werden Unterschiede und Gemeinsamkeiten
zwischen den Daten, die während des Projektes gesammelt wurden und den
Daten, die in einer Erfahrungsdatenbank („experience base“) abgelegt wurden,
ermittelt. Dadurch können neue Erfahrungen in die Erfahrungsdatenbank
einfließen. Der organisatorische Feedback-Zyklus ist in sechs Phasen eingeteilt.
Phase 1: „Charakterisieren und Verstehen“
Ziel der ersten Phase des QIP-Modells ist die Charakterisierung des aktuellen
Projekts, um ein Verständnis für das Projekt und dessen Ansprüche aufzubauen.
Mit diesen Charakteristika werden in der Erfahrungsdatenbank Erfahrungen
identifiziert, die Ähnlichkeiten zu den Prozessen des Projekts aufweisen, um diese
möglicherweise wiederverwenden zu können.
Phase 2: „Ziele setzen“
In der zweiten Phase werden Ziele für eine erfolgreiche Projektdurchführung und
-verbesserung gesetzt. Diese Ziele sollen möglichst quantitativ und messbar sein,
um zuverlässige Daten zu bekommen. Zur Überprüfung dieser Ziele, während der
Seite 65
Durchführung des Projektes, werden Maße festgelegt. Beispiele für solche Maße
sind die Anzahl und Art der Fehler, die bei einer Inspektion gefunden wurden.
Phase 3: „Prozesse, Methoden und Werkzeuge auswählen“
In diesem Schritt werden für das Projekt geeignete Prozesse, Methoden und
Werkzeuge gewählt. Die Entscheidung basiert auf der Charakterisierung des
Projekts aus der ersten Phase und auf der Zielsetzung der zweiten Phase. Ziel der
Phase ist ein Projektplan, der es erlaubt, die Projektziele zu erreichen.
Phase 4: „Prozessausführung“
Die vierte Phase des organisatorischen Feedback-Zyklus beinhaltet die
Ausführung des Prozesses, d.h. der Ablauf des Projekts wird entsprechend dem
erstellten Projektplan durchgeführt. Diese Phase wird durch den
projektspezifischen Zyklus beschrieben. Der projektspezifische Feedback-Zyklus,
der zeigt, wie sich das Projekt selbst steuert und verbessert, ist in drei Aktivitäten
unterteilt:
1. „Prozess ausführen“
Bei der Prozessausführung wird das Produkt erstellt und zu definierten
Zeitpunkten Daten über den Prozess gesammelt.
2. „Ergebnisse analysieren“
Die gesammelten Daten werden im nächsten Schritt in Hinsicht auf die
gesetzten Ziele analysiert, indem sie z.B. mit Soll-Daten verglichen
werden.
3. „Prozess mit Feedback unterstützen“
Die aus der Analyse gewonnenen Ergebnisse können in den Prozess
einfließen, um ihn zu verbessern. Beispielsweise können bei einem nicht
zufriedenstellenden Soll/Ist-Datenvergleich frühzeitig Konsequenzen für
das Projekt, noch während der Projektdurchführung, gezogen werden.
Phase 5: „Ergebnisse analysieren“
In der fünften Phase des QIP-Modells wird der Projektablauf und das
Projektergebnis analysiert und bewertet. Dabei werden in der Analyse Vorschläge
für spätere Projekte entwickelt und sowohl positive als auch negative Erfahrungen
aus dem Projekt ausgewertet. Anschließend werden diese Erfahrungen und
Vorschläge formuliert. Eine mögliche Erfahrung ist z.B., dass für die gegebenen
Projektcharakteristika die angewandte Inspektionstechnik weniger effektiv ist als
erwartet.
Phase 6: „Verpacken und Erfahrung speichern“
Die sechste und abschließende Phase des organisatorischen Feedback-Zyklus
beinhaltet die Aufbereitung und das „Verpacken“ der gewonnenen Erfahrungen.
Die Erfahrungen werden in der Erfahrungsdatenbank zur späteren Nutzung
abgelegt.
Um eine aussagekräftige Erfahrungsdatenbank zu erhalten sind jedoch einige
Zyklus-Iterationen nötig. Solch eine Datenbank ist allerdings nie vollständig und
bedarf dauernder Aktualisierung und Aufbereitung mit neu gewonnenen
Erfahrungen.
Seite 66
5.3.2 QIP-Bezug zum Tailoring
Beim Tailoring spielt die kontinuierliche Prozessverbesserung ebenfalls eine große
Rolle. Die für das Tailoring wichtigen Funktionen für die Kriterien und
Projektmerkmale werden vom Prozesstailorer aus den Erfahrungen verschiedener
vorhergehender Projekte gebildet.
Das QIP-Modell kann bei der Erstellung dieser Funktionen helfen, indem durch die
beschriebene Sammlung und Auswertung von Erfahrungen während der
Durchführung des Projektes eine Erfahrungsdatenbank erstellt wird. Der Prozesstailorer muss entsprechend neu gewonnener Erfahrungen die Funktionen des
Tailoring-Algorithmus anpassen, um dabei bessere Ergebnisse zu erzielen.
Am Anfang einer Erfahrungssammlung kann der Prozesstailorer Annahmen auf
Grundlage seiner eigenen Erfahrungen treffen und Funktionen erstellen, die für ihn
sinnvoll erscheinen. Innerhalb eines Projektes kann dann entschieden werden, ob
ein vom Tailoring-Algorithmus für sinnvoll erschienenes Kriterium in diesem
spezifischen Projekt auch wirklich sinnvoll ist. Wenn nicht, kann dies als neue
Erfahrung aufgenommen und im Algorithmus berücksichtigt werden. Auf der
anderen Seite kann während des Projektes aber auch der Fall auftreten, dass ein
vom Algorithmus nicht gewähltes Kriterium doch sinnvoll gewesen wäre. Auch
diese Erfahrung muss in die Erfahrungsdatenbank einfließen, um den Algorithmus
zu verbessern.
Eine andere Möglichkeit bei der anfänglichen Erstellung der Funktionen bietet der
„Best-Practise“-Ansatz. Dort geht man zunächst davon aus, dass alle Bewertungen zu den Kriterien bzw. Aussagen am Anfang gleichwertig behandelt
werden. So kann das Ergebnis eines ersten Tailorings so aussehen, dass alle
Kriterien eine Bewertung von 100% bekommen. Durch den Erfahrungskreislauf
werden dann die Bewertungen nach und nach angepasst.
Eine Erfahrungsdatenbank ist jedoch von Organisation zu Organisation
verschieden. Somit können auch Daten, die im Tailoring-Assistent gespeichert
sind und speziell an eine Organisation angepasst wurden, nicht einfach ohne
erneute Anpassungen für ein anderes Unternehmen übernommen werden.
Beispielsweise wird bei einer großen Software-Firma ein „großes Team“ anders
charakterisiert sein als bei einem kleineren Unternehmen.
Die Erstellung einer „experience base“ ist somit ein aufwendiger Prozess und
benötigt kontinuierlich neue Erfahrungen.
Seite 67
6 Realisierung
In diesem Kapitel wird näher auf die Realisierung des Assistenten für das Tailoring
von Quality Gates eingegangen. Zunächst wird beschrieben, welche Software zum
Einsatz kommt. Der Aufbau und das Vorgehen des Assistenten mit den
verwendeten Konzepten aus der Fuzzy-Logik werden anschließend kurz erläutert.
Ein Datenbankschema soll zusätzlich unterstützend den Aufbau des Programms
demonstrieren. Am Ende dieses Kapitels wird der entstandene Assistent mit Hilfe
von Screenshots dargestellt.
6.1 Eingesetzte Software
Der innerhalb dieser Arbeit entstandene Tailoring-Assistent ist als Java-SwingAnwendung realisiert. Dabei wurde für die Implementierung Java in der Version 5
verwendet [21].
Als Java-Enticklungsumgebung wird „eclipse“ [10] eingesetzt. Eclipse ist ein
Open-Source-Projekt und eine der weit verbreitetsten Entwicklungsumgebungen
für Java. Durch die offene plugin-basierte Struktur kann es aber auch für andere
Programmiersprachen und unterschiedlichen Entwicklungsaufgaben eingesetzt
werden.
Zur Speicherung der Datenbestände wird eine Apache Derby Datenbank in der
Version 10.2.2.0 verwendet [1]. Apache Derby ist eine frei verfügbare und leicht
gewichtige relationale Datenbank. Sie ist komplett in Java implementiert und
standardmäßig als Java DB in der neuen Java 6 Plattform enthalten. Daher ist es
ein großer Vorteil, dass Derby direkt in die Java-Applikation eingebettet werden
kann. Derby zielt besonders auf Anwendungen ab, die kein großes EnterpriseDatenbank-System benötigen, wie z.B. kleinere Stand-alone-Lösungen oder kleine
Webseiten. Ein weiterer großer Vorteil von Derby ist der geringe Speicherbedarf
von ca. 3 MB.
6.2 Aufbau und Vorgehen beim QGT-Assistenten
Ein Ziel dieser Arbeit ist es, ein Tool zu erstellen, das
die in den vorigen Kapiteln vorgestellten Konzepte
realisiert. Der Quality-Gate-Tailoring-Assistent (QGTAssistent) setzt dabei das in Kapitel 5 vorgestellte
Tailoringkonzept um.
Um das Tailoring eines Quality Gates mit dem
Assistenten durchführen zu können, muss der User drei Schritte durchführen:
1. Projektprofil festlegen
2. Tailoring-Konfiguration anpassen
3. Gesamtergebnis anzeigen lassen
Im ersten Schritt gibt der Benutzer über eine Eingabemaske die Eigenschaften
des anzupassenden Projekts an.
Seite 68
Aufbauend auf dem angegebenen Projektprofil kann anschließend das Tailoring
mit Hilfe eines Fuzzy-Controllers (s. Abbildung 32) durchgeführt werden. Die
angegebenen Daten bilden dabei die scharfen Eingangswerte für die
Fuzzifizierung. Bei der nachfolgenden Fuzzy-Inferenz wird die MamdaniImplikation verwendet (s. Kapitel 5.1.6). Der nach der Defuzzifizierung ermittelte
Ausgangswert wird vom Algorithmus mit Hilfe eines Filters bewertet. Diese
Bewertung wird dem Benutzer im 2. Schritt in Form eines Baumes, nach TailoringBausteinen kategorisiert, angezeigt. Jedes Kriterium besitzt dann eines der drei
Zustände „enthalten“, „nicht enthalten“ und „unbewertet“, die zeigen, ob ein
Kriterium im entsprechenden Baustein verwendet werden soll oder nicht.
Unbewertete Kriterien müssen vom Benutzer nachträglich bewertet werden. Bei
der Defuzzifizierung wurde die „Center-of-Maximum“-Methode angewandt.
Im dritten und letzten Schritt bekommt der Benutzer das Gesamtergebnis des
Tailorings in einer Übersicht angezeigt.
6.3 Datenbankschema
Wie bereits erwähnt, wird zur Datenhaltung die Datenbank Derby von Apache
verwendet. Für die Speicherung der Daten werden die in dem Datenbankschema
aus Abbildung 57 dargestellten Tabellen benötigt.
rule
attribute
att_function
id
name
scale_from
scale_till
step
unit
category
id
id_att
id_function
name
id
id_att_function
id_crit_function
functions
category
crit_function
id
name
id
id_att
id_crit
id_function
name
criteria
id
description
tailoring_category
id
left_
middleleft
middleright
right_
height
filter
filter_description
tailoring_category
id
description
id
name
id
tailoring_category
p_from
p_till
id_filter_description
Abbildung 57: Datenbankschema
Im Folgenden sollen nun die benötigten Tabellen und deren Funktionen
tabellarisch erläutert werden:
Seite 69
Tabelle
attribute
category
criteria
tailoring_category
att_function
crit_function
functions
rule
filter
filter_description
Funktion
Speichert die einzelnen Projektmerkmale, wie z.B.
“Projektgröße” und “Teamgröße”, anhand deren das
Projektprofil spezifiziert wird
Beinhaltet die Kategorien für die Projektmerkmale.
Beispiele
für
Kategorien
sind
„Allgemeine
Projektangaben“ und „Technologie“. Die einzelnen
Merkmale aus der Tabelle attribute werden einer
Kategorie zugeordnet.
speichert einzelne Kriterienbeschreibungen
Speichert die Beschreibungen der Tailoring-Bausteine,
die als Kategorie für die Kriterien eingesetzt werden.
Die einzelnen Kriterien aus criteria werden jeweils
einer Tailoring-Kategorie zugeordnet.
In dieser Tabelle wird jedem Merkmal eine
Zugehörigkeitsfunktion zugeordnet, die aus mehreren
Funktionen (functions) bestehen kann.
Diese Tabelle verbindet jedes Kriterium und Merkmal
mit einer Output-Funktion. Diese Funktion bildet die
eigentliche Bewertung des Kriteriums für ein
bestimmtes Merkmal.
Beinhaltet die Speicherung der mathematischen
Funktionen durch Angabe von vier x-Werten. Mit Hilfe
dieser vier Punkte können alle möglichen Trapezformen
dargestellt werden.
Speichert die Fuzzy-Regeln, die Zugehörigkeitsfunktionen mit Output-Funktionen verknüpfen.
Enthält den für jede Tailoring-Kategorie speziell
festgelegten Filter mit der Angabe, in welchen
prozentualen Intervallen welcher Filter verwendet wird.
Gibt die Farbbeschreibung möglicher Filter an. Als
Standard sind fünf Filterbeschreibungen angegeben:
„rot“, „orange“, „gelb“, „hellgrün“, „grün“
Tabelle 8: Datenbank-Tabellenübersicht
6.4 Beschreibung des Assistenten
An dieser Stelle soll nun auf das Programm und dessen Bedienung für den
Benutzer eingegangen werden. Dabei werden die einzelnen Funktionalitäten des
Quality-Gate-Tailoring-Assistenten anhand von Screenshots beschrieben. Dazu
wird auf die drei Schritte des Tailoring-Vorgangs aus Kapitel 6.2 Bezug
genommen (Projektprofil festlegen, Tailoring-Konfiguration anpassen, Gesamtergebnis anzeigen lassen).
In der Abbildung 58 kann man den Aufbau des Tailoring-Assistenten nach dem
Start erkennen. Auf der linken Seite befindet sich die Navigation mit den Buttons,
mit dessen Hilfe der Benutzer zwischen den einzelnen Schritten des TaloringVorgangs wechseln kann. Auf der rechten Seite ändert sich je nach gewähltem
Schritt der Inhalt des Fensters.
Seite 70
Abbildung 58: Startbildschirm mit Eingabe des Projektprofils
Die Abbildung zeigt weiterhin, dass die Navigation aus den vier Buttons
Projektprofil ( ), Tailoring ( ), Ergebnis ( ) und Editieren ( ) besteht. Die
ersten drei stellen die zuvor beschriebenen Schritte des Tailoring-Vorgangs dar,
wobei zu Anfang Schritt 2 und 3 deaktiviert sind. Der vierte Button ist zum
Editieren der Bewertungen in der Datenbank, auf dessen Grundlage das Tailoring
basiert, gedacht.
Im Folgenden sollen nun die einzelnen Schritte und die Benutzerinteraktionen im
Assistenten nacheinander vorgestellt werden.
6.4.1 Projektprofil angeben
Nach dem Start des Assistenten befindet sich der Benutzer gleich im 1. Schritt des
Tailoring-Vorgangs – dem Projektprofil (Abbildung 58). Der rechte Teil des
Fensters gliedert sich in zwei Bereiche: dem Info-Bereich ( ) und der Eingabemaske ( ).
Der Info-Bereich stellt Informationen als Hilfe für den Benutzer bereit, damit er
weiß, in welchem Schritt des Tailorings er sich befindet und welche Aufgaben ihn
erwarten.
Die Eingabemaske besteht aus einer Menge an Tabs (bzw. Reitern), die die
einzelnen Projektmerkmale nach einzelnen Kategorien anordnet. Beispielsweise
befinden sich unter den „Allgemeinen Projektangaben“ die Merkmale
„Projektgröße“ und „Teamgröße“ mit deren jeweiligen Maßeinheiten. Der User
bzw. Prozess-Tailorer hat nun in diesem ersten Schritt die Aufgabe, das Projekt,
für das er ein Tailoring durchführen möchte, anhand der vorgegebenen Merkmale
zu bewerten. Dazu gibt er die jeweiligen Eigenschaften des Projekts, z.B. mit Hilfe
eines Sliders, an.
Seite 71
Um Merkmale aus der Tailoring-Berechnung auszuschließen, können diese mit
Hilfe der Checkboxen ( ) aktiviert bzw. deaktiviert werden.
Wenn der User alle nötigen Informationen zum Projekt angegeben hat, kann er in
den zweiten Schritt – das „Tailoring“ – übergehen. Voraussetzung ist jedoch, dass
mindestens ein Merkmal bewertet wurde (Checkbox aktiviert), damit der TailoringButton ( ) aktiviert wird, da ohne Projektangaben kein Tailoring durchgeführt
werden kann. Es müssen jedoch nicht alle Merkmale bewertet werden.
6.4.2 Tailoring-Konfiguration anpassen
Nachdem das Projektprofil erstellt wurde, gelangt der User über den „Tailoring“Button in den 2. Schritt des Tailoring-Vorgangs. Mit Hilfe der im Profil
angegebenen Daten und der in der Datenbank gespeicherten Bewertungen hat
der Assistent eine Liste mit bewerteten Kriterien gegliedert nach TailoringBausteinen erstellt, die in einem Baum dargestellt werden (s. Abbildung 59).
Abbildung 59: Übersicht der Tailoring-Konfiguration
Die einzelnen Tailoring-Bausteine, wie die Checkliste, das Gate Netzwerk usw.,
sind wiederum in Tabs eingeteilt. Jeder dieser Tabs beinhaltet Kriterien für die
jeweilige Kategorie. Vor dem Namen eines Kriteriums befindet sich die Bewertung
auf Grundlage der in Kapitel 5 vorgestellten Fuzzy-Logik. Der scharfe
Ausgangswert der Fuzzy-Logik wird in einem Kasten prozentual dargestellt. Dieser
Wert sagt aus, zu welchem Prozentsatz das Kriterium beim gegebenen
Projektprofil sinnvoll ist. Durch einen Doppelklick auf ein Kriterium werden durch
Aufklappen des Baumes die Unterbewertungen für die einzelnen Merkmale
angezeigt. Dieses Feature gibt dem Benutzer die Übersicht, wie die
Gesamtbewertung zustande gekommen ist und welche Merkmale speziell dafür
verantwortlich sind.
Seite 72
Die Farbe des Kastens vor einem Kriterium repräsentiert den gewählten Filter (s.
Kap. 5.2.3) und kann die Farben rot, orange, gelb, hellgrün und grün annehmen.
Vor dem Filter werden drei mögliche Vorselektionen mit Hilfe der Icons ? ,
und
dargestellt. Die Vorselektion
ist gewählt, wenn das Kriterium im grünen
Filterbereich liegt und somit vom Tailoring-Algorithmus als „sehr sinnvoll“
eingestuft wird. Als „nicht sinnvoll“ werden alle Kriterien mit Hilfe der Vorselektion
markiert, die im roten Filterbereich liegen. Bei prozentualen Werten um die
50% (orange, gelb, hellgrün), bei denen der Tailoring-Algorithmus nicht genau
bewerten kann, ob das Kriterium in speziellen Fällen vielleicht doch sinnvoll sein
könnte, wird das Kriterium mit Hilfe des Symbols ? markiert. Nun hat der Benutzer
die Aufgabe, alle Kriterien, die mit einem ? markiert sind, selbstständig zu
bewerten. Als Unterstützung dient die prozentuale Angabe aus dem Fuzzy-LogikAlgorithmus. Der Benutzer kann mit einem Rechtsklick auf das jeweilige Kriterium
mit Hilfe eines Kontext-Menüs auswählen, ob das Kriterium aktiviert ( ) oder
deaktiviert ( ) werden soll.
Aber nicht nur unsichere Kriterien können nachträglich vom Benutzer gesondert
bewertet werden. Auch die vom Algorithmus schon vorselektierten Kriterien
können im nachhinein auf die beschriebene Weise bewertet werden, da in
manchen Situationen z.B. als nicht sinnvoll markierte Kriterien für den Tailorer für
sinnvoll gehalten werden können. Beispielsweise könnte ein für den Tailorer
unwichtigeres Merkmal für die schlechte Gesamtbewertung des Kriteriums
verantwortlich sein.
Auf diese Weise kann der User interaktiv die vom Algorithmus vorgegebene
Tailoring-Konfiguration nach seinen Wünschen nachträglich anpassen. Um sich
das Gesamtergebnis des Tailorings anzeigen lassen zu können, müssen jedoch
alle mit ? bewerteten Kriterien vom Tailorer bewertet werden.
6.4.3 Tailoring-Gesamtergebnis anzeigen
Abbildung 60: Anzeige des Tailoring-Gesamtergebnis
Seite 73
Die Abbildung 60 zeigt den dritten Schritt des Tailoring-Vorgangs. In diesem
letzten Schritt werden alle zuvor gewählten Kriterien noch einmal nach der
jeweiligen Tailoring-Kategorie (Baustein) aufgelistet. Die Liste stellt das
Gesamtergebnis des Tailorings auf Grundlage der im Projektprofil angegebenen
Informationen dar. Das Ergebnis selbst beinhaltet diejenigen Kriterien, die für das
Quality Gate benötigt werden.
6.4.4 Bearbeitung der Bewertungen aus der Datenbank
Der Tailoring-Algorithmus verwendet den in Kapitel 5 beschriebenen Fuzzy-LogikAnsatz. Wie man dort anhand eines Beispiels erkennen konnte, benötigt man für
jedes Kriterium und Merkmal eine Bewertung in Form einer Funktion. Diese
Bewertungen sind in einer Datenbank gespeichert. Da im Laufe der Zeit durch
kontinuierliche Qualitätsverbesserung (s. QIP) neue Erfahrungen in den TailoringVorgang einfließen, müssen Bewertungen angepasst, neu eingefügt oder gelöscht
werden können. Der Assistent soll dabei möglichst dynamisch anpassbar sein, so
dass auch eine Anpassung des Projektprofils nach den Wünschen des
Prozesstailorers ermöglicht werden soll.
Diese Möglichkeiten sind unter dem Menüpunkt „Editieren“ realisiert. Dort können
dann mit Hilfe des „bearbeiten“-Buttons zunächst Kriterien, Kategorien und
Merkmale bearbeitet oder erstellt werden. Abbildung 61 zeigt diese
Bearbeitungsmöglichkeiten.
Abbildung 61: Bearbeiten von Kategorien, Merkmalen und Kriterien
Möglichkeiten der Bearbeitung:
Bearbeitung der (Ober-)Kategorien für die Merkmale
Bearbeitung von Merkmalen
Bearbeitung der Tailoring-Kategorie, die Kriterien enthalten
Bearbeitung der Kriterien
Kategorie bearbeiten/einfügen/löschen
Abbildung 62: Kategorie bearbeiten/einfügen/löschen
Seite 74
Abbildung 62 stellt das Dialogfenster für die Bearbeitung von Kategorien dar.
Dabei können die Beschreibungen von vorhandenen Kategorien, die für die
Einteilung der Projektmerkmale zuständig sind, angepasst oder neue Kategorien
erstellt werden. Weiterhin können Kategorien gelöscht werden. Dies ist jedoch nur
möglich, wenn keine Merkmale mehr für diese Kategorie vorhanden sind.
Merkmal bearbeiten/einfügen/löschen
Abbildung 63: Merkmale bearbeiten/einfügen/löschen
Bei der Bearbeitung eines Merkmals muss zunächst in einer Combobox gewählt
werden, in welcher Kategorie die Merkmale bearbeitet werden sollen (Abbildung
63). Je nach gewählter Kategorie werden die darin enthaltenen Projektmerkmale
angezeigt. Für jedes Merkmal müssen der Name, ein Skala-Intervall, die
Schrittgröße und eine Einheit festgelegt werden. Die Skala benötigt dazu
numerische Werte, die angeben, welche Angaben im Projektprofil festgelegt
werden können. Wird bei der rechten Grenze des Intervalls kein Wert gewählt, so
können beliebig hohe Werte angenommen werden. „Schritt“ gibt die Schrittweite
beim Slider an. Die Einheit beschreibt die Maßeinheit des Merkmals, auf die sich
die numerischen Werte beziehen. Es können, wie bei den Kategorien auch, neue
Merkmale hinzugefügt und vorhandene bearbeitet oder gelöscht werden.
Tailoring-Kategorie bearbeiten/einfügen/löschen
Abbildung 64: Tailoring-Kategorien bearbeiten/einfügen/löschen
Seite 75
Die Bearbeitung der Tailoring-Kategorie (Abbildung 64) funktioniert in gleicher
Weise, wie die Kategoriebearbeitung für die Merkmale. Einziger Unterschied ist
die Möglichkeit der Anzeige des zur Tailoring-Kategorie gehörigen Filters. Wird
eine neue Tailoring-Kategorie eingefügt, wird automatisch ein neuer StandardFilter (rot, gelb, grün) angelegt. Das Löschen einer Tailoring-Kategorie ist nur
möglich, wenn keine Kriterien in dieser Kategorie vorhanden sind.
Filter bearbeiten/einfügen/löschen
Abbildung 65: Filter bearbeiten/einfügen/löschen
In der Abbildung 65 sind die Einstellungsmöglichkeiten des Filters dargestellt. Dort
kann zunächst eine von maximal fünf Farben gewählt werden. Anschließend wird
mit Hilfe eines Intervalls angegeben, in welchem Prozentbereich dieser Filter
gelten soll. Dabei ist darauf zu achten, dass alle Prozentwerte von 0 bis 100%
abgebildet werden.
Kriterium bearbeiten/einfügen/löschen
Abbildung 66: Kriterien bearbeiten/einfügen/löschen
Beim Editieren von Kriterien (Abbildung 66) wird zunächst wieder die
entsprechende Tailoring-Kategorie gewählt. Innerhalb der gewählten Kategorie
können Kriterien bearbeitet und gelöscht oder neue Kriterien eingefügt werden.
Seite 76
Bearbeiten der Fuzzy-Funktionsgraphen
Abbildung 67: Anzeige und Bearbeitung der Fuzzy-Funktionen und Regeln
Seite 77
Nachdem nun Kategorien, Merkmale und Kriterien angelegt wurden, benötigt man
nun noch die für den Fuzzy-Algorithmus benötigten Fuzzy-Funktionen. Dazu wählt
man, wie in Abbildung 67 zu sehen ist, zunächst eine Kategorie und ein Merkmal
aus ( ). Anschließend werden dem Benutzer zum einen die gespeicherten Daten
der Funktion tabellarisch ( ) und zum anderen mit Hilfe eines Graphen visuell
angezeigt ( ). Jede Funktion besteht aus vier Punkten und einer Höhe. Mit Hilfe
der vier Punkte (nur x-Werte) können dann alle erforderlichen Trapez-Funktionen
für die Fuzzy-Funktionen erstellt werden. Bei Sonderfällen, wie z.B. der „Peak“Funktion (Dreiecksfunktion, siehe , blaue Funktion), besitzen Punkt 2 und 3 den
gleichen x-Wert. Durch Angabe dieser Punkte und einer maximalen Höhe von 1
kann der User die Zugehörigkeitsfunktionen für die Merkmale erstellen. Für die
Punkte 3 und 4 kann auch „Inf“ (Infinity = Unendlich) gewählt werden, damit auch
, rote
Funktionen bis ins Unendliche dargestellt werden können (siehe
Funktion). Zur besseren Übersicht entspricht die Farbe der Funktionen im
Graphen die der Textfarbe der Funktionen-ID (Fkt.-ID) in der Tabelle.
Bei der Erstellung einer neuen Funktion bekommt diese automatisch eine neue ID
zugewiesen, die später bei der Erstellung der Regeln benötigt wird.
Wurde bei den Comboboxen auch eine Tailoring-Kategorie und ein Kriterium
gewählt, so wird dafür die entsprechende Output-Funktion zum gewählten Attribut
angezeigt ( ).
Dort kann der User ebenfalls die Output-Funktionen je nach Bewertung des
Kriteriums anpassen. Im Unterschied zu den Zugehörigkeitsfunktionen sind die
wählbaren x-Werte auf den prozentualen Bereich 0 bis 100 beschränkt. Deshalb
sind offene Funktionen mit x-Werten bis Unendlich nicht möglich.
Im letzten Schritt muss der Benutzer noch die Fuzzy-Regeln erstellen ( ), indem
er die einzelnen Trapez-Funktionen aus den beiden Graphen miteinander
verknüpft. Die Verknüpfung wird mit Hilfe der Funktionen-IDs (Fkt.-ID) der beiden
Funktionen vorgenommen, die man in der tabellarischen Darstellung ablesen kann
und in den Comboboxen für die Regeln vorgegeben sind.
Der QGT-Assistent geht bei der Bewertung von einem minimalistischen Ansatz
aus, d.h. gibt es für die Kriterien keine Bewertungsfunktionen, so werden sie auch
nicht im Ergebnis berücksichtigt.
Bei der Bearbeitung der Funktionen für die Merkmale muss beachtet werden, dass
die Änderungen für alle Kriterien gelten, da die Merkmalsfunktionen immer gleich
bleiben. Für die Kriterien jedoch muss jeweils für jedes Merkmal eine neue
Funktion erstellt werden.
Weiterhin ist zu beachten, dass beim Editieren von Datenbankeinträgen der zuvor
angegebene Tailoring-Vorgang verloren geht, da die Änderungen in der
Datenbank auch Änderungen im Tailoring-Algorithmus hervorrufen.
Seite 78
7 Zusammenfassung & Ausblick
In diesem abschließenden Abschnitt werden zunächst Schwierigkeiten, die bei der
Erstellung der Arbeit aufgetreten sind, aufgezeigt. Weiterhin werden Möglichkeiten
zur Erweiterung des Tailoring-Ansatzes und des QGT-Assistenten beschrieben.
Anschließend schließt die Arbeit mit einer Bewertung und einem Fazit ab.
7.1 Schwierigkeiten
Während der Bearbeitung der Masterarbeit sind stellenweise Probleme und
Schwierigkeiten aufgekommen, die es zu bewältigen galt.
Eine Schwierigkeit lag in der Erstellung des konzeptionellen Metamodells. Die
Problematik schlug sich besonders darin nieder, die verschiedenen Quality-GateKonzepte zu vereinen. Schon kleine Änderungen im Modell zogen automatisch
Änderungen an anderen Stellen nach sich. Die Modellierung eines Metamodells
kann somit zu verschiedenen Ergebnissen führen. Außerdem ist ein solches
Metamodell nie wirklich „fertig“ oder „perfekt“. Viele Stellen sind deshalb auch jetzt
noch diskussionswürdig und können verschiedene Betrachtungsweisen nach sich
ziehen.
Problematisch war auch die Übertragung des Fuzzy-Logik-Ansatzes auf das
Tailoring von Quality Gates. Die Fuzzy-Logik selbst wird, wie beschrieben, im
Normalfall in der Steuerungs- und Regelungstechnik verwendet. Daher galt es zu
analysieren, wie die Fuzzy-Logik angewendet wird und wie daraus ein TailoringAlgorithmus erstellt werden kann. Das führte zwischenzeitlich zu falschen
Ansätzen und einer daraus resultierenden Kompletterneuerung des Algorithmus.
7.2 Ausblick & Erweiterungsmöglichkeiten
Das in dieser Arbeit verwendete Tailoringkonzept, das die Fuzzy-Logik als
Grundlage verwendet, kann auf unterschiedliche Weise erweitert und verbessert
werden. In diesem Abschnitt sollen nun einige dieser Möglichkeiten, sowohl für
den Tailoring-Algorithmus als auch für den QGT-Assistenten, dargestellt werden.
Beim Algorithmus musste entschieden werden, welche der verwendeten Konzepte
sich am besten für die vorliegende Situation eignen. Wie man im Kapitel 5.1, das
die Grundlagen der Fuzzy-Logik vorstellt, sehen kann, bietet die Fuzzy-Logik auch
noch andere Möglichkeiten. Eine Entscheidung war die Verwendung der
Mamdani-Implikation bei der Durchführung des zweiten Schrittes – der FuzzyInferenz. Eine Erweiterungsmöglichkeit wäre die Verwendung der Larsen’s
Implikation. Anschließend könnte betrachtet werden, wie sich die Änderungen im
Ergebnis des Tailorings auswirken.
Bei der Defuzzifizierung ist die Entscheidung für die Center-of-Maximum-Methode
gefallen, da sie intuitiv die besten Ergebnisse liefert und der Berechnungsaufwand
relativ gering ist. Doch erst in der Praxis wird sich zeigen, ob die Ergebnisse auch
bei größeren Bewertungsmengen den Erwartungen entsprechen. Alternativ könnte
man zum Vergleich eine andere Defuzzifizierungs-Methode wählen, wobei die
Seite 79
Schwerpunktmethode andere und eventuell bessere Ergebnisse liefern könnte, mit
dem Nachteil der komplexen und aufwendigeren Berechnung.
Die entscheidende Bewertungsgrundlage des Tailoring-Algorithmus sind die
Fuzzy-Funktionen. In dieser Arbeit wurden, der Einfachheit halber, lediglich
trapezförmige Funktionen oder Spezialisierungen davon zugelassen. Als
Erweiterungsoption sind jedoch auch viele andere Darstellungsformen der FuzzyFunktionen vorstellbar, wie Parabel-, Wurzel- oder auch Logarithmusfunktionen.
Dabei wäre zu untersuchen, in welchen Fällen die Wahl dieser Funktionen sinnvoll
ist.
Eine weitere Verbesserungsmöglichkeit, bezogen auf den Tailoring-Algorithmus,
ist die Verwendung von Gewichtungen bei den Projektmerkmalen. Mit Hilfe der
Gewichtung könnte der Prozesstailorer festlegen, wie wichtig ihm ein bestimmtes
Projektmerkmal bei der Bewertung ist. Beispielsweise könnte so die Projektgröße
als wichtiger eingestuft werden als die Teamgröße.
Auch die Erstellung und Verwendung von Fuzzy-Regeln kann ausgebaut werden.
Dazu könnte man mehrere Regeln miteinander verbinden. Jedoch steigert das
Verbinden mehrerer Regeln die Komplexität und muss daher auch als kritisch
angesehen werden.
Erweiterungen und Verbesserungen sind jedoch nicht nur beim Algorithmus
möglich, sondern auch beim QGT-Assistenten. Der Assistent, der innerhalb dieser
Arbeit entstanden ist, ist eine erste Version, der die Vorgehensweise des
beschriebenen Fuzzy-Logik-Ansatzes demonstrieren soll. Eine Möglichkeit der
Erweiterung ist das Speichern und Öffnen von Tailoringkonfigurationen. Dadurch
gehen durchgeführte Tailoring-Vorgänge nicht mehr verloren und könnten später
noch eingesehen oder modifiziert werden.
Wünschenswert ist weiterhin die Implementation einer Export-Funktion, um
gewonnene Ergebnisse z.B. in einem XML-Format speichern und weiterverwenden zu können.
7.3 Bewertung und Fazit
In diesem Abschnitt soll geklärt werden, wie der Einsatz von Fuzzy-Logik für das
Tailoring von Quality Gates zu bewerten ist.
Die Erstellung der Zugehörigkeits- und Output-Funktionen ist die größte
Herausforderung beim Tailoring. Dabei stellt sich die Frage, wie der Aufwand im
Verhältnis zum Gewinn steht. Schon bei einer kleinen Anzahl an Kriterien und
Projektmerkmalen benötigt man sehr viele Bewertungen in Form von
mathematischen Funktionen. Bei der Erstellung dieser Funktionen sind viele Dinge
zu beachten, damit am Ende auch das erwartete Ergebnis resultiert. Der
Prozessmodellierer bzw. das Gate Management benötigt dafür einen großen
Erfahrungsschatz, der die Durchführung von vielen Quality-Gate-Projekten
benötigt. Man muss sich bewusst sein, dass kleine Änderungen an den
Funktionen schon zu großen Änderungen im Gesamtergebnis führen können. Der
Aufwand, speziell am Anfang, ist also als extrem hoch einzustufen.
Seite 80
Wie kann jedoch der Gewinn beurteilt werden? Das kann sicherlich erst die Praxis
zeigen, indem der QGT-Assistent kontinuierlich durch Erfahrungskreisläufe mit
neuen Daten versorgt wird. Dies ist jedoch ein langwieriger Prozess. Aus diesen
Gründen wird der Einsatz in kleineren Unternehmen mit wenigen Projekten nur
wenig Sinn machen. Erst wenn die Erfahrungen aus vielen Projekten in den
Prozess einfließen, ist es denkbar, dass am Ende eine Datenbasis entsteht, aus
der sinnvolle Ergebnisse gewonnen werden können.
Seite 81
8 Anhang
8.1 Verwendete Kriterien und Projektmerkmale im QGTAssistenten
Die folgende Liste enthält Projektmerkmale, die aus dem Softwareprojekt des
Fachgebiets Software-Engineering der Universität Hannover stammen und im
QGT-Assistenten als Beispieldaten übernommen wurden.
Allgemeine Projektangaben
• Projektgröße
•
Teamgröße
Technologie
• J2EE
•
PHP
•
C++
•
C#
•
.Net
•
Delphi
•
Java
Software-Architektur
• Client-Server
•
Peer-To-Peer
•
Distributed Computing
•
Eventbasierte Systeme
•
Blackboard
•
Monolithische Systeme
•
Web Service Architecture
•
N-Schichten-Architektur
•
Dreischichtenarchitektur
•
Service Oriented Architecture (SOA)
•
Model Driven Architecture
•
Embedded
Seite 82
Softwareentwicklungsprozess
• Extreme Programming (XP)
•
Rational Unified Process (RUP)
•
SCRUM
•
Wasserfall-Modell
•
V-Modell
•
V-Modell XT
•
Spiral-Modell (Boehm)
•
Prototyping
•
Aspect-Oriented Software Development (AOSD)
Domäne
• Versicherungen/Banken
•
Medizinische Anwendungen
•
Betriebssoftware
•
Standardsoftware
•
Eingebettete Software
•
Verwaltungssoftware
•
Infrastruktur
•
Modellierungswerkzeug
Die folgenden Kriterien stammen ebenfalls zum größten Teil aus dem
Softwareprojekt, aber auch teilweise aus dem Konzept des V-Modell XT.
Checkliste
• Die Dokumente sind durchgehend in deutscher oder englischer Sprache
verfasst und entsprechen den Regeln dieser Sprache
•
Die Dokumente liegen elektronisch im MS Word oder MS Powerpoint Format
vor
•
Das Layout der Dokumente ist konsistent
•
Alle Dokumente besitzen eine Versionsnummer und ein Erstellungsdatum
•
Die Gruppenbezeichnung ist vorhanden
•
Zu unterschreibene Dokumente sind mit den nötigen Unterschriften, Zeit- und
Orstangaben versehen und liegen vor (Bitte auf Papier mitbringen und bei
diesem Quality Gate vorlegen).
•
Die Vorgaben für Dateinamen wurden eingehalten (Vorgabe: SWP-WS0607[Gruppenname]-[Dokumentenname]-[Versionsnummer].[Dateiextension])
•
Die Anforderungsspezifikation verwendet das verteilte Template
•
Priorisierte Anforderungen des Kunden werden genannt
Seite 83
•
Die Aufgabe ist beschrieben
•
Es sind Angaben zur Anforderungsanalyse (Herkunft, wahrgenommene
Kundentermine, etc.) vorhanden
•
Es sind Angaben zu Rahmenbedingungen und zum Umfeld vorhanden.
Insbesondere sind Anwender und die vorhandene Software, Hardware,
Orgware benannt. Schnittstellen zu anderen Systemen sind erwähnt
•
Use Cases sind vorhanden
•
Es sind Angaben zu den Qualitätsanforderungen vorhanden. Interne
Qualitätsstandards sind benannt. Die Qualitätsanforderungen des Kunden
sind benannt und priorisiert
•
Maßnahmen zum Erfüllen der Qualitätsanforderungen sind benannt (z.B.
Richtlinien für die Dokumentation, zur konsistenten Formatierung des
Quelltextes, Verwendung eines Versionskontrollsystems usw.)
•
Risiken und mögliche Probleme sind benannt
•
Ein Glossar ist vorhanden, welches wichtige Fachbegriffe und Abkürzungen
erklärt
•
Es wurden Abnahmetestfälle aufgestellt und dokumentiert, die das spätere
Produkt erfüllen muss
•
Die Anforderungsspezifikation wurde von der/dem SE-Berater(in) inhaltlich
geprüft.
•
Ein Use-Case-Diagramm mit korrekter UML-Syntax ist vorhanden.
•
Die Rollenverteilung ist schriftlich festgelegt. (enthält Angaben über interne
Rollenverteilung (Gruppenleiter, Stellvertreter, Dokumentator usw.) und den
Teamnamen)
•
Es ist ein Gruppenprofil vorhanden. Jedes Gruppenmitglied wird kurz mit
seinern Software-, Programmier- und Entwicklungskenntnissen vorgestellt
•
Die Entwurfsspezifikation verwendet das verteilte Template
•
Wichtige übergreifende Konzepte
beschrieben, erläutert und begründet
•
Wichtige Schnittstellen zur Außenwelt sind beschrieben. Jede Schnittstelle,
die auch noch andere (Projekte) betreffen könnte, ist exakt (z.B. formal)
beschrieben. Dies betrifft auch Protokolle und Austauschformate.
•
Grundkonzepte der Funktionsverteilung auf verschiedene Rechner oder
Systemteile sind beschrieben und begründet. Die Kommunikation zwischen
diesen Teilen ist beschrieben
•
Es gibt eine grafische Übersicht der verwendeten Packages/Module. Die
Packages/Module und ihre Schnittstellen untereinander sind beschrieben
•
Es ist eine grafische Übersicht wichtiger Klassen vorhanden. Funktionen und
Schnittstellen der Klassen sind beschrieben
•
Abläufe und der Austausch von Nachrichten werden durch Interaktionsdiagramme (z.B. Sequenz- oder Kollaborationsdiagramme) aufgezeigt
und
Entwurfsentscheidungen
sind
Seite 84
•
Alle Diagramme entsprechen dem UML-Standard, sofern sie in UML
modelliert werden können
•
Die (grobe) Softwarearchitektur wird durch eine Paketaufstellung o.ä.
spezifiziert
•
Ein Walkthrough oder Review wurde bestanden
•
Abschätzungen zum Speicherverbrauch während der Laufzeit sind vorhanden.
•
Die physische Verteilung der einzelnen Softwarekomponenten ist spezifiziert.
•
Die Hauptarten der Benutzeroberflächen sind entworfen (GUI-Design, ...)
•
Die Entwurfsentscheidungen betreffend des Erreichens
Anforderungen festgelegten Qualitätsziele sind erläutert.
•
Netzwerkprotokolle sind mit entsprechenden Abläufen und Nachrichtenformaten definiert
•
Abhängigkeiten
spezifiziert
•
Gemeinsam zu erarbeitende oder festzulegende Schnittstellen sind von allen
betreffenden Teams mit einer Unterschrift bestätigt worden
•
Wichtige Algorithmen und Patterns werden erklärt
•
Eine Zuordnung der Personen zu Aufgaben und Modulen/Packages/Klassen
ist vorhanden
•
Ein Integrationsplan für die Zusammenführung und den Test einzelner
Module/Packages/Klassen ist vorhanden
•
Die Quelltexte sind nach den selbst gesetzten Qualitätsstandards formatiert
•
Die Quelltexte sind ausreichend kommentiert
•
Eine Archiv-Datei mit den Quelltexten liegt vor
•
Alle Methoden haben einen McCabe-Wert von <= 10.
•
In der vom FG SE gestellten Versionsverwaltung existiert eine als Final
getaggte Version mit einer Versionsnummer >= 1.0.
•
Die Anwendung liegt als ausführbares Archiv vor.
•
Die Anwendung lässt sich ohne Probleme installieren und ausführen
•
Die Anwendung erfüllt alle in der Anforderungsspezifikation vereinbarten
Abnahmetestfälle
•
Es liegt eine Schnittstellenbeschreibung vor.
•
Die Schnittstellenbeschreibung umfasst alle Klassen und Funktionen, die von
außen (anderen System) verwendet werden können
•
Die Schnittstellenbeschreibung ist ausführlich genug
•
Die Bedienungsanleitung beschreibt alle Funktionen der Anwendung
•
Die Bedienungsanleitung ist adressatengerecht verfasst
zu
Softwarebibliotheken
sind
auf
mind.
der
in
den
Paketebene
Seite 85
•
Die Technische Beschreibung ist adressatengerecht verfasst und beschreibt
den Installationsvorgang
•
Die Akzeptanztestfälle laufen wie spezifiziert ab. Jeder Test ist mit einem
Namenskürzel versehen, das bestätigt, dass der Test erfolgreich lief.
•
Die Testfälle sind nach Heuristiken bzw. einer Systematik aufgestellt worden.
Diese Systematik ist zudem angegeben
•
Besondere Risiken des Einsatzes sind in die Testpläne aufgenommen und
entsprechende, auch längere Abläufe sind vor dem Quality Gate erfolgreich
erprobt worden
Projektvertreter
• Die Projektvertreter müssen fundiertes betriebswirtschaftliches Wissen
besitzen
•
Die Projektvertreter müssen fundiertes marktwirtschaftliches Wissen besitzen
•
Die Projektvertreter benötigen große Erfahrung in der Durchführung von
Projekten
•
Es werden bis zu 5 Projektvertreter benötigt
•
Es werden zwischen 6 und 10 Projektvertreter benötigt
•
Es werden mehr als 10 Projektvertreter benötigt
Gatekeeper
• Die Gatekeeper benötigen einen großen Erfahrungsschatz
•
Es werden bis zu 2 Gatekeeper benötigt
•
Es werden zwischen 3 und 6 Gatekeeper benötigt
•
Es werden mehr als 6 Gatekeeper benötigt
Gate Manager
• Der Gate Manager benötigt große Erfahrung bei der Leitung eines Projektes
•
Die Aufgabe des Gate Managers übernehmen mehrere Personen
Lieferant
• Die Lieferung der Dokumente kann online erfolgen
•
Die Lieferung der Dokumente muss persönlich erfolgen
Gate
• Fertig für Anforderungen
•
Fertig für Entwurf
•
Fertig für Implementierung
•
Fertig für Abnahme
Seite 86
Gate Netzwerk
• Vergabe und Durchführung eines Systementwicklungsprojektes (AG)
•
Vergabe und Durchführung mehrerer Systementwicklungsprojekte (AG)
•
Inkrementelle Systementwicklung (AN)
•
Komponentenbasierte Systementwicklung (AN)
•
Agile Systementwicklung (AN)
•
Wartung und Pflege von Systemen (AN)
•
Inkrementelle Systementwicklung (AG/AN)
•
Komponentenbasierte Systementwicklung (AG/AN)
•
Agile Systementwicklung (AG/AN)
•
Wartung und Pflege von Systemen (AG/AN)
•
Einführung und Pflege eines organisationsspezifischen Vorgehensmodells
Gate Review
• Es nehmen der Teamleiter und 2 Projektvertreter am Gate Review teil
•
Es nehmen der Teamleiter und 3 Projektvertreter am Gate Review teil
•
Ein einleitendes Kickoff wird durchgeführt
Entscheidung
• Die „go-Entscheidung“ kann getroffen werden
•
Die „kill-Entscheidung“ kann getroffen werden
•
Die "hold-Entscheidung" kann getroffen werden
•
Die "conditional-go-Entscheidung" kann getroffen werden
•
Die "repeat-Gate-Entscheidung" kann getroffen werden
Kriterium
• Es werden alle Dokumente überprüft
•
Es werden nur Teile der Dokumente überprüft
•
Es werden Aktivitäten und deren Ergebnisse überprüft
Kriteriendefinition
• Es werden Ergebnisse vereinbart
•
Der Weg wird dargelegt
Protokoll
• Es wird kein Protokoll benötigt
•
Das Protokoll beinhaltet die Entscheidung der Gatekeeper
Seite 87
•
Das Protokoll beinhaltet alle Aktivitäten und Ergebnisse aus dem Gate
Review
• Es findet eine individuelle Vorbereitung der Gatekeeper statt
•
Es wird ein Gate Review durchgeführt
•
Es werden Maßnahmen nach einer getroffenen Entscheidung über den
Verlauf des Projektes überwacht
Seite 88
8.2 Literaturverzeichnis
1
Apache Derby
http://db.apache.org/derby
2
Balzert, Helmut
Lehrbuch der Software-Technik
Spektrum Akademischer Verlag (2000)
3
Bank, Mathias
Fuzzy Logik
Proseminar Soft Computing, Univerität Ulm (2004)
4
Cooper, Robert G.
Winning at New Products – Accelerating the Process from Idea to Launch
Perseus Books Group, 3rd Edition (2001)
5
Cossentino, Massimo et al
A metamodelling-based approach for method fragment comparison
Eleventh International Workshop on “Exploring Modeling Methods in Systems
Analysis and Design” (EMMSAD, 2006)
6
DANTES
Sustainability aspects in a Stage-Gate model for product development
http://www.dantes.info/Strategies/R&D/ABBGatemodel/strategies_RandD_AB
BGate_background.html
7
de Vries, Lars
Erfahrungsbasierte (Software-) Prozessverbesserung
Seminar-Vortrag, Fachgebiet Software Engineering, Leibniz Universität
Hannover (WS 2005/2006)
8
Differding, Christiane / Rombach, Dieter
Kontinuierliche Software-Qualitätsverbesserung in der industriellen Praxis
AG Software Engineering, Universität Kaiserslautern (1996)
9
Dolog, Peter
Engineering Adaptive Web Applications
Dissertation, Leibniz Universität Hannover (2006)
10 Eclipse
http://www.eclipse.org/
11 Filß, Christian
Vergleichsmethoden für Vorgehensmodelle
Diplomarbeit, Technische Universität Dresden (2005)
12 Flohr, Thomas
NetQGate – Tool Support for Quality Gate Processes
FG Software Engineering, Leibniz Universität Hannover (2006)
Seite 89
13 Fraunhofer IESE Kompetenzzentrum
www.software-kompetenz.de
14 Geburzi, Alexander
Das Metamodell der UML und in FUJABA
Projekt-Vortrag, Universität Paderborn (2004)
15 Gepting, Alexander
Grundlagen von MOF
Seminarausarbeitung, Universität Paderborn (2004)
16 Greive, Jens
Entwurf und Implementierung eines Systems zur netzbasierten Durchführung
von Quality Gates
Bachelorarbeit, Leibniz Universität Hannover (2005)
17 Hampel, Prof. Dr.-Ing. habil. Rainer et al
Fuzzy Control (Lehrbrief)
Hochschule Zittau / Görlitz, TU Liberec (2002)
18 Hawlitzky, Nicolas
Integriertes Qualitätscontrolling von Unternehmensprozessen - Gestaltung
eines Quality Gate-Konzeptes
Verlag: TCW (2002)
19 Ittner, Jan
Appropriate Processes: Tailoring Agile Processes
Proceedings of the 3rd World Congress for Software Quality (2005), Vol. II,
S. 261-285
20 Ittner, Jan
Softwaregestütztes Anpassen von Prozessbeschreibungen
Dissertation, Universität Erlangen-Nürnberg (2005)
21 Java Sun
http://java.sun.com/
22 Kamiske, Gerd F. / Brauer, Jörg-Peter
Qualitätsmanagement von A bis Z - Erläuterungen moderner Begriffe des
Qualitätsmanagement
Carl Hanser Verlag, 5. Auflage (2005)
23 KBSt 4
V-Modell XT: Meta-Modell und Konsistenzbedingungen
Version 1.1 (2005)
24 KBSt4
V-Modell XT: Online Dokumentation
http://ftp.uni-kl.de/pub/v-modell-xt/Release-1.2/Dokumentation/html
4
Bundesverwaltung
Seite 90
25 KBSt 5
Das neue V-Modell XT
http://www.kbst.bund.de
26 Kestler, Hans A.
Fuzzy Logik
VL Soft Computing, Universität Ulm (2003)
27 Kinnula, Atte
Quality Improvement Paradigm–cycle
Oulu University Library, Software process engineering systems: models and
industry cases (2000), Chapter 3
http://herkules.oulu.fi/isbn9514265084/html/x287.html
28 Krapp, Fabian
Einführung in die Fuzzy Logik
Seminar-Vortrag, University of Applied Science (2006)
29 Kruchten, Philippe
Der Rational Unified Process – Eine Einführung
Addison-Wesley, 2. Auflage (1999)
30 Lübke, Daniel / Flohr, Thomas
Experiences from the Conduction of a simulated Software Project driven by
Quality Gates
FG Software Engineering, Leibniz Universität Hannover (2005)
31 Pfeifer, Tilo / Schmidt, Reinhard
Das Quality-Gate-Konzept – Entwicklungsprojekte softwareintensiver Systeme
verlässlich planen, synchronisieren und absichern
Industrie Management Nr. 5, 2003, 21-24, Fraunhofer-Institut
32 Scharer, Michael
Quality Gate-Ansatz mit integriertem Risikomanagement : Methodik und
Leitfaden zur zielorientierten Planung und Durchführung von
Produktentstehungsprozessen
Dissertation, Universität Karlsruhe (2001)
33 Scholz, Daniel
Entwurf und Implementation von NetQGate mit J2EE
Masterarbeit, Leibniz Universität Hannover (2006)
34 Schönberg, Arndt
Ein unscharfes Bewertungssystem für die Bedrohungs- und Risikoanalyse von
IT-Systemen
Diplomarbeit, Universität Oldenburg (1998)
5
Bundesverwaltung
Seite 91
35 Stetter, Dr.-Ing Rainer
Software im Maschinenbau – lästiges Anhängsel oder Chance zur
Marktführerschaft
Software Factory & ITQ GmbH
36 Stahl, Thomas / Völter, Marku
Modellgetriebene Softwareentwicklung
Dpunkt Verlag, 1. Auflage (2005)
37 Vorpahl, Ronny
Fuzzy Control – Unscharfe Regler und dessen Anwendungen
Seminar-Vortrag, TU Freiburg (2002)
38 Wallin, Christina et al
Combining Models for Business Decisions and Software Development
Proceedings of the 28 th Euromicro Conference, IEEE
39 Wallin, Christina et al
Integrating Business and Software Development Models
IEEE SOFTWARE November/December 2002, S. 28-33
40 Wikipedia Enzyklopädie
http://de.wikipedia.org
Hinweis:
Zum Abgabezeitpunkt dieser Masterarbeit waren
angegebenen Internet-Adressen aktuell und erreichbar.
alle
an
dieser
Stelle
Seite 92
8.3 Abbildungsverzeichnis
Abbildung 1: Modell für Rolle, Aktivität und Artefakt ............................................... 4
Abbildung 2: Quality-Gate-Prozess ........................................................................ 6
Abbildung 3: Quality-Gate-Referenzprozess [12] ................................................... 7
Abbildung 4: Ein konkreter Quality-Gate-Prozess [12] ........................................... 8
Abbildung 5: Zusammenhang der Gate-Komponenten ........................................ 10
Abbildung 6: Stage-Gate-Prozess von Cooper..................................................... 11
Abbildung 7: Von den Projektmerkmalen zur Projektdurchführungsstrategie....... 16
Abbildung 8: Entscheidungspunkte im V-Modell XT ............................................. 18
Abbildung 9: V-Modell XT Projektassistent - Projekttyp........................................ 18
Abbildung 10: V-Modell XT Projektassistent – Anwendungsprofil ........................ 19
Abbildung 11: V-Modell XT - Tailoring-Metamodell .............................................. 19
Abbildung 12: Synchronisation durch Quality Gate nach Pfeifer/Schmidt ............ 20
Abbildung 13: Quality-Gate-Plan nach Pfeifer/Schmidt ........................................ 21
Abbildung 14: 4-stufige Quality-Gate-Vorgehensweise von Pfeiffer/Schmidt ....... 21
Abbildung 15: Gates im ABB Gate Modell [6]....................................................... 22
Abbildung 16: 4-Schichten-Metamodellarchitektur nach Stahl/Völter [36] ............ 25
Abbildung 17: Beispiel für 4-Schichten-Architektur [14]........................................ 26
Abbildung 18: Das konzeptionelle Metamodell für Quality Gates ......................... 28
Abbildung 19: Metamodell Paket: „Struktur“ ......................................................... 29
Abbildung 20: Metamodell Paket: „Entscheidung” ................................................ 30
Abbildung 21: Metamodell Paket: „Steuerung“ ..................................................... 31
Abbildung 22: Metamodell Paket: „Inhalt“............................................................. 33
Abbildung 23: Metamodell Paket: „Anpassung“.................................................... 33
Abbildung 24: Paketabhängigkeiten zum Tailoring............................................... 34
Abbildung 25: Konzeptionelles Metamodell (Paketübersicht)............................... 35
Abbildung 26: Tailoring eines projektspezifischen Prozesses .............................. 38
Abbildung 27: Vergleich Bool'scher- und Fuzzy-Untermengen............................. 43
Abbildung 28: Zugehörigkeitsfunktion in der Bool'schen Logik............................. 43
Abbildung 29: Zugehörigkeitsfunktion in der Fuzzy Logik..................................... 44
Abbildung 30: Übliche Zugehörigkeitsfunktionen.................................................. 44
Abbildung 31: Fuzzy-Funktionen A und B ............................................................ 44
Abbildung 32: Aufbau eines Fuzzy-Controllers..................................................... 45
Abbildung 33: Fuzzifizierung der Eingangswerte.................................................. 46
Abbildung 34: Funktion der Output-Menge in der Fuzzy-Inferenz ........................ 47
Seite 93
Abbildung 35: Mamdani-Implikation...................................................................... 48
Abbildung 36: Konklusionsmenge zweier Regeln durch Mamdani-Implikation..... 48
Abbildung 37: Mamdani-Inferenz mit zwei Prämissen .......................................... 49
Abbildung 38: Larsen's Implikation ....................................................................... 49
Abbildung 39: Konklusionsmenge durch Larsen’s Implikation.............................. 50
Abbildung 40: Left-, Mean- und Right-of-Maximum-Methode ............................... 50
Abbildung 41: Schwerpunktmethode bzw. "Center of Gravity" (CoG) .................. 51
Abbildung 42: Center-of-Maximum-Methode (CoM) ............................................. 51
Abbildung 43: Zugehörigkeitsfunktion für die Teamgröße .................................... 54
Abbildung 44: Output-Funktion für Teamgröße und Kriterium .............................. 55
Abbildung 45: Bewertung des Kriteriums nach der Teamgröße ........................... 55
Abbildung 46: Zugehörigkeitsfunktion für die Projektgröße .................................. 56
Abbildung 47: Output-Funktion für Projektgröße und Kriterium ............................ 57
Abbildung 48: Bewertung des Kriteriums nach der Projektgröße ......................... 57
Abbildung 49: Gesamtbewertung des Kriteriums nach Team- & Projektgröße..... 58
Abbildung 50: Output-Funktion für das Tailoring beim Gatekeeper ...................... 59
Abbildung 51: Bewertung der Aussage nach der Projektgröße ............................ 59
Abbildung 52: Beispiel-Funktion für das 100%-Bewertungs-Problem................... 62
Abbildung 53: Lösungsfunktionen ........................................................................ 63
Abbildung 54: Beispiel für die Darstellung einer bool'schen Funktion .................. 63
Abbildung 55: Beispiel-Output-Funktion für Höhe-Problem .................................. 64
Abbildung 56: Quality-Improvement-Paradigm-Zyklus [7] .................................... 65
Abbildung 57: Datenbankschema......................................................................... 69
Abbildung 58: Startbildschirm mit Eingabe des Projektprofils............................... 71
Abbildung 59: Übersicht der Tailoring-Konfiguration ............................................ 72
Abbildung 60: Anzeige des Tailoring-Gesamtergebnis......................................... 73
Abbildung 61: Bearbeiten von Kategorien, Merkmalen und Kriterien ................... 74
Abbildung 62: Kategorie bearbeiten/einfügen/löschen ......................................... 74
Abbildung 63: Merkmale bearbeiten/einfügen/löschen ......................................... 75
Abbildung 64: Tailoring-Kategorien bearbeiten/einfügen/löschen ........................ 75
Abbildung 65: Filter bearbeiten/einfügen/löschen................................................. 76
Abbildung 66: Kriterien bearbeiten/einfügen/löschen ........................................... 76
Abbildung 67: Anzeige und Bearbeitung der Fuzzy-Funktionen und Regeln........ 77
Abbildung 68: Apache Derby in Eclipse................................................................ 97
Seite 94
8.4 Tabellenverzeichnis
Tabelle 1: Rollen und Aktivitäten beim Quality Gate............................................... 8
Tabelle 2: Beschreibung der Gates des ABB-Gate-Modells................................. 23
Tabelle 3: Proof-of-Concept am Beispiel des Stage-Gate-Prozesses .................. 37
Tabelle 4: Tailoringmöglichkeiten bei den einzelnen Bausteinen ......................... 41
Tabelle 5: Logische Operatoren auf unscharfen Mengen..................................... 45
Tabelle 6: Bewertung der Defuzzifizierungs-Methoden ........................................ 52
Tabelle 7: Beispiel für einen Filter ........................................................................ 60
Tabelle 8: Datenbank-Tabellenübersicht .............................................................. 70
8.5 Formelverzeichnis
Formel 1: Berechnungsformel des Center of Maximum ....................................... 52
Seite 95
8.6 Inhalt der CD-ROM
Die beiliegende CD-ROM beinhaltet:
Masterarbeit
Ausarbeitung dieser Masterarbeit als
Word- und PDF-Dokument
QGT-Assistent
QGT-Assistenten in verschiedenen Versionen
Quellcode aus Eclipse
Quellcode des Programms aus Eclipse
ohne Bewertungen
QGT-Assistent als JAR-Archiv ohne
Bewertungsfunktionen für die Kriterien
mit Best-Practise-Bewertungen
QGT-Assistent als JAR-Archiv mit BestPractise-Bewertungen für die Kriterien
(alle Bewertungen ergeben 100%
Übereinstimmung)
mit Beispiel-Bewertungen
QGT-Assistent mit zufälligen BeispielBewertungen für die Kriterien
Software
Software, die im Laufe der Arbeit
verwendet wurden
Apache Derby
Plugins zur Installation der Apache
Derby Datenbank
JGoodies Forms
Layout-Manager für Java-Swing-Anwendungen,
der
bei
der
Implementierung verwendet wurde und gut
zur Erstellung von Formularen geeignet
ist
(weitere
Informationen
unter
README.html)
8.6.1 Installation des QGT-Assistenten
Zur Installation des QGT-Assistenten muss lediglich der Inhalt eines der
Verzeichnisse aus \QGT-Assistent auf der beigelegten CD in ein beliebiges
Verzeichnis auf der Festplatte kopiert werden.
Ist eine aktuelle Java-Runtime-Environment-Version installiert, kann die Datei
„QGT-Assistent.jar“ per Doppelklick direkt als Programm im Windows Explorer
oder aber mit java –jar QGT-Assistent.jar aus der Kommandozeile gestartet
werden.
Seite 96
8.6.2 Installation von Apache Derby zur Nutzung in Eclipse
Die Datenbank „Apache Derby“ wird in dieser Arbeit in der Version 10.2.2.0
verwendet. Sie ist frei verfügbar und standardmäßig in der Java 6 Plattform
integriert. Derby wird von der Entwicklungsumgebung Eclipse unterstützt, aus der
SQL-Anfragen gestellt werden können. Dazu ist jedoch die Installation von Derby
in Eclipse (Version 3.1 oder höher vorausgesetzt) nötig, die mit Hilfe der folgenden
Schritte durchgeführt werden kann:
1. Entpacken des Archivs „derby_core_plugin_10.2.2.485682.zip“ von der
Masterarbeit-CD (\Software\Apache Derby) in das Eclipse-Verzeichnis
2. Entpacken des Archivs „derby_ui_plugin_1.1.0.zip“ von der MasterarbeitCD (\Software\Apache Derby) in das Eclipse-Verzeichnis
Nach dem Starten von Eclipse kann eine Derby-Datenbank durch Rechtsklick auf
ein entsprechendes Projekt und wählen von „Apache Derby“ Æ „Add Apache
Derby nature“ angebunden werden (siehe Abbildung 68).
Abbildung 68: Apache Derby in Eclipse
Im Hintergrund werden die Archive derby.jar, derbynet.jar, derbytools.jar,
derbyclient.jar zum Java Build Path des Projektes hinzugefügt. Nun kann man mit
Hilfe von „Apache Derby“ Æ „ij (Interactive SQL)“ in den Kommandozeilen-Modus
wechseln.
Folgender Befehl legt zunächst eine neue Datenbank mit dem Namen „myDB“
(Benutzer „me“, Passwort „mine“) an und stellt automatisch eine Verbindung her:
connect 'jdbc:derby:myDB;create=true;user=me;password=mine';
Dort können mit SQL-Befehlen neue Tabellen angelegt und gefüllt werden.
Folgende Anweisungen bilden ein Beispiel für den Verbindungsaufbau zur
Datenbank und dem Absetzen einer Abfrage aus Java:
String dbURL = "jdbc:derby:myDB;create=true;user=me;password=mine";
Class.forName("org.apache.derby.jdbc.ClientDriver").newInstance();
Connection conn = DriverManager.getConnection(dbURL);
Statement stmt = conn.createStatement();
stmt.execute("…"); // SQL-Abfrage
stmt.close();
Weitere Informationen zu Apache Derby unter: http://db.apache.org
Seite 97
8.7 Aufgabenstellung
Ein Anpassungskonzept für Quality Gates basierend auf
Bausteinen
Hintergrund
Quality Gates werden in Organisationen aus unterschiedlichsten Gründen eingesetzt.
Meistens steht jedoch die Prüfung der Prozesskonformität, Risikokontrolle,
Projektkontrolle,
Synchronisation
verschiedener
Teilprojekte
oder
die
Qualitätssicherung im Vordergrund. Quality Gates können nicht immer direkt - also
ohne Anpassung (Tailoring) - für ein Projekt verwendet werden. Darüber hinaus
müssen Quality Gates zunächst als Referenz in einer Organisation etabliert werden.
Wenn dabei ein Referenzprozess als Basis dient, wie z.B. der Stage-Gate-Prozess
von Cooper, so ist auch hier eine Anpassung notwendig.
Aufgabe
Im Rahmen dieser Arbeit soll ein Anpassungskonzept für Quality Gates basierend auf
Bausteinen entwickelt werden. Ziel ist es dabei, Quality Gates an ein konkretes
Projekt anzupassen.
Die Anpassung bezieht dabei im Wesentlichen vier Aspekte mit ein: die Quality Gates
(als Referenz in der Organisation), ein Projektprofil, Tailoringregeln und Erfahrungen.
Dabei ist von Interesse, wie Quality Gates zerlegt werden müssen, damit ein Tailoring
durchgeführt werden kann. In der Theorie, aber auch in der Praxis (zum Beispiel im VModell XT), wird diesbezüglich häufig das Bausteinprinzip genutzt. Dabei wird ein
Prozess in verschiedene unabhängige Komponenten zerlegt, die je nach Projektprofil
und Tailoringregeln in dem angepassten Prozess verwendet werden oder nicht. Dies
führt aber zu einigen Problemen: Was passiert, wenn Tailoringregeln sich
widersprechen oder Bausteine einander ausschließen? Ein geeigneter Algorithmus
zum Tailoring müsste damit umgehen können.
Tailoring kann bezogen auf Quality Gates horizontal oder vertikal stattfinden.
Horizontales Tailoring bezieht sich dabei auf Inhalt und Anzahl der Quality Gates
(vergleiche Cooper). Während vertikales Tailoring sich auf den genauen Ablauf der
einzelnen Quality Gates bezieht.
Hauptleistungen dieser Arbeit sind:
• Übertragung des Bausteinprinzips auf Quality Gates.
• Erarbeitung eines Projektmodells, welches für die Anpassung verwendet
werden kann.
• Entwurf und Implementierung (in Java) eines Anpassungsalgorithmus für
Quality Gates, der bestimmte Nebenbedingungen (z.B. maximale Anzahl
Quality Gates) betrachtet und Konflikte löst.
Im Rahmen der Arbeit ist eine schriftliche Ausarbeitung im Umfang von ca. 80 Seiten
zu erstellen.
Organisatorisches
Betreuer: Dipl.-Math. Thomas Flohr
Beginn: ab sofort
Voraussetzungen: Kenntnisse über Softwareentwicklungsprozesse
Seite 98
8.8 Erklärung
Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbstständig und
ohne fremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen
Quellen und Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher
Form noch keinem anderen Prüfungsamt vorgelegen.
Bünde, den …………………………..
……………………………….
(Christian Peucker)
Seite 99

Ein Anpassungskonzept basierend auf Bausteinen für Quality Gates

Transcrição

Documentos relacionados

Comdex – The Show must go on

PDF Datei - Kunsthaus Bregenz

10% Rabatt - Munich Airport

internet copy

Vorschau

Six in the cities die schönsten Mode

"Forbes"-Liste der Superreichen Das sind die reichsten Menschen

Pressemitteilung TRIUVA erwirbt Waverley Gate in Edinburgh

qualitätssicherung und softwaretest

Kurzer Artikel im 20 Minuten zur kick`n`rush-Bibel