Quantitative WinWin
Ziel:
Die Anforderungen an Software sind in frühen Phasen der Entwicklung oft unpräzise und unvollständig, nehmen jedoch mit fortschreitendem Entwicklungsprozess an Präzision und Umfang zu. Weiterhin haben die verschiedenen Stakeholder oft unterschiedliche und teilweise gegensätzliche oder widersprüchliche Erwartungen an die zu erstellende Software. Der mögliche Aufwand und der Zeitrahmen für das System sind zudem ebenfalls begrenzt. Das Ziel dieser Technik ist, Entscheidungen unter diesen Bedingungen durch den Einsatz quantitativer Methoden objektiver zu gestalten.
Beschreibung:
Quantitative WinWin unterstützt den Anforderungserhebungsprozess durch die systematische und iterative Definition, Priorisierung sowie Auswahl von Anforderungen. Der Einsatz von quantitativen Methoden bei der Erhebung und Verhandlung von Anforderungen fördert hierbei die Objektivität der getroffenen Entscheidungen. Dies schließt die Bewertung der Anforderungen hinsichtlich entstehendem Nutzen sowie dafür anfallenden Kosten mit ein.
Grundlegende Konzepte
Quantitative WinWin bietet unter den genannten Bedingungen eine fundierte Entscheidungsunterstützung. Die Unterstützung beruht dabei auf der Quantifizierung von verschiedenen Benutzererwartungen, deren Priorisierung sowie einer Beurteilung der erwarteten Kosten hinsichtlich des zur Verfügung stehenden Budgets und des Zeitrahmens. Eine Auswahl der am höchsten bewerteten Kriterien erfolgt am Ende der Methode.
Dies geschieht zunächst durch die Bildung eines mathematischen Modells der Anforderungen verknüpft mit den Stakeholdern. Diese werden anschließend durch die Anwendung des Analytical Hierarchical Process (AHP) bewertet und priorisiert. Im Anschluss erfolgt eine Simulation der entstehenden Kosten, welche die Basis für die endgültige Auswahl der spezifischen Anforderungen bildet.
Modellbildung
Die Methode setzt die Existenz einer Menge von formulierten Anforderungen voraus, die als R = {r 1, r 2 ,r 3, …, r n} bezeichnet werden. Diese Menge wird in q disjunkte Anforderungsklassen R 1, R 2, …, R q (q<n) zerlegt (somit gilt R = R 1 + R 2 + … + R q). Hierbei wird eine Zerlegung anhand von Dimensionen wie z.B. Anforderungen an User Interface oder nichtfunktionale Anforderungen vorgeschlagen.
Den Anforderungen einer jeden Klasse werden anschließend Gewichte zugeordnet, die die relative Wichtigkeit beschreiben. Die Gewichte α(r i) entstammen dabei dem Intervall (0,1]. Ein Gewicht von α(r i) = 1 bedeutet hierbei, dass die Anforderung verpflichtend ist. Ein Gewicht von α(r j) = 2α(r i) hingegen bedeutet, dass r j doppelt so wichtig wie r i ist.
Da die Anforderungen durch verschiedene Stakeholder unterschiedlich gewichtet werden, werden an dieser Stelle mehrere Klassen von Benutzern S 1, S 2, …, S p eingeführt, die später zur Bewertung der Anforderungsklassen dienen.
Problemformulierung
Die verfügbaren Ressourcen zur Verwirklichung der Anforderungen stellen die Obergrenze für den realisierbaren Aufwand dar. Diese Grenze wird als EFFORT bezeichnet. Für alle Untermengen R* aus R muss somit gelten: der vorhergesagte Aufwand ef( R* ) ist kleiner gleich EFFORT [ef( R* ) ≤ EFFORT].
Als Methoden zur Aufwandsabschätzung kommen z.B. Function Points oder System Dynamics verbunden mit Experteninterviews in Frage.
Zur Selektion einer hinsichtlich Business Value und Kosten optimalen Menge von Anforderungen wird nun die Gewichtung der Anforderungsklassen aus der Perspektive der Stakeholder vorgenommen. Der normalisierte Vektor β = {β(R 1), β(R 2), β(R 3), …, β(R q)} gibt hierbei die Gewichtung der einzelnen Klassen an. Die absolute Gewichtung χ(r i) einer einzelnen Anforderung wird nun durch das Produkt der Gewichtung der Anforderungsklasse β(R ψ(i)) und der relativen Gewichtung α(r i) der Anforderung r i gegeben [χ(r i) = β(R ψ(i)) * α(r i)].
Daraus ergibt sich insgesamt folgende Problembeschreibung:
Vorgehen
Im Folgenden werden die zur Lösung des oben genannten Problems notwendigen Schritte erläutert.
Schritt 1: Definition der Kandidatenmenge von AnforderungenAm Anfang einer Iteration i wird der Grenzbereich level i festgelegt, der über die Zugehörigkeit von Anforderungen r i zur Kandidatenmenge entscheidet [ R i = {r j ε R : χ(r j) ≥ level i}].
Schritt 2: Ermittlung der Gewichtung der einzelnen StakeholderZur Ermittlung der Präferenzen einzelner Stakeholder wird der Analytical Hierarchical Process verwendet. Der AHP ordnet die betrachteten Elemente zunächst hierarchisch an (1. Ebene: Business Value, 2. Ebene: Stakeholder, 3. Ebene: Anforderungsklassen, 4. Ebene: Anforderungen). Die Stakeholder werden nun paarweise verglichen und aus Sicht des Business Value bewertet (Skala von 1-9). Die Werte werden anschließend in Matrixform angeordnet und der Eigenvektor wird berechnet. Dieser stellt den normalisierten Vektor von Gewichten dar.
Schritt 3: Ermittlung der Gewichtung der Anforderungsklassen
Im Anschluss werden die Anforderungsklassen aus Sicht der einzelnen Stakeholder ebenfalls durch paarweisen Vergleich bewertet. Die Berechnung des Eigenvektors resultiert ebenfalls in einem Vektor von Gewichten.
Schritt 4: Ermittlung der generellen Gewichtung zwischen Anforderungsklassen
Die in Schritt drei ermittelten Vektoren werden in einer Matrix angeordnet und anschließend mit dem Vektor aus Schritt 2 multipliziert. Das Resultat ist ein Vektor von Gewichten β = (β(R 1), β(R 2), β(R 3), …, β(R q)), der die jeweilige "Wichtigkeit" der Anforderungsklassen widerspiegelt.
Schritt 5: Verfeinerung der Anforderungskandidaten
Die Kandidatenmenge aus Schritt 1 wird neu berechnet auf Basis von neuen definierten Anforderungen [ R = R + Δ R i, wobei Δ R i neue Anforderungen sind].
Schritt 6: Aufwandsabschätzung und Machbarkeitsstudie
Für jede Untermenge R i = {r j ε R : χ(r j) ≥ level i} mit χ(r j) = β(R ψ(j)) * α(r j) wird durch die Berechnung von ef( R i) eine Aufwandsabschätzung vorgenommen. Die Menge von Anforderungen ist implementierbar, falls ef( R i) ≤ EFFORT.
Tool für den Analytical Hierarchical Process (kommerziell):
Im Projekt GENSIM wird im Verbund von sechs Fraunhofer-Instituten (FIRST, IIS/EAS, ISE, IBP, IWU, IPK) ein generisches Simulationswerkzeug zur zeitkontinuierlichen und zeitdiskreten Analyse heterogener technischer Systeme entwickelt. Die zentrale simulationstechnische Innovation stellt hierbei die Abbildung von zustandsabhängigen Änderungen der Modellstruktur (Modellstrukturdynamik) dar. Hierdurch können z.B. Simulationsexperimente mit Modellen variabler Modellierungstiefe durchgeführt werden, die mit herkömmlichen auf dem Markt befindlichen Simulationswerkzeugen nur schwer zu realisieren sind.
Diese Technik erfüllt folgende Praktiken:
Scope festlegenStakeholder und Quellen identifizieren
Anforderungen messbar und testbar beschreiben
Kosten und Zeit schätzen
Rationale dokumentieren
Literaturverweis:
Quantitative WinWin - A new Method for Decision Support in Requirements
Negotiaton
The Analytic Hierarchy Process