Aufwandsschätzung mit Use Case Points. Manipulation durch Subjektivität

Inhaltsverzeichnis

Abkürzungsverzeichnis

Tabellenverzeichnis

Abbildungsverzeichnis

Formelverzeichnis

1 Einleitung
1.1 Aktualität des Themas
1.2 Problemstellung und Zielsetzung der Arbeit
1.3 Methodisches Vorgehen und Aufbau der Arbeit

2 Stand der Forschung
2.1 Definition Use Case
2.2 Herkunft der Use-Case-Point-Methode
2.3 Beschreibung der Anwendung

3 Untersuchung
3.1 Ausgangslage
3.1.1 Erstellung des Use Case
3.1.2 Berechnung des Bearbeitungsaufwands
3.2 Manipulation durch Umformulierung des Use Case
3.3 Manipulation durch subjektive Bewertung

4 Ergebnis

5 Diskussion
5.1 Schlussfolgerung
5.2 Ausblick
5.3 Reflexion

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Tabellenverzeichnis

Tabelle 1: Bewertungsskala für Szenarien/Schritte/Dialoge

Tabelle 2: M-Faktor Kriterien

Tabelle 3: T-Faktor Kriterien

Tabelle 4: Use Case "Ticket kaufen"

Tabelle 5: Szenario-Variante des Use Cases

Abbildungsverzeichnis

Abbildung 1: Elemente von UCP 3.0

Formelverzeichnis

Formel 1: M-Faktor Berechnung

Formel 2: T-Faktor Berechnung

Formel 3: Bearbeitungsaufwand Berechnung

1 Einleitung

1.1 Aktualität des Themas

Anwendungsprogramme werden immer komplexer, Softwareproduktion immer aufwändiger und die damit verbundenen Aufwandsschätzungen in Projekten immer schwieriger, unübersichtlicher und schlussendlich deutlich riskanter. Im Jahr 2009 wurden, laut der Chaos Studie der Standish Group, nur 32%^[1] der IT-Projekte erfolgreich, also ohne Zeitverzug und höhere Kosten, als anfangs geschätzt, abgeschlossen.

1.2 Problemstellung und Zielsetzung der Arbeit

Die Anfang der 1990er Jahre entwickelte Aufwandschätzmethode von Gustav KARNER^[2] basiert auf zu einem Softwareprojekt entwickelten Use Cases und errechnet auf diesen Angaben eine Bearbeitungsdauer. 2010 wurde diese Methode in der Dissertation von Stephan FROHNHOFF weiterentwickelt. FROHNHOFF modifizierte die Methode in Hinblick auf viele Kriterien um sie präziser und moderner zu gestalten. Die Modifizierungen fanden größtenteils in der Berechnung, den Formeln und den Gewichtungen statt. Das ehemalige Kostenfaktormodell, das in Kapitel 2.3 näher erläutert wird, wurde komplett überarbeitet. Ein Kritikpunkt, der in dieser Arbeit problematisiert wird, konnte nicht beseitigt werden:

Die Methode ist in Bezug auf ihre Formeln und Gewichtungen ausgezeichnet durchdefiniert. Dennoch wurde das größte Problem, dass Use Cases und ihre Transaktionen, je nach Ersteller individuell ausführlich, komplex und groß ausfallen, nicht gelöst. Es wird der These nachgegangen, dass man, sofern man diese Methode kennt, durch schriftliche Veränderungen der Use Case oder durch minimale Änderungen in subjektiven Bewertungen, das Endergebnis sehr leicht manipulieren kann.

1.3 Methodisches Vorgehen und Aufbau der Arbeit

Die Seminararbeit bezieht sich primär auf die Dissertation FROHNHOFFS, da diese den aktuellen Stand der Forschung widerspiegelt. Sie besteht neben den Verzeichnissen und der Einleitung aus vier großen Teilen. Zuerst wird auf den aktuellen Stand der Forschung eingegangen. Es wird die Entwicklung der Methode UCP 3.0 erläutert und die Methode selber wird erklärt. In Kapitel 3 wird die Problemstellung näher erörtert und mit Hilfe eines Beispiels untersucht. Das Ergebnis wird in Kapitel 4 zusammengefasst. In Kapitel 5 wird das Vorgehen und das Ergebnis in Bezug auf die Anfangs gestellte Hypothese reflektiert.

2 Stand der Forschung

2.1 Definition Use Case

Als Basis der Use-Case-Point Methode zur Aufwandsschätzungen von Softwareentwicklungsprojekten dienen die Use Cases. Als Use Cases wird das beschrieben, was entsteht wenn ein Benutzer mit dem System interagiert.^[3] Das System hat hierbei das Ziel eine Aufgabe für den User zu bearbeiten und zu lösen. Diese Aufgabe besteht aus mehreren einzelnen Schritten, sogenannten Transaktionen. Ein Use Case umfasst alle Szenarien die das System prozessual abbilden muss, die nötig sind, um die Anfrage des Benutzers zu lösen und stellt einen Vertrag zwischen den Stakeholdern dar.^[4]

Ein Use Case besteht nach FROHNHOFF aus folgenden Elementen:^[5]

Abbildung in dieser Leseprobe nicht enthalten

2.2 Herkunft der Use-Case-Point-Methode

Die Einschätzungen von Aufwänden für die Erstellung einer Software gestalten sich, auf Grund der komplexen und vielzähligen Faktoren als sehr kompliziert. So haben die Anforderungen des Users an die Software genauso Einfluss auf den Umfang und den Aufwand des Projektes, wie die Erfahrung der Programmierer und Projektmitarbeiter, die Individualität der Software, die zu programmierenden Klassen und Schnittstellen und Vieles mehr. All diese Größen haben einen Einfluss auf den Aufwand, der betrieben werden muss, um ein Softwareprojekt durchzuführen.

Ein großes Problem ist an dieser Stelle, dass viele Größen nicht, oder nur schwer messbar sind. Mit dem Ziel, diese Faktoren greifbar zu machen, wurde Anfang der 1990er Jahre eine Schätzmethode auf Basis des Use Cases einer Software erstellt. Gustav KARNER entwickelte diese Methode im Rahmen seiner Diplomarbeit in Zusammenarbeit mit der Firma Objectory AB^[6]. KARNER teilte, für den Aufwand relevante, Informationen, Zahlenwerte und Regeln zu, aus denen der Gesamtaufwand zur Erstellung der Software berechnet werden kann^[7]. Diese Methode wurde 2008 durch Stephan FROHNHOFF in seiner Masterarbeit und 2009 in seiner Doktorarbeit in Zusammenarbeit mit Capgemini sd&m jeweils auf den Stand UCP 2.0 und UCP 3.0 modifiziert.^[8] Hierbei wurden die Werte der einzelnen Faktoren abgeändert und den heutigen Standard angepasst sowie eine UCP-Sprache entwickelt. Diese vereinfacht das Mapping von textuellen Use Cases zu einer, für die Use-Case-Point Methode nutzbaren Sprache

FROHNHOFF überarbeitete die Gewichtungen der Einflüsse von Akteuren und Transaktionen und unterteilte letztere in Dialoge, Szenarien und Schritte, um eine detailliertere Analyse und Auswertung der Use Cases zu ermöglichen.

2.3 Beschreibung der Anwendung

Da die Use-Case-Point Methode auf der Basis von den zu implementierenden Use Cases einer Softwareanwendung läuft, werden für eine Durchführung dieser Methode alle relevanten Use Cases der zu implementierenden Anwendung benötigt.

Ziel der Anwendung ist, die zu erwartende Bearbeitungsdauer, den Project Effort (PE) des Software Projektes in Bearbeiterstunden (Bh) zu berechnen. Abbildung 1 zeigt die Zusammenhänge der einzelnen Elemente, aus denen der Aufwand errechnet wird. PE ist das Produkt aus den A-, M- und T-Faktoren sowie aus dem Produktivitätsfaktor. Der A-Faktor widerum entsteht durch die Addition der Gewichtung der Actors in Points und der Gewichtung der Szenarien/Schritte/Dialoge in Points.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Elemente von UCP 3.0^[9]

Im Folgenden werden die einzelnen Elemente und ihre Berechnung näher erläutert.

UAW ^[10] ,^[11] steht für „Unadjusted Actor Weight“ und stellt die Points dar, die durch die Anzahl und Komplexität der, an dem Use Case beteiligten Actors, entstehen. Hierfür werden die Actors nach folgendem Schema bewertet:

Handelt es sich um einen menschlichen Actor werden automatisch 3 Points vergeben. Bei technischen Actors gilt die Regel, dass, wenn mindestens 1 Kriterium als komplex gilt, 2 Points gegeben werden. Gelten alle 3 Kriterien als komplex werden 3 Points vergeben. In allen anderen Fällen wird 1 Point vergeben.

UUCW ^[12] ,^[13] steht für „Unadjusted Use Case Weight“ und stellt die Points dar, die durch die Anzahl der im Use Case vorkommenden Szenarien/Schritte/Dialoge entstehen. Für die Vergabe von Points an Szenarien, Schritten und Dialogen gilt folgende Tabelle:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Bewertungsskala für Szenarien/Schritte/Dialoge^[14]

A-Faktor wird durch die Summe der UAW und UUCW berechnet. Er stellt den Aufwand der funktionalen Anforderungen in Points dar.

M-Faktor steht für Management-Faktor und wird aus der Gewichtung und Komplexität der Einflussgrößen der Projektorganisation und des Projektumfeldes gebildet. Die nach KARNER 64 definierten Kriterien wurden in UCP 3.0 auf die 10 wichtigsten Kriterien reduziert und bilden den M-Faktor.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: M-Faktor Kriterien^[15]

T-Faktor, nach KARNER „Technical Complexity Factor“, stellt die Einflussgrößen der technischen Anforderungen dar, die in Tabelle 3 gelistet sind. Wi ist hierbei der Gewichtungsfaktor, mit dem die Bewertung (1-5 Points) pro Kriterium in den T-Faktor einfließt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: T-Faktor Kriterien^[16]

Produktivitätsfaktor (PF) ist ein Faktor, der von Unternehmen zu Unternehmen unterschiedlich ist und für jedes Unternehmen individuell angepasst werden muss.

3 Untersuchung

3.1 Ausgangslage

3.1.1 Erstellung des Use Case

Da es in Kapitel 3 um die Manipulation innerhalb der Methode UCP 3.0 geht, wird in nachfolgenden Szenarien vorausgesetzt, dass den Teammitgliedern sowie den Stakeholdern die Methode und Begrifflichkeiten bekannt sind.

Um die Funktionsweise von UCP 3.0 genau verstehen und die Probleme besser nachvollziehen zu können, wird an Hand eines einfachen Use Case die Use Case Point Methode 3.0 durchgeführt. Tabelle 4 zeigt den Use Case „Ticket kaufen“:

[...]

^[1] Vgl. EVELEENS, L.; VERHOEF, C. (2010), S. 31

^[2] Vgl. KARNER, G.(1993), S. 1

^[3] Vgl. COCKBURN, A. (2006), alistair.cockburn.us

^[4] Vgl. COCKBURN, A. (2000), S. 1

^[5] Vgl. FROHNHOFF, S. (2009), S. 40

^[6] Vgl. KARNER, G. (1993), S. 1

^[7] Vgl. DEKANENKO, O. (2007), S. 29

^[8] Vgl. DUMKE, R.; SCHMIETENDORF, A.; SEUFERT, M.; WILLE, C. (2014), S. 91

^[9] Vgl. FROHNHOFF, S. (2009), S. 142f

^[10] Vgl. FROHNHOFF, S.; KEHLER, K.; DUMKE, R. (o. D.), S. 3

^[11] Vgl. HUMMEL, O. (2011), S. 57

^[12] Vgl. FROHNHOFF, S.; KEHLER, K.; DUMKE, R. (o. D.), S. 3

^[13] Vgl. HUMMEL, O. (2011), S. 57

^[14] FROHNHOFF, S. (2009), S. 60f

^[15] Vgl. FROHNHOFF, S. (2009), S. 140

^[16] FROHNHOFF, S. (2009), S. 140