Optimales Anforderungsmanagement im agilen Software Engineering aus Sicht des Product Owner

Inhalt

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Formelverzeichnis

Symbolverzeichnis

1 Einleitung
1.1 Problemstellung und Motivation
1.2 Zielstellung und Forschungsfragen
1.3 Methodik und Aufbau der Arbeit

2 Problem der Entwicklungsüberwachung im agilen Projekt

3 Wissens- und Forschungsstand
3.1 Anforderungen in der agilen Softwareentwicklung
3.2 Merkmale adäquater Aufwandsabschätzungen
3.3 Objektive Aufwandsschätzverfahren
3.3.1 Metriken zur Größenbestimmung
3.3.2 Objektive Aufwandsschätzer
3.4 Auswahl einer Schätzmethode
3.5 Kontrolle und Optimierung in agilen SE-Projekten
3.5.1 Grundlagen des IT-Projektmanagements
3.5.2 Kontroll- und Optimierungsmöglichkeiten
3.5.3 Erfassung von Erfahrungswerten in Projekten

4 Methodische Grundlagen
4.1 Auswahl geeigneter Schätzer als Entscheidungsproblem
4.2 Erfahrungswert-Datenbanken
4.3 Bewertungskriterien für einen Proof of Concept

5 Methode zur anforderungsbasierten Auswahl objektiver Aufwandsschätzverfahren
5.1 Auswahlkriterien
5.2 Modellierung des Entscheidungsproblems
5.2.1 Alternativen
5.2.2 Zustandsraum
5.2.3 Ergebnisfunktion
5.3 Modellierung der Entscheidungsregeln
5.3.1 Methode zur Maximierung des Erwartungsnutzens
5.3.2 Spezifizierte EBA-Regel
5.3.3 Spezifizierte Lexikographische Regel
5.4 Faktorskalierung der Schätzfunktionen
5.5 Auswahlalgorithmus
5.6 Modellierung der Erfahrungswert-Datenbank
5.6.1 Datenbank-Use Case
5.6.2 Datenmodell
5.6.3 Relationales Datenbank-Modell

6 Proof of Concept: Anwendung der entwickelten Auswahlmethode
6.1 Anforderungen
6.2 Anwendung des Auswahlalgorithmus
6.2.1 Anforderungsbezogene Auswahl der Schätzer
6.2.2 Schätzergebnisse
6.2.3 Evaluation des Proof of Concept

7 Diskussion der Auswahlergebnisse

8 Zusammenfassung und Fazit

Quellenverzeichnis

Anhang I: Projekt Entwicklung B2B-Portal Aunex Data Service
Unternehmensvorstellung
Projekt Data Service Portal
Projektziel
Organisatorische Rahmenbedingungen
Projekt-Team
Projektplan

Anhang II: Übersicht Entwicklungsanforderungen Data Service Portal

Abbildungsverzeichnis

Abbildung 1 Wissenschaftliches Vorgehen in der Arbeit

Abbildung 2 Semantisches Netz der Problemstellung

Abbildung 3 Merkmale von Anforderungen

Abbildung 4 Merkmalsabhängigkeiten bei Schätzmethoden

Abbildung 5 Abgrenzung Vorgehensmodelle IT-Projektmanagement

Abbildung 6 Projektmanagementzyklus

Abbildung 7 Elemente eines Entscheidungsmodells

Abbildung 8 Zusammenhang zwischen Entwicklungsanforderungen, Forderungen an die Schätzmethode und Methodenmerkmalen

Abbildung 9 Auswahlalgorithmus

Abbildung 10 Erfahrungswertalgorithmus

Abbildung 11 Datenmodell für die Erfahrungswert-DB

Abbildung 12 Relationales Datenbank-Modell der Erfahrungsdatenbank

Abbildung 13 Häufigkeitsverteilung der Entwicklungsstunden

Abbildung 14 Genauigkeit der Schätzer nach Auswahl durch Algorithmus

Abbildung 15 Avisierte Portal-Version 1.0

Abbildung 16 Projektzeitplan

Tabellenverzeichnis

Tabelle 1 Wertebereiche der Merkmale

Tabelle 2 Merkmale der COCOMO-Familie

Tabelle 3 Merkmale der Methode UWE

Tabelle 4 Merkmale der Methode Analogieschätzung

Tabelle 5 Merkmale der ML-Techniken (1/2)

Tabelle 6 Merkmale der ML-Techniken (2/2)

Tabelle 7 Beurteilungskriterien PoC

Tabelle 8 Vorgehen PoC

Tabelle 9 Auswahlkriterien und Selektionsstufen

Tabelle 10 Aktionsraum des Entscheidungsmodells: Alternativen und -eigenschaften

Tabelle 11 Dimensionen und Ausprägungen der Umweltzustände

Tabelle 12 Übersicht Eigenschaften Entwicklungsanforderungen

Tabelle 13 Häufigkeitsverteilung Typ und Spezialisierung

Tabelle 14 Methodenauswahl durch Algorithmus (mit/ohne Erfahrung) und Zufall

Tabelle 15 Schätzergebnisse Genauigkeit und Schätzaufwand

Tabelle 16 Ergebnisse Hypothesentests

Tabelle 17 Einfluss Erfahrung auf Methodenmerkmale

Tabelle 18 Evaluierungsergebnisse PoC

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Formelverzeichnis

Gleichung 1 Allgemeine Form der Schätzfunktion

Gleichung 2 MMRE

Gleichung 3 Pred(l)

Gleichung 4 Nullhypothese für das Ziele Genauigkeit

Gleichung 5 Alternativhypothese für das Ziel Genauigkeit

Gleichung 6 Teststatistik für Ziel Genauigkeit

Gleichung 7 Nullhypothese für das Ziele Schätzaufwand

Gleichung 8 Alternativhypothese für das Ziele Schätzaufwand

Gleichung 9 Teststatistik für Ziel Schätzaufwand

Gleichung 10 Einfach-skalierte Schätzfunktion bei agiler Entwicklung

Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung und Motivation

Die Entwicklung komplexer Softwarelösungen für die Unternehmensnutzung wird in gängiger Industrie-Praxis häufig an externe Dienstleister vergeben.^[1] Auftraggeber^[2] haben im Allgemeinen ein wirtschaftliches Interesse an der Maximierung der Entwicklungsleistung, die mit der Bezahlung von Entwicklerkapazitäten erworben wurde.^[3] Dies bedingt unter anderem eine optimale Ausnutzung der Entwicklungszeit durch die Entwickler. Typischerweise bewegt sich die projektbezogene Leistungserbringung in einem Bereich, welcher durch die Restriktionen Zeit, Budget und Qualität bestimmt ist.^[4] Ein Auftraggeber steht damit vor der Herausforderung, die Entwicklungsleistung der externen Partner im Rahmen dieser Restriktionen zu steuern, zu bemessen und zu kontrollieren.

Dies kann sich besonders in solchen agilen Entwicklungen problematisch gestalten, wo aufwandsbezogene Verträge geschlossen wurden. Dienstleister sichern hier ausschließlich (zeitliche) Entwicklerkapazitäten zu, aber keine verbindlichen Leistungsumfänge.^[5] Damit trägt der Auftraggeber den größten Teil des Entwicklungsrisikos.^[6] Eine Möglichkeit ihre Interessen zu wahren, besteht für Auftraggeber folglich darin, das Projekt durch ein eigenes Management zu begleiten, welches Anforderungen steuert, Entwicklungsaufwände überprüft und mit den Entwicklerkapazitäten vergleicht.

Ist ein aufwandsbezogener Vertrag über eine agile Entwicklungsleistung geschlossen worden, kann der Auftraggeber am ehesten über den von ihm eingesetzten Product Owner (PO) Einfluss auf die Entwicklung nehmen. In der agilen Softwareentwicklung nimmt ein PO die Funktionen eines Projekt- und Produktmanagers innerhalb des Entwicklungsteams wahr.^[7] Als organisatorisches Bindeglied zwischen Projekt-Shareholdern, Entwicklern und weiteren Stakeholdern beinhaltet die Rolle des PO wesentliche Steuerungsaufgaben. Dazu zählt die Ausrichtung der Entwicklung an der Vision des Endprodukts durch geeignetes Anforderungsmanagement. Der PO formuliert und priorisiert die Anforderungen. Hierbei macht er auch Vorgaben bezüglich ihrer Qualität. Bis zu einem bestimmten Grad kann ein direkter Zusammenhang zwischen Entwicklungsqualität und -aufwand unterstellt werden.^[8] In diesem Bereich kann der PO damit sowohl auf das Produkt, als auch auf Projektkosten und Entwicklungszeit aktiv Einfluss nehmen. Im Anschluss an die Entwicklung bewertet er anhand dieser Vorgaben die Umsetzungsleistung der Entwickler in Qualität und Umfang.^[9]

Die Entwickler entscheiden jedoch selbst, welche und wie viele der anstehenden Anforderungen im aktuellen Entwicklungszyklus umgesetzt werden können und sollen. Ihrer Entscheidung zugrunde legen sie ihre eigene Einschätzung bezüglich Entwicklungsaufwand und bestehender Entwicklungskapazitäten. In der Praxis geschieht die Abschätzung oftmals mithilfe von subjektiven, sprich erfahrungsbasierten Methoden.^[10] Diese werden aufgrund ihrer einfachen Handhabbarkeit geschätzt.^[11] Die Genauigkeit einer solchen Expertenschätzung ist allerdings häufig inakzeptabel.^[12]

Fehlt dem PO das für diese Methoden notwendige Erfahrungswissen, kann die Vergleichsschätzung zum Zwecke der Überwachung auf diese Weise nicht gelingen.^[13] In der Literatur werden für diesen Fall verschiedene Ansätze, insbesondere aus der Prinzipal-Agenten-Theorie^[14] dem agilen Projektmanagement^[15] und dem agilen Software Engineering^[16], diskutiert. Jedwede Kontrolle der Aufwandsschätzung wird allerdings in den häufigsten Fällen wieder auf Erfahrungswissen zurückgeführt.^[17]

Eine Alternative besteht in der Anwendung objektiver Schätzmethoden.^[18] Sie bieten Aufwandschätzungen anhand von Kriterien, zu denen sich Messwerte objektiv ermittelt lassen. Damit sind sie unabhängig bestehender Erfahrungswerte anwendbar. Allerdings wurden die objektiven Schätzmethoden für ein klassisches Projektvorgehen, wie im Wasserfallmodell, entwickelt und kommen unter diesen Bedingungen zur Anwendung. Dabei dienen sie der Abschätzung von Projekt-Gesamtaufwänden. Ihre Spezifizierung finden sie u.a. im Schätzaufwand und in der Berücksichtigung unterschiedlicher Anforderungskriterien. In der agilen Entwicklungspraxis haben sie sich bislang nicht durchgesetzt. Ihre Anwendbarkeit in agilen Projekten wird bisweilen sogar angezweifelt.^[19]

Es bleibt damit zu erörtern, wie sich eine erfahrungsfreie Aufwandsschätzung gestalten lässt, um die Aufgaben des PO optimal zu unterstützen. Die Aufgaben richten sich dabei streng an dem Projektziel aus. Steuerung und Kontrolle der externen Entwicklungsleistung durch den PO sollen die Einhaltung der gegebenen Projektrestriktionen bei der Entwicklung des Produkts gewährleisten. Der anforderungsbezogenen Auswahl geeigneter objektiver Methoden zur Aufwandsschätzung in agilen Entwicklungsprojekten kommt in diesem Zusammenhang eine besondere Bedeutung zu. Es existiert eine aktuelle Studie, die ein Unterstützungssystem für die Aufwandsschätzung in agilen Projekten skizziert.^[20] Allerdings ist die strukturierte Auswahl geeigneter Schätzmethoden explizit ausgeklammert und der zukünftigen Forschung angedacht.^[21] Richtlinien, welche einen solchen Auswahlprozess unterstützen können, sind nach Kenntnis des Autors in der Literatur bislang nicht präsentiert worden.^[22]

Die dargelegte Problemstellung hat sich im Rahmen eines realen Projekts konkret ergeben. Die Entwicklung des Business-to-Business (B2B)-Portals für das Unternehmen Aunex GmbH trägt sämtliche geschilderten Problemmerkmale. Sie bietet damit einen geeigneten Untersuchungsrahmen, um die zugrundeliegende, Problemstellung im Rahmen der vorliegenden Arbeit zu erörtern und eine entwickelte Lösung unter realen Bedingungen zu überprüfen.

1.2 Zielstellung und Forschungsfragen

In dieser Arbeit soll für den Product Owner eines agilen Projekts eine Möglichkeit entworfen werden, die geforderte Entwicklungsleistung externer Dienstleister durch geeignete Aufwandsschätzung der Anforderungen zu steuern und kontrollieren. Dazu wird eine Methode entwickelt, geeignete objektive Aufwandsschätzer von Entwicklungsleistungen anhand von Anforderungskriterien auszuwählen. Unter objektiven Schätzern sind alle diejenigen Methoden zur Schätzung des Entwicklungsaufwands zu fassen, welche explizit nicht auf Erfahrungswissen, insbesondere dem von Entwicklern, beruhen. Sie verwenden im Gegensatz dazu operationalisierte Erfahrungswerte zur Schätzung.

Eine projektbezogene Erfahrungswert-Datenbank soll diesen Auswahlprozess unterstützen. Sie soll dabei zum einen projektspezifische Werte, wie Anforderungscharakteristika, Entwicklerfähigkeiten und den tatsächlichen Entwicklungsaufwand erfassen. Zum anderen soll sie die Schätzergebnisse vorhalten, die mit den jeweils ausgewählten Methoden realisiert wurden. In einem Folgeschritt sollen diese Werte für eine messbare, im Optimum kontinuierliche Verbesserung des Auswahlalgorithmus weiterverwendet werden (lernender Auswahlalgorithmus).

Die entwickelte Auswahlmethode soll anschließend ihre Eignung und Vorhersagefähigkeit in einem konkreten Entwicklungsprojekt unter Beweis stellen. Den Rahmen für diesen Proof of Concept (PoC) liefert das Projekt ‚B2B Data Service Portal‘ der Aunex GmbH. Abschließend soll die Generalisierbarkeit der Resultate des PoC und eine Anwendungsempfehlung erörtert werden.

Explizit nicht Gegenstand dieser Arbeit ist die Ermittlung von Projektaufwänden die über die konkrete Entwicklungsleistung hinausgehen, wie z.B. mit dem Projekt verbundene Organisations-, Personal- und Managementleistungen. Ebenfalls unbetrachtet bleibt die Bewertung von Anforderungen im Projektrahmen hinsichtlich ihres Nutzens für und ihrer Rolle im zu entwickelnden Gesamtsystem. Die Auswahl einer Anforderung und damit die Entscheidung für oder gegen ihre Entwicklung werden als gegeben vorausgesetzt. Auf die Auswirkungen von Aufwandsschätzungen auf ein Entwicklungsprojekt wird nur am Rande eingegangen. Insbesondere die aus dem Schätzergebnis ableitbaren Managementmaßnahmen werden aber nicht weiter besprochen. Für eine Einführung in die angesprochenen Punkte wird auf die einschlägige Requirements Engineering- und Projektmanagement-Literatur verwiesen.^[23]

Ausgehend von den Zielstellungen der Arbeit, werden die Forschungsfragen formuliert. Zur späteren Zuordnung sind die Fragestellungen mit römischen Ziffern fortlaufend nummeriert. Mehrere inhaltlich zusammengehörige Fragen erhalten dieselbe Nummer, jeweils durch einen lateinischen Buchstaben ergänzt.

(I a) Welche anforderungsbedingten Auswahlkriterien sollten für Methoden zur Aufwandsschätzung zu Rate gezogen werden?
(I b) Welche objektiven Methoden zur Abschätzung des Entwicklungsaufwands werden in der Literatur als etabliert beschrieben?
(I c) Welche dieser beschriebenen Methoden kommen für eine Anwendung im hier beschriebenen Fall in Frage?
(I d) Wie kann eine Methode mit lernendem Algorithmus zur Schätzerauswahl gestaltet sein, die diese Auswahlkriterien integriert?
(I e) Wie können die in einem Projekt sukzessiv aufgebauten Erfahrungswerte genutzt werden, um den Auswahlalgorithmus zu verbessern?
(I f) Wie ist die für das Lernen notwendige Erfahrungswert-DB zu gestalten?
(II) Welche Performanz zeigt die Auswahlmethode in der Anwendung im Entwicklungsprojekt des B2B-Portals?
(III) Wie ist diese Performanz in Bezug auf ihre Anwendbarkeit in ähnlich gelagerten Anwendungsfällen zu bewerten?

Im folgenden Abschnitt wird das methodische Vorgehen zur Beantwortung dieser Fragestellungen und der damit verbundenen Zielstellung der Arbeit beschrieben.

1.3 Methodik und Aufbau der Arbeit

Das nachfolgend geschilderte Vorgehen ist ausgerichtet an der grundlegenden Problemstellung, welche sich im Zuge der Entwicklung des Data Service -Portals für die Aunex GmbH ergeben hat. Im Rahmen einer vorläufigen Sichtung der Quellenlage in Bereichen, die mögliche Aspekte des Problems thematisieren, konnte keine etablierte oder auf das Problem ohne weiteres adaptierbare Lösung identifiziert werden. Die per Mind Mapping identifizierten Bereiche sind Vertragsgestaltung (Recht), wirtschaftliche Gestaltung von Anreiz, Gegenleistung und Belohnung (Principal-Agent-Theorie) sowie Management der Entwicklungsanforderungen. Dieses Management beinhaltet Steuerung und Kontrolle der Arbeitsleistung durch geeignete Aufwandsschätzung und -messung der Entwicklungsleistung. Insbesondere der Managementaspekt eignet sich thematisch zur Untersuchung im Rahmen einer Masterthesis im Bereich der Wirtschaftsinformatik. Er wird deshalb für die weitere Ausrichtung der Arbeit ausgewählt.

Für die Evaluierung der Lösungsansätze aus dem Bereich der Aufwandsschätzung ist festzustellen, dass sich eine ergiebige Zahl an neueren Journalveröffentlichungen allgemein dem Thema Aufwandsabschätzung in agilen Software Engineering-Projekten widmet. Allerdings werden beinahe ausschließlich Erfahrungswissen-basierte Schätzmethoden besprochen. Priorität genießt in diesen Arbeiten die Entwicklung methodischer Werkzeuge. Sie sind häufig verbunden mit einer empirischen Studie. In diesen wird die vorgestellte Methode auf einen konkreten Sachverhalt angewandt und dabei deren Vorhersagequalität im Vergleich zu bestehenden Aufwandsschätzern bestimmt. Das Fallstudien-Format wird dabei regelmäßig genutzt.

Für objektive Schätzmethoden besteht diese Quellenvielfalt nicht. Dokumentierte Methoden stellen oft Adaptionen von Schätzern aus dem Bereich der plangesteuerten Software-Entwicklung dar. Aktuelle Methoden bedienen sich moderner Empirie-basierter Verfahren aus den Bereichen und der Künstlicher Intelligenz (Data Mining, Maschinelles Lernen (ML)). Um ein Verständnis für ihre praktische Anwendung zu schaffen, existieren erläuternde Beschreibungen in Monographien und Artikeln in ausreichender Zahl. Aktuelle Fallstudien, die die Anwendbarkeit und Vorhersagegenauigkeit objektiver Methoden in agilen Projekten thematisieren, sind nur in kleinem Umfang zu finden. Die Notwendigkeit einer besseren Erforschung dieses Aspektes ist jedoch allgemein anerkannt.^[24] Eine Durchsicht der wenigen Übersichtsartikel, welche das Feld der Aufwandsschätzmethoden in der agilen Softwareentwicklung systematisieren und die Erkenntnisse zusammenfassen, unterstreicht diese Erkenntnis.^[25]

In der berücksichtigten Literatur bestehen also eine Reihe gut beschriebener objektiver Schätzmethoden. Allerdings gibt es in den recherchierten Quellen kaum Aussagen zur Anwendbarkeit der Methoden in agilen Projekten. Weiterhin bestehen nur wenige, auf intermethodischem Vergleich beruhende Erkenntnisse über Schätzaufwand und Vorhersageerfolg in der praktischen Anwendung. Zudem wird in den Artikeln mit praktischem Untersuchungsbezug regelmäßig von großen Schätzunsicherheiten berichtet. Dieser Umstand deutet auf ein bislang unzureichend ergründetes Verständnis zwischen Entwicklungsaufwand und dessen Schätzung hin. Ein anforderungsbasierter Auswahlprozess geeigneter Schätzmethoden wird allenfalls mit der Bestimmung der Vorteile und Spezifizierung der Methoden im Rahmen ihrer Beschreibung impliziert. Etwas deutlicher werden die wenigen aktuellen komparativen Studien, welche insbesondere Methoden gleicher Klassen untersuchen (z.B. Methoden, die Algorithmen des ML verwenden).^[26] Im Ergebnis beschreiben die Autoren dieser Studien, welche der betrachteten Methode für den untersuchten Anwendungsbereich die nach ihren Kriterien besten Schätzergebnisse liefert.^[27] Die Verwendung von projektbezogenen Erfahrungswerten zur Auswahl geeigneter Schätzer wird nicht beschrieben. Damit existiert keine belastbare wissenschaftliche Basis für einen systematischen Auswahlprozess dieser Methoden im hier betrachteten Anwendungsfall.

Das Untersuchungsdesign zur Bearbeitung der Forschungsfragen I bis III und zur Erreichung der Zielstellung wird diesen Erkenntnissen angepasst gewählt. Es ist zusammenfassend dargestellt inAbbildung 1. Die Arbeit gliedert sich in einen theoretischen Teil, in dem die wesentlichen Grundlagen erarbeitet werden und in einen praktischen Teil, in welchem die erarbeitete Auswahlmethode im Rahmen eines PoC angewandt wird. Ein waagerechter Pfeil im oberen Bildteil symbolisiert Vorgehensrichtung und entsprechende -unterteilung. Darunter reihen sich abwechselnd die einzelnen Vorgehensschritte (weißes Kästchen mit grauem Rahmen) und die daraus entstehenden Resultate (graues Kästchen). Die Arbeit schließt mit einem Fazit ab.

Abbildung 1 Wissenschaftliches Vorgehen in der Arbeit.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Die zugrundeliegende Problemstellung soll zunächst anhand der Entwicklung des Data Service Portals von dem Unternehmen Aunex GmbH eingehend beschrieben werden. Der reale Bezug dient der induktiven Bestimmung von allgemeinen Einflussbereichen auf die Problemstellung. Jedoch liegt der Fokus auf die bereits thematisierte Aufwandsschätzung. Aus den Einflussbereichen sollen theoriegestützte Lösungsansätze identifiziert und schließlich die Auswahlmethode abgeleitet werden. Auf diese Weise sollen die explorativen Forschungsfragen I a bis I f beantwortet werden.

Im theoretischen Teil dieser Arbeit sollen aus der Literatur vier Sachverhalte grundlegend erarbeitet werden. Diese sind:

1. Bestimmung von Auswahlkriterien zur Selektion geeigneter Schätzmethoden (zur Beantwortung Forschungsfrage I a). Dabei sollen die Kriterien insbesondere die Adaptierbarkeit der Methoden in der agilen Entwicklung berücksichtigen.
2. Ermittlung des Forschungsstandes bei Methoden und Theorien zur Aufwandsabschätzung im Rahmen des IT-Projekt- und Anforderungsmanagements in der agilen Software-Entwicklung (zur Beantwortung Forschungsfrage I b und I c). Im Fokus stehen hierbei objektive Methoden.
3. Erarbeitung von Grundlagen zur Algorithmen-basierten Schätzerauswahl (zur Beantwortung Forschungsfrage I d).
4. Bestimmung von Grundlagen zum Aufbau einer projektbezogenen Erfahrungswert-DB und deren Nutzung im skizzierten Problemfall (zur Beantwortung Forschungsfrage I e und I f).

Bei der Literaturauswahl werden folgende Kriterien zugrunde gelegt:

1. Die Suche erfolgt in den großen wissenschaftlichen Online-Suchmaschinen SCOPUS, Science Direct, IEEE Xplore, Springer Link und Google Scholar.
2. Gesucht werden begutachtete Artikel in ausgewählten Journalen sowie themenrelevante Monographien und Sammelwerke.
3. Berücksichtigt wird Literatur in englischer und deutscher Sprache.
4. Die Journalauswahl richtet sich nach Empfehlung des VHB Teilranking Wirtschaftsinformatik mit Bewertung A und besser.^[28]
5. Das Suchergebnis in den Journal-Datenbanken wird auf aktuelle Arbeiten beschränkt (01.06.2016 - 31.05.2018), um den aktuellen Stand der Forschung zu erfassen.
6. Die verwendeten Suchterme basieren auf folgenden Schlagworten und Schlagwortverbindungen sowie ihren deutschen Entsprechungen: IT project management, software development, agile development, software cost / effort estimation, performance, requirements engineering.
7. In den so identifizierten und ausgewählten Artikeln wurden zusätzlich die dort referenzierten Quellen anhand ihrer Titel nach weiteren relevanten Arbeiten durchsucht (unabhängig ihres Erscheinungsdatums).
8. Bei Monographien und Sammelwerken erhalten die Titel mit einem höheren Zitations-Index Vorrang vor solchen mit einem niedrigeren. Eine zeitliche Einschränkung erfolgt nicht.

Mit dem Entwicklungsprojekt des B2B-Data Service Portals steht für die vorliegende Untersuchung ein Betrachtungsrahmen zur Verfügung, anhand dessen die identifizierte Schätzerauswahlmethode evaluiert werden kann. Im praktischen Teil der Arbeit wird dazu ein PoC durchgeführt und damit Forschungsfrage II beantwortet. Schließlich wird das Ergebnis des PoC in Bezug auf die Möglichkeit eines erweiterten Anwendungsbereichs zur Beantwortung von Forschungsfrage III bewertet.

Der Aufbau der Arbeit lehnt sich an das hier geschilderte Vorgehen an. Im nachfolgenden Kapitel 2 wird die grundlegende Problemstellung erörtert. Kapitel 3 ist dem Wissens- und Forschungsstand gewidmet. Die in der Literatur behandelten Lösungsansätze werden in Kapitel 4 thematisiert. Gegenstand des folgenden Kapitel 5 ist die Entwicklung einer neuen Methode zur Auswahl geeigneter objektiver Aufwandsschätzer in agilen Projekten. Die Konzeption einer Wissensdatenbank zur Unterstützung und sukzessiven Verbesserung des Auswahlalgorithmus wird ebenfalls in diesem Kapitel vorgestellt. Das anschließende Kapitel 6 behandelt die praktische Anwendung der entwickelten Auswahlmethode und stellt die Ergebnisse des PoC vor. Die Ergebnisse werden in Kapitel 7 einer kritischen Bewertung unterzogen. In diesem Rahmen werden auch das methodische Vorgehen sowie die auf diese Weise ermittelten Erkenntnisse diskutiert. Der inhaltliche Teil der Arbeit schließt mit einer Zusammenfassung der Erkenntnisse und einem an die zukünftige Forschung gerichteten Fazit in Kapitel 8.

2 Problem der Entwicklungsüberwachung im agilen Projekt

Die Firma Aunex GmbH (kurz ‚Aunex‘) hat die Absicht, ein Data Service Portal in ihr unternehmerisches Leistungsspektrum aufzunehmen. Das Produkt Data Service Portal existiert bislang nicht und soll im Rahmen eines Projekts entwickelt werden. Die organisatorischen und zeitlichen Grundlagen des Projekts sind in Anhang I beschrieben. Bei der Durchführung des Projekts ergab sich eine Problemstellung, welche bislang nicht zufriedenstellend gelöst werden konnte: die Überwachung der Entwicklungsleistung. Ziel der nachfolgenden Betrachtung ist es, dieses Problem präzise zu beschreiben. Auf dieser Grundlage sollen dann in den folgenden Kapiteln mögliche Lösungsansätze und dabei betroffene Wissenschaftsbereiche abgeleitet werden.

Die Absicht der Unternehmensgründer basiert auf der Produktidee, ihren potenziellen Kunden einen konkreten Mehrwert zu verschaffen: Verringerung des organisatorischen Aufwandes verbunden mit signifikanter Zeitersparnis bei der Suche nach Gerätebeschreibungsdateien.

Das Produkt ist zu Beginn des Projekts nur vage spezifiziert. Konsens zwischen den Gründern ist, dass das Portal ein Software-Produkt sein soll, welches verschiedene Fähigkeiten abbildet, um den vorher identifizierten Kundennutzen zu bedienen. Allerdings sind die für eine Entwicklung notwendigen Anforderungen bislang nicht vorhanden oder nur unvollständig beschrieben.

Ferner besteht innerhalb des Unternehmens keine ausreichende Software-Engineering- und -Developer-Kompetenz, um das Software-Produkt selbst zu entwickeln. Aufgrund betrieblicher Restriktionen kann diese auch nicht kurzfristig aufgebaut werden. An einem langfristigen Personalaufbau sind die Gründer ebenfalls nicht interessiert. Aus diesen Gründen soll die entsprechende Kompetenz extern eingekauft werden. Mit der Entwicklung im Projektrahmen wurde deshalb das externe Dienstleistungsunternehmen tevim UG (kurz ‚tevim‘) vertraglich beauftragt.

Das beauftragte Unternehmen entwickelt und steuert das Projekt aufgrund eigener Erfahrung ausschließlich agil. Vertraglich sind für das Projekt 136 Entwicklungsstunden pro Monat über einen Zeitraum von drei Monaten festgelegt. Für den Funktionsumfang des Entwicklungsergebnisses gibt tevim allerdings keine verbindliche Zusage. Aunex trägt damit das gesamte Entwicklungsrisiko. tevim trägt nur insofern ein Risiko, dass bei unbefriedigender Leistung Folgeaufträge von Aunex ausbleiben könnten. Ferner könnte bei entsprechend negativer Kommunikation durch Aunex die Reputation in Mitleidenschaft gezogen werden.

Im Projekt stellt Aunex den Product Owner, welcher u.a. die Interessen des Auftraggebers beim Auftragnehmer vertritt. Er spezifiziert und priorisiert die zu entwickelnden Anforderungen im Product Backlog entlang der Produktvision. Aus diesem Product Backlog wählen die Entwickler im Dialog mit dem Product Owner die Anforderungen, welche im kommenden Entwicklungszyklus (Sprint) bearbeitet werden sollen. Das Entwicklungsvolumen eines Sprints wird im Selected Backlog transparent für alle Projektbeteiligten festgehalten.

Den Füllgrad des Selected Backlog innerhalb eines Sprints bestimmen die Entwickler. Diese Bestimmung beruht wesentlich auf ihrem Erfahrungswissen. Sie verzichten dabei auf Methoden der Aufwandsabschätzung, wie zum Beispiel dem üblichen Planning Poker. In der Praxis schwankt die Vorhersagekraft solcher Methoden ohnehin enorm.^[29] Subjektive Einflüsse auf die erfahrungsbasierte Einschätzung (Motivation, Hidden Agenda, Erfüllungswunsch, konkurrierende Ziele), methodenunterstützt oder nicht, bleiben dem Product Owner in jedem Fall verborgen.

Dem Product Owner bleibt somit die Option, auf die Einschätzung der Entwickler bei der Erfüllung zu vertrauen. Vertrauen ohne gegenseitige Kenntnis der Personen birgt insbesondere für den Product Owner das Risiko einer Ausnutzung oder Täuschung. Vertrauensbildende Maßnahmen könnten hilfreich sein, um die gegenseitigen Ziele von Entwicklern und Product Owner kennenzulernen und nach Möglichkeit in Einklang zu bringen. Dies wurde im Rahmen eines gemeinsamen, zweitägigen Workshops vor Entwicklungsauftakt forciert. Neben dem wichtigen Aufbau eines Produktverständnisses bei den Entwicklern, standen vertrauensbildende und kommunikationsfördernde Aktivitäten im Vordergrund. Hierbei sollten die gegenseitigen Ziele, Sorgen und Ängste, die mit dem Projekt verknüpft sind, offen angesprochen und gemeinsame Lösungen festgelegt werden.

Dennoch wollen sich die Auftraggeber nicht vollständig auf das Vertrauen verlassen. Alternative, anreizbasierte Maßnahmen, die die Entwickler auf die Ziele von Aunex steuern sollten, wurden nicht ergriffen. Dafür wurde zwischen Entwicklern und Product Owner festgelegt, dass letzterer die Einschätzungen der Entwickler durch eigene Schätzungen kontrolliert und diese in der fortlaufenden Projektplanung berücksichtigt. Bei für den Product Owner nachteiligen Abweichungen, könnte entsprechend im Rahmen seiner Projektmanagementaufgaben reagiert werden.^[30] Der Product Owner steht nun allerdings vor dem Problem, Entwicklungsaufwände adäquat zu schätzen, ohne dass eigenes Erfahrungswissen existiert.

Die zugrundeliegenden Projekt- und Problemcharakteristika lassen sich nun zusammenfassen. Vor der Herausforderung Entwicklungsaufwände adäquat zu schätzen stehen Auftraggeber einer Entwicklungsleistung generell immer, sofern

- Entwicklungsprojekte betrachtet werden, bei denen Anforderungen ex ante nicht vollständig spezifiziert sind,
- aufwandsbezogene Verträge mit externen Entwicklern abgeschlossen wurden,
- Entwickler agil arbeiten und ihre eigenen, intransparenten Aufwandsschätzungen zugrunde legen,
- Auftraggeber keine entsprechenden eigenen Erfahrungswerte zur erfahrungsbasierten Aufwandsschätzung besitzen,
- Auftraggeber die Leistung der Entwickler kontrollieren und in ihrer fortlaufenden Projektplanung berücksichtigen wollen.

Dieser Merkmalsrahmen charakterisiert das vorliegende Problem aus Projektsicht. Lösungsansätze müssen diesen Rahmen berücksichtigen und entsprechende Alternativen zur adäquaten Aufwandsschätzung präsentieren. Projekte, die ebenfalls diese Merkmale aufweisen, stehen grundsätzlich vor demselben Problem. Ein Lösungsansatz für das hier beschriebene Projekt sollte dementsprechend auch auf andere Projekte mit gleichem Merkmalsrahmen übertragen werden können.

In diesem Kapitel konnte gezeigt werden, dass das Problem der objektiven Aufwandsabschätzung in agilen Entwicklungsprojekten für eine Reihe von Projekten mit gleichen Merkmalen von grundsätzlicher Natur ist. Lösungsansätze, die in dieser Arbeit thematisiert werden sollen, fokussieren auf den Bereich der objektiven Aufwandsschätzmethoden. Der Forschungsstand in diesem Bereich ist Thema des folgenden Kapitels.

3 Wissens- und Forschungsstand

Das Ziel des vorliegenden Kapitels ist es, den Wissens- und Forschungsstand zur erarbeiteten Problemstellung (Kapitel 2) aus der Literatur zusammen zutragen. Dabei sollen relevante Theorien identifiziert und potenzielle Lösungsansätze ermittelt werden. Ein gegebenenfalls vorherrschendes Theoriedefizit ist in diesem Rahmen zu bestimmen.

Zunächst ist zu erörtern, welche theoretischen Fragen durch die Problemstellung tangiert werden und welche Themenfelder dabei betroffen sind. Dazu wird das Problem zunächst in seine Merkmale dekonstruiert. Das Ergebnis lässt sich dann in ein ontologisches Modell der Problemstellung überführen. In dieser Arbeit wird das Modell in Form eines semantischen Netzes verwirklicht. Semantische Netze eignen sich Fragestellungen und Wissensbereiche zu systematisieren und zu visualisieren, die mit der Problemstellung ontologisch verbunden sind.^[31] Aus diesem Modell werden einerseits Fragestellungen abgeleitet, welche die Untersuchung der Problemstellung weiter spezifizieren. Andererseits ergeben sich aus dem Modell und daraus abgeleiteten Fragestellungen die Suchfelder und -terme der anschließenden Literaturrecherche. Ist die relevante Literatur identifiziert, wird sie bezüglich der aus der Problemstellung abgeleiteten Fragestellungen analysiert. Die Analyseergebnisse werden schließlich auf ihre Anwendbarkeit in der Problemstellung verglichen. Fehlen geeignete Lösungsansätze, so weist dies auf ein bestehendes Theoriedefizit hin.

Die Problemstellung, welche sich aus der Betrachtung des Projekts ergeben hat, trägt folgende Merkmale:

- Auswahl von geeigneten Methoden zur
- adäquaten, erfahrungsfreien Aufwandsabschätzung von
- Anforderungen in
- agiler Software-Entwicklung zum Zwecke der
- Kontrolle der Arbeit der Entwickler und
- optimalen Ausnutzung des Selected Backlog.

Anhand dieser Aufstellung wird ein semantisches Netz aufgestellt, welches die theoretischen Fragen und betroffenen Themenfelder für die vorliegende Problemstellung bestimmt (Abbildung 2).

Abbildung 2 Semantisches Netz der Problemstellung.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Über Pfeile sind Objekte mit einander verbunden, die taxonomisch voneinander abhängen. Die Pfeiltönung wird bestimmt durch die höchste Taxonomieebene aller beteiligten Objekte. Ebene 1 stellt dabei die höchste Ebene dar. Zentral im Netz auf der Taxonomieebene 1 befindet sich das Problem der Schätzung von Anforderungen (schwarzes, abgerundetes Rechteck). Um dieses herum platziert sind die mit der Problemstellung verbundenen Elementarfragen in W-Form (dunkelgraues, abgerundetes Rechteck; Taxonomieebene 2). Die klassifizierten Antworten auf die Elementarfragen sind in Hellgrau abgebildet. Sie repräsentieren die Objekte der Taxonomieebene 3. Hierunter befinden sich auch die beiden wesentlichen Subjektklassen PO und Entwickler. Diese stehen mit anderen Objekten in einer Tätigkeitsbeziehung. Hellgraue Ovale charakterisieren diese Tätigkeit. So sind die Verantwortlichkeiten des PO in Bezug auf die Anforderungen innerhalb des Projekts durch eine Reihe von Tätigkeiten bestimmt: Identifizierung und Formulierung der Anforderungen, Priorisierung im Product Backlog, Kontrollausübung auf die Entwicklungstätigkeit der Entwickler sowie Optimierung des Füllgrads des Selected Backlog. Auf welche Weise der PO die Schätzmethode auswählt, soll in dieser Arbeit bestimmt werden. Die Elemente des Untersuchungsbereichs sind mit halbtransparenten, hellgrau-gestrichelten Rahmen markiert und gleichfarbigen Linien verbunden.

Aus Merkmalsaufstellung und semantischem Netz ergeben sich zunächst acht Fragen, die durch geeignete Theorien beantwortet werden sollen:

i. Wie sind Anforderungen in der agilen Software-Entwicklung definiert?
ii. Wie unterscheiden sich Anforderungsdefinitionen in der agilen und nicht-agilen Software Entwicklung?
iii. Was sind Merkmale einer adäquaten Aufwandsabschätzung?
iv. Was sind objektive, erfahrungsfreie Aufwandsschätzungen?
v. Welche Möglichkeiten einer adäquaten und erfahrungsfreien Aufwandsabschätzung von Anforderungen in der agilen Software-Entwicklung existieren?
vi. Welche Möglichkeiten zur systematischen Auswahl eines adäquaten Aufwandsschätzers werden in der Literatur beschrieben?
vii. Welche prinzipiellen Möglichkeiten stehen dem Projektmanagement zur Verfügung, um die Arbeitsleistung der Entwickler in agilen Projekten zu kontrollieren?

Wie kann der Selected Backlog auf der Grundlage der priorisierten Anforderungen im Product Backlog optimal gefüllt werden? Oder allgemeiner formuliert:

viii. Wie kann die Ausschöpfung der Entwicklerkapazität in einem Sprint optimiert werden?

Im ersten Punkt der Merkmalsaufzählung wird die Software-Entwicklung als ‚agil‘ spezifiziert. Die Bestimmung des Begriffs und sein Einfluss auf die Charakterisierung von Entwicklungsanforderungen bilden das erste Themenfeld. Anhand dessen sind die Fragen i und ii zu beantworten (Kapitel3.1).

Das Merkmal ‚adäquat‘ charakterisiert die Qualität des ermittelten Schätzwertes einer Aufwandsschätzungen. Die Qualität bemisst sich dabei naturgemäß anhand definierter Kriterien, die ein Schätzergebnis mit dem tatsächlich realisierten Entwicklungsaufwand in Beziehung setzen. Sie sollen einen strukturierten Vergleich und eine daraus systematisch abgeleitete Bewertung ermöglichen. Diese Aspekte bilden den zweiten Themenkomplex, in dessen Zuge Frage iii zu beantworten ist (Kapitel3.2).

Andererseits verweist das Qualitätsmerkmal ‚adäquat‘ auf eine nicht-willkürliche, planvolle und systematische Ermittlung von Aufwänden.^[32] Darunter sind methodengestützte Schätzungen zu fassen. Es ist weiter spezifiziert, dass die Schätzung erfahrungsfrei, das heißt ohne Berücksichtigung von Erfahrungswissen, erfolgen soll. Erfahrungsfreie Aufwandsschätzmethoden bilden damit das dritte zu betrachtende Themenfeld, bei welchem Fragen iv und v zu beantworten sind (Kapitel3.3).

Frage vi thematisiert Möglichkeiten zur systematischen Auswahl von Aufwandsschätzmethoden. Aktuelle Ansätze und bestehende Konzepte in diesem Bereich werden in Kapitel3.4vorgestellt.

In den beiden letzten Aufzählungspunkten wird der Zweck der Schätzung thematisiert: Kontrolle und Optimierung. Beides sind Managementaufgaben im Projektmanagement, welche durch den Projekttypen (Software-Entwicklung) und die Vorgehensweise bei der Entwicklung (agile Software-Entwicklung) näher charakterisiert werden. Aus der Betrachtung dieses fünften Themengebietes sollen schließlich die Fragen vii und viii beantwortet werden (Kapitel3.5).

Die hier spezifizierten Themengebieten werden im Folgenden nacheinander betrachtet. Dabei sollen die acht abgeleiteten Fragen beantwortet werden. Ihre Erörterung basiert auf einer Auswertung von Textquellen, welche im Rahmen der Literaturrecherche ermittelt wurden. Die dazu verwendeten Suchfelder und -terme wurden aus dem oben skizzierten ontologischen Modell gewonnen. Sie werden an dieser Stelle nicht explizit angeführt, da sie bereits in Kapitel1.3vollständig aufgezählt sind.

3.1 Anforderungen in der agilen Softwareentwicklung

Verschiedene Analysen zum Erfolg von Software-Engineering-Projekten haben immer wieder auf den großen Einfluss der Beschreibung einer konkreten Anforderung (Anforderungsdefinition) für dessen Umsetzung verwiesen. Unvollständige oder falsche Anforderungen werden regelmäßig als Grund für das Scheitern von Projekten angeführt.^[33]

Der Begriff der Anforderung im Zusammenhang mit Softwareentwicklung erfährt in der Literatur breite inhaltliche Verwendung ohne eine verbindliche Definition.^[34] Valentini et al. formulieren allgemein „[Projekt-]Ziele sind Anforderungen“.^[35] Eine klassische Einteilung besteht in der Unterscheidung von funktionalen und nicht-funktionalen Anforderungen.^[36] Funktionale Anforderungen umfassen demnach die Funktionalitäten der Software im Sinne von Fähigkeiten. Nicht-funktionale Anforderungen des zu entwickelnden Systems hingegen spezifizieren die funktionalen Anforderungen hinsichtlich der Qualität der geforderten Fähigkeiten. Ein in der Praxis verbreitetes Qualitätsmodell ist in der Norm ISO/IEC 25010 standardisiert.^[37] In Bezug auf das Entwicklungsprojekt werden häufig weitere nicht-funktionale Anforderungen formuliert, welche im Wesentlichen Projekt-Randbedingungen (z.B. Zeit, Ressourcen, Kosten, etc.) betreffen.^[38]

In einer alternativen Kategorisierung von Valentini et al. wird zwischen Kundenanforderungen, Systemanforderungen und Designanforderungen unterschieden. Der Interpretation der Autoren folgend, beschreiben Kundenanforderungen das Entwicklungsproblem, Systemanforderungen mögliche abstrakte Lösungen und Designanforderungen die konkrete technische Implementierung.^[39] Sie beziehen sich in diesem Sinne eindeutig auf funktionale Aspekte der Anforderungen. Diese Zuordnungsweise kann die oben angeführte Einteilung in funktionale und nicht-funktionale Anforderungen problemlos ergänzen und trägt zu einer verfeinerten Betrachtung bei.

In den beiden vorgenannten Definitionsansätzen spielt das verwendete Vorgehensmodell bei der Entwicklung keine Rolle.^[40] Curcio et al. verweisen auf den Umstand, dass die typischen Phasen des Requirements Engineering (RE), also Erhebung, Analyse, Dokumentation, Validierung und Verifizierung von Anforderungen, im klassischen Vorgehensmodell bereits während der Analysephase der Softwareentwicklung stattfinden.^[41] In agilen Projekten sind diese Phasen ebenfalls relevant, wenn auch in angepasster Intensität. Allerdings ist ihre zeitliche Einordnung in den Entwicklungsablauf weniger eindeutig.^[42]

Agile Projekte sind geprägt von kurzen, iterativen Entwicklungszyklen, in denen jeweils definierte Teile eines avisierten Softwareprodukts umgesetzt werden.^[43] Diese Teile sind zu Projektbeginn zumeist nicht vollständig definiert und spezifiziert. Erst unmittelbar vor dem Entwicklungszyklus, in dem ein Teil erstellt werden soll, müssen die dazugehörigen Anforderungsinformationen finalisiert sein. In agilen Projekten wird die Beschreibung der Anforderungen häufig in Form von Use Cases getätigt. Diese beinhaltet die Erläuterung des Nutzerinteresses an der Funktion, um die Entwicklung zielgerichtet auf den Nutzer zu fokussieren.^[44] Dazu empfiehlt es sich Akzeptanzkriterien aufzunehmen, die eine Evaluierung der Entwicklungsleistung mit einem verbindlichen Abschluss ermöglichen.^[45] So kann zwar einerseits vom Projektmanagement flexibel auf Anforderungsänderungen im Laufe der Entwicklung reagiert werden.^[46] Andererseits kann durch eine Fokussierung auf Teilaspekte des zu entwickelnden Projekts der Blick auf das Gesamtkonzept verstellt sein.^[47]

Eine Möglichkeit dieser Gefahr zu begegnen, besteht in dem konsequenten Durchlaufen der oben angesprochenen RE-Phasen vor jedem Entwicklungszyklus. Aus praktischen Erwägungen muss dies allerdings in kleinerem Maßstab als im Wasserfall-Modell und fokussiert auf die Teilentwicklung geschehen. Dabei sind die Grundsätze agiler Entwicklung, insbesondere der starke Einbezug von Stakeholdern in den Entwicklungsprozess, zu berücksichtigen.^[48]

Wie genau die RE-Phasen in agile Projekten optimal adaptiert werden können, ist Gegenstand anhaltender Forschung.^[49] In diesem Zusammenhang wird in der Literatur ein Mangel an geeigneten Methoden zur Ableitung von Anforderungen und deren Spezifikationen in der agilen Entwicklung beklagt.^[50]

Ein Aspekt dieses Problems stellt die Aufwandsschätzung für die Umsetzung einer Anforderung dar. Für die Betrachtung in dieser Arbeit bedarf es Ansätzen, die auf der Grundlage einer gegebenen Anforderungsbeschreibung sämtliche Informationen zusammenstellen können, welche für den Auswahlprozess einer geeigneten Schätzmethode nötig sind. Ob dabei Rücksicht auf die oben skizzierte Kategorisierung von Anforderungen genommen werden sollte, ist in der Literatur nicht beschrieben.

Immerhin können Merkmale von Anforderungen in Bezug auf die Aufgabenstellung dieser Arbeit abgeleitet werden. Eine Übersicht bietetAbbildung 3, die außerdem auch auf die Abhängigkeiten der Merkmale untereinander eingeht. Die abgebildete Pfeilrichtung gibt dabei die Beziehungen zwischen den Merkmalen nach folgendem Muster an: Aus <Pfeilquelle> folgt <Pfeilziel>.

Abbildung 3 Merkmale von Anforderungen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung nach Inhalten von Pichler, R., Agile Product Management, 2010, S. 52, Valentini, U., et al., Requirements Engineering und, 2013, S. 26, 125 ff.

Grundsätzlich verursacht jede Anforderung bei ihrer Umsetzung einen spezifischen Entwicklungsaufwand. Dieser ist abhängig von verschiedenen Faktoren. Die Literatur bietet dazu eine Reihe von Faktoren an. Für diese Betrachtung werden die Faktoren unter den drei Kategorien Anforderungsbeschreibung, funktionale Aspekte und nicht-funktionale Aspekte subsumiert.

Anforderungen in agilen Projekten müssen erst kurz vor der Umsetzung spezifiziert sein. Dann benötigen sie allerdings eine Beschreibung, aus welcher der Nutzen für den Anwender hervorgeht. Zusätzlich werden Akzeptanzkriterien benötigt. In diesen beiden Spezifizierungen fließen wiederum funktionale und nicht-funktionale Aspekte der Umsetzung ein.

Ein für den Wert der Aufwandsschätzung wesentlicher, wenn auch schwer zu quantifizierender Aspekt bildet dabei der Funktionsumfang der Anforderungen. Dieses Merkmal umfasst die einzelnen Funktionen, welche mit der Anforderung umgesetzt werden sollen. Ein Indikator für ihren Wert stellen die Akzeptanzkriterien dar, wenn sie die einzelnen Funktionen und deren Qualität spezifizieren. Er ist stark beeinflusst von den zur Umsetzung verfügbaren Projektressourcen. Die weitere Einteilung der funktionalen Aspekte in die Kategorien von Valentini et al. hilft, um die Detaillierung der Anforderung zu ermessen. Dabei weist eine Kundenanforderung den niedrigsten und eine Designanforderungen den höchsten Detaillierungsgrad auf. Sowohl Design- als auch in etwas geringerem Maße Systemanforderungen setzen ein klares Verständnis des umzusetzenden Systems voraus.

Nicht-funktionale Aspekte finden sich in der Festlegung der Umsetzungsqualität und den gegebenen Projektrahmenbedingungen Zeit, Personal und sonstige Ressourcen. Dabei bedingen sich Qualität und Projektrahmen gegenseitig, wie der bidirektionaler Pfeil inAbbildung 3verdeutlichen soll. Das bedeutet, dass jegliche Qualitätsforderung durch entsprechende Ressourcengestellung im Projektrahmen unterlegt sein muss, um sie erfüllen zu können. Andererseits ermöglicht die Bereitstellung eines gewissen Ressourcenumfangs die Umsetzung der Entwicklung in einer gewissen Qualität.

Eine vollkommene Korrelation zwischen Projektressourcen und Qualität besteht aufgrund weiterer Einflussfaktoren nicht. Dieser Betrachtung sind nicht zuletzt durch die Interdependenzen zwischen den Projektressourcen natürliche Grenzen gesetzt.^[51] Der Einfluss weiterer Faktoren, welche nicht unter diesem Zusammenhang subsummiert werden können, ist allerdings nicht Gegenstand dieser Untersuchung. Die Relation zwischen Qualität und Projektressourcen wird deshalb im Rahmen dieser Arbeit als vollkommen in dem Sinne angenommen, dass der Einfluss eines Faktors durch den jeweils anderen vollständig beschrieben werden kann.

Die obige Betrachtung zur Definition von und Umgang mit Anforderungen in der agilen Software-Entwicklung bildet die Antwort auf die eingangs in diesem Kapitel formulierten Fragen i und ii. Die Anforderungsmerkmale ausAbbildung 3werden in Kapitel5für den Entwurf einer Schätzerauswahlmethode verwendet.

3.2 Merkmale adäquater Aufwandsabschätzungen

Methoden zur Aufwandsschätzung werden genutzt, um den Entwicklungsaufwand ex ante adäquat, das heißt in einer hinreichenden Qualität, vorherzusagen. Eine grundlegende Forderung an solche Methoden besteht in ihrer Anwendbarkeit auf das Schätzproblem.^[52] Dementsprechend müssen Ausschlusskriterien zu den Methoden ermittelt werden, die den Anwendungsbereich möglichst eindeutig abgrenzen. Das in der Literatur am häufigsten genannte Qualitätsmerkmal zur Charakterisierung der Aufwandsschätzung ist die Vorhersagegenauigkeit.^[53] Sie adressiert die Differenz zwischen dem geschätzten und den im Projekt realisiertem, gemessenen Entwicklungsaufwand. Für ihre Evaluierung stehen verschiedene Messmethoden zur Verfügung, welche in Kapitel3.3.2näher besprochen werden.^[54] Die Vorhersagegenauigkeit stellt damit ein Maß der Korrektheit einer Schätzung dar.^[55]

Die Schätzmethoden unterscheiden sich in ihrer Performanz hinsichtlich der Vorhersagegenauigkeit und dem zu betreibenden Aufwand zur Ermittlung eines Schätzwertes. Welche Qualität der Vorhersage als hinreichend angesehen wird, bestimmt nicht zuletzt der Projektmanager durch seine Zeit-, Ressourcen- und Produktplanung. Jede Schätzung des Entwicklungsaufwands bedarf eines spezifischen Schätzaufwands, um diese Schätzung zu ermitteln. Um die Genauigkeit einer Schätzung zu steigern, müssen im Allgemeinen mehr Ressourcen in die Ermittlung der Schätzung investiert werden.^[56] Dies erhöht unmittelbar den Schätzaufwand. Allerdings ist eine vollkommene Übereinstimmung zwischen dem Ergebnis einer Aufwandsschätzung und dem realisierten Entwicklungsaufwand in der Regel nicht zu erreichen.^[57] Die angestrebte Schätzgenauigkeit und die damit verbundene Auswahl der Schätzmethode lassen sich demnach als ökonomische Entscheidungen zwischen Aufwand und Nutzen innerhalb des Projekts interpretieren.

Zwischen den Schätzmethoden bestehen weitere Unterschiede insbesondere in ihrem Vorgehen, d.h. ihrer Schätzmetrik, und der Dimension ihrer Ergebniswerte. In ihrer Systematik berücksichtigen sie verschiedene Aspekte der zu schätzenden Entwicklungsleistung und gewichten diese zudem unterschiedlich. Die Informationsbasis auf der die Schätzung beruht, variiert deshalb von Methode zu Methode. Dabei können grob zwei Informationskategorien unterschieden werden, die in unterschiedlicher Intensität verwendet worden sind: Systemmodell oder Vergleichsmerkmale in Kombination mit Erfahrungswerten.

Hinzu tritt, dass die benötigten Informationen unter Umständen in unterschiedlichen Phasen eines Entwicklungsprojekts zur Verfügung stehen.^[58] Damit ergeben sich zwangsläufig Unterschiede in den Zeitpunkten ihrer Anwendbarkeit innerhalb eines Projekts.

Insgesamt bilden die Methoden auf diese Weise voneinander verschiedene Schwerpunkte, was faktisch zu einer Spezialisierung auf bestimmte Anwendungsbereiche führt.^[59] In der Literatur findet sich beispielsweise eine Trennung zwischen der Entwicklung von Web-Anwendungen, mobilen Anwendungen, Softwaresystemen und Software für eingebettete Systeme, was die Methodenspezialisierung zur Aufwandsermittlung anbelangt.^[60] Diese Spezialisierung äußert sich schließlich in unterschiedlichen Resultaten, die die Anwendung der Methoden auf ein und dasselbe Schätzproblem im Allgemeinen mit sich bringen.

Die Resultate können dabei nicht nur in ihrer Genauigkeit variieren, sondern auch in der Ergebnisdimension. In der Literatur finden sich im Wesentlichen zwei Dimensionskategorien: Entwicklungsumfang (Größe, Komplexität der zu entwickelnden Anforderung) und Entwicklungsaufwand (Ressourcenbedarf, Bedarf an Entwicklern und Entwicklungszeit).^[61] Auf der Basis von Erfahrungswerten und Faustformeln lassen sich die Dimensionen teilweise in einander überführen.^[62]

Mit den oben stehenden Erörterungen ergeben sich sieben grundsätzliche Merkmale, welche eine adäquate Aufwandsabschätzung näher charakterisieren können:

- grundsätzliche Anwendbarkeit der gewählten Methode auf das Schätzproblem
- geforderte Genauigkeit,
- maximal tolerierter Schätzaufwand,
- Informationsbasis
- Zeitpunkt der Schätzung im Projektplan,
- geforderte Spezialisierung der Schätzmethode sowie
- geforderte Dimension des Schätzergebnisses.

Die abgeleiteten Merkmale adäquater Schätzungen beziehen sich vornehmlich auf nicht-funktionale Aspekte einer Anforderungsbeschreibung. Lediglich die Merkmale ‚Informationsbasis‘ und ‚Spezialisierung‘ einer Methode richten sich nach funktionalen Kriterien.

Diese Merkmale gilt es im Rahmen eines Auswahlprozesses zur Identifizierung einer geeigneten Schätzmethode zu berücksichtigen. Sie bilden die Antwort auf Forschungsfrage I a und die in diesem Kapitel eingangs formulierte Frage iii. Ihre Implikationen in Bezug auf die Bestimmung relevanter Optimalitätskriterien sind dabei noch genauer zu erörtern. Kapitel5.1widmet sich intensiv diesem Themenfeld. Bei der nachfolgenden Betrachtung objektiver Schätzmethoden werden aus der Literatur entsprechend der sieben Merkmale die Eigenschaften für relevante Schätzer sowie deren prinzipielle Funktionsweise ermittelt.

3.3 Objektive Aufwandsschätzverfahren

Im Verständnis dieser Arbeit umfasst der Term „Objektive Aufwandsschätzer“ sämtliche Methoden zur Schätzung des Entwicklungsaufwands von Software, die ohne Erfahrungswissen von Entwicklern und Experten bei der Ermittlung von Schätzwerten auskommen.^[63] Empirische Daten aus Referenz- oder Vorgängerprojekten können hingegen sehr wohl Teil der Schätzmethode sein. In der Literatur werden für diese Methoden auch die Bezeichnungen „parametrische Schätzmodelle“, „algorithmische Schätzverfahren“ oder „modellbasierte Schätzmethoden“ verwendet.^[64] Der explizite Fokus auf die Erfahrungsfreiheit fehlt bei ihrer Präsentation meist, ist aber im Sinne dieser Arbeit ein prägnantes Merkmal.

Hummel kategorisiert die objektiven Aufwandsschätzer in algorithmische Kostenmodelle und analytische Modelle.^[65] Zu den ersteren zählt er unter anderem die bekannte Familie der Constructive Cost Models (COCOMO), begründet von Boehm,^[66] sowie die Analogiebetrachtung^[67]. Bei letzterer Methode werden aus Vergleichsbetrachtungen zwischen Erfahrungswerten und aktuellen Systemanforderung Analogieschlüsse bezüglich des Aufwands gezogen.^[68] Beispiele für analytische Modelle fügt er nicht an. Allerdings verweist er in diesem Zusammenhang auf deren geringe Verbreitung und der damit verbundenen ebenso geringen praktischen Relevanz.^[69]

Azhar unterscheidet zwischen algorithmischen Methoden und Methoden, die Techniken des Maschinellen Lernens (ML) verwenden.^[70] In der Literatur werden verschiedene ML-Techniken für die Aufwandsabschätzung angeführt: Artificial neural nets (ANNs), Bayes’sche Netzwerke (BN), Classification and Regression Trees (CART), Case-based Reasoning (CBR), Rule Induction (RI), Stochastic Gradient Boosting (SGB), verschiedene Konzepte zum Einsatz von Support Vector Machines (SVM) und schrittweise Regression (SWR).^[71] Auf die Eigenschaften dieser Methoden wird in diesem Kapitel weiter unten eingegangen. In der Literatur finden sich noch weitere, allgemeinere Einteilungsversuche, die sich unter die beiden dargestellten Varianten subsumieren lassen und nicht zu weiteren Erkenntnissen beitragen.^[72] Daneben existieren Methoden, die sich einer klaren Einteilung entziehen, da sie Kombinationen von Methoden aus verschiedenen Kategorien bilden. Dies gilt insbesondere für die Verwendung von ML-Techniken in Verbindung mit algorithmischen Kostenmodellen.^[73]

Der ursprüngliche Anwendungsbereich vieler Algorithmen-basierter Methoden liegt in der Abschätzung von Entwicklungsaufwänden von vollständigen Software-Projekten.^[74] In diesem Umstand liegt ein wesentlicher Kritikpunkt in Bezug auf die Anwendbarkeit dieser Methoden in agilen Entwicklungen.^[75] Agile Entwicklungen sind geprägt von kurzen, iterativen Entwicklungszyklen, bei denen ein Gesamtprojekt in handhabbare Entwicklungsaufgaben zerlegt wird, welche im Rahmen eines Sprints abgearbeitet werden können. Diese Teilentwicklungen sind am Anfang eines Projekts zumeist weder vollzählig noch vollständig spezifiziert.^[76] Ihre Abschätzung durch modell-basierte Methoden erscheint vor diesem Hintergrund nicht verhältnismäßig. Ob die Methoden dennoch Anknüpfungspunkte für eine adäquate Schätzung liefern oder sie per se auszuschließen sind, soll an dieser Stelle durch einen Blick auf ihr Vorgehen näher untersucht werden.

Das Vorgehen der modellbasierten Schätzmethoden ist häufig sehr ähnlich: zunächst wird von dem zu schätzenden Entwicklungsgegenstand ein Modell erstellt. Anschließend wird die modellierte Systemgröße ermittelt.^[77] Erfahrungsgemäß vereint dieser Schritt den höchsten Aufwand bei der Anwendung der Schätzmethode auf sich.^[78] Die Abschätzung des Entwicklungsaufwands erfolgt dann formelbasiert. Der Aufwand ist dabei eine Funktion von projekt- oder modellspezifischen Merkmalen (A), der Größe des zu messenden Projekts, einer Komplexitätspotenz B und zu berücksichtigender Kostentreiber (C). Die klassischen Schätzfunktionen folgen im Allgemeinen der in nachfolgenderGleichung 1gezeigten Form:

Gleichung 1 Allgemeine Form der Schätzfunktion.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Hummel, O. Aufwandsschätzungen, 2013, S. 68.

Als problematisch für die Anwendung in dieser Arbeit könnte sich die empirische Grundlage der algorithmischen Kostenmodelle erweisen. Ein Teil der Faktoren ihrer Schätzfunktionen basiert im Wesentlichen auf empirischen Erkenntnissen. So wurde eine Anzahl realer Projekte für Regressionsanalysen herangezogen, deren Ergebnisse schließlich in die Schätzfunktionen eingeflossen sind. Viele dieser Kostenmodelle wurden bereits in den 1970er und 1980er Jahren entwickelt und berücksichtigen dementsprechend Projekte und den Technologiestand dieser Zeit.^[79] Einige Methoden dieser Klasse haben eine Aktualisierung ihrer Schätzfunktionen erfahren. Dabei wurden moderne Projekte berücksichtigt, die auf aktuellen Soft- und Hardwaretechnologien beruhen. Methoden, die den aktuellen Stand der Technik nicht abbilden, kommen heutzutage nur noch als Konzeptvorlage in Betracht. Die empirisch ermittelten Koeffizienten der Schätzfunktion sind dabei in jedem Fall zu hinterfragen.

Ziel ist es, die erfahrungsfreien Schätzmodelle für Wasserfall-Projekte auch in agilen Projekten zur Ermittlung des Entwicklungsaufwands zu nutzen. Bei der Anwendung dieser Art von modellbasierten Schätzfunktionen in agilen Projekten werden in der Literatur zwei grundlegende Herausforderungen genannt:^[80] die Faktoren und Exponenten der Schätzunktionen

1. sind auf die Abschätzung von Gesamtprojekten skaliert und
2. benötigen umfassende Entwicklungsinformationen, welche sie traditionell aus einem detaillierten Systemmodell beziehen.

Die erstgenannte Herausforderung erfordert folglich eine geeignete Skalierung für die Faktoren zu ermitteln, damit diese auf einzelne Entwicklungsanforderungen angewandt werden können. Eine Übertragung der Faktoren auf agile Projekte ist nach Kenntnis des Autors in der Literatur bislang nicht besprochen worden. Da die Faktoren allerdings häufig aus Überlegungen zu kumulierten Aufwänden der einzelnen Entwicklungsanforderungen des Projekts resultieren, ist eine Lösung für einzelne Entwicklungsanforderungen bereits implizit enthalten. Eine Möglichkeit eine geeignete Skalierung der Faktoren zu erhalten, wird in Kapitel4vorgestellt.

Die zweitgenannte Herausforderung adressiert die Wertermittlung für die Faktoren der Schätzfunktion und die Systemgröße. Für die Anwendung ihrer Metriken benötigen die Modell-basierten Methoden mitunter vielfältige Informationen. Die Identifikation und Bewertung von Einflussfaktoren aus Projekt und Organisation sowie weiteren Bereichen ist ein reges Forschungsfeld, deren Erkenntnisse die objektiven Schätzmethoden unterschiedlich ausgeprägt berücksichtigen.^[81] Hinzu tritt der Umstand, dass die von einer Methode genutzten Faktoren zu Beginn eines Projektes (noch) nicht verfügbar sind oder sich während des Projekts verändern. Folglich führt ein Verzicht relevanter Eintragungen bei Größenbestimmung und Faktorermittlung zu einer sinkenden Genauigkeit in der Schätzung.^[82]

Eine in der Literatur ausgesprochene Empfehlung sieht eine projektspezifische Ermittlung dieser Koeffizienten unter Einbezug von im Projekt anfallenden Erfahrungswerten vor.^[83] Aufgrund statistischer Gegebenheiten kann dieses Vorgehen allein, zumindest am Projektanfang, nicht zu validen Schätzergebnissen führen. Mit zunehmender Projektdauer und einem damit einhergehenden Anwachsen von Erfahrungswerten, kann auf diese Weise eine Projektspezifizierung der Schätzmethode erreicht werden.

An dieser Stelle setzen aktuelle Konzepte an, die Algorithmen aus dem Maschinellen Lernen in bestehende Modelle integrieren, um Entwicklungsaufwände zu schätzen.^[84] Zur Ermittlung des Entwicklungsaufwands analysieren sie Daten vergangener Projekte (des eigenen Unternehmens) und Referenzprojekte, um daraus per Analogieschluss Erkenntnisse zum zu schätzenden Projekt zu ziehen.

Einige Studien berichten in diesem Zusammenhang von einem erfolgreichen Einsatz von Bayes‘schen Netzwerken zur Empirie-basierten Abschätzung von Entwicklungsaufwänden in agilen Projekten.^[85] Wie alle ML-Techniken, ist diese zudem lernfähig. Sie verwendet Ergebnisdatensätze aus Referenzprojekten und, sobald verfügbar, aus dem aktuellen Projekt, um die Eintrittswahrscheinlichkeit bestimmter Zustände und damit verbundener Aufwände aktualisiert zu ermitteln.^[86]

Allerdings ist der Einsatz von ML-Methoden zur Vorhersage von Schätzaufwänden nicht unumstritten. Die Kritik richtet sich vornehmlich gegen die Verwendung alter, nicht relevanter Daten­sätze zum Training der Algorithmen und einer Überanpassung der Algorithmen auf die Datensätze. Dies mindert einerseits die Robustheit der Algorithmen, im Sinne ihres Verhaltens bei der Anwendung auf Datensätze, die ähnlich den Trainingsdaten sind.^[87] Andererseits verhindert die Überanpassung eine valide Vergleichbarkeit zwischen Algorithmen hinsichtlich ihrer Vorhersagegenauigkeit.^[88]

Können die Faktoren der Schätzfunktionen an die Gegebenheiten agiler Projekte und damit einhergehend zu schätzender Entwicklungsanforderungen angepasst werden, ist die Anwendung Algorithmen-basierter Methoden in diesem Bereich möglich. Die Ergänzung der Methoden um Techniken des Maschinellen Lernens zur Implementierung von objektiven Erfahrungswerten kann dabei die Schätzergebnisse verbessern und gleichzeitig den Schätzaufwand verringern.

Im Folgenden werden in der Literatur beschriebene Metriken zur Ermittlung der Software-Größe vorgestellt. Ihnen schließt eine Übersicht von Methoden an, die Entwicklungsaufwände aus der gemessenen (Modell-)Größe ableiten. Sie werden anhand der in Kapitel3.1erarbeiteten Merkmalskategorien charakterisiert, soweit diese Merkmale aus der Literatur ersichtlich sind.

3.3.1 Metriken zur Größenbestimmung

Die Metriken zur Bestimmung der Systemgröße haben generell großen Einfluss auf das finale Schätzergebnis.^[89] Die Größenbestimmung erfolgt üblicherweise über dimensionsbehaftete, abzählbare Kennzahlen, wie Lines of Code (LOC; zu Deutsch: Code-Zeilen) oder über funktionsbasierte Kriterien. Die Bestimmung über LOCs ist dabei vorherrschend in der Praxis.^[90] Die LOC der zu schätzenden Entwicklung werden per Analogieschluss abgeleitet aus der Vermessung vorhandener Software, welche als Referenz herangezogen wird. Dabei hängt ihr Wert wesentlich von der eingesetzten Programmiersprache und der Qualität der Entwicklungsarbeit ab. Der konkrete Wert steht zudem erst im Anschluss an die Umsetzung eines Projekts, bzw. bei Vorhandensein geeigneter Referenzsoftware zur Verfügung. Die Nutzung dieser Kennzahl ist aus diesen Gründen fortwährend Gegenstand eines wissenschaftlichen Diskurses in der Literatur.^[91]

Die funktionsbasierten Kriterien sind hingegen analytisch geprägt. Sie verwenden Erkenntnisse aus dem zugrundeliegenden Systemmodell des zu entwickelnden (Teil-)Projekts. Dabei reflektieren sie die ermittelten Werte zu benötigten Systemteilen, wie Datenbanktabellen, Reports, Benutzerschnittstellen, Geschäftsprozesse, Entitäten und Utilities.^[92] Die manuelle Bestimmung dieser Werte aus dem Modell ist generell fehleranfällig. Eine Reihe von Studien untersucht daher Möglichkeiten, die Modellauswertung unter Nutzung geeigneter Modellierungssprachen, wie der weit verbreiteten Unified Modeling Language (UML), zu automatisieren.^[93]

Zu den funktionsbasierten Kriterien zählt Hummel die Function Points nach Albrecht (FP), Use Case Points (UCP), Story Points (SP), Mark II Points (MII-P), COSMIC (full) Function Points (C(F)FPs), The Dutch Method und Object Points (OPs).^[94] Usman et al. ermitteln in ihrer Studie mit der Anzahl und der Länge von User Stories noch zwei weitere Kriterien.^[95] Alle Metriken haben bereits Weiterentwicklungen und Modifikationen erfahren, um sie an aktuelle technische Entwicklungen und spezielle Projektsachverhalte anzupassen oder schlicht ihre Messgenauigkeit zu erhöhen.^[96] Über geeignete Konversionsfunktionen lassen sich die Messwerteinheiten auch in einander überführen.^[97] Mit der Function Point Analysis (FPA) ist zudem eine Metrik zur Bestimmung der Systemgröße (FP) weiterentwickelt worden zu einer eigenständigen Aufwandsschätzmethode.^[98]

Anwendungszeitpunkt und Zählaufwand sind Metrik-spezifisch.^[99] Ihre Verwendung innerhalb der Schätzmethoden beeinflusst deshalb wesentlich deren frühestmöglichen Einsatzzeitpunkt und Schätzaufwand.^[100] Die Merkmale Schätzaufwand und Einsatzzeitpunkt der Aufwandsschätzer werden deshalb in den von Hummel (2013) vorgeschlagenen Wertebereichen für die Schätzmetriken zur Größenbestimmung ermittelt.^[101]

3.3.2 Objektive Aufwandsschätzer

Wie in Kapitel3.3herausgearbeitet, bietet sich eine Einteilung der objektiven Aufwandsschätzer in klassische, algorithmische Kostenmodelle und Techniken des Maschinellen Lernens an. In der Literatur lassen sich auch Kombinationen von Methoden beider Kategorien finden, um die Vorhersagegenauigkeit zu erhöhen.^[102] Sie werden an dieser Stelle aber nicht gesondert aufgeführt.

Die betrachteten sieben Merkmalskategorien entsprechen den in Kapitel3.2herausgearbeiteten Merkmalen adäquater Aufwandsschätzung. Erläuterungen zu den Merkmalen sowie ihr jeweiliger Wertebereiche und die Skala der Merkmalsausprägung sind inTabelle 1festgehalten.

Tabelle 1 Wertebereiche der Merkmale.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung nach Inhalten von Hummel, O., Aufwandsschätzung in der, 2013, S. 120.

Das Merkmal Anwendbarkeit stellt ein generelles Auswahlkriterium für die Berücksichtigung von Schätzmethoden im Auswahlprozess dar. Die sechs weiteren Methodenmerkmale weisen untereinander Interdependenzen auf, wie inAbbildung 4gezeigt. Ein Pfeil zwischen zwei Elementen repräsentiert ein Abhängigkeitsverhältnis. Das Pfeilende zeigt dabei auf das abhängige Element. Die Spezialisierung steht als Quelle ganz oben im Bild. Sie ergibt sich aus der konkret zu schätzenden Entwicklungsanforderung. Anders als beim Merkmal Anwendbarkeit stellt die Spezialisierung keine notwendige Bedingung für die Verwendung einer Methode dar. Methoden können auch angewandt werden, wenn sie nicht über die Spezialisierung verfügen, die durch die Entwicklungsanforderung nahegelegt wird.

Aus der Abbildung geht weiterhin hervor, dass die Spezialisierung die Schätzmetrik beeinflusst, welche wiederum die benötigten Informationen sowie die möglichen Ergebnisdimensionen bestimmt. Da eine Methode erst eingesetzt werden kann, wenn die erforderlichen Informationen für deren Anwendung bereitstehen, bestimmt der Informationsbedarf den frühestmöglichen Einsatzzeitpunkt der Methode im Projektrahmen. Schätzaufwand und -genauigkeit sind zum einen ebenfalls abhängig von den Informationen, die für die Schätzung ermittelt werden müssen. Dabei ist die Betrachtung nicht auf quantitative Aspekte limitiert. Sie schließt insbesondere die Diskussion um die relevanten Aufwands- und Kostentreiber mit ein, welche in der Literatur geführt wird. Zwischen beiden besteht zum anderen ein bidirektionaler Pfeil. Dieser deutet den bereits angesprochenen Zusammenhang zwischen den beiden Merkmalen an: in einem methodenspezifischen Maß lässt sich eine höhere Genauigkeit mit größerem Schätzaufwand erreichen. Der Umkehrschluss ist innerhalb dieses Rahmens ebenfalls zulässig.

Abbildung 4 Merkmalsabhängigkeiten bei Schätzmethoden.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Üblicherweise wird die Genauigkeit von Schätzwerten mit Metriken ermittelt. Der mittlere Betrag des relativen Fehlers und als relative Häufigkeit von Beobachtungen, deren Betrag des relativen Fehlers () unter einer Fehlerschranke liegen, sind in der Literatur am häufigsten anzutreffen.^[103] Insbesondere unterliegt einer fundamentalen Kritik, bei der die Geeignetheit als Maß für die Vorhersagegenauigkeit bezweifelt wird.^[104] Da diese Metrik allerdings in der referenzierten Literatur als einzige durchgängig verwendet wird, bietet sie in diesem Aspekt die einzige Vergleichsmöglichkeit zwischen den Studien. Sie wird aus diesem Grund, trotz der möglicherweise bestehenden Unzulänglichkeiten, weiter verwendet. Die Bildungsvorschriften für und sind in den nachfolgenden beiden Gleichungen festgehalten.

Gleichung 2 MMRE.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Conte, S. D., et al., Software engineering metrics, 1986, S. 172.

repräsentiert dabei den Betrag des relativen Fehlers. Variable gibt dabei den tatsächlich realisierten Aufwand und Variable den geschätzten Aufwand in Entwicklung wieder.

Gleichung 3 Pred(l).

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Conte, S. D., et al., Software engineering metrics, 1986, S. 173.

Die Formel gibt dabei die Anzahl an Beobachtungen an, bei denen der kleiner oder gleich der Fehlerschranke ist, im Vergleich zur Gesamtzahl an Beobachtungen . Die Fehlerschranke wird in diesem Zusammenhang häufig als relative Fehlerschranke und damit in der gleichen Dimension wie angegeben. In der Literatur wird ein Vorhersagemodell üblicherweise als gut eingeschätzt, sobald sein bzw. sein ist.^[105]

Die Einteilung der Genauigkeit in ‚niedrig‘, ‚mittel‘ und ‚hoch‘ auf einer Ordinalskala erfolgt über den Vergleich der MMRE-Werte der verfügbaren Methoden nach folgendem Schema:

Sei die Menge aller MMRE-Werte aus den Studien der hier besprochenen ML-Techniken und der MMRE-Wert der -ten ML-Technik. Dann wird die Skalentransformation der Werte wie folgt durchgeführt:

1. Der Wertebereich der MMRE-Werte wird in drei gleichgroße Bereiche geteilt: ein Intervall hat demnach die Größe für alle .
2. MMRE-Werte die im Intervall liegen, erhalten den Wert ‚hoch‘ auf der Ordinalskala.
3. MMRE-Werte die im Intervall ] liegen, erhalten den Wert ‚mittel‘ auf der Ordinalskala.
4. MMRE-Werte die im Intervall ] liegen, erhalten den Wert ‚gering‘ auf der Ordinalskala.

Zusätzlich zu den Werten der ordinal-skalierten Genauigkeit sind bei den Methoden die MMRE- und Pred(25)-Werte angegeben, sofern aus der Literatur entnehmbar.

3.3.2.1 Algorithmische Kostenmodelle

Alle nachfolgend präsentierten Kostenmodelle benötigen ein umfassendes Systemmodell, anhand dessen die Faktoren abgeleitet werden.

Die Eigenschaften der COCOMO-Familie sind inTabelle 6vorgestellt. COCOMO findet traditionell Anwendung in Wasserfall-Projekten.^[106] Die Modifikation COCOMO II ist für Projekte unter 2000 LOC schlecht kalibrierbar.^[107] Für kleine Projekte (<5000 LOC) existieren keine in der Literatur besprochenen Erfahrungswerte für die Faktoren und Exponenten der Schätzfunktion.^[108]

Tabelle 2 Merkmale der COCOMO-Familie.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung mit Werten aus Hummel, O., Aufwandsschätzung in der Software-, 2013, S. 71, 72, 78, 79 f., 121.

Eine moderne Objekt-orientierte Methode dieser Kategorie ist das UML-basierte Web Engineering (UWE).^[109] Vom zu schätzenden System wird dazu auf der Basis von UML ein Modell erstellt, welches verschiedene Aspekte, wie Use Case, Content, Navigation und Prozess berücksichtigt. Anschließend wird die Größe des Modells, z.B. mit der Metrik CFP ermittelt. Der Aufwand wird dann unter Berücksichtigung von Daten aus Referenzprojekten per Regression geschätzt.Tabelle 3zeigt die Werte zu den Merkmalen dieser Methode.

Tabelle 3 Merkmale der Methode UWE.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung mit Werten aus Ceke, D. und Milasinovic, B., Early effort estimation, 2015, S. 221, 228, 234.

Eine Methode, die eine hohe Verbreitung in subjektiven, wie objektiven Schätzmethoden genießt, ist die Analogieschätzung (Tabelle 4). Voraussetzung für ihre Anwendung ist die Zugriffsmöglichkeit auf geeignete Erfahrungswerte von Entwicklungen bezüglich Größe und Entwicklungsaufwand.^[110] Die Erfahrungswerte müssen der zu schätzenden Entwicklung so weit ähneln, dass eine Vergleichsschätzung statthaft ist. Anderenfalls droht die Schätzung durch nicht berücksichtigte Ähnlichkeitsattribute beliebig von der Realität abzuweichen.^[111] Die Auswahl geeigneter Vergleichsmerkmale wird deshalb in der Literatur intensiv diskutiert.^[112] Sie beeinflussen wesentlich Schätzaufwand und Genauigkeit. Sind Erfahrungswerte vorhanden, kann in Kombination mit der ermittelten Größe der zu schätzenden Entwicklung eine Dreisatz-Rechnung vorgenommen werden.^[113] Das Ergebnis dieser Rechnung stellt schließlich die Aufwandsschätzung dar.^[114]

Tabelle 4 Merkmale der Methode Analogieschätzung.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung mit Werten aus Hummel, O., Aufwandsschätzung in der Software-, 2013, S. 24.

3.3.2.2 Techniken des Maschinellen Lernens

Die nachfolgend ausgewählten Methoden repräsentieren laut der referenzierten Literatur die wesentlichen Vertreter des Maschinellen Lernens. Ihre Merkmalswerte sind der Literatur entnommen und inTabelle 5undTabelle 6festgehalten. Insbesondere die Werte zur Genauigkeit sind dabei vor dem Hintergrund der weiter oben angesprochenen Problematik der Überanpassung von ML-Algorithmen mit Vorsicht zu bewerten. Das Vorhandensein eines geeigneten Validierungsdatensatzes in der referenzierten Studie erhöht dabei regelmäßig das Vertrauen in die angegebenen Werte. Dieses Kriterium wird daher als Voraussetzung für die Aufnahme des Wertes in die vorliegende Betrachtung gewählt.

Andererseits weisen die Genauigkeitswerte, je nach Studie, eine große Streuung auf. Dies machen insbesondere die Sekundärstudien deutlich.^[115] Begründungen für diesen Umstand sind vielschichtig, hängen aber zumeist mit der Parameterauswahl des Algorithmus oder mit der Größe und dem Informationsgehalt des Referenzdatensatzes zusammen.^[116] Um den aktuellen Stand der Forschung im Bereich der ML-Techniken zu erfassen, werden deshalb nach Verfügbarkeit Werte aktueller Studien angegeben. Die Skalentransformation des Merkmals gem. dem eingangs in Kapitel3.3.2beschriebenen Schema ergibt für die Angaben aus der Literatur folgende Einteilung:

Zum Schätzaufwand bei der Anwendung der Methoden existieren wenige Erkenntnisse in der Literatur. Mair et al. haben den Aufwand für ANN, CBR und RI verglichen.^[117] Radlinski weist auf die zeitaufwändige Berücksichtigung von Expertenwissen bei der Erstellung von BN, auch wenn er den Aufwand nicht quantifiziert. Bei der Ableitung eines BN nur aus empirischen Daten sei dieser nicht nötig, führt aber mutmaßlich zu einem Modell niedrigerer Übereinstimmung mit der Realität.^[118] Diese Angaben führen zur unspezifischen Eintragung ‚niedrig bis hoch‘ unter dem Aufwandsmerkmal inTabelle 5. Bei anderen Techniken können mangels Referenzen überhaupt keine Werte für den Aufwand angegeben werden. Es ist trotzdem davon auszugehen, dass sie im Vergleich zu den algorithmischen Kostenmodellen deutlich niedriger liegen, da kein detailliertes Systemmodell erstellt werden muss, aus dem die Größe aufwendig abzuleiten ist.

Die Funktionsweise der ML-Techniken basiert im Wesentlichen auf der Auswertung historischer Projektdaten. Dabei stellen die Techniken verschiedene Ansprüche an die Qualität des Datensatzes.^[119] Die Auswertung erfolgt Computer-gestützt mithilfe technikimmanenter Analysealgorithmen, die wiederum verschiedene Vorhersagemodelle abbilden.^[120] Hierin liegt die Begründung für ihre flexible Anwendbarkeit zu einem allgemein frühen Einsatzzeitpunkt. Sobald Informationen zum zu entwickelnden System (als Muster) verfügbar sind, kann in den Referenzdaten nach ähnlichen Mustern gesucht werden.

Aus den Eintragungen ist ersichtlich, dass die ML-Techniken über keine besondere Spezialisierung in Bezug auf ihren Anwendungsbereich verfügen. Dieser wird vielmehr definiert durch den Referenz-Datensatz, was eine Spezialisierung auf praktisch jede Anwendung ermöglicht.

Tabelle 5 Merkmale der ML-Techniken (1/2).

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung mit Werten aus Mair, C. et al., An investigation of machine, 2000, S. 26, 28, Satapathy, S. M., et al., Effort estimation on web-based, 2016, S. 978, 979, Mendes, E., A Comparison of Techniques, 2007, S. 341 and Radlinski, L., A survey of bayesian, 2010, S. 106.

Ähnliches kann für die Dimension festgestellt werden. Analysiert werden die Zusammenhänge in den Daten in der Form, wie die Daten vorliegen. Dabei ist das Vorgehen der Methode unabhängig von der Dimension der Ergebnisdaten. Lediglich eine Mischung zwischen den Dimensionen Kosten / Aufwand ist auszuschließen, um eine valide Schätzung zu garantieren. Dies kann durch eine geeignete Umwandlung der Daten von einer Dimension in die andere erreicht werden. Für die Umwandlung bestehen allgemeine Erfahrungswerte.^[121] Alternativ können wieder Daten von Referenzprojekten herangezogen werden, sofern diese für beide Dimensionen existieren, um eine Umwandlung durch Regression oder ML-Techniken zu erreichen.^[122]

Tabelle 6 Merkmale der ML-Techniken (2/2).

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung mit Werten aus Mair, C. et al., An investigation of machine, 2000, S. 26, 28, Satapathy, S. M., et al., Effort estimation on web-based, 2016, S. 978, 979, Mendes, E., A Comparison of Techniques, 2007, S. 341.

Insgesamt sollte den Angaben zum Schätzaufwand kein großes Vertrauen geschenkt werden, da diese nicht aus einem Vergleich aller Methoden resultieren, sondern aus verschiedenen Quellen stammen, die ihre Angaben teilweise nicht begründet haben. Ein objektives Maß, auf welches die Angaben zum Schätzaufwand zurückgeführt werden können, ist in keinem Fall angegeben worden. So entstammen die Angaben zu den algorithmischen Aufwandsschätzern der COCOMO-Familie zwar aus einem Kontext, aber die Ermittlung der Werte bleibt unerklärt.^[123] Ähnlich verhält es sich mit den Angaben zu den ML-Techniken ANN, CBR und RI.^[124] Ein Vergleich der Aufwände bei der Anwendung algorithmischer Modelle mit den Aufwänden bei der Anwendung von ML-Techniken findet sich in der Literatur nicht und darf deshalb nicht aus den hier getätigten Angaben abgeleitet werden.

Die Angaben werden, aus Mangel an Alternativen, dennoch zur Initialisierung des Auswahlalgorithmus (Kapitel5.5) verwendet. Dabei werden sie aber durch Erfahrungswerte sukzessive aktualisiert. Mit der obigen Betrachtung der objektiven Schätzmethoden sind abschließend Forschungsfragen I b und I c, sowie die in diesem Kapitel eingangs formulierten Fragen iv und v beantwortet.

3.4 Auswahl einer Schätzmethode

Die Auswahl einer geeigneten Methode zur Abschätzung des Entwicklungsaufwands in Projekten stellt in der Literatur bislang ein offenes Untersuchungsfeld dar.^[125] Resmi et al. führen als Problem bei der Auswahl einer geeigneten Schätzmethode auf der Basis historischer Informationen die inhärente Vielschichtigkeit der einbezogenen Merkmalsattribute an.^[126] Dennoch existieren Ansätze, welche den Auswahlprozess unterstützen können. Sie werden im Folgenden besprochen.

Sharma et al. plädieren dafür, mehrere Schätzmethoden zu nutzen und die Ergebnisse hinsichtlich ihrer Konvergenz zu untersuchen.^[127] Dieser Ansatz ist zumindest im akademischen Bereich naheliegend, sofern Ressourcen und Schätzaufwand im Projekt eine untergeordnete Rolle spielen. Allerdings erscheint die Berücksichtigung und parallele Nutzung aller (dem Anwender) bekannten Methoden weder realistisch noch pragmatisch. Entsprechend bedarf es einer geeigneten Methodenauswahl, die es zu unterstützen gilt.

In der Literatur finden sich mehrere komparative Studien, die Schätzmethoden, teils aus einer Methodenklasse, hinsichtlich ihrer Anwendung auf unterschiedlichste Entwicklungsprojekte untersuchen.^[128] Studien aus den beginnenden 2000er Jahren haben einige Richtlinien erarbeitet, wie die betrachteten Methoden einer bestimmten Klasse vor dem Hintergrund konkreter Schätzprobleme ausgewählt werden können.^[129] Sie überschneiden sich mit den in Kapitel3.1erarbeiteten Merkmalen adäquater Aufwandsschätzer, wonach die Schätzer kategorisiert werden können. Hinzu treten klassenspezifische Merkmale, wie z.B. die Konfigurierbarkeit neuronaler Netze unter den eingesetzten Methoden und Projektbedingungen.^[130] Insofern tragen sie keine neuen Erkenntnisse zur Fragestellung bei, aber unterstreichen die Relevanz der identifizierten Merkmale. Die in Kapitel3.1erarbeiteten Merkmale bilden damit die Antwort auf Forschungsfrage I a.

Adnan et al. schlagen ein Ontologie-basiertes Schätzverfahren für agile Entwicklungen vor. Dabei wird eine Projektontologie angelegt, um die relevanten Schätzinformationen zu strukturieren und für die Schätzung transparent aufzubereiten. Ihre Schätzung beruht schließlich wieder auf subjektiven Erfahrungswerten.^[131]

Allerdings kann dieser Ansatz helfen, alle relevanten Informationen für die verschiedenen Schätzmethoden automatisiert verfügbar zu machen. Dieser Aspekt liegt allerdings nur am Rande der in dieser Arbeit betrachteten Aufgabenstellung und wird deshalb nicht intensiver verfolgt. Er wird im Zusammenhang mit der Konzeption der Erfahrungswert-Datenbank in Kapitel5.5kurz diskutiert.

Celar et al. präsentieren in ihrer Studie einen evolutionären Ansatz zur Schätzung des Aufwandes in agilen Entwicklungen. Im Wesentlichen beschreiben sie, wie ein Repositorium aufzubauen ist, in dem schätzrelevante Daten vergangener Projekte Eingang finden und wie die Informationen schließlich wieder für die Schätzung genutzt werden können. Interessant für die vorliegende Aufgabenstellung sind dabei besonders die beiden nachfolgend besprochenen Punkte.

Zum einen kategorisieren die Autoren die Entwicklungsobjekte (als schätzrelevante Daten) auf Komponentenbasis in den Dimensionen Typ (Modul / Report), [Entwicklungs-]Komplexität, und Entwicklung (neu / vorhanden). Dies ermöglicht feingranulierte Analogiebetrachtungen. Zum anderen beruht ihr Ansatz auf einem 3-Phasenmodell, bestehend aus Datenerhebung, -verarbeitung und -validierung. Diese Phasen sind bei der Konzeption eines Auswahlprozesses, welcher kontinuierlich Erfahrungswerte in Projekten erfasst und wiederverwendet, relevant.^[132]

Ein Konzept, wann und wie Erfahrungswerte Eingang in die Auswahl einer geeigneten Schätzmethode in einer klassenübergreifenden Betrachtung finden können, existiert in der Literatur bislang allerdings nicht.^[133] Diese Betrachtung bildet die Antwort auf die in diesem Kapitel eingangs formulierte Frage vi. In Kapitel5dieser Arbeit wird zu diesem Aspekt ein Vorschlag vorgestellt.

3.5 Kontrolle und Optimierung in agilen SE-Projekten

3.5.1 Grundlagen des IT-Projektmanagements

Projekte sind im Allgemeinen charakterisiert durch ihre zeitliche und ressourcentechnische Begrenztheit, ihre Einmaligkeit und ihre Zielgerichtetheit.^[134] Sie verfügen zumeist über einen eigenen Organisationsrahmen.^[135] In SE-Projekten ist die Zielgerichtetheit konkretisiert durch die (Weiter-)Entwicklung von Software Engineering-Produkten. Die Lehre unterscheidet verschiedene Projektphasen, welche jeweils durch eigene Aufgaben und entsprechende Maßnahmen des Projektmanagements (PM) charakterisiert sind: Projektentstehung (inklusive Projektdefinition), Projektdurchführung und Projektabschluss.^[136]

Neben dem Projektmodell sind für SE-Projekte noch das Modell des Produktlebenszyklus (PLC) und das Modell des Softwarelebenszyklus (SLC) erwähnenswert. Dabei wird die zu erstellende Software als Produkt interpretiert und kann damit in das PLC-Management eines Unternehmens aufgenommen werden. Die Erstellung einer Software (als Teil des SLC) kann wiederum im Rahmen eines Projektes erfolgen.

Auch das PLC- und das SLC-Modell definieren Phasen. Diese können mit den einzelnen Phasen des Projektlebenszyklusmodells verknüpft werden.^[137] Eine bestehende Unschärfe in der Zuordnung der dabei vorgesehenen Aufgaben ist allerdings zu berücksichtigen. Auf die allgemeinen Phasen der Modelle soll an dieser Stelle nicht näher eingegangen werden, da sie für das Ziel dieser Arbeit eine untergeordnete Rolle spielen. Einzig die Entwicklungsphase aus dem SLC-Modell ist herauszuheben, welche der Phase der Projektdurchführung zugeordnet werden kann.^[138]

In der Praxis haben sich für die Entwicklungsphase zwei Vorgehensmodelle etabliert: das Wasserfallmodell und das agile Modell (Abbildung 5). Die beiden Modelle unterscheiden sich wesentlich in ihrem Vorgehen. Beim Vorgehen nach dem Wasserfallmodell werden sämtliche Anforderungen an das Produkt vor der Entwicklung in Form von Lasten- und Pflichtenheften definiert und spezifiziert. Der Entwicklungsfokus ist damit fix. Variabel gestalten sich Termine und Kosten, in Abhängigkeit der Entwicklungsgeschwindigkeit. Anforderungen zu ändern oder zu ergänzen erfordert allgemein Nachverhandlungen zwischen den Vertragspartnern.

Abbildung 5 Abgrenzung Vorgehensmodelle IT-Projektmanagement.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Opelt et al., Der agile Festpreis, 2014.^[139]

Agile SE-Projekte sind hingegen gekennzeichnet durch ihr agiles Entwicklungsvorgehen. Je nach Vertragsgestaltung, können dabei Termine und Kosten zu Projektbeginn festgelegt sein. Entwicklungsleistung und -umfang wird allerdings den Projektgegebenheiten (z.B. der tatsächlichen Entwicklungsgeschwindigkeit) angepasst. Bei diesem Vorgehen müssen Anforderungen am Anfang einer Entwicklung nicht vollständig definiert und spezifiziert sein. Änderungen können flexibel berücksichtigt werden. Allerdings ist das Ergebnis der Entwicklung zu Beginn des Projekts schlechter prognostizierbar als im Wasserfallmodell.

Die Herausforderung für das Management agiler SE-Projekte besteht folglich in der Gestaltung einer zielgerichteten Softwareentwicklung unter Einhaltung der Rahmenbedingungen. Dafür ist seitens der Lehre eine Reihe von Managementaufgaben vorgesehen, welche wiederholt auftreten und sich gegenseitig bedingen.^[140] Sie werden häufig in Form eines Projektmanagementzyklus dargestellt (Abbildung 6). Der Projektmanagementzyklus ist dabei zu interpretieren als Regelkreis von Aufgaben, die während der Projektdurchführung durch das Management ununterbrochen zu betreiben sind.

Abbildung 6 Projektmanagementzyklus.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Broy et al., Projektorganisation und Management, 2013, S. 10.

Eine im Projektrahmen regelmäßig wahrzunehmende Hauptaufgabe ist die Kontrolle. Im Managementzyklus wird sie flankiert von der Planung und der Steuerung, wie in Abbildung 6 gezeigt.^[141] Die Elemente des Regelkreises sind durch diese drei Aufgaben keinesfalls erschöpft. Andere Projektmanagement-Methoden erweitern die Darstellung um verschiedene Aspekte. So kennt die im Projektmanagement arrivierte PRINCE2-Methode beispielsweise noch die Delegierung als eigenständige Aufgabe.^[142] Für die Betrachtung in dieser Arbeit reicht die Darstellung in Abbildung 6 aber vollkommen aus und wird deshalb in dieser Form weiterverwendet.

3.5.2 Kontroll- und Optimierungsmöglichkeiten

Kontrolle in SE-Projekten meint die regelmäßige Überwachung der Entwicklungsleistung und des damit einhergehenden Ressourcenverbrauchs. Valentini et al. unterscheiden hierbei zwischen der Fortschrittskontrolle und der Kostenkontrolle.^[143] Broy et al. ergänzen die Änderungs- und Qualitätskontrolle.^[144] Für die Kontrolle der jeweiligen Aspekte wurden unterschiedliche Werkzeuge entwickelt, die einen Projektmanager bei der Wahrnehmung seiner damit verbundenen Aufgaben unterstützen können.

Eine Kontrolle erfolgt gemeinhin über den Abgleich zwischen Erwartungswerten (Soll) und realisierten Werten (Ist). Diese Beschreibung schließt Kennzahlsysteme mit ein. In Abhängigkeit des Differenzwertes kann das Management Maßnahmen angepasster Intensität ergreifen, mit dem Ziel, zukünftige Differenzen zu minimieren. Sie werden gemeinhin der Phase der Projektsteuerung zugeordnet.^[145] Durch Kontrollen induzierte Maßnahmen stellen deshalb immer Reaktionen auf Projektgegebenheiten dar.

Diese Maßnahmen lassen sich unter dem Oberbegriff ‚Optimierung‘ fassen, ohne ihn erschöpfend zu beschreiben.^[146] Optimierung in diesem Zusammenhang bezieht sich auf die Verbesserung des Verhältnisses zwischen Entwicklungsleistung und Ressourcenverbrauchs durch geeignete Maßnahmen.^[147] Die damit verbundenen Aufgaben können nicht nur reaktiv, sondern auch proaktiv und antizipierend angelegt sein.

Bezogen auf das in dieser Arbeit skizzierte Grundproblem ist der Aufwand jeder Teilentwicklung im Projekt zu kontrollieren. Dabei geht die ex ante aufgenommene Aufwandsschätzung als Soll-Wert und der ex post realisierte Aufwand als Ist-Wert in die Betrachtung ein. Geeignete Werkzeuge für diese Kontrolle sind in Kapitel3.3besprochen worden. Die Differenz, die auf diese Weise ermittelt wurde, bietet anschließend Ansätze zur Optimierung.

Maßnahmen zur Optimierung können in diesem Zusammenhang auf zwei Aspekte abzielen. Der erste Aspekt behandelt den tatsächlichen, realen Entwicklungsaufwand. Geeignete Managementmethoden konzentrieren sich in diesem Fall auf Produktivität und Qualität der Umsetzung und aller damit verbundenen organisatorischen und personellen Bereiche. Beispiele hierfür finden sich im Fehlermanagement, im Risikomanagement und im Qualitätsmanagement. Hierzu zählt explizit auch die Schätzer-unterstütze Befüllung des Selected Backlog, welches die Entwicklerkapazitäten optimal auszunutzen versucht. Ein weiterer klassischer Bereich, der diese Ziele beeinflusst, stellt die Personalmotivation dar. Diese Maßnahmen sind hochrelevant für den Erfolg eines Projekts, befinden sich allerdings nicht im Fokus der Betrachtung dieser Arbeit. Sie werden aus diesem Grund nicht näher betrachtet.

Der zweite Aspekt bei der Optimierung besteht in der Verbesserung der Schätzung des Entwicklungsaufwands entlang den in Kapitel3.1herausgearbeiteten Merkmalen. Die Hauptforschungsrichtung in der Literatur zielt hierbei auf eine konsequente Weiterentwicklung existierender Schätzmethoden ab. Die Methoden werden dabei verfeinert durch Kombination mit Maschinellen Lern-Techniken. Diese Techniken ermöglichen die Ableitung von Trends aus großen, komplexen Datenmengen durch geeignete Analyseverfahren. Die Bestimmung der Ähnlichkeit zwischen dem zu schätzenden Objekt und der berücksichtigten Referenzdaten spielt bei diesen Verfahren eine tragende Rolle. Einige in diesem Bereich durchgeführte Studien belegen insgesamt eine Verbesserung der Schätzung im Vergleich zu klassischen Methoden, wie den algorithmischen Kostenmodellen.^[148]

Wenig erforscht ist der Auswahlprozess einer geeigneten Schätzmethode.^[149] Dieser liegt zeitlich vor der Schätzer-Anwendung. Die wissenschaftliche Literatur hat den Mangel an Methoden zur Auswahl geeigneter Schätzer bereits moniert.^[150] Weitere Optimierungsmöglichkeiten, welche die hier aufgezeigten Ansätze ergänzen könnten, wurden in der Literatur nicht identifiziert.

Die hier dargelegten Erkenntnisse aus der Literatur zu Kontroll- und Optimierungsmöglichkeiten in agilen SE-Projekten bilden die Antwort auf die eingangs in diesem Kapitel formulierten Fragen vii und viii. Lösungsansätze, welche den Auswahlprozess unterstützen könnten, sehen durchweg die Nutzung projektbezogener (empirischer) Informationen vor.^[151] Hierzu zählen insbesondere Projekt-, Produkt- und Softwaremerkmale, sowie historische Daten vergleichbarer Projekte. Aus diesem Grund soll auf die Literatur zu Aufbau und Verwendung einer geeigneten Projekt-Informationsbasis im Folgenden näher eingegangen werden. Diese Betrachtung dient gleichzeitig der Vorbereitung zur Beantwortung von Forschungsfrage I e und I f.

3.5.3 Erfassung von Erfahrungswerten in Projekten

Im Verständnis dieser Arbeit umfasst der Begriff ‚Erfahrungswert‘ sämtliche historische Daten, die Personen oder Organisationen empirisch aus Unternehmensprojekten oder aus frei zugänglichen SE-Datenbanken gewonnen haben. Diese Daten sind zum Zwecke der Anwendung als Vergleichsgrundlage in einem bestehenden Projekt auszuwerten und zu verwerten. Ihre semantische, bzw. in einem Folgeschritt pragmatische Verknüpfung begründet damit den informations- bzw. wissensbasierten Ansatz.^[152]

Relevante empirische Daten können die Vorhersagegenauigkeit der Schätzung erhöhen.^[153] Die Nutzung dieser Erfahrungen zur Initialisierung von Parametern ist generell vorteilhaft gegenüber eigenen Erfahrungswerten, wenn diese erst im Aufbau befindlich sind.^[154] González-Barahona et al. schlagen in diesem Zusammenhang Regeln vor, wie die empirischen Elemente von Softwarestudien zu ihrer Reproduzierbarkeit verwendet werden können.^[155] Diese Regeln eignen sich auch dazu, die Erkenntnisse für eine Initialisierung einer Erfahrungsdatenbank nutzbar zu machen.

In der Literatur existiert ein Ansatz, bei dem neben eigenen Erfahrungswerten auch frei zugängliche SE-Repositorien genutzt werden.^[156] Verschiedene Anbieter von freien Repositorien für Aufwandsschätzdaten zur Initialisierung von Schätzfunktionen und Erfahrungs-Datenbanken lassen sich im Internet ausmachen.^[157] Die Universität von Alcalá bietet eine Übersicht über frei zugängliche Daten-Repositorien für Software-Engineering Projekte.^[158] Allerdings liegt deren Erkenntnisbereich bei Erfahrungen zu Projekt- bzw. zu Entwicklungsaufwänden, nicht zur Performanz von Schätzmethoden.^[159] Auch konnten keine frei zugänglichen Repositorien identifiziert werden, die Daten zu agilen Entwicklungsprojekten auf der Basis einzelner Anforderungen führen.

Grundsätzlich ist die Sicherung von Informationen und Wissen aus einem Projekt und die Schaffung geeigneter organisatorischer Voraussetzungen dafür Aufgabe des Projektmanagements.^[160] Die damit verbundenen Aufgaben sind optimaler Weise in einem eigenen Informations- bzw. Wissensmanagement-Ansatz zu bündeln. Der Ansatz kann erweitert werden um die Bereitstellung relevanter Informationen und entsprechenden Wissens in einem laufenden Projekt.^[161] Auf diese Weise entfällt die gebräuchliche Limitierung der Erfassung von Wissen auf die Phase des Projektabschlusses. Vielmehr ermöglicht dieser Ansatz eine kontinuierliche, strukturierte Aufnahme und Verwertung von Informationen und Wissen über den gesamten Projektlebenszyklus. Eine entsprechende Nutzung von Informationen und Wissen für Folgeprojekte bleibt davon unbenommen.

Für die Erfassung der Erfahrungswerte im Zusammenhang mit SE-Projekten existieren in der Literatur verschiedene informations- und wissensbasierte Ansätze, welche im Wesentlichen auf dem Aufbau von projektspezifischen DB beruhen. Nachfolgend werden aktuelle Ansätze aus der Forschung präsentiert und ihre Implikationen in Bezug auf die vorliegende Arbeit diskutiert.

Der Ontologie-basierte Ansatz für agile Entwicklungen von Adnan et al. ist bereits in Kapitel3.4angesprochen worden. Mit ihrem Ansatz verfolgen Adnan et al. das Ziel, das innerhalb eines Projektes generierte Wissen für zukünftige Aufwandsschätzungen nutzbar zu machen.^[162] Sie verwenden dazu Wissensmanagement-Komponenten zur Speicherung und Strukturierung des Wissens. Ihre Modellarchitektur besteht aus den fünf Komponenten Multiagenten-Aufwandsschätzsystem, Ontologie-Wissens-DB, Wissensbildung, Wissensbaum und DV-Unterstützung zur Aufnahme historischer Daten in das Modell.^[163] Auf der Grundlage des Modells speichern praktisch sämtliche Stakeholder strukturiert und regelmäßig ihr persönliches, subjektives Wissen ab.

Eine Evaluierung des Modells ergab Werte, die auf eine Überlegenheit gegenüber den klassischen subjektiven Schätzmethoden Planning Poker und Delphi hindeuten.^[164] Leider berichten die Autoren nicht über den Schätzaufwand. Allein die regelmäßige, massive Personalbindung lässt allerdings hohe Werte vermuten. Immerhin liegt mit diesem Modell ein Ansatz vor, wie Schätzer-relevantes Wissen mithilfe einer Ontologie in einer Wissens-DB strukturiert gespeichert und für eine Aufwandsschätzung nutzbar gemacht werden kann.

Celar et al. bauen für ihren evolutionären Ansatz ein Repositorium auf, welches objektorientiert die Daten zu Entwicklungskomponenten aus vergangenen Unternehmensprojekten speichert.^[165] Die berücksichtigten Dimensionen sind Objekttyp (Modul / Report), Komplexität (niedrig / mittel / hoch) und Entwicklungsperspektive (neu, erweitern, überholen). Schätzungen des Entwicklungsaufwands anstehender Komponenten werden auf der Grundlage von Erfahrungswerten gleichkategorisierter Komponenten durchgeführt. Ein offensichtlicher Nachteil ihres Ansatzes besteht in der Abhängigkeit von der für eine Analogiebetrachtung nötigen Datenbasis. Diese ist im Allgemeinen in der Einführungsphase des Ansatzes noch nicht existent. Eine Erweiterung unter Nutzung von geeigneten SE-Referenz-DB erscheint deshalb berücksichtigenswert.

Für die Entwicklung mobiler Anwendungen schlagen Lusky et al. eine Wissens-DB zur erfahrungsbasierte Schätzung des Entwicklungsaufwands vor.^[166] Die Autoren wollen hierbei Wissen über die Entwicklung von Komponenten einer mobilen Anwendung erfassen. Dies beinhaltet explizit Erfahrungen der Entwickler über den Entwicklungsaufwand. Für die vorliegende Arbeit von besonderem Interesse ist der geplante Aufbau der Wissens-DB: die Strukturierung der Wissens-DB folgt ermittelten Charakteristika von Komponenten, sowie allgemeinen Kostentreibern und dem Anpassungsgrad der Komponente.^[167]

Damit bildet sie zum einen Merkmale ab, die zur Bestimmung der Ähnlichkeit von Komponenten herangezogen und schließlich mit dem erwartbaren Entwicklungsaufwand korreliert werden können (z.B. über geeignete ML-Techniken). Zum anderen ermöglichen die in der DB berücksichtigten Informationen die Anwendung einer Reihe von Schätzfunktionen aus dem Bereich der algorithmischen Kostenmodelle. Allein der von den Autoren verfolgte Ansatz, sämtliche Daten der Wissens-DB über Expertenbefragungen zu generieren, ist im Hinblick auf das Ziel der vorliegenden Arbeit nicht weiter berücksichtigenswert.

Im Bereich der ML-getriebenen Ansätze werden Erfahrungswerte insbesondere zum Training der Algorithmen verwendet.^[168] Für den Aufbau ihres Bayes‘schen Netzwerks nutzen Dragicevic et al. z.B. zwei Datenbanken.^[169] Die erste enthält sämtliche firmeninternen Erfahrungen über Entwicklungsaufwand bezogen auf Software-Entitäten. Die zweite Datenbank enthält Daten über die Entwickler, insbesondere über Fähigkeiten und Motivation etc., welche halbjährlich aktualisiert wird.

Es bleibt damit festzustellen, dass Ansätze existieren, die Erfahrungswerte bei der Verwendung von Schätzmethoden einbringen. Sämtliche Methoden, die aufgrund der Ähnlichkeit von Eigenschaftskonstellationen zwischen historischen Anforderungen und dem zu schätzenden Objekt auf dessen Umsetzungsaufwand schließen, bedienen sich solcher Erfahrungswerte. Bei der Sichtung der Literatur konnte hingegen kein Ansatz ermittelt werden, welcher aus diesen Daten auf die Performanz von Schätzmethoden zu schließen wusste. Hierin besteht demnach Forschungsbedarf.

Mit der Betrachtung von Möglichkeiten zur Strukturierung von Erfahrungswissen in SE-Projekten endet die Aufnahme des aktuellen Wissens- und Forschungsstandes. Die in diesem Kapitel eingangs erarbeiteten acht Fragestellungen konnten dabei sämtlich erörtert werden. Zunächst wurde der Begriff der Anforderung definiert und seine Rolle in agilen SE-Projekten beschrieben. Anschließend konnten sieben Merkmale adäquater Aufwandsschätzung aus der Literatur abgeleitet werden. Diese Merkmale dienten im Folgeschritt zur Charakterisierung aktueller objektiver Methoden zur Aufwandsschätzung. In diesem Zusammenhang wurde der Forschungsstand zur Auswahl geeigneter Schätzer erarbeitet. Hier finden sich praktisch keine Methoden, die den Auswahlprozess eines Schätzers vollständig bedienen. Schließlich wurde die Rolle der Aufwandsschätzung im Rahmen der Projekt-Managementaufgaben Kontrolle und Steuerung näher beleuchtet. Insbesondere bei der Nutzung von Erfahrungswerten in SE-Projekten konnten aufschlussreiche Ansätze ermittelt werden, welche die Entwicklung einer geeigneten Informations- bzw. Wissens-DB im Rahmen dieser Arbeit nahelegen.

Die Grundlagen für dessen Entwicklung im Hinblick auf die Nutzung im Rahmen eines Auswahlprozesses für Schätzmethoden sind Gegenstand des folgenden Kapitels. In Kapitel4werden ebenfalls Bewertungskriterien für einen Proof of Concept erarbeitet, um dem in dieser Arbeit entwickelten Ansatz zur Schätzerauswahl zu evaluieren.

4 Methodische Grundlagen

Im vorangegangenen Kapitel wurden Lücken in der Theorie zur Auswahl von Aufwandsschätzmethoden in SE-Projekten identifiziert. In diesem Kapitel werden die methodischen Grundlagen erarbeitet, die zur Schließung der Lücke beitragen sollen. Dabei werden drei Zielstellungen verfolgt, die die Organisation dieses Kapitels prägen. Im ersten Teil werden Methoden aus der Entscheidungstheorie diskutiert, welche für die Auswahl eines geeigneten Schätzers verwendet werden können (Kapitel4.1). Im zweiten Teil wird der prinzipielle Aufbau von Wissensdatenbanken besprochen, welche für die Anwendung auf das in dieser Arbeit besprochene Problem in Frage kommen (Kapitel4.2). Die Informationen beider Teile fließen in die in Kapitel5konzipierte Methode zur Auswahl geeigneter Aufwandsschätzer ein. Im dritten Teil werden die Rahmenbedingungen des Proof of Concept (POC) erarbeitet (Kapitel4.3). Diese werden für die in Kapitel6durchgeführten Evaluierung des Konzepts verwendet.

4.1 Auswahl geeigneter Schätzer als Entscheidungsproblem

Die Auswahl einer geeigneten Schätzmethode aus einem Pool von Alternativen stellt ein klassisches Entscheidungsproblem dar. Aus diesem Grund sollen Erkenntnisse aus der Entscheidungstheorie auf das vorliegende Problem zum Zwecke seiner optimalen Lösung übertragen werden.^[170] Die Entscheidungstheorie bildet ein Teilgebiet der mathematischen Statistik innerhalb der Wahrscheinlichkeitsrechnung.^[171] In ihr werden prinzipiell drei Kategorien von Entscheidungen untersucht: normative, deskriptive und präskriptive Entscheidungen.^[172]

Da in dieser Arbeit ein normatives Konzept zur optimalen Auswahl geeigneter Methode erarbeitet werden soll, kommt für die weitere Betrachtung nur die normative Entscheidungstheorie in Frage. Diese Kategorie widmet sich Lösungskonzepten, welche optimale Entscheidungen, auch unter dem Eindruck unbestimmter Einflüsse bzw. Einflüsse unsicherer Dimension, ermöglichen. Klassische Entscheidungsunterstützungssysteme und Heuristiken fallen in diese Kategorie. Sie lässt psychologische Aspekte der Entscheidungsfindung außen vor.

Die normative Entscheidungstheorie verfügt über allgemeine Entscheidungsmodelle, welche sich in Hinblick auf ein konkretes Problem spezifizieren lassen.^[173] Ihre Charakteristika sollen im Folgenden mit Hinblick auf die Konzeptionierung in Kapitel5beschrieben werden. Einen systematischen Überblick über die zu besprechenden Elemente liefertAbbildung 7.

Abbildung 7 Elemente eines Entscheidungsmodells.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung nach Inhalten von Schneeweiß, H., Das Grundmodell der Entscheidungstheorie, 1966, S.125 ff. und Laux, H. et al., Entscheidungstheorie, 2014, S. 29 ff.

Im Modell lässt sich eine Entscheidungssituation beschreiben durch ihr Entscheidungsfeld und die angewandte Entscheidungsregel. Ein Entscheidungsfeld besteht aus einem festgelegten Set von Handlungsalternativen, der Menge möglicher Umweltzustände sowie der Ergebnismenge.^[174] Die hier gewählte Darstellung als Ergebnismatrix mit Alternativen in der Vorspalte, Umweltzuständen in der Überschriftenspalte und Ergebnissen als Zellwerten der Matrix folgt dem Grundmodell der Entscheidungstheorie.^[175]

Die Alternativen stellen die vom Entscheider identifizierten und berücksichtigten Möglichkeiten des Handelns dar, welche sich gegenseitig ausschließen. Aus dem Set der Handlungsalternativen ist per Entscheidung genau eine auszuwählen. Alternativen werden in den Dimensionen des Zielsystems bemessen. Die Realisierungen einer Alternative in diesen Dimensionen hängen im Allgemeinen von berücksichtigenswerten Faktoren ab, die durch den Entscheider nicht beeinflussbar sind: den Umweltzuständen.

Gemäß den Annahmen des Entscheiders bezüglich der bestehenden Umweltzustände wird das Problem weiter charakterisiert, mit dem Ziel eine passende Entscheidungsregel auswählen zu können.^[176] Sind die wahren Umweltzustände bekannt, ist eine Entscheidung unter Sicherheit möglich und es liegt ein deterministisches Entscheidungsproblem vor. Bei Unbekanntheit sind zwei weitere Fälle zu unterscheiden:

1. Ist nicht bekannt, welcher konkrete Umweltzustand eintritt, aber die Eintrittswahrscheinlichkeiten aller Zustände, erfolgt die Entscheidung unter Risiko. Ein stochastisches Entscheidungsproblem liegt vor, bei dem die Erwartungswerte der Entscheidungsalternativen berechnet werden können.
2. Ist weder bekannt, welcher Umweltzustand eintritt noch mit welcher Wahrscheinlichkeit, erfolgt die Entscheidung unter Unsicherheit. In diesem Fall wird häufig eine Gleichverteilung bei den Eintrittswahrscheinlichkeiten der Umweltzustände angenommen, um dennoch Erwartungswerte zu den Handlungsoptionen^[177] ermitteln zu können.

Alternativen und Umweltzustände werden schließlich über Ergebnisfunktionen kombiniert zu Ergebnissen. Diese repräsentieren die möglichen Konsequenzen des Handelns unter den gegebenen Umweltzuständen. Dabei genügt eine Beschränkung auf die vom Entscheider als relevant eingeschätzten Ergebnisdimensionen. Diese werden auch als Zielgrößen bezeichnet.^[178] Ein Ergebnis stellt schließlich eine Wertekonstellation von Zielgrößen dar.

Das auf diese Weise definierte Problem wird mithilfe von Entscheidungsregeln gelöst. Entscheidungsregeln berücksichtigen die aus dem Zielsystem abgeleiteten Präferenzen und Optimalitätskriterien. Dies impliziert, dass der Entscheider zwischen zwei gegebenen Ergebnisvektoren eine Ordnung bezüglich seiner Präferenz herzustellen vermag (Ordnungsaxiom).^[179] Das Vorhandensein einer Zielvorstellung, welche das Ordnungsaxiom erfüllt wird in der weiteren Betrachtung vorausgesetzt.^[180] Mit Hilfe von Präferenzen und Optimalitätskriterien können die möglichen Ergebnisse einer Alternative zu einem konkreten Nutzenwert kombiniert werden. Die Nutzwerte der Alternativen lassen sich dann untereinander vergleichen und diejenige Alternative mit dem höchsten Nutzwert auswählen.^[181]

Für Entscheidungsprobleme mit mehr als zwei Zielgrößen sind konkrete, numerische Nutzenfunktionen praktisch nicht aufstellbar. Die Literatur schlägt zur Lösung deterministischer Entscheidungsprobleme mit mehr als zwei Merkmalen als Zielgrößen das etwas aufwändige Transformationskonzept vor.^[182] Hierbei werden die Alternativen jeweils bezüglich zweier Komponenten, in denen sie sich unterscheiden mit einander verglichen. Für eine vertiefende Betrachtung wird auf die einschlägige Literatur verwiesen.^[183]

Im Falle risikobehafteter, rationaler Entscheidungen findet das Bernoulli-Prinzip der Erwartungsnutzentheorie als Lösungsansatz Anwendung.^[184] Es berücksichtigt die Eintrittswahrscheinlichkeiten der Umweltzustände bei der Entscheidungsfindung. Zusätzlich ist aus den Präferenzen des Entscheiders und dessen Risikobereitschaft nach eine Nutzenfunktion aufzustellen, um als Entscheidungsregel wirken zu können.^[185] Hier fließt jedes Ziel gemäß der Entscheiderpräferenz gewichtet in die Nutzenfunktion ein.^[186] Durch die Anwendung der Regel kann der Erwartungswert des Nutzens der möglichen Ergebnisse maximiert werden.^[187] Nutzenmaximierende Alternativen lassen sich mithilfe dieses Prinzips auch bei Vorliegen mehrerer Zielgrößen ermitteln.^[188] Insbesondere der letzte Punkt lässt sich durch Computer-gestützte Verfahren begleiten, was den Berechnungsaufwand für den Menschen massiv minimiert.

Heuristiken bieten eine weitere Möglichkeit, die Lösung von Entscheidungsproblemen, insbesondere die unter Unsicherheit, methodisch zu unterstützen. Das Ziel bleibt die Ermittlung einer nutzenmaximierten Auswahl. Sie stellen simple Entscheidungsregeln dar, die helfen, eine Alternative schnell und mit geringem Aufwand zu identifizieren.^[189] Dabei reduzieren sie üblicherweise die Komplexität der gegebenen Problemstellung, indem sie nur eine Teilmenge der Probleminformation bei der Beurteilung von Eintrittswahrscheinlichkeiten und Erwartungsprognosen berücksichtigen. So setzen sie auf eine Vereinfachung der Zielfunktion, z.B. durch Zielgewichtung, Zielunterdrückung oder Formulierung von entsprechenden Anspruchsniveaus an die Ziele. Dadurch erhöht sich einerseits die Entscheidungsgeschwindigkeit. Andererseits sinkt dabei meist die Vorhersagegenauigkeit.

Für eine Merkmal-basierte Auswahl werden in der Literatur z.B. folgende prominente Heuristiken vorgeschlagen: die ‚Elimination-by-Aspects‘-Methode (EBA)^[190] und die lexikographische Regel^[191]. Bei der EBA-Methode vergleicht ein Entscheider zunächst alle Alternativen bezüglich eines Merkmals und eliminiert die unterlegenen Alternativen. Er fährt fort mit dem nächsten Merkmal, usw. bis eine Alternative übrig bleibt. Diese wird schließlich gewählt. Hier werden ein oder mehrere Ziele beim Vergleich außer Acht gelassen.^[192]

Die lexikographische Regel konzentriert sich auf die Bedienung des Merkmals, dass die höchste Präferenz besitzt. Diejenige Alternative, die den Wert dieses Merkmals optimiert, wird schließlich gewählt. Ebenso wie die EBA-Methode, werden hier Ziele unterdrückt. Die beiden präsentierten Heuristiken lassen sich ohne weiteres kombinieren mit der Formulierung von Anspruchsniveaus für die einzelnen Zielmerkmale.^[193]

Soll das Entscheidungsproblem automatisiert, d.h. Computer-unterstützt werden, ist aufgrund der verfügbaren Rechenleistung eine künstliche Limitierung des verfügbaren Informationsraumes bei der Alternativenauswahl praktisch nicht notwendig. Deshalb kommen auch leistungsintensive Verfahren, bei denen große Datenmengen verarbeitet werden, in Betracht. Diese Verfahren orientieren sich an einer Auswahloptimierung gemäß der Erwartungsnutzenfunktion. Die Erwartungswerte werden dabei prognostiziert durch empirisch ermittelte Wahrscheinlichkeitsverteilungsfunktionen für die Elemente des Zustandsraums. Für die Ermittlung der Verteilungsfunktionen stehen wiederum verschiedene, bereits betrachtete ML-Techniken zur Verfügung.^[194]

An dieser Stelle ist festzuhalten, dass die modellbasierte Darstellung eines Entscheidungsproblems eine Struktur liefert, aus welcher eine geeignete Entscheidungsregel als Lösungskonzept abgeleitet werden kann. Dabei existieren verschiedene Lösungskonzepte für das in dieser Arbeit vorliegende Entscheidungsproblem. Die hier vorgestellten Methoden machen deutlich, wie und auf welcher Grundlage Heuristiken, bzw. ML-Techniken zur Lösung eingesetzt werden können. Als Selektionsoption finden ihre Konzepte Einzug in die Schätzerauswahlmethode. Die konkrete Modellierung der Auswahl geeigneter Schätzmethoden als Entscheidungsproblem erfolgt schließlich in Kapitel5.1.

4.2 Erfahrungswert-Datenbanken

Verschiedene Studien haben Gebrauch von der Datenbank-unterstützten Erfassung und Wiederverwendung von Erfahrungswerten gemacht. Einige wurden im Rahmen dieser Arbeit bereits referenziert.^[195] Nachfolgend werden grundlegende Eigenschaften und ein Konzept zur Modellierung von Datenbanken vorgestellt, welche relevant für die Konzeption einer Datenbank in Bezug auf die vorliegende Aufgabenstellung sind.^[196]

Datenbanken haben im Allgemeinen die Aufgabe, strukturierte Daten, welche miteinander in sachlogischer Beziehung stehen zu speichern.^[197] Der Zugriff auf die Daten wird durch ein Datenbankmanagementsystem (DBMS) organisiert. DB und DBMS bilden zusammen das eigentliche Datenbanksystem.^[198] Ein wesentlicher Zweck eines Datenbanksystems besteht neben der Speicherung von Daten in deren nutzerorientierten Bereitstellung. Die Nutzerorientiertheit ist dabei nicht auf menschliche Anwender beschränkt und deshalb eher auf andere Attribute der Bereitstellung fokussiert. Dazu gehören insbesondere Korrektheit, Widerspruchsfreiheit und Vollständigkeit der Daten.^[199] Anknüpfung zu Managementaufgaben bieten die Forderungen nach der Verfügbarkeit der Daten zur richtigen Zeit und für den richtigen Nutzer.

Der obigen Beschreibung folgend, sind Informations- bzw. Wissensdatenbanken spezielle DB, die Informations- bzw. (explizierte) Wissenselemente als Daten in geeigneter Form (z.B. als Dokument) speichern.^[200] Sie wirken als kollektives Gedächtnis einer Organisation und ermöglichen einen „aktualisierten, vollständigen und integrierten Zugriff zur relevanten Information, über Funktions- und Geschäftseinheitsgrenzen hinweg“.^[201] Eine Spezifizierung der Datenbank dem Einsatzzweck nach, z.B. als Projekt-Datenbank, die Erfahrungswerte einer Organisation in Bezug auf Projekte erfasst, ist üblich.^[202]

Demgegenüber können Repositorien als spezielle Datenbanken verstanden werden, die als Archiv fungieren und alle damit verbundenen Tätigkeiten abbilden, wie z.B. Versionskontrolle von Daten und Metadaten-Indizierung der Inhalte zur Suchunterstützung. Üblicherweise werden Repositorien ihrem inhaltlichen Archivzweck nach kategorisiert.

Die Konzeption einer problembezogenen Datenbank erfordert ein Datenmodell, welches Auskunft über die zu speichernden Daten gibt (Informationsbedarf). Der Entwurf des Datenmodells erfolgt dabei in vier Schritten:^[203]

- Klassifizierung: Über welche Objekttypen sollen Informationen gespeichert werden?
- Abstraktion: Welche Objekteigenschaften sind relevant zu berücksichtigen?
- Identifizierung: Wie können die Objekte voneinander unterschieden werden?
- Beschreibung der sachlogischen Zusammenhänge: Welche inhaltliche Verbindungen bestehen zwischen den Objekten?

Im Ergebnis entsteht eine informationsorientierte Abbildung der Daten. Sind sämtliche Angaben im Modell explizit, widerspruchsfrei und vollständig und bedürfen keiner weiteren menschlichen Interpretation, so kann das Modell durch automatisierte Prozesse verarbeitet werden.^[204] Auf dieser Grundlage kann das logische Datenschema der Datenbank konzipiert werden.^[205] Hierbei steht die datenorientierte Sicht im Fokus, bei der die objektbildenden Datensätze miteinander in Beziehung gesetzt sind.^[206] Datenbankmodelle unterstützen diese Aufgabe.

Das relationale Datenbank-Modell, als Standard-Modell^[207], zeichnet sich durch große Flexibilität bei der Informationssuche aus. Entsprechende Datenverknüpfungen werden dynamisch, nach Bedarf erstellt.^[208] Die Flexibilität bedingt allerdings eine geringere Suchgeschwindigkeit, aufgrund des Zeitbedarfs der Datenverknüpfung zur Laufzeit.^[209]

Dennoch soll dieses Modell im Hinblick auf die vorliegende Aufgabenstellung weiterverwendet werden, da bei der Implementierung unterschiedlicher Aufwandsschätzverfahren eine dynamische Datenverknüpfung von Vorteil ist. Auf die Darstellung der theoretischen Implikationen des Modells wird an dieser Stelle verzichtet, da sie keine Spezifizierung auf die vorliegende Problemstellung benötigen. Sie können gem. allgemeiner Lehrbuchdarstellung angewandt werden. Zudem existieren Generatorprogramme, welche aus dem konzeptionellen Datenmodell auf der Grundlage des relationalen Datenbank-Modells die Struktur der Datenbank automatisiert ableiten.^[210] Mit der obigen Betrachtung liegt schließlich ein Konzept vor, mit dessen Hilfe eine Erfahrungswert-DB entworfen und umgesetzt werden kann.

4.3 Bewertungskriterien für einen Proof of Concept

Als Proof of Concept (PoC) wird im Rahmen des Projektmanagements der Machbarkeits- bzw. Durchführbarkeitsnachweis, oft als Ergebnis einer Machbarkeitsstudie, eines Vorhabens bezeichnet.^[211] Der PoC repräsentiert dabei einen wichtigen Meilenstein des Projekts, da er dessen Fortgang wesentlich beeinflusst. Er wird deshalb im Allgemeinen so früh wie möglich, meist noch in der Projektentstehungsphase durchgeführt.^[212]

In SE-Projekten ist der PoC häufig verbunden mit der Entwicklung eines Prototypens. Anhand dessen kann die Machbarkeit eines gewählten Ansatzes ermittelt werden. Dazu zählen die Verifizierung der Anforderungen, sowie die Abschätzung von Performanz und Entwicklungsaufwand.^[213]

Das Ziel der Prototypen-Erstellung ist ein ablauffähiger Demonstrator, der erste ausgewählte oder kritische Funktionen abbildet. Voraussetzung ist eine klare Definition der Funktionen vor Entwicklungsbeginn des Prototypens.^[214] Die Erstellung erfolgt realitätsnahe. So kann der Prototyp im Hinblick auf das Gesamtprojekt evaluiert bzw. experimentell getestet werden. Er kann ferner einem Akzeptanztest der Entwicklungsauftraggeber unterzogen werden.

In der Literatur sind drei Arten von Prototypen bekannt, die sich im Wesentlichen in ihrem Zweck und dadurch in ihrem Umfang unterscheiden:^[215]

- Demonstratoren: dienen der Kundenakquise in einer frühen Projektphase und sind funktional sehr limitiert.
- Labormuster: dienen der Untersuchung bestimmter, z.B. technischer Fragestellungen. Ihre Funktionalität richtet sich dementsprechend nach dem zugrundeliegenden Untersuchungsgegenstand.
- Pilotsystem: dienen dem Test durch Endanwender und sind entsprechend bereits sehr detailliert in ihrer Funktionalität. Sie befinden sich nahe am Zielsystem.

Die Lehre unterscheidet ferner zwei Muster von Prototypen:^[216]

- den horizontalen, der sich ausschnitthaft auf die Benutzerschnittstelle konzentriert, um Anwendern ein erstes Gefühl im Umgang zu vermitteln. Technische Funktionalitäten abseits der GUI werden dabei größtenteils vernachlässigt. Daneben kennt man
- den vertikalen, der ein Teil des Systems über alle Schichten der Architektur hinweg abbildet. Er dient zur Erprobung komplexer Funktionalität bzw. prinzipieller Realisierbarkeit.

Die Bewertung des Prototypens im Rahmen eines PoC erfolgt dabei auf der Grundlage der vorher festgelegten Entwicklungsziele. Diese sollten aus diesem Grund messbar formuliert bzw. mit operationalisierten Akzeptanzkriterien versehen sein. Das bedingt auch eine Festlegung der Prüfverfahren vor der Realisierung.^[217]

In der vorliegenden Arbeit soll eine Methode zur Schätzerauswahl entwickelt werden. Damit soll die prinzipielle Möglichkeit der Entwicklung und des sinnvollen Einsatzes dieser Methode untersucht werden. Dabei ist nicht Ziel, sämtliche in der Literatur beschriebenen Schätzmethoden zu integrieren, sondern eine sinnvolle Auswahl. Diese Auswahl soll allerdings über den gesamten Auswahlprozess begleitet werden. Die Entwicklung trägt daher den Charakter eines Labormusters mit vertikaler Funktionalität.

Das in Anhang I beschriebene Projekt bildet den Rahmen für den Proof of Concept der Auswahlmethode. Dabei dienen die umzusetzenden Anforderungen als Prüfungsobjekte. Anhand ihrer Merkmale sollen geeignete Aufwandsschätzer ausgewählt und angewandt werden. Ziel bei der Anwendung der Auswahlmethode ist es,

1. den Prozess zur Auswahl einer Methode dahin gehend zu unterstützen, dass eine Auswahlempfehlung getroffen wird.
2. dass die Auswahl anhand von durch einen Anwender festgelegten Auwahlkriterien bzw. Schwellwerten für diese Kriterien geleitet wird.
3. dass Erfahrungswerte aus vorangegangen Projekten im Auswahlprozess berücksichtigt werden.
4. dass die Schätzergebnisse, die durch die Auswahl optimaler Schätzer erreicht wird, nicht schlechter sind, als die Schätzergebnisse von
a. einer zufällig ausgewählten Schätzmethode bzw.
wenn das Merkmal ‚Genauigkeit‘ in der Ausprägung ‚hoch‘ gefordert ist.
5. dass der Schätzaufwand, der durch die Auswahl optimaler Schätzer erreicht wird, nicht höher ist, als der Schätzaufwand von
a. einer zufällig ausgewählten Schätzmethode bzw. wenn das Merkmal ‚Schätzaufwand‘ in der Ausprägung ‚sehr gering‘ oder ‚gering‘ gefordert ist.

Die ersten drei Ziele können durch eine einfache Erfüllungsprüfung analog einer Checkliste validiert werden.^[218] Das erste Ziel stellt dabei ein notwendiges Kriterium dar, welches in der Prüfung stets erfüllt sein muss. Falls nicht, so ist der Prototyp zu verwerfen. Die folgenden beiden Ziele bilden optionale Kriterien ab, die in Abhängigkeit der Entscheidereinstellungen berücksichtigt werden sollen oder nicht. Sie müssen durch den Auswahlalgorithmus im Falle ihrer Selektion zur Anwendung kommen und werden bei der Prüfung entsprechend validiert.

Das vierte Ziel konzentriert sich auf die Schätzgenauigkeit, wenn die Ausprägung ‚hoch‘ gefordert ist.^[219] Es kann mithilfe statistischer Hypothesentests überprüft werden.^[220] Ebenso verhält es sich mit dem fünften Ziel, bei dem ein sehr geringer bzw. geringer Schätzaufwand gefordert ist.^[221] Die zu testende Hypothese kann bei beiden Zielen ähnlich formuliert werden. Sie lautet für den Fall der Schätzgenauigkeit:

„Die Schätzgenauigkeit des durch Algorithmus ausgewählten Schätzers ist allgemein höher als die Schätzgenauigkeit zufällig ausgewählter Schätzer.“

Als Maß für die Genauigkeit wird das bereits in Kapitel 3.3.2 vorgestellte (Gleichung 2) verwendet. Dieses Maß gibt den Betrag des relativen Schätzfehlers wieder. Kleinere Werte deuten also auf genauere Schätzungen. Anders als in der ursprünglichen Definition, wird aber für die Werte der durch den Auswahlalgorithmus selektierten Methoden ermittelt (). Analog wird verfahren bei der Bestimmung des für die zufällig ausgewählten Schätzer (). Die in der Hypothese angesprochene ‚allgemein höhere‘ Schätzgenauigkeit, soll über das Merkmal ‚höhere Schätzgenauigkeit‘ gezeigt werden. Dabei wird zu jeder Anforderung bestimmt, ob die durch Algorithmus ausgewählte Methode eine höhere Genauigkeit aufweist als die zufällig ausgewählte. Besteht kein Unterschied zwischen den beiden Auswahlmethoden, so müssten deren jeweiliger Anteil an der Gesamtzahl an Beobachtungen gleich sein, nämlich . Diese Werte werden schließlich in der Nullhypothese (Gleichung 4) mit einander in Beziehung gesetzt:

Gleichung 4 Nullhypothese für das Ziele Genauigkeit.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Rumsey, D. J., Statistics essentials for, 2010, S. 96.

Die Alternativhypothese, wonach der Anteil an genaueren Schätzwerten beim Algorithmus signifikant höher liegt, kann dann wie folgt formal dargestellt werden (Gleichung 5):

Gleichung 5 Alternativhypothese für das Ziel Genauigkeit.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Rumsey, D. J., Statistics essentials for, 2010, S. 96.

Gemäß dem zentralen Grenzwertsatz von Lindeberg-Levy ist normal-verteilt, wenn die Anzahl der Messwerte groß genug (>30) ist.^[222] Für kleinere Populationen kann eine t-Verteilung angenommen werden.^[223] Die wahre Standardabweichung ist unbekannt. Der Standardfehler der Messungen (entspricht dem Teiler in Gleichung 6) wird deshalb über die Anzahl der Messwerte sowie über den angenommenen Populationserwartungswert ermittelt. Damit ergibt sich folgende Teststatistik:

Gleichung 6 Teststatistik für Ziel Genauigkeit.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Rumsey, D. J., Statistics essentials for, 2010, S. 96, Bronstejn, I.N., et al., Taschenbuch der Mathematik, 2006, S. 802.

Die Teststatistik genügt einer -Verteilung mit Freiheitsgraden.^[224] Das Sicherheitsniveau des Tests wird mit in allgemeiner Übereinstimmung mit der Literatur vorgegeben. D.h., der Fehler, die Null-Hypothese abzulehnen, obwohl sie korrekt ist liegt bei unter . Zum Wert der Teststatistik ist das dazugehörige Quantil z.B. über die tabellierte -Verteilung zu ermitteln. Liegt das Quantil außerhalb des durch vorgegeben Sicherheitsbereiches, ist zu verwerfen.

Analog wird mit Ziel 5 verfahren. Die Hypothese zum Schätzaufwand lautet:

„Der Schätzaufwand bei dem durch Algorithmus ausgewählten Schätzer ist allgemein niedriger als der Aufwand bei zufällig ausgewählten Schätzern.“

Als Aufwandsmaß wird die bislang noch nicht besprochene Dauer zur Durchführung der Schätzung gewählt. Zwei Gründe sind für diesen pragmatischen Ansatz ausschlaggebend: Zum einen finden sich in der referenzierten Literatur keinerlei Hinweise auf etablierte, evaluierte Messtechniken hinsichtlich des Schätzaufwands. Zum anderen ist der Zeitverbrauch für eine Tätigkeit ein in verschiedenen Disziplinen allgemein verwendetes Maß für den mit der Tätigkeit verbundenen Aufwand.^[225]

Für den statistischen Hypothesentest, werden wie bei Ziel 4 die merkmalsbasierten Populationsanteile verwendet. Zu jeder Anforderung wird bestimmt, ob die durch Algorithmus ausgewählte Methode einen geringeren Schätzaufwand aufweist als die zufällig ausgewählte. Besteht kein Unterschied, müssten deren jeweiliger Anteil an der Gesamtzahl an Beobachtungen gleich sein (). Die Null-Hypothese lautet dementsprechend formal:

Gleichung 7 Nullhypothese für das Ziele Schätzaufwand.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Rumsey, D. J., Statistics essentials for, 2010, S. 96.

Die Alternativhypothese kann dann wie nachfolgend inGleichung 8formuliert werden:

Gleichung 8 Alternativhypothese für das Ziele Schätzaufwand.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Rumsey, D. J., Statistics essentials for, 2010, S. 96.

Die Testgröße ist mit der in Gleichung 6 gezeigten Größe identisch im Aufbau:

Gleichung 9 Teststatistik für Ziel Schätzaufwand.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Rumsey, D. J., Statistics essentials for, 2010, S. 96, Bronstejn, I.N., et al., Taschenbuch der Mathematik, 2006, S. 802.

Die Auswertung der Teststatistik erfolgt mit Sicherheitsniveau 00.32 analog zum vierten Ziel.

Damit wurde nun ein Set von Beurteilungskriterien aufgestellt, dass für die Evaluierung der Schätzerauswahlmethode im Rahmen eines Proof of Concept genutzt werden soll. Es ist in Tabelle 7 zusammengefasst dargestellt. Für die Ablehnung des Prototypens reicht dabei die Falsifizierung eines Zieles aus.

Tabelle 7 Beurteilungskriterien PoC.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Das daraus entwickelte Vorgehen zeigtTabelle 8. In einem zweistufigen Ansatz werden zunächst zufällig die Ziele und die Entscheidungsregeln festgelegt. Anschließend erfolgt die Datenerhebung für drei Datensets gemäß den Vorgaben aus Stufe 1. Die Datensets unterscheiden sich hinsichtlich der Nutzung des Auswahlalgorithmus und der Nutzung von Erfahrungswerten.

Die Schätzungen der Algorithmen-basierten Kostenmodelle basieren zum Teil auf freiverfügbaren Excel-Templates. Sie werden in einem Gesamtdokument (‚20180911 Masterarbeit Datenerhebung.xlsm‘) der Arbeit beigefügt. Die Faktorskalierung gem. Kapitel5.4erfolgt manuell. Die Größe der Anwendung wird zur besseren Vergleichbarkeit der Werte durchgängig mit der Use Case Points-Methode bestimmt.^[226] Diese Methode ist der Notation der Anforderungen im Projekt (Use Case-Notation) am ähnlichsten, woraus sich Vorteile bei dessen Anwendung versprochen werden.^[227] Die Umrechnung von Use Case Points und Function Points in Entwicklerstunden wird analog Cohn (2005) vorgenommen.^[228] Für die ML-Techniken werden die implementierten Funktionen von Matlab (R2018b) verwendet. Im Fall von SGB und SVM erfolgt die Initialisierung der Funktionen analog zu den Literaturangaben.^[229]

Der Schätzaufwand wird in Zeiteinheiten mithilfe einer Computer-Systemuhr gemessen. Die Messung startet mit dem Beginn der Akquirierung von für die Schätzmethode relevanten Informationen. Sie endet, sobald das Schätzergebnis vorliegt. Die so gewonnenen Daten lassen sich schließlich anhand der Beurteilungskriterien des PoC zur Bestimmung der Wirksamkeit des Algorithmus auswerten.

Tabelle 8 Vorgehen PoC.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

In diesem Kapitel wurden die methodischen Grundlagen für die Entwicklung und Evaluierung einer Auswahlmethode für Aufwandsschätzer in SE-Projekten erarbeitet. Damit steht nun eine Möglichkeit zur Verfügung, die Auswahlmethode als Entscheidungsproblem zu modellieren. Dieses berücksichtigt sämtliche Elemente die relevant sind, um eine wirksame Entscheidung ableiten zu können (Kapitel4.1). Weiterhin ist ein Konzept zum Aufbau einer Datenbank ermittelt worden, welches die Voraussetzung zur Speicherung und Bereitstellung von Erfahrungswerten im Rahmen des Auswahlprozesses schafft (Kapitel4.2). Schließlich ist der PoC beschrieben und sind die Bewertungskriterien zur Evaluierung der Auswahlmethode im Rahmen des PoC festgelegt worden (Kapitel4.3). Im folgenden Kapitel5werden das Entscheidungsmodell und das Datenbankmodell für die Entwicklung der Schätzerauswahlmethode verwendet. Der PoC folgt in Kapitel6.

5 Methode zur anforderungsbasierten Auswahl objektiver Aufwandsschätzverfahren

In diesem Kapitel wird eine Methode zur anforderungsbasierten Auswahl objektiver Schätzverfahren vorgestellt. Mit dessen Hilfe sind Entscheider in die Lage versetzt, auf der Basis ihrer Auswahlkriterien die für ihre Situation bestmögliche Schätzmethode auszuwählen. Ihre Konzeption beruht auf den in den beiden vorangegangenen Kapiteln erarbeiteten Grundlagen und Überlegungen.

Das Kapitel ist wie folgt aufgebaut: Zunächst werden die Kriterien für die Auswahl einer Schätzmethode zusammengestellt (Kapitel5.1). Anschließend wird das zugrundeliegende Entscheidungsproblem modelliert (Kapitel5.2). Im folgenden Abschnitt wird die für die Implementierung der algorithmischen Kostenmodelle notwendige Skalierung der Faktoren vorgestellt (Kapitel5.4). Es folgt der Entwurf der Erfahrungswert-Datenbank in Kapitel5.5. Den Kern und Abschluss dieser Betrachtung bildet Kapitel5.5, in der der Auswahlalgorithmus präsentiert wird. Dieser implementiert die in den vorangegangenen Abschnitten erarbeiteten Erkenntnisse. Die Evaluierung dieser Methode folgt dann in Kapitel6.

5.1 Auswahlkriterien

In diesem Abschnitt werden mögliche Auswahlkriterien diskutiert und schließlich ein Set von Kriterien für die weitere Nutzung ausgewählt. Dabei wird näher auf den Zusammenhang zwischen Eigenschaften einer Entwicklungsanforderung, den daraus abgeleiteten Forderungen an die Schätzmethode und den Merkmalen einer Schätzmethode eingegangen. Im Ergebnis dieser Betrachtung ist ersichtlich, aus welchen Eigenschaften der Anforderung die Forderungen an einen Schätzer resultieren und wie diese Forderungen die Auswahl eines Schätzer beeinflussen. Aus dieser Erkenntnis heraus lässt sich schließlich das Set von Auswahlkriterien begründet ableiten.

In Kapitel3.2wurden sieben Merkmale herausgearbeitet, welche eine adäquate Aufwandsabschätzung näher charakterisieren können:

- grundsätzliche Anwendbarkeit,
- geforderte Genauigkeit,
- maximal tolerierter Schätzaufwand,
- verfügbare Informationen,
- Zeitpunkt der Schätzung im Projekt,
- geforderte Spezialisierung der Schätzmethode sowie
- geforderte Dimension des Schätzergebnisses.

Nach diesen Merkmalskategorien wurden in Kapitel3.3.2die Eigenschaften ausgewählter Schätzmethoden zusammengestellt. Sie verbinden damit Forderungen und Methoden. Deshalb kommen sie als Auswahlkriterien grundsätzlich in Frage und sollen nun auf ihre Verwendbarkeit in einem Auswahlprozess erörtert werden.

Das erste Merkmal der Aufzählung, die grundsätzliche Anwendbarkeit in der agilen Entwicklung, stellt eine notwendige Bedingung für die Berücksichtigung einer Methode im Auswahlalgorithmus dar. Es war außerdem ein notwendiges Auswahlkriterium für die Schätzmethoden, die in dieser Arbeit betrachtet werden.^[230] Das ausgewählte Set von Schätzmethoden lässt sich durch dieses Merkmal nicht weiter diskriminieren. Es wird deshalb nur im Rahmen der Neuaufnahme von Methoden in die Auswahlmethode berücksichtigt.

Über die restlichen sechs Merkmale lässt sich der Zusammenhang zwischen Entwicklungsanforderungen und Methodeneigenschaften herstellen (Abbildung 8). Die unidirektionalen Pfeile verbinden Eigenschaften der Entwicklungsanforderungen mit Forderungen an die Schätzmethode. Die Lesart ist wie folgt: <Pfeilquelle> beeinflusst <Pfeilziel>.

Aus Abbildung 8 ist ersichtlich, dass die für die Umsetzung der Anforderung zur Verfügung gestellten Projektressourcen die geforderte Genauigkeit und den tolerierten Schätzaufwand beeinflussen. Der Zusammenhang wurde bereits in Kapitel 3.2 verdeutlicht. Unmittelbar einsichtig ist der Einfluss der Anforderungsbeschreibung auf die Informationen, die einer Schätzmethode zur Verfügung gestellten werden können. Da die Anforderungsbeschreibung selbst ihre Informationen aus dem Entwicklungsumfang und dem jeweiligen Anforderungstypen bezieht (vgl. Abbildung 3), sind auch diese Verbindungen selbsterklärend.

Der Einfluss der Anforderungstypen auf den Schätzzeitpunkt wird bezogen auf das typenimmanente Systemverständnis der Entwicklungsanwendung und der mit diesem Verständnis verbundenen Informationsbasis: die Beschreibung von Kundenanforderungen beruht auf keinem besonderen Systemverständnis. Bei den System- und Designanforderungen ist dieses bereits dezidiert ausgeprägt in dem Sinne, dass es auf einem bestehenden Systemmodell beruht. Die Informationsbasis wiederum ist ausschlaggebend für die Informationen, die einer Methode zur Verfügung gestellt werden können.

Der Einfluss des Typen auf die geforderte Spezialisierung der Methode lässt sich so erklären, dass die Feststellung einer Spezialisierung auf einer entsprechenden Typisierung der Anforderung beruht. Gleichwohl muss diese nicht der von Valentini et al. (2013) vorgeschlagenen Typisierung folgen. Es bietet sich in diesem Fall eine Typisierung der Anforderung gemäß den für die Methoden herausgearbeiteten Spezialisierungen (vgl.Tabelle 1) an. Die Typisierung weist damit zwei Dimensionen auf: eine Dimension beruht auf der Einteilung von Valentini et al. (2013) und die andere auf der Methodenspezialisierung.

Abbildung 8 Zusammenhang zwischen Entwicklungsanforderungen, Forderungen an die Schätzmethode und Methodenmerkmalen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Nicht angebunden an die Auswahl der Methode sind die beiden Anforderungseigenschaften Entwicklungsaufwand und Qualität der Umsetzung. Der Entwicklungsaufwand soll durch die im Auswahlprozess selektierte Methode geschätzt werden. Diesen als Voraussetzung für eine Auswahl zu berücksichtigen, würde eine vorherige Abschätzung oder Kategorisierung des Aufwands bedürfen. Damit stünde man aber wieder am Anfang der Betrachtung dieser Arbeit. Es entstünde eine Zirkelbeziehung, bei der das Merkmal Entwicklungsaufwand zugleich Ursache und Wirkung darstellt, ähnlich einem Regelkreis. Eine iterative Herangehensweise soll an dieser Stelle aber nicht weiter verfolgt werden. Aus diesem Grund wird diese Eigenschaft nicht bei der Auswahl berücksichtigt.

In Kapitel3.1wurde die Annahme getroffen, dass sich die Qualität der Umsetzung vollständig durch die im Projekt bereitgestellten Ressourcen darstellen lässt und umgekehrt. Da die Projektressourcen bereits bei den Forderungen an die Schätzmethode berücksichtigt wurden, genügt dies im Sinne dieser Argumentation auch der Qualität.

Damit lässt sich feststellen, dass die Belange der Entwicklungsanforderungen sämtlich durch die aufgestellten Forderungen an die Schätzerauswahl berücksichtigt werden. Ein geeigneter Auswahlprozess muss nun die hier abgebildeten Zusammenhänge berücksichtigen, um den Anforderungen entsprechen zu können. Dabei sollte der Auswahlprozess die aus der Definition einer Entwicklungsanforderung resultierenden Forderungen auf der Grundlage der verfügbaren Schätzmethoden und deren Eigenschaften bestmöglich bedienen. Falls eine vollständige Übereinkunft einer Methode mit den Forderungen nicht erreicht werden kann, muss der Auswahlalgorithmus einen geeigneten Ausgleich zwischen ihnen erwirken. Diesen Umstand symbolisiert der bidirektionale Pfeil zwischen den Forderungen und Methodeneigenschaften.

Im Ergebnis des Auswahlprozesses soll schließlich eine geeignete Schätzmethode stehen. Als geeignete Schätzmethode wird im Rahmen dieser Arbeit diejenige Schätzmethode verstanden, welche aus dem Kreis der berücksichtigten Schätzmethoden die Anforderungen an die Schätzmethode optimal befriedigt.

Das Optimalitätskriterium lässt sich in zweierlei Hinsicht ausgestalten. Es besteht die Möglichkeit, nur eine Methode zur Auswahl zuzulassen, welche alle Anforderungen gänzlich erfüllt. Auf diese Weise ließe sich ein im Projektrahmen definiertes Qualitätslevel sichern. Allerdings birgt diese Herangehensweise die Gefahr, dass der Auswahlprozess endet, ohne dass eine Schätzmethode selektiert werden konnte. In diesem Fall ist das erste Ziel des Auswahlprozesses verletzt, welches in jedem Fall eine Entscheidung für eine Methode fordert (vgl. Kapitel4.3).^[231] Dieser Ansatz wird aus diesem Grund verworfen.

Alternativ dazu kann festgelegt werden, dass diejenige Methode optimal ist, welche unter allen berücksichtigten Schätzmethoden die Forderungen am besten erfüllt. Die Optimalität wird dabei über einen Vergleich der Methoden definiert. Mit dieser Variante kann sichergestellt werden, dass der Auswahlprozess in jedem Fall zu einem Ergebnis, das heißt zur Auswahl einer Methode, führt. Letztere Variante ist konstruktiv im Sinne des Ziels, den Entwicklungsaufwand von Anforderungen im Projektrahmen zu schätzen. Dieser Ansatz wird deshalb im Rahmen dieser Arbeit weiter verfolgt.

Das Ergebnis der Schätzerauswahl soll den Zielen und Präferenzen des Entscheiders optimal entsprechen, unter Einhaltung der gezeigten Relationen zwischen den Merkmalen. Um diese Vorgaben in der Kriterienselektion abbilden zu können, müssen die sechs festgelegten Kriterien weiter individualisierbar sein. Es ist dazu erforderlich, eine Präferenz-Reihenfolge der Kategorien, optional verbunden mit entsprechenden Schwellwerten, festlegen zu können.

Dabei sind die selektierbaren Schwellwerte der Skalierung der Merkmale anzupassen, um den Merkmalsangaben der vorhandenen Schätzer entsprechen zu können.^[232] Üblicherweise spielt bei der Kriterienauswahl stets das günstigste Selektionselement eine Rolle, um die Ziele abzubilden (etwa ‚hohe Genauigkeit‘ oder ‚geringer Schätzaufwand‘). Eine gezielte Auswahl eines Schätzers mit niedriger Genauigkeit entspricht nicht dem Optimierungsgedanken. Die übrigen Selektionsstufen können deshalb mit fehlender Präferenz hinsichtlich dieses Kriteriums gleichgesetzt und schließlich zusammengefasst werden. Wie später gezeigt wird, verringert diese Maßnahme den Zustandsraum des Entscheidungsmodells erheblich (vgl.Tabelle 11in Kapitel5.2.2).

Der obigen Betrachtung folgend, werden die inTabelle 9festgehaltenen Auswahlkriterien weiterverwendet. Zusätzlich sind ihre Selektionsstufen zur weiteren Individualisierung der Auswahl angegeben. Ein Schrägstrich symbolisiert dabei die Zusammenfassung und ein Komma die Trennung von Selektionsstufen.

Die Auswahlkriterien sollen im Folgenden für die Modellierung von Nutzenfunktionen verwendet werden. Auf dessen Basis erfolgen schließlich Methodenvergleich und Auswahlalgorithmus.

Tabelle 9 Auswahlkriterien und Selektionsstufen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

5.2 Modellierung des Entscheidungsproblems

Das in Kapitel4.1ermittelte allgemeine Entscheidungsmodell wird nun auf das vorliegende Problem dieser Arbeit übertragen. Dabei finden die erarbeiteten die Merkmale von Anforderungen und die Auswahlkriterien für Schätzmethoden Anwendung. Das Problem kann demnach anhand der Komponenten des Entscheidungsfelds, das heißt Aktionsraum, Zustandsraum und Ergebnisse, charakterisiert werden. Aus den im vorherigen Kapitel erarbeiteten Auswahlkriterien werden anschließend Nutzenfunktionen abgeleitet.

5.2.1 Alternativen

Den Alternativen entspricht die Menge aller zur Verfügung stehenden objektiven Schätzmethoden, charakterisiert durch deren sieben Merkmale. InTabelle 10sind die ausgewählten Schätzmethoden mit ihren aus der Literatur entnommenen Eigenschaften in den sechs diskriminierenden Merkmalen zusammengefasst. Die Merkmale ‚Genauigkeit‘ und ‚Schätzaufwand‘ sind dabei mit einer gewissen Unsicherheit belegt, welche sich in den Ergebnissen niederschlägt. Beim Merkmal ‚Informationsbedarf‘ wurden aus Darstellungsgründen die Abkürzungen ‚Sys-Mod‘ für ‚Systemmodell‘ und ‚V+E‘ für ‚Vergleichsmerkmale und Erfahrungswerte‘ verwendet.

Tabelle 10 Alternativen des Entscheidungsmodells: Schätzmethoden und -eigenschaften.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung mit Werten aus Mair, C. et al., An investigation of machine, 2000, S. 26, 28, Mendes, E., A Comparison of Techniques, 2007, S. 341, Radlinski, L., A survey of bayesian, 2010, S. 106, Hummel, O., Aufwandsschätzung in der Software-, 2013, S. 24, 71, 72, 78, 79 f., 82, 121, Ceke, D. und Milasinovic, B., Early effort estimation, 2015, S. 221, 228, 234, Satapathy, S. M., et al., Effort estimation on web-based, 2016, S. 978, 979.

5.2.2 Zustandsraum

Der Zustandsraum wird gebildet aus den Kombinationen der unterschiedlichen Ausprägungen der zu schätzenden Anforderungseigenschaften und den erarbeiteten Auswahlkriterien. Diese richten sich nach den in den Kapiteln 3.1 und 3.2 erarbeiteten Merkmalskategorien bzw. den in Kapitel 5.1 festgelegten Kriterien.^[233] Dazu zählen auf Seiten der Anforderungseigenschaften:

- Entwicklungsaufwand

Dieses Merkmal ist mit Unsicherheit versehen und soll durch einen geeigneten Schätzer erst annährend ermittelt werden.^[234] Der geeignete Schätzer stellt allerdings das Ergebnis des Auswahlprozesses dar. Aus diesem Grund findet der Entwicklungsaufwand der Anforderung als eigenständiges Merkmal im Auswahlprozess keine Berücksichtigung. Er wird durch die drei Einflusskategorien Beschreibung, funktionale Aspekte (kurz: ‚Funktion‘) und nicht-funktionale Aspekte substituiert.

- Beschreibung in den Ausprägungen ‚vorhanden‘ und ‚nicht vorhanden‘

Die vorhandene Beschreibung ist eine notwendige Bedingung für den Start des Auswahlalgorithmus. Fehlt die Beschreibung, existiert keine Auswahlgrundlage. Es wird deshalb im Folgenden von einer vorhandenen Beschreibung der Anforderung ausgegangen. Damit ist dieses Merkmal nicht weiter diskriminierend und wird im Modell nur in der Ausprägung ‚vorhanden‘ aufgeführt.

- Funktion in den Ausprägungen ‚Typ‘ und ‚Umfang‘

- ‚Typ‘ in den Ausprägungen ‚Kunden-‘, ‚System-‘‚ und ‚Designanforderung‘.

Die Ausprägungen werden zur Abbildung verschieden detaillierter Anforderungsbeschreibungen verwendet. Der Detaillierungsgrad impliziert das Vorhandensein von Systemmodellen (im Fall von System- und Designanforderungen) oder deren Abwesenheit (im Fall von Kundenanforderung).

- ‚Umfang‘

Der funktionale Umfang ist seiner Natur entsprechend eng mit dem noch zu schätzenden Entwicklungsaufwand verbunden. Seiner Berücksichtigung kommt deshalb eine besondere Bedeutung zu, obgleich seine Quantifizierung einer Aufwandsschätzung gleichkommt. Dabei wird der wahre Wert wesentlich von Projektrahmenbedingungen und geforderter Qualität bestimmt (vgl.Abbildung 3). Der Einfluss des Umfangs auf die Auswahl der Schätzmethode ist beschränkt auf die zu fordernde Informationsbasis. Diese ist bereits berücksichtigt im Zustandsraum. Deshalb muss der Umfang nicht weiter betrachtet werden in diesem Zusammenhang.

- Nicht-funktionale Anforderungen Qualität sowie Projektrahmenbedingungen in den Ausprägungen ‚Zeit‘ und weitere ‚(Personal-)Ressourcen‘

In dieser Arbeit wurde die Annahme getroffen, dass sich der Einfluss der Qualität vollständig durch den der Rahmenbedingungen erklären lässt und umgekehrt (vgl. Kapitel 3.1). Bei der Modellierung wird deshalb die Abbildung einer der beiden Aspekte als ausreichend erachtet. Während die Qualität keinen berücksichtigenswerten Einfluss auf die Schätzerauswahl nimmt, spielen die Ressourcen beim Schätzaufwand und bei der Schätzgenauigkeit eine tragende Rolle. Beide Aspekte sind bereits im Zustandsraum erfasst, weshalb die Ressourcen nicht gesondert aufgeführt werden müssen.

Ergänzt werden diese Zustandsdimensionen um die Auswahlkriterien:

- Anwendbarkeit auf agile Projekte

Das Merkmal ist als Auswahlkriterium der Kapitel3.3.2betrachteten objektiven Schätzer genutzt worden. Weiterhin entstammen alle Prüfobjekte aus dem PoC einem agilen Projekt. Aus diesem Grund kann dieses Merkmal als erfüllt vorausgesetzt werden. Es ist damit in dem konkretisierten Problem kein diskriminierendes Merkmal. In der Beschreibung der Zustände wird es deshalb nur verkürzt in der Ausprägung ‚anwendbar‘ dargestellt.

- geforderte Genauigkeit in den Ausprägungen ‚niedrig/mittel‘ und ‚hoch‘

Die tatsächlichen Ausprägungen dieses Merkmals sind dann Ergebnisse der Anwendung der Schätzmethoden.

- geforderter Schätzaufwand in den Ausprägungen ‚sehr gering/gering‘ und ‚mittel/hoch/ sehr hoch‘

Ebenso wie bei der Genauigkeit sind die tatsächlichen Ausprägungen dieses Merkmals dann Ergebnisse der Anwendung der Schätzmethoden.

- Informationsbedarf in den Ausprägungen ‚Systemmodell‘ und ‚ Vergleichsmerkmale + Erfahrungswerte‘

- Einsatzzeitpunkt in den Ausprägungen ‚früh‘ und ‚mittel/spät‘

- Spezialisierung in den Ausprägungen ‚Web/Realtime-Anwendung‘ und ‚andere‘

Bereits in Kapitel5.1wurde herausgearbeitet, dass das Anforderungsmerkmal ‚Typ‘ zwei Dimensionen bedient, von denen die hier angesprochene Spezialisierung eine darstellt. Ihre Berücksichtigung dient der verfeinerten Kategorisierung von Anforderungen. Zur Vereinfachung des Zustandsraumes wurden entsprechend der Eigenschaften der zur Verfügung stehenden Methoden die Ausprägungen angepasst.

- Dimension in der Ausprägung ‚Aufwand/Kosten‘

Um den Zustandsraum zu vereinfachen, werden die in einander umwandelbaren Ausprägungen ‚Aufwand‘ und ‚Kosten‘ zusammengefasst betrachtet.

In den hier ausgewählten Umweltzuständen sind sämtliche in Kapitel5.1erarbeiteten Auswahlkriterien enthalten. Hinzu treten die Zustandsdimensionen Anwendbarkeit, Beschreibung (beide nicht diskriminierend) und Typ. Jeder Zustand wird dementsprechend durch einen neun-elementigen Vektor dargestellt, dessen Dimensionen den Zuständen gemäß den weiter oben ausgewählten Merkmalskategorien entsprechen. Sämtliche Zustände werden als sicher in dem Sinne eingeschätzt, dass ein Entscheider die Zustände der betrachteten Anforderung anhand ihrer gegebenen Beschreibung ableiten kann. Eine Übersicht bietetTabelle 11. Die Menge der Kombinationen der Merkmalsausprägungen entspricht schließlich der Menge der Umweltzustände (insgesamt 96). Um die Komplexität des Zustandsraumes zu verringern, besteht die Möglichkeit, das Problem in Teilprobleme zu zerlegen. Bei diesen wird jeweils nur eine Merkmalsauswahl als Dimensionen betrachtet.^[235]

Tabelle 11 Dimensionen und Ausprägungen der Umweltzustände.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

5.2.3 Ergebnisfunktion

Mit den in Kapitel3.2erarbeiteten Merkmalen adäquater Aufwandsschätzung steht ein geeignetes Zielgrößensystem zur Festlegung der Ergebnisse zur Verfügung. Die Ergebnisse sollen die Übereinstimmung der jeweiligen Schätzmethoden mit den Zielkriterien anhand ihrer Merkmalsausprägungen unter den gegebenen Umwelteinflüssen abbilden. Die Ergebnisangabe soll dabei ein Vergleich zwischen den Schätzmethoden zulassen.

Der Problemcharakterisierung aus Kapitel4.1folgend, stellt die betrachtete Aufgabenstellung ein deterministisches Entscheidungsproblem dar, da das Eintreten sämtlicher Umweltzustände sicher eingeschätzt werden kann. Unsicherheit besteht lediglich bezüglich der Schätzerausprägungen in den Dimensionen Genauigkeit und Aufwand.

Der Ergebnisvektor trägt dementsprechend Informationen darüber, ob eine Methode die Gegebenheiten aus den jeweiligen Umweltzuständen erfüllt. Dabei wird für die Dimensionen folgende Festlegung getroffen: Ein Ergebnis wird als Vektor beschrieben, dessen Dimensionen den Auswahlkriterien entsprechen. Der Wert der Dimensionen Anwendbarkeit, Spezialisierung, Informationsbedarf, Einsatzzeitpunkt und Ergebnisdimension wird nach folgender Bildungsvorschrift festgelegt:

Vergleiche die Ausprägung der Dimension der betrachteten Alternative mit derjenigen des betrachteten Umweltzustands: bei Gleichheit, vergebe das Ergebnis ‚1‘, sonst vergebe das Ergebnis ‚0‘.

Für die Dimensionen Genauigkeit und Aufwand wird folgende Bildungsvorschrift festgelegt:

1. Lege für jede Ausprägungen der Dimension eine Eintrittswahrscheinlichkeit gemäß den aktuellen Erfahrungswerten fest, sodass die Summe der Eintrittswahrscheinlichkeiten gleich ‚1‘ ist und eine Verteilungsfunktion entsteht.
2. Ermittle eine randomisierte Zufallszahl, dessen Wertebereich zwischen ‚0‘ und ‚1‘ liegt.
3. Ermittle anhand des Wertes der Zufallszahl in der Verteilungsfunktion eine Dimensionsausprägung.
4. Vergleiche die so ermittelte Dimensionsausprägung der betrachteten Alternative mit derjenigen des betrachteten Umweltzustands: bei Gleichheit, vergebe das Ergebnis ‚1‘, sonst vergebe das Ergebnis ‚0‘.

Auf diese Weise entstehen Ergebnisvektoren mit binären Zustandswerten. Der Ergebnisraum kann schließlich als Ergebnismatrix mit 13 Zeilen und 96 Spalten für alle Kombinationen aus Schätzmethoden und Umweltzuständen dargestellt werden. Aufgrund von Platzrestriktionen wird an dieser Stelle darauf verzichtet und es bei der Angabe der Bildungsvorschriften belassen.

5.3 Modellierung der Entscheidungsregeln

Im Folgenden werden drei Entscheidungsregeln aufgestellt, nach welcher ein Entscheider eine Schätzmethode auswählen kann: Methode zur Maximierung des Erwartungsnutzens, Elimination-by-Aspects-Regel und Lexikographische Regel. Wie bereits in Kapitel5.1festgelegt wurde, soll diejenige Schätzmethode ausgewählt werden, welche den Zielen des Entscheiders optimal, d.h. am besten entspricht. Dies erfordert sowohl einen Vergleich der Methodenleistungen untereinander, als auch einen Abgleich mit den geforderten Selektionsstufen der Auswahlkriterien. Naheliegend ist die Transformation der Ergebnisse in ein Methoden-Ranking entlang einer Präferenzordnung.^[236]

5.3.1 Methode zur Maximierung des Erwartungsnutzens

Gemäß den Erkenntnissen aus Kapitel4.1zur Modellierung von Entscheidungsproblemen ist Voraussetzung für eine begründete Auswahlentscheidung eine Bewertung der Ergebnisse hinsichtlich ihres Nutzens. Dieser Bewertung muss wiederum eine Definition von Optimalität vorangehen. Entsprechend ist derjenige Schätzer optimal und damit auszuwählen, welcher den höchsten erwartbaren Nutzen realisiert. Dazu ist eine Entscheider-spezifische Nutzenfunktion auszuwählen, anhand welcher der Nutzen beschrieben werden kann.

Im Fall der Methode zur Maximierung des Erwartungsnutzens werden sämtliche Auswahlkriterien und ihre Selektionsstufen in der Nutzenfunktion als Ziele berücksichtigt und entsprechend der Präferenzen des Entscheiders gewichtet.^[237] Die Ergebnisse lassen sich entsprechend der Nutzenfunktion in einen Nutzenwert transformieren. Entsprechend der Eintrittswahrscheinlichkeiten kann aus den Nutzenwerten der Erwartungsnutzen berechnet und die Alternative mit dem maximalen Wert ausgewählt werden.

Sind für einen Entscheider alle Ziele gleichwichtig, so stimmt die Nutzenfunktion mit der Ergebnisfunktion überein. Die optimale Alternative stellt dann diejenige mit dem höchsten Erwartungswert dar. In dem vorliegenden deterministischen Entscheidungsproblem entspricht dies derjenigen Schätzmethode, die unter Berücksichtigung der gegebenen Auswahlkriterien (abgebildet durch genau einen Umweltzustandsvektor) die höchste Summe der Vektorelemente aufweist.

Für Merkmal-basierte Auswahlen, die Zielpräferenzen ohne konkrete Gewichtungen berücksichtigen sollen, eignen sich die beiden in Kapitel4.1vorgestellten Heuristiken Elimination-by-Aspects-Regel (EBA) und die lexikographische Regel. Sie vermögen eine frühzeitige Eliminierung dominierter Alternativen, was den Auswahlaufwand erheblich verringert.^[238] Die Heuristiken dienen als Vorlage für die beiden nachfolgend beschriebenen Auswahlregeln.

5.3.2 Spezifizierte EBA-Regel

Die Regel wird durch den Entscheider durch folgendes Vorgehen initialisiert:

1. Lege die relevanten Auswahlkriterien fest.
2. Lege die Selektionsstufen der relevanten Auswahlkriterien fest.
3. Starte den Auswahlalgorithmus.

Der Auswahlalgorithmus arbeitet dann wie folgt:

4. Lege eine Betrachtungsreihenfolge für die Kriterien fest.^[239]
5. Betrachte die Kriterien gemäß ihrer Reihenfolge, beginnend mit dem ersten Kriterium.
6. Stoppe den Algorithmus, wenn alle Kriterien betrachtet wurden. In diesem Fall, wähle aus den verbliebenen Methoden eine mit gleicher Wahrscheinlichkeit aus.
7. Ordne jeder Methode den Nutzen ‚1‘ zu, wenn ihre Ausprägung in der Kriteriumsdimension gleich der Selektionsstufe des Kriteriums ist.
8. Ordne jeder Methode den Nutzen ‚0‘ zu, wenn ihre Ausprägung in der Kriteriumsdimension ungleich der Selektionsstufe des Kriteriums ist.
9. Vergleiche alle Methoden bezüglich der Selektionsstufe des Kriteriums.
10. Falls genau eine Methode bezüglich des Kriteriums den Nutzen ‚1‘ aufweist, wähle diese Methode als optimalen Schätzer aus.
11. Falls mehr als eine Methode bezüglich des Kriteriums den Nutzen ‚1‘ aufweist, eliminiere alle unterlegenen Methoden und betrachte die verbliebenen Methoden bezüglich des nächsten Kriteriums. Verfahre weiter ab Punkt 6.
12. Falls keine Methode bezüglich des Kriteriums den Nutzen ‚1‘ aufweist, betrachte das nächste Kriterium. Verfahre weiter ab Punkt 6.

5.3.3 Spezifizierte Lexikographische Regel

Die Regel wird durch den Entscheider durch folgendes Vorgehen initialisiert:

1. Lege die relevanten Auswahlkriterien fest.
2. Lege die Selektionsstufen der relevanten Auswahlkriterien fest.
3. Lege die Präferenzreihenfolge der Auswahlkriterien, beginnend mit der wichtigsten, fest.
4. Starte den Algorithmus.
Der Auswahlalgorithmus arbeitet dann wie folgt:
5. Betrachte die Kriterien gemäß der festgelegten Präferenzreihenfolge, beginnend mit dem ersten Kriterium.
6. Stoppe den Algorithmus, wenn alle Kriterien betrachtet wurden. In diesem Fall, wähle aus den verbliebenen Methoden eine mit gleicher Wahrscheinlichkeit aus.
7. Ordne jeder Methode den Nutzen ‚1‘ zu, wenn ihre Ausprägung in der Kriteriumsdimension gleich der Selektionsstufe des Kriteriums ist.
8. Ordne jeder Methode den Nutzen ‚0‘ zu, wenn ihre Ausprägung in der Kriteriumsdimension ungleich der Selektionsstufe des Kriteriums ist.
9. Vergleiche alle Methoden bezüglich der Selektionsstufe des Kriteriums.
10. Falls genau eine Methode bezüglich des Kriteriums den Nutzen ‚1‘ aufweist, wähle diese Methode als optimalen Schätzer aus.
11. Falls mehr als eine Methode bezüglich des Kriteriums den Nutzen ‚1‘ aufweist, eliminiere alle unterlegenen Methoden und betrachte die verbliebenen Methoden bezüglich des nächste Kriteriums. Verfahre weiter ab Punkt 6.
12. Falls keine Methode bezüglich des Kriteriums den Nutzen ‚1‘ aufweist, betrachte das nächste Kriterium. Verfahre weiter ab Punkt 6.

Es ist festzustellen, dass zwischen den Heuristiken nur der Unterschied bei der Festlegung der Betrachtungsreihenfolge der Kriterien besteht. Während bei der EBA-Regel die Reihenfolge durch den Algorithmus zufällig festgelegt wird, geschieht dies bei der Lexikographischen Regel durch den Entscheider gemäß seiner Präferenzreihenfolge.

Bei diesen Entscheidungsregeln stellt die frühzeitige Eliminierung von Alternativen Vorteil und Nachteil zugleich dar. Einerseits wird auf diese Weise effektiv und effizient der Aktionsraum verkleinert. In kurzer Zeit und ohne viel Rechenaufwand (verglichen mit der Methode zur Maximierung des Erwartungsnutzens) erhält der Entscheider eine Auswahlempfehlung. Andererseits können bei diesem Vorgehen Alternativen eliminiert werden, dessen kombinierte Zielerreichung höher ist als die von anderen Alternativen, aber in dem zur Eliminierung führenden Kriterium geringer. Dies kann zu einer suboptimalen Auswahl führen. Wenn ein Entscheider diesen Fall ausschließen möchte, ist die Verwendung der Methode zur Maximierung des Erwartungsnutzens empfehlenswert.

Ein Entscheider kann im Auswahlalgorithmus zwischen den drei vorgestellten Entscheidungsregeln wählen. Denkbar ist die Implementierung weiterer Regeln in den Algorithmus, der in Kapitel5.5vorgestellt wird. Die dargelegten Regeln nehmen in der Literatur der Entscheidungstheorie allerdings eine prominente Stellung ein und dürften dementsprechend auch in der Praxis, zumindest als Grundlagen, noch relevant sein. Sie werden deshalb als ausreichend für die Zielstellung dieser Arbeit erachtet. Eine Erweiterung des Regelkataloges wird der zukünftigen Verfeinerung des Auswahlalgorithmus anempfohlen.

5.4 Faktorskalierung der Schätzfunktionen

In diesem Abschnitt wird eine Möglichkeit zur Skalierung der Faktoren von Schätzfunktionen erfahrungsfreier Schätzmodelle auf agile Projekte vorgestellt. Der Ansatz macht sich das grundsätzlich additive Vorgehen der Schätzfunktionen zunutze, wonach die Faktoren aus der Summe einzelner Funktionalitäten und Projektgegebenheiten abgeleitet werden. Entsprechend der in Kapitel 3.3 eingeführten Gleichung 1, berücksichtigen Schätzfunktionen die Systemgröße sowie drei Faktoren A, B und C.

Die Systemgröße wird durch geeignete Metriken (vgl. Kapitel 3.3.1) ermittelt. Faktor bildet projekt- oder modellspezifische Merkmale in der Funktion ab. Faktor steht für das potenzielle Aufwandswachstum in großen Projekten.^[240] Kostentreiber im Projekt werden durch Faktor erfasst. Für die Faktorskalierung auf agile Entwicklungsprojekte werden folgende vereinfachende Annahmen getroffen:

1. Entwickler arbeiten in agilen Projekten und Wasserfallprojekten handwerklich gleich.
2. Funktionale und nicht-funktionale Aspekte für betrachtete Entwicklungsanforderung sind in agilen Projekten und Wasserfall-Projekten gleich.

Die wesentliche Konsequenz dieser Annahmen lautet:

Der Aufwand für die Umsetzung einer einzelnen Entwicklungsanforderung (nicht für das gesamte Entwicklungsprojekt) ist in den beiden Vorgehensmodellen Wasserfall und agil annährend identisch.

Mit dieser Erkenntnis lassen sich die Faktoren der Schätzfunktion wie nachfolgend dargelegt ermitteln:

1. Anforderungsgröße

In Gesamtprojektschätzungen ergibt sich die Systemgröße aus der Kumulation der Größen einzelner Entwicklungsanforderungen. Dementsprechend kann in agilen Projekten die Größe einer einzelnen Entwicklungsanforderung unter Berücksichtigung der konkret umzusetzenden funktionalen und nicht-funktionalen Forderungen im betrachteten Sprint identisch ermittelt werden. Lediglich auf die Kumulation der Größen einzelner Entwicklungsanforderung ist zu verzichten.

2. Faktor : projekt- oder modellspezifischen Merkmale

Die Skalierung folgt den für die Entwicklungsanforderung bekannten Angaben unter Auslassung sämtlicher, auf das Gesamtprojekt bezogener Einstellungen.

3. Potenzfaktor : Aufwandswachstum in großen Projekten

Der Fokus der Betrachtung liegt auf einzelnen Anforderungen, nicht auf dem Rahmen des Gesamtprojekts. Entsprechend muss das potenzielle Aufwandswachstum in großen Projekten nicht berücksichtigt werden. Der Potenzfaktor wird aus diesem Grund neutral als ‚1‘ angenommen.

4. Faktor : Kostentreiber im Projekt

Kostentreiber im Projekt können Einfluss auf die Entwicklung einzelner Anforderungen nehmen. Allerdings geschieht dies in einem verminderten Rahmen. Deshalb wird dieser Faktor so lange als neutral (Wert ‚1‘) bewertet, bis eindeutige Gegebenheiten aus dem Projektrahmen gesonderte Berücksichtigung erfordern. In diesem Fall kann als erster Anhaltspunkt den Einstellmöglichkeiten unter dem klassischen Wasserfall-Vorgehensmodell gefolgt werden.

Im einfachsten Fall, sofern keine Anhaltspunkte für eine Spezifizierung des Faktors existieren, vereinfacht sich damit die Schätzfunktion zu:

Gleichung 10 Einfach-skalierte Schätzfunktion bei agiler Entwicklung.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: In Anlehnung an Hummel, O., Aufwandsschätzungen in der, 2013, S. 68.

Damit wird deutlich, dass der Aufwand die Einheit der Größe erhält. Der Einfluss der Konstante ist Einheitenunabhängig. Über geeignete Umrechnungserfahrungswerte lassen sich die Einheiten schließlich in das gewünschte Maß konvertieren.

5.5 Auswahlalgorithmus

Dieser Abschnitt widmet sich der Modellierung eines Algorithmus, der die Selektion von Aufwandsschätzmethoden in SE-Projekten unterstützt. Dabei soll der Algorithmus die optimale Schätzmethode aus dem Kreis der berücksichtigten identifizieren. Die Optimalität wird bestimmt durch die Ziele und Präferenzen des Entscheiders. Dieser artikuliert die Ziele und Präferenzen in der Vorgabe der Auswahlkriterien und deren Selektionsstufen sowie der anzuwendenden Entscheidungsregel.

Der Auswahlalgorithmus benötigt neben diesen Vorgaben Informationen bezüglich der zu schätzenden Anforderung. Dabei entspricht die Kombination der Anforderungseigenschaften exakt einem Umweltzustand. Anhand der Eigenschaften soll der Algorithmus die Performanz der berücksichtigten Methoden prognostizieren. Die Prognose beruht dabei auf der Übereinstimmung der Methodenmerkmale mit den Auswahlkriterien. Sofern in ausreichender Zahl verfügbar, aktualisieren entsprechende Erfahrungswerte aus der Datenbank die Methodenmerkmale.

Erfahrungswerte zu einer Methode entstehen durch die Anwendung der Methode auf eine Entwicklungsanforderung. Zu erfassen sind die Erfahrungswerte deshalb in Bezug auf die Eigenschaften der Anforderung. Dieser Bezug muss bei der Wiederverwendung der Erfahrungswerte erhalten bleiben. Die Eigenschaften der Anforderungen liefern schließlich die geeigneten Ähnlichkeitskriterien, um die Erfahrungswerte im Algorithmus auf die gegebene Anforderung beziehen zu können.

Auch unter Einbezug geeigneter Referenzdatenbanken dürften dabei selten genügend Erfahrungswerte bereitstehen, um alle Konstellationen von Anforderungseigenschaften abdecken zu können. Erst recht gilt dies für die Anzahl an Erfahrungswerten, die nötig wäre für eine statistische Auswertung bezüglich einer Kombination aus Anforderungseigenschaften. Entsprechend müssen die vorhandenen Erfahrungswerte kombiniert werden, um dennoch valide Prognosen ableiten zu können. Diese Kombination gelingt durch Anwendung entsprechender ML-Techniken, wie Bayes’scher Netzwerke.

Aus den vorhandenen Erfahrungswerten und der gegebenen Parameterkonstellation werden in einem Bayes’schen Netzwerk die Eintrittswahrscheinlichkeiten bestimmter Zustände ermittelt.^[241] Bei der Initialisierung wird das Netzwerk anhand der vorhandenen Werte trainiert, um Struktur und Wahrscheinlichkeitsverteilungen an den Netzwerkknoten approximieren zu können. Auf der Grundlage des Trainings kann dann im Anwendungsfall eine Wahrscheinlichkeitsprognose bezüglich der betrachteten Zustände erstellt werden. Für die Implementierung eines BN existieren fertige, anwenderfreundliche Software-Lösungen, wie z.B. Matlab (R2018a). Andere ML-Techniken bieten ähnliche Voraussetzungen wie die hier für BN skizzierten. Über Vor- und Nachteile der ML-Techniken in Bezug auf die vorliegende Aufgabenstellung sind keine Anhaltspunkte gegeben. Deshalb sei BN aus dem Kreis der ML-Techniken lediglich beispielhaft für die Umsetzung herausgegriffen.

Die besprochenen Elemente können nun in einen Auswahlprozess integriert werden. Die Darstellung des Prozessablaufs erfolgt in der Unified Modeling Language 2 (UML)^[242] in Form eines UML-Aktivitätsdiagramms^[243] (Abbildung 9). Aus diesem sind die Reihenfolge und die Bedingungen für das Auftreten der Elemente ersichtlich.^[244]

Abbildung 9 Auswahlalgorithmus.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung, realisiert mit www.draw.io.

Das Diagramm verdeutlicht die Zweiteilung des Prozesses in Initialisierung, welche durch den Entscheider durchzuführen ist und Schätzerauswahl, welche durch den Algorithmus erfolgt. Bei der Initialisierung legt der Entscheider die Werte zu Auswahlkriterien gem. Kapitel5.1und Anforderungseigenschaften gem. Kapitel5.2.2sowie eine Entscheidungsregel gemäß Kapitel5.3fest. Aus diesen Werten bestimmt der Algorithmus anschließend den relevanten Umweltzustand. Für jede Methode (vgl. Kapitel Fehler! Verweisquelle konnte nicht gefunden werden.) wird dann dem Umweltzustand entsprechend der Ergebnisvektor gemäß der in Kapitel5.2.3vorgestellten Bildungsvorschriften bestimmt. Hierbei finden die Methodenmerkmale Anwendung. Auf die Ergebnisvektoren wird im nächsten Schritt die ausgewählte Entscheidungsregel angewandt. In deren Ergebnis steht die optimale Schätzermethode, welche schließlich auszuwählen ist.

InAbbildung 10ist ein Algorithmus zur Erfassung von Erfahrungswerten dargestellt. Dieser besteht aus den drei Teilprozessen Schätzergebnis durch den Entscheider erfassen, Ergebnisse Anforderungsentwicklung durch die Entwickler erfassen und Speicherung der Erfahrungswerte durch einen Datenbankbeauftragten. Die Erfassung der Erfahrungswerte bildet dabei die Voraussetzung für deren Speicherung in der Erfahrungswert-DB.

Bei der Schätzung entsteht der Erfahrungswert durch Anwendung der selektierten Schätzmethode auf die zu entwickelnde Anforderung. Im Ergebnis liefert die Methode einen Schätzwert zum Entwicklungsaufwand sowie einen Wert für den Schätzaufwand. Beide Werte werden zusammen mit den Anforderungseigenschaften erfasst. In einem von der Schätzung unabhängigen Teilprozess setzen Entwickler die betrachtete Anwendung um. Dabei entsteht ein Entwicklungsaufwand. Dieser wird nach Abschluss der Umsetzung als Erfahrungswert zusammen mit den Anforderungseigenschaften erfasst. Bei Vorliegen beider Erfahrungswertbeiträge werden diese zusammen von einem Beauftragten in die Erfahrungswert-DB übertragen. Die Schätzgenauigkeit wird entsprechend der inGleichung 2beschriebenen Methode aus den Teilbeiträgen ermittelt und mit dem Schätzaufwand sowie den Anforderungseigenschaften in Beziehung gesetzt. Die Erfahrungswerte werden schließlich wieder im Auswahlalgorithmus bei der Erstellung der Ergebnisvektoren gemäß Kapitel5.2.3genutzt. Dabei soll ein BN zur Anwendung kommen, um die Eintrittswahrscheinlichkeiten der Merkmalsausprägungen zu bestimmen.

Abbildung 10 Erfahrungswertalgorithmus.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung, realisiert mit www.draw.io.

5.6 Modellierung der Erfahrungswert-Datenbank

In diesem Abschnitt wird eine Datenbank modelliert, die die Erfahrungswerte vergangener Projekte des Unternehmens bzw. von Referenzprojekten abspeichert und für den Auswahlalgorithmus zur Verfügung stellt. Die Modellierung richtet sich am Informationsbedürfnis dieses Falles aus. Er wird in Form eines Use Cases im ersten Teil dieses Abschnitts beschrieben. Bei der Modellierung wird dem in Kapitel4.2erarbeiteten Vorgehen gefolgt. Dementsprechend wird zunächst ein Datenmodell entworfen, das Auskunft über die zu speichernden Daten gibt (Informationsbedarf). Auf dieser Basis wird ein relationales Modell der Datenbank erstellt, welches anschließend physisch implementiert werden kann.

5.6.1 Datenbank-Use Case

Die Erfahrungswert-Datenbank soll Informationen für den Auswahlalgorithmus bereitstellen. Die benötigten Informationen beziehen sich auf Angaben, welche für die Auswahl von Schätzmethoden relevant sind.^[245] Dazu zählen sämtliche Angaben, die einen Vergleich mit der aktuell zu schätzenden Anforderung zur Feststellung der Ähnlichkeit ermöglichen. Aus diesem Vergleich werden im Zuge des Auswahlalgorithmus erwartbare Auswirkungen auf die Schätzungen der berücksichtigten Methoden ermittelt. Der entsprechende Use Case kann wie folgt formuliert werden:

„Der Algorithmus benötigt Informationen über die Schätzergebnisse einer Methode bei ähnlicher Konstellation der Anforderungseigenschaften, um daraus zu ermessen, wie sie bei der aktuellen Anforderung abschneidet. Die Schätzergebnisse sollen sich auf die aktuell gegebenen Auswahlkriterien sowie die Anforderungseigenschaften beziehen.“

Damit ergeben sich für die Datenbank zwei wesentliche Aufgaben: relevante Daten speichern und diese in geeigneter Form dem Algorithmus zur Verfügung stellen. Die Aufgaben sind im Erfahrungswertalgorithmus (Abbildung 10) bereits beschrieben worden. Im Folgenden kann aus diesen Informationen das Datenmodell aufgestellt werden.

5.6.2 Datenmodell

Der Entwurf des Datenmodells erfolgt in den vier Schritten Klassifizierung, Abstraktion, Identifizierung und Beschreibung der sachlogischen Zusammenhänge. Dabei werden die in Abbildung 8 hergestellten Zusammenhänge zwischen Eigenschaften von Anforderungen, Merkmalen adäquater Schätzung und Merkmalen von Aufwandsschätzer Verwendung finden. Die Ergebnisse sind nachfolgend entsprechend der vier Vorgehensschritte aufgelistet:

- Klassifizierung der Objekttypen, über die Informationen gespeichert werden sollen:

- die Anforderung als zu schätzendes Objekt,
- die Forderung an die Schätzmethode
- die angewandte Schätzmethode,
- die Schätzung und
- das Projekt.

Gemäß dem Use Case sind die Informationen über Forderungen an die Schätzmethode sowie über das Projekt nicht relevant für die Speicherung von Erfahrungswerten. Sie werden deshalb nicht weiter berücksichtigt. Dafür erscheint es sinnvoll die quantifizierbaren Erfahrungswerte (d.h. die Methodenmerkmale ‚Schätzgenauigkeit‘ und ‚Schätzaufwand‘) als eigenes Objekt zu behandelt.

- Abstraktion der Objekte bezüglich ihrer Objekteigenschaften, welche relevant zu berücksichtigen sind:^[246]

- Angaben zum Schätzobjekt: Entwicklungsaufwand (ermittelt nach Umsetzung), Projektressourcen, Anforderungsbeschreibung, Anforderungstyp/-spezialisierung,
- Angaben zur Schätzung: Ergebnis der Aufwandsschätzung, Schätzzeitpunkt, Parametereinstellungen gem. Auswahlkriterien,
- Angaben zur Schätzmethode: Name, Parametereinstellungen, erreichbare Genauigkeit, nötiger Schätzaufwand, Informationsbedarf, möglicher Einsatzzeitpunkt, Methodenspezialisierung, geforderte Dimension,
- Angaben zum Erfahrungswert: Schätzgenauigkeit (berechnet aus Entwicklungsaufwand und Ergebnis der Aufwandsschätzung), Schätzaufwand

Um Daten nicht redundant in der Datenbank halten zu müssen, wurden die entsprechenden Merkmale, ihrem genuinen Objekt zugeordnet.

- eindeutige Identifizierbarkeit der Objekte:

Die Unterscheidbarkeit der Objekte ist eine wesentliche Voraussetzung für deren Abbildung in der Datenbank und Nutzung als Datum. Die minimale Kombination von Eigenschaften und gerichteten Relationen, anhand der die Objekte identifiziert werden können, wird als Schlüssel bezeichnet.^[247] Die Schlüssel der Objekte werden jeweils unterstrichen. Bei den Objekten Anforderung, Schätzung und Erfahrungswert eigenen sich die Eigenschaften nicht für eine eindeutige Identifizierung. Sie werden als schwache Objekttypen bezeichnet.^[248] Die Konkretisierung dieses Schritts ist dem Datenmodell inAbbildung 11entnehmbar.

- Beschreibung der sachlogischen Zusammenhänge:

Dieser Schritt stellt inhaltliche Verbindungen zwischen den Objekten her, auf welchen später in der physischen Datenbank die Aggregation von Daten beruht. Die Konkretisierung dieses Schritts ist dem Datenmodell inAbbildung 11entnehmbar.

In der vorliegenden Anwendung bestehen mehrdimensionale Datenstrukturen. Sie können mithilfe komplexer Designsprachen, wie Application Design for Analytical Processing Technologies (ADAPT), in einem semantischen Modell abgebildet werden.^[249] ADAPT bietet Werkzeuge zur Unterstützung der Visualisierung geplanter und logischer Zusammenhänge von der semantischen bis zur physischen Ebene der Datenmodellierung. Allerdings entstehen auf diese Weise komplexe Diagramme, deren Lesart mitunter schwer verständlich ist.

Eine alternative Darstellung des Datenmodells erfolgt klassischerweise in der grafischen Sprache des Entity-Relationship-Modells (ER).^[250] Die Darstellungsmöglichkeiten mit ER werden auch für mehrdimensionale Anwendungen als ausreichend erachtet.^[251] Diese Notation ist im Folgenden zur Modellierung des semantischen Modells genutzt, ohne an dieser Stelle tiefer auf die Sprachelemente einzugehen.^[252] Das auf diese Weise beschriebene semantische Datenmodell ist inAbbildung 11gezeigt.

Abbildung 11 Datenmodell für die Erfahrungswert-DB.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung, realisiert mit www.draw.io.

5.6.3 Relationales Datenbank-Modell

Im relationalen Datenbank-Modell gelingt die mehrdimensionale Datenorganisation mit dem Fokus auf Datenanalyse durch Trennung von Fakten und Dimensionen in eigenen Tabellen. Fakten repräsentieren dabei für einen Geschäftsprozess wesentliche Kennzahlen. Sie sind quantifizierbar und können berechnet sein. Dimensionen hingegen ermöglichen über ihre Eigenschaften eine qualifizierte Ansicht der Fakten.^[253] Dieser Ansatz ist vergleichbar mit dem Datawarehouse-Konzept im Online Analytical Processing des Business Intelligence. Im Gegensatz zu Datenorganisationen, die auf Transaktionen optimiert sind, ist diese Form besonders geeignet für die Analyse-geprägte Informationsnutzung. Datenbanken können hier Suchanfragen, die eine Durchsuchung großer Datenmengen erfordern, effizienter bedienen.

Zusammen mit der Schätzung bildet der Erfahrungswert das quantitative Interesse des Use Case ab. Ohne ihre geeignete Aggregation, Gruppierung und Sortierung für die Prognose der Methodenperformanz wäre die Datenhaltung hinfällig. Sie repräsentieren deshalb die Fakten im vorliegenden Modell, wohingegen Methode und Anforderung die Dimension darstellen.

Um die Tabellen miteinander verknüpfen zu können, muss zunächst eine eindeutige Identifizierbarkeit der Objekte hergestellt werden. Dies gelingt über die Vergabe eines künstlichen Schlüssels (SK), der als Nummer (Integer) eingeführt wird. Aus Darstellungsgründen wird ein künstlicher Schlüssel auch bei der Tabelle des Objekts ‚Methode‘ angefügt.

Die Datentabellen weisen eine Verbindung zu den Faktentabellen der Form ‚1 zu optional viele‘ auf. Die Verknüpfung der Tabellen gelingt demnach über die Eintragung von Fremdschlüsseln (FK) in die Faktentabelle.^[254] Die Fremdschlüssel sind die Primärschlüssel der mit der Faktentabelle verknüpften Datentabellen. In diesem Fall sind die Primärschlüssel, als eindeutige Objekteigenschaften, gleichbedeutend mit den vergebenen künstlichen Schlüsseln. In der Abbildung 12 ist vor der entsprechenden Eigenschaft die Abkürzung ‚FK‘ angegeben.

Schließlich sind die Ausprägungen jeder Objekteigenschaft in einer Hierarchie abzubilden, wonach später die Fakten aggregiert, gruppiert und geordnet werden können.^[255] In der vorliegenden Aufgabenstellung besteht allerdings in keiner Objekteigenschaft eine natürliche Hierarchie, wonach die Fakten zusammenzustellen wären. Die inTabelle 9angezeigten Ausprägungen genügen dem hier zugrunde gelegten Use Case. Auf eine Hierarchisierung der Attribute wird deshalb verzichtet.

Das Relationale Datenbank-Modell wird in einem Galaxie-Schema präsentiert (Abbildung 12). In diesem stehen die beiden Faktentabellen im Zentrum und die Dimensionen sind außen herum gruppiert.^[256] Aufgrund der geringen Anzahl an Dimensionstabellen tritt der Effekt einer gesteigerten Übersichtlichkeit durch diese Darstellungsform hier allerdings nicht sonderlich deutlich zu Tage. Nachfolgend ist das Relationale Datenbank-Modell abgebildet.

Abbildung 12 Relationales Datenbank-Modell der Erfahrungsdatenbank.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung, realisiert mit www.draw.io.

Mit dieser Darstellung schließt die Konzeption der Schätzerauswahlmethode. Es wurde ein anforderungsbasierter Schätzerauswahl-Algorithmus vorgestellt, welcher Erfahrungswerte Datenbank-unterstützt geeignet berücksichtigen kann. Damit konnten die Forschungsfragen I d bis I e abgehandelt werden. Die Überprüfung des Konzepts anhand realer Projektdaten ist Gegenstand des im folgenden Kapitel vorgestellten Proof of Concept.

6 Proof of Concept: Anwendung der entwickelten Auswahlmethode

Das in Kapitel5erstellte Modell einer Auswahlmethode für objektive Anforderungsschätzer in der agilen Entwicklung soll nun im Rahmen eines Proof of Concept in der praktischen Anwendung getestet werden. Mit der in Anhang I vorgestellten Entwicklung des Aunex Data Service Portals steht ein reales Projekt als Anwendungsfall zur Verfügung. Das Modell soll anhand der in Kapitel4.3festgelegten Bewertungskriterien überprüft werden. Zunächst werden dazu die Entwicklungsanforderungen vorgestellt. Anschließend wird auf diese Anforderungen der in Matlab (R2018a) programmierte Auswahlalgorithmus angewandt und die Ergebnisse betrachtet.

6.1 Anforderungen

Im Rahmen der ersten Entwicklungsrunde (01.02.2018 bis 30.04.2018) wurden durch das Entwicklungsteam 50 Anforderungen umgesetzt. Die Entwicklung erfolgte hauptsächlich in der Programmiersprache JavaScript. In Anhang II ist eine vollständige Übersicht der Anforderungen und ihrer Eigenschaften festgehalten. Eine Zusammenfassung der Anforderungseigenschaften zeigtTabelle 12 . Insgesamt wurden für die Umsetzung der Anforderungen 388 Entwicklungsstunden verbraucht. Die Differenz zu den 408 vertraglich zugesicherten Stunden wurde für die wöchentlichen Meetings verbraucht.

Tabelle 12 Übersicht Eigenschaften Entwicklungsanforderungen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Die Häufigkeitsverteilung der Entwicklungsstunden pro Anforderung ist inAbbildung 13gezeigt.

Abbildung 13 Häufigkeitsverteilung der Entwicklungsstunden.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Die meisten Anforderungen haben weniger als fünf Entwicklungsstunden benötigt. Von diesen hat der überwiegende Teil (22 von 29) sogar weniger als eine Entwicklungsstunde benötigt. Hierbei handelte es sich häufig um Anpassungen in der Formulierung (11/22) oder die Behebung kleiner Fehler (4/22). Große und sehr große Anforderungen, deren Entwicklungszeit über 15 Stunden lag, machten insgesamt 16 % der Entwicklung aus (8/50). Zu ihnen gehörten der Aufbau der Geräte-Datenbank, die Implementierung der Registrierungs- und Anmeldefunktion sowie die Einrichtung einer Funktion zur Überwachung des Portals.

Eine weitere Aufschlüsselung der Anforderungen hinsichtlich der Verteilung von Typ und Spezialisierung bietetTabelle 13. Die Verteilung von Web/-Realtime-Anforderungen und anderen Spezialisierungen hält sich in etwa die Waage. Bei der Typenverteilung vereinen Kundenanforderungen und Systemanforderungen jeweils 2/5 aller Anforderungen auf sich. Das restliche Fünftel entfällt auf Designanforderungen. Während System- und Designanforderungen sich hinsichtlich der Spezialisierung die Waage halten, sind 2/3 aller Kundenanforderungen aus dem Web/Realtime-Bereich. Sie bilden damit die größte Gruppe in dieser Matrixbetrachtung. Ein Drittel der Kundenanforderungen entfällt entsprechend auf andere Spezialisierungen.

Die Auswahl eines geeigneten Schätzers mithilfe des in Kapitel 5 entworfenen Algorithmus sowie die damit realisierte Schätzung werden im nachfolgenden Abschnitt betrachtet.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

6.2 Anwendung des Auswahlalgorithmus

In diesem Abschnitt wird zunächst das Ergebnis des in Matlab programmierten Auswahlalgorithmus für jede Anforderung dargestellt. Anschließend werden die Schätzergebnisse präsentiert, welche mit der Schätzerauswahl realisiert werden konnten. Schließlich werden die Ergebnisse anhand der in Kapitel 4.3 festgelegten Bewertungskriterien evaluiert.

6.2.1 Anforderungsbezogene Auswahl der Schätzer

In Tabelle 14 ist für jede Anforderung (dargestellt über deren ID) das Ergebnis des Auswahlalgorithmus (durchgeführt jeweils einmal mit und einmal ohne Berücksichtigung von Erfahrungswerten) und das Ergebnis einer zufälligen Auswahl festgehalten.^[257] Die dem Auswahlalgorithmus zugrundeliegende Zielreihenfolge und Zielgewichtung, sowie die gewählte Entscheidungsregel sind ebenfalls angegeben. Dabei entsprechen die Angaben bei der Zielreihenfolge der Kriteriennummer aus Tabelle 9 (linke Spalte), ergänzt um den Anforderungstypen: 1 - Genauigkeit, 2 - Schätzaufwand, 3 - Anforderungstyp, 4 - Spezialisierung, 5 - Informationsbedarf, 6 - Einsatzzeitpunkt, 7 - Ergebnisdimension. Wird keine gesonderte Zielreihenfolge angegeben, ist in Tabelle 14 der Einheitsvektor eingetragen. Die Zielgewichtung ist als relatives Gewicht angegeben, mit einem Gesamtgewicht der Größe ‚1‘. Werden die Ziele nicht gesondert gewichtet, so erhält jede Auswahlkategorie denselben Zielbeitrag (entspricht einer Gleichgewichtung). In Tabelle 14 ist unter Zielgewichtung dann der entsprechende Gleichgewichtsvektor eingetragen.

Tabelle 14 Methodenauswahl durch Algorithmus (mit/ohne Erfahrung) und Zufall.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

6.2.2 Schätzergebnisse

Die folgendeTabelle 15führt die mit den Aufwandsschätzern erreichten Ergebnisse in den Kategorien Genauigkeit und Schätzaufwand auf. Die Ergebnisse sind für die drei Auswahlmethoden Algorithmus mit Erfahrung, Algorithmus ohne Erfahrung und zufällige Auswahl angegeben. Dabei folgt die Berechnung der GenauigkeitswerteGleichung 2. Sie bilden die Grundlage für die Evaluation der Ziele 4 und 5 des PoC.

Tabelle 15 Schätzergebnisse Genauigkeit und Schätzaufwand.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Die Werte ausTabelle 15werden anschließend zur Überprüfung der Hypothesen zur Genauigkeit (Gleichung 4) und zum Schätzaufwand (Gleichung 7) verwendet. Dabei sind nur diejenigen Anforderungen relevant, die einen entsprechenden Genauigkeits- bzw. Schätzaufwandsanspruch formulieren. Das Ergebnis der Hypothesentests ist inTabelle 16gezeigt.

Tabelle 16 Ergebnisse Hypothesentests.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Demnach ist für beide Ziele die Null-Hypothese zu verwerfen. Dies unterstützt die aufgestellten Alternativhypothesen.

6.2.3 Evaluation des Proof of Concept

Die Beurteilungskriterien des PoC (Tabelle 7) fordern, dass durch den Algorithmus durchgängig ein Schätzer ausgewählt wird, bei dem Auswahlkriterien und Erfahrungswerte berücksichtigt sind. Die Auswahl soll zudem in den Kriterien Genauigkeit und Aufwand einer zufälligen Schätzerauswahl überlegen sein.

Das erste Ziel, die durchgängige Auswahl eines Schätzers, ist mit Blick aufTabelle 14als erfüllt anzusehen. Allerdings unterscheidet sich der Algorithmus in diesem Punkt nicht von der zufälligen Schätzerauswahl. Vergleicht man die Schätzerauswahl durch Algorithmus mit der zufälligen Auswahl, so weist ersterer häufiger eine bessere Übereinstimmung mit den zuvor angelegten Auswahlkriterien auf (in 12 von 50 Fällen). Überwiegend ist allerdings ein identischer Übereinstimmungswert zu verzeichnen (in 29 von 50 Fällen). Davon unbenommen ist damit auch Ziel 2 als erfüllt zu bewerten.

Die Berücksichtigung von Erfahrungswerten bei der Schätzerauswahl (Ziel 3) innerhalb des Algorithmus hat primär zu einer Aktualisierung der Methodenmerkmale geführt, wie ausTabelle 17ersichtlich ist. Dort sind für alle Methoden die Werte für Genauigkeit und Schätzaufwand vor und nach dem Projekt gegenübergestellt. Die Änderungen der Ausprägungen lassen sich schließlich auf den Einfluss der Erfahrungswerte zurückführen.

Tabelle 17 Einfluss Erfahrung auf Methodenmerkmale.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Weiterhin sei beispielhaft für das Merkmal Genauigkeit der Einfluss der Erfahrungswerte gezeigt. InAbbildung 14ist die Anzahl an Anforderungen höherer Genauigkeit für die Schätzerauswahl mit Erfahrungswerten (dunkelgrau) und ohne (hellgrau) kumuliert dargestellt. Der steilere Anstieg für den Fall einer Algorithmen-basierten Auswahl mit Erfahrungswerten im Vergleich zur Auswahl ohne Erfahrungswerte ist deutlich erkennbar.

Abbildung 14 Genauigkeit der Schätzer nach Auswahl durch Algorithmus.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Abschließend sind die Ziele 4 und 5 des PoC zu erörtern. InTabelle 16sind die Ergebnisse der Hypothesentests für beide Ziele festgehalten. Die Null-Hypothesen sind demnach zu verwerfen und die Alternativhypothesen zu unterstützen. Damit sind die durch Algorithmus bestimmten Schätzer den zufällig ausgewählten in den Merkmalen Genauigkeit und Schätzaufwand signifikant überlegen und die Ziele 4 und 5 erfüllt.

Eine abschließende Zusammenfassung der Evaluierungsergebnisse des PoC bietetTabelle 18. Kein Ziel erfüllt in seiner Bewertung ein Falsifizierungskriterium. Demnach sind sämtliche Ziele des PoC erreicht.

Tabelle 18 Evaluierungsergebnisse PoC.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

In diesem Kapitel wurde der Auswahlalgorithmus einer realen Anwendung unterzogen und seine Wirksamkeit im Rahmen eines PoC ermittelt. Dazu wurden die Auswahlergebnisse entlang der in Kapitel4.3erarbeiteten Bewertungskriterien überprüft. Im Ergebnis hat der Algorithmus sämtliche Ziele des PoC erfüllt. Diese Ergebnisse repräsentieren gleichsam die Antwort auf Forschungsfrage II. Dennoch besteht zu einer Reihe von Aspekten den Algorithmus betreffend Diskussionsbedarf, auf welchen im folgenden Kapitel7näher eingegangen wird.

7 Diskussion der Auswahlergebnisse

Im Anschluss an den erfolgten PoC werden in diesem Kapitel die Ergebnisse der vorliegenden Arbeit hinsichtlich ihrer Validität und Generalisierbarkeit diskutiert. Dabei wird eine Reihe von Aspekten aufgegriffen, die im Auswahlalgorithmus nicht abgebildet wurden bzw. potenziell die Aussagekraft der Ergebnisse beeinflussen. Die Aspekte können zwei Themenblöcken zugeordnet werden. Der erste umfasst die Implementierung des Algorithmus. Der zweite Themenbereich adressiert die Berechnung der Schätzergebnisse. Sie werden im Folgenden nacheinander betrachtet.

In dieser Arbeit konnte aus dem Bedürfnis nach einer geeigneten Auswahl von objektiven Aufwandsschätzmethoden in agilen Entwicklungsprojekten ein Algorithmus entwickelt werden, welcher dieses Vorhaben unterstützt. Neben den Anforderungszielen werden dabei auch Erfahrungswerte im Umgang mit den Methoden berücksichtigt. Der PoC hat die Wirksamkeit des Algorithmus für die Anwendung in einem realen Projekt bestätigt. So konnte bei entsprechender Priorisierung gegenüber einer zufälligen Schätzerauswahl die Schätzgenauigkeit signifikant erhöht bzw. der Schätzaufwand signifikant verringert werden.

Allerdings ergaben sich bei der Implementierung des Algorithmus bereits Einschränkungen, welche die Auswahl der Methoden wesentlich beeinflussen. Aus der Literatur konnten bezüglich der Methodeneigenschaften sechs Merkmalskategorien abgeleitet werden, deren Ausprägungen ordinal bzw. nominal skaliert sind. Dabei besteht eine so geringe Anzahl an Ausprägungen, dass die Methoden anhand der Auswahlkriterien nicht eineindeutig identifizierbar sind. Der implementierte Ansatz, für Genauigkeit und Schätzaufwand eine Kardinalskalierung zu nutzen, hat sich diesbezüglich bewährt, um eine bessere Differenzierung zu erhalten. Dennoch besteht insbesondere zu Projektbeginn lediglich der Rückgriff auf die schwer miteinander vergleichbaren Literaturangaben. Die zufällige Auswahl eines Schätzers aus dem Kreis derer, die den Auswahlkriterien am besten entsprechen, erschien diesbezüglich zwar pragmatisch. Eine Erweiterung des Satzes von Auswahlkriterien, bzw. berücksichtigenswerten Methodenmerkmalen, sollte dennoch in Betracht gezogen werden.

In Projekten mit einem höheren Aufkommen an Anforderungen werden schnell entsprechende Erfahrungswerte geniert, die zur Schätzerauswahl herangezogen werden können. Bezogen auf das Gesamtprojekt wird sich das Problem also vergleichsweise zügig von selbst lösen. Auch ein bestehendes Reservoir an entsprechenden Erfahrungswerten bezüglich der eingesetzten Methoden kann diesem Problem Abhilfe verschaffen. Der Mangel an frei zugänglichen Erfahrungswertrepositorien zu Entwicklungsaufwänden in agilen Projekten auf der Basis von Anforderungen zeigt sich an dieser Stelle allerdings sehr deutlich.

Damit unmittelbar verbunden sind Effektivität und Effizienz des Einsatzes von ML-Techniken und der Analogieschätzung. Diese benötigen ein Minimum an Trainingsdaten als Bezugsrahmen, um ihre Schätzung überhaupt durchzuführen zu können. Generell gilt: je größer der Erfahrungsdatensatz, desto höher ihre Vorhersagegenauigkeit. Zu Beginn eines Projekts, wenn noch keine Erfahrungswerte existieren, ist der Einsatz dieser Methoden folglich entweder nicht möglich oder die Schätzwerte sind ungenau. Der Algorithmus reagiert darauf, indem er die Auswahl dieser Schätzer vom Vorhandensein entsprechend großer Erfahrungswertdatensätze abhängig macht.

Bei der Konzeption des Algorithmus wurden weiterhin Festlegungen getroffen, die den Auswahlprozess unmittelbar beeinflussen, aber durchaus optional sind. Dazu zählt die Messung der Genauigkeit in MMRE, sowie des Schätzaufwands in Zeitwerten. Sie sind aus pragmatischen Gründen ausgewählt worden, können aber ohne großen Aufwand im Algorithmus durch andere Messmethoden ausgetauscht werden ohne die grundlegende Funktionsweise zu ändern. Ähnliches ist zu berichten von der Bewertung von Erfahrungswerten beim Aktualisieren der Methodeneigenschaften. Momentan werden sämtliche Erfahrungswerte gleichgewichtet. So sind die aus der Literatur abgeleiteten Werte genauso wichtig, wie die der ersten Aufwandsschätzung im Projekt. In Abhängigkeit von der Bewertung der Qualität der vorliegenden Methodeneigenschaften, lässt sich ohne weiteres eine alternative Gewichtung realisieren.

Die Implementierung des Algorithmus in Matlab (R2018a) hat sich aufgrund der großen Funktionsbibliothek bewährt. Der Implementierungsaufwand hat sich damit merklich reduziert, verglichen mit einer eigenständigen Programmierung der Funktionen. Sowohl der Algorithmus selbst als auch die Aufwandsschätzung durch ML-Techniken haben von dem vorhandenen Funktionsumfang profitiert. Die Kombination des Algorithmus mit Excel, als Datenhort für Aufwandsschätzungen ohne ML-Beteiligung erfolgte durch das Import-Tool von Matlab problemlos. Da der Algorithmus allerdings auf keinerlei Matlab-spezifische Funktionen angewiesen ist, kann man davon auszugehen, dass die Implementierung in anderen Entwicklungsumgebungen ebenfalls zum gewünschten Resultat führen würde.

Weiterhin gibt der Bereich der Schätzergebnisse Anlass zur Diskussion. Abgesehen von den ML-Techniken, nutzten die Schätzer die Metrik Use Case Points zur Bestimmung ihrer Schätzwerte. Da dies durchgängig für alle Anforderungen eingehalten wurde, kann man von einer konsistenten Bewertungsgrundlage ausgehen. Allerdings ist die Behauptung legitim, dass andere Metriken zur Größenbestimmung der Anforderungen möglicherweise zu besseren Schätzergebnissen geführt hätten. Dieser Umstand konnte im Rahmen dieser Arbeit nicht widerlegt werden, war allerdings auch nicht Gegenstand der Untersuchung.

Der Auswahlalgorithmus arbeitet zunächst unabhängig von der eingesetzten Größenmetrik. Da sie allerdings Einfluss auf das Schätzergebnis und dieses wiederum als Erfahrungswert Einfluss auf die Methodeneigenschaften besitzt, ist eine konsistente Wertermittlung notwendig. Die Methodeneigenschaften werden dann relativ zum eingesetzten Methodenset durch Erfahrungswerte aktualisiert. Das bedeutet, dass die zugewiesenen Merkmalsattribute auf Grundlage aller zu den Methoden ermittelten Erfahrungswerten bestimmt werden - im Gegensatz zu einem absolut festgelegten Bezugsrahmen, wie ihn Conte et al (1986) vorschlagen.^[258] Damit könnte auch jede andere Metrik zur Größenbestimmung herangezogen werden. Die oben festgelegte Methode schränkt die Allgemeingültigkeit der Auswahlergebnisse des Algorithmus jedenfalls nicht ein.

Die Repräsentativität der Projektanforderungen ist ein weiterer Punkt bei der Bestimmung der Generalisierbarkeit der Auswahlergebnisse. In Kapitel3.1wurden aus der Literatur die grundsätzlichen Eigenschaftskategorien von Anforderungen in der agilen Softwareentwicklung herausgearbeiteten. Diese Auswahl stellt den Stand der Forschung dar. Jedoch ist der Einwand statthaft, dass sich sowohl weitere Kategorien, als auch weitere Ausprägungen der Kategorien finden lassen, die in konkreten Projekten zur differenzierten Schätzerauswahl beitragen können. In diesem Fall bedarf es einer Anpassung des Algorithmus hinsichtlich der Dimensionen des implementierten Entscheidungsproblems. Diese Anpassung hätte sicherlich eine andere Schätzerauswahl zur Folge. Die Lösungsweise des Problems wird davon allerdings nicht berührt. An der Wirksamkeit des Algorithmus ändert eine dergestaltige Modifizierung deshalb grundsätzlich nichts. Die hier präsentierten Ergebnisse sind allerdings vor dem Hintergrund der diesem Entscheidungsproblem zugrundeliegenden Anforderungseigenschaften zu bewerten.

Die betrachteten Anforderungen bilden hinsichtlich ihrer Eigenschaften das gesamte Spektrum dahingehend ab, dass jede Merkmalsausprägung mindestens einmal vorkommt. Allerdings ist die Häufigkeitsverteilung der Ausprägungen nicht ausgeglichen. Auch sind nicht sämtliche möglichen Merkmalskombinationen im Projektdatensatz vorhanden. Demnach existiert Unsicherheit bezüglich der Effektivität des Algorithmus. Es besteht allerdings kein Anlass zur Vermutung, der Algorithmus würde unter anderen Merkmalskombinationen der Anforderungen kein Ergebnis oder ein Ergebnis ohne Berücksichtigung der Auswahlkriterien erbringen. Die Konstruktion der implementierten Auswahlmethoden steht dieser Vermutung entgegen. Die Anzahl der Anforderungen war zudem ausreichend für eine statistische Evaluierung der Effizienz des Algorithmus im Hinblick auf Genauigkeit und Schätzaufwand.

Was die vorliegende Betrachtung nicht abschließend zu klären vermochte ist die Frage, ob die eingesetzten Methoden zu befriedigenden Schätzergebnissen geführt haben. Diese sind allerdings weniger vom Auswahlalgorithmus und mehr von ihrer eigenen Konzeption und den verfügbaren Erfahrungswerten abhängig. Eine Erweiterung des Pools an Schätzmethoden ist in diesem Zusammenhang generell stets möglich. Sie geht mit einer Änderung des Aktionsraums des Entscheidungsproblems einher.

Insgesamt kann deshalb festgestellt werden, dass die Auswahlergebnisse des Algorithmus im PoC bereits dessen Wirksamkeit belegen. Eine Verbesserung durch Anpassung in den oben angesprochenen Punkten ist davon unbenommen. Abschließend kann damit konstatiert werden, dass die im Rahmen des PoC ermittelten Ergebnisse für die Feststellung einer generellen Anwendbar- und Wirksamkeit des Algorithmus ausreichen. Er eignet sich prinzipiell für eine Kriterien-gestützte Auswahl von objektiven Schätzmethoden in agilen SE-Projekten. Damit ist abschließend Forschungsfrage III beantwortet.

8 Zusammenfassung und Fazit

Product Owner in agilen SE-Projekten stehen regelmäßig vor der Herausforderung, die geforderte Entwicklungsleistung externer Dienstleister durch geeignete Aufwandsschätzung der Anforderungen zu steuern und zu kontrollieren. Bestehen keine Erfahrungswerte muss zu diesem Zwecke auf objektive Schätzmethoden zurückgegriffen werden. Diese unterscheiden sich allerdings in ihrer Effektivität und Effizienz voneinander. Eine strukturierte Auswahl einer Schätzmethode erscheint vor diesem Hintergrund vorteilhaft. Das Ziel dieser Arbeit bestand in der Entwicklung eines Hilfsmittels zur Auswahlunterstützung von objektiven Schätzmethoden in agilen SE-Projekten.

Aus dem aktuellen Stand der Forschung wurden dazu zunächst die einer Auswahl zugrundeliegenden relevanten Eigenschaften von Entwicklungsanforderungen sowie von objektiven Aufwandsschätzverfahren bestimmt. Damit einhergehend wurde der Einsatz von Erfahrungswerten zur Optimierung der Steuerung von Entwicklungsanforderungen besprochen. Auf dieser Grundlage wurde die Schätzerauswahl als Entscheidungsproblem modelliert und der Auswahlalgorithmus aufgestellt. Dieser berücksichtigt Auswahlkriterien, welche sich an den relevanten Eigenschaften der Entwicklungsanforderungen orientieren.

Anschließend kam der Algorithmus im Rahmen eines PoC in einem realen Projekt, der Entwicklung eines B2B-Dataservice Portals, zum Einsatz. Auf der Grundlage festgelegter Auswahlkriterien wurden für 50 Entwicklungsanforderungen mithilfe des Algorithmus anschließend die jeweils geeigneten Aufwandsschätzer bestimmt. Zur Evaluierung der Effektivität und Effizienz des Algorithmus wurden zusätzlich für die gleichen Anforderungen jeweils ein Schätzer mit dem Algorithmus ohne Berücksichtigung von Erfahrungswerten und eine zufällige Methode ausgewählt. Im Vergleich dieser drei Auswahlmethoden schnitt der Algorithmus mit Berücksichtigung von Erfahrungswerten am besten ab.

Der Algorithmus erfüllt damit alle vom PoC vorgegebenen Ziele. Sein Einsatz in agilen SE-Projekten kann die Evaluierungstätigkeit des Product-Owner bei der Abschätzung von Entwicklungsleistungen bedeutend vereinfachen und das Ergebnis verbessern. Es bleibt abzuwarten, ob sich der Algorithmus auch in anderen Projekten bewährt. Sicherlich werden Erfahrungen aus der praktischen Anwendung weitere Verbesserungen in der Performanz und der Handhabbarkeit ermöglichen. Vielleicht kann so zukünftig auf subjektive Schätzer gänzlich verzichtet werden.

Quellenverzeichnis

Abrahamsson, Pekka, Outi Salo, Jussi Ronkainen, und Juhani Warsta. 2002. Agile software development methodsReview and analysis. arXiv preprint arXiv:1709.08439

Adnan, Muhammad, und Muhammad Afzal. 2017. Ontology Based Multiagent Effort Estimation System for Scrum Agile Method. IEEE Access 5:25993–26005. doi: 10.1109/ACCESS.2017.2771257

Ahram, Tareq, and Waldemar Karwowski (eds.). 2018. Advances in Human Factors, Software, and Systems Engineering, Los Angeles, 17 - 21 Juli 2017. Cham, Switzerland: Springer International Publishing

Anderson, D. J., et al. 2018. Die Essenz von Kanban kompakt. Heidelberg: dpunkt.verlag

Ariely, Dan, und Dan Zakay. 2001. A timely account of the role of duration in decision making. acta psychologica 108 (2): 187–207. doi: 10.1016/S0001-6918(01)00034-8

Atkinson, Roger. 1999. Project managementCost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria. International journal of project management 17 (6): 337–342

AXELOS Limited. 2014. Erfolgreiche Projekte managen mit PRINCE2. London: TSO

Azhar, Damir, Emilia Mendes, und Patricia Riddle. 2012. A systematic review of web resource estimation. In Proceedings of the 8th International Conference on Predictive Models in Software Engineering, 49–58. the 8th International Conference, Lund, Sweden. 9/21/2012 - 9/22/2012. New York, NY: ACM. doi: 10.1145/2365324.2365332

Baumgartner, M., et al. 2017. Agile testingDer agile Weg zur Qualität: Carl Hanser Verlag GmbH Co KG

Boehm, B. W. 1981. Software engineering economics

Book, Matthias, Volker Gruhn, und Rüdiger Striemer (Hrsg.). 2017. Erfolgreiche agile ProjektePragmatische Kooperation und faires Contracting. Berlin: Springer Vieweg

Britto, Ricardo, Emilia Mendes, und Jurgen Borstler. 2015. An Empirical Investigation on Effort Estimation in Agile Global Software Development. In Proceedings of the IEEE 10th International Conference on Global Software Engineering (ICGSE), 38–45. IEEE 10th International Conference on Global Software Engineering, Ciudad Real, Spain. 13 - 16 July. Piscataway, NJ: IEEE. doi: 10.1109/ICGSE.2015.10

Britto, Ricardo, Muhammad Usman, und Emilia Mendes. 2017. A taxonomy of web effort predictors. Journal of Web Engineering 16 (7-8): 541–570

Bronštejn, I. N., et al. 2006. Taschenbuch der Mathematik, 6. Aufl. Frankfurt am Main: Deutsch

Broy, M., et al. 2013. Projektorganisation und Management im Software Engineering: Springer

Čeke, Denis, und Boris Milašinović. 2015. Automated web application functional size estimation based on a conceptual model. In 2015 23rd International Conference on Software, Telecommunications and Computer Networks (SoftCOM), 234–241. 2015 23rd International Conference on Software, Telecommunications and Computer Networks (SoftCOM), Split, Croatia. 9/16/2015 - 9/18/2015: IEEE / Institute of Electrical and Electronics Engineers Incorporated. doi: 10.1109/SOFTCOM.2015.7314074

Čeke, Denis, und Boris Milašinović. 2015. Early effort estimation in web application development. Journal of Systems and Software 103:219–237. doi: 10.1016/j.jss.2015.02.006

Celar, S., L. Vickovic, und E. Mudnic. 2012. Evolutionary measurement-estimation method for micro, small and medium-sized enterprises based on estimation objects. Advances in Production Engineering & Management 7 (2): 81–92. doi: 10.14743/apem2012.2.132

Cerpa, Narciso, Matthew Bardeen, César A. Astudillo, und June Verner. 2016. Evaluating different families of prediction methods for estimating software project outcomes. Journal of Systems and Software 112:48–64

Choi, Jae, und Maeve L. Cummings. 2016. Outcome-based Contract Model for IT OutsourcingA System Dynamic Approach. Issues in Information Systems 17 (2)

Cohn, M. 2005. Agile estimating and planning: Pearson Education

Conte, S. D., et al. 1986. Software engineering metrics and models. Menlo Park, Calif.: Benjamin/Cummings

Coombs, Clyde Hamilton, Robyn M. Dawes, Amos Tversky, Dirk Wendt, und Coombs-Dawes-Tversky (Hrsg.). 1975. Mathematische PsychologieEine Einführung. Weinheim: Beltz

Curcio, Karina, Tiago Navarro, Andreia Malucelli, und Sheila Reinehr. 2018. Requirements engineering: A systematic mapping study in agile software development. Journal of Systems and Software 139:32–50. doi: 10.1016/j.jss.2018.01.036

Dhir, Saru, Deepak Kumar, und V. B. Singh. 2017. An estimation technique in agile archetype using story points and function point analysis. International Journal of Process Management and Benchmarking 7 (4): 518–539. doi: 10.1504/IJPMB.2017.086933

Di Martino, Sergio, Filomena Ferrucci, Carmine Gravino, und Federica Sarro. 2016. Web Effort EstimationFunction Point Analysis vs. COSMIC. Information and Software Technology 72:90–109. doi: 10.1016/j.infsof.2015.12.001

Dörn, S. 2018. Programmieren für Ingenieure und Naturwissenschaftler. Berlin, Heidelberg: Springer Berlin Heidelberg

Dragicevic, Srdjana, Stipe Celar, und Mili Turic. 2017. Bayesian network model for task effort estimation in agile software development. Journal of Systems and Software 127:109–119. doi: 10.1016/j.jss.2017.01.027

Fishburn, Peter C. 1974. Exceptional paper—Lexicographic orders, utilities and decision rules: A survey. Management science 20 (11): 1442–1471

Foss, T., E. Stensrud, B. Kitchenham, und I. Myrtveit. 2003. A simulation study of the model evaluation criterion mmre. IEEE Transactions on software engineering 29 (11): 985–995. doi: 10.1109/TSE.2003.1245300

Garg, Sakshi, und Daya Gupta. 2015. PCA based cost estimation model for agile software development projects. In International Conference on Industrial Engineering and Operations Management (IEOM), 2015: 3 - 5 March 2015, Hyatt Regency, Dubai, United Arab Emirates, 1–7. 2015 International Conference on Industrial Engineering and Operations Management (IEOM), Dubai. 3/3/2015 - 5/3/2015. Piscataway, NJ, Piscataway, NJ: IEEE. doi: 10.1109/IEOM.2015.7228109

Garmus, David, und David Herron. 2001. Function Point AnalysisMeasurement Practices for Successful Software Projects

González-Barahona, Jesús M., und Gregorio Robles. 2012. On the reproducibility of empirical software engineering studies based on data retrieved from development repositories. Empirical Software Engineering 17 (1-2): 75–89

Hahne, Michael. 2006. Mehrdimensionale Datenmodellierung für analyseorientierte Informationssysteme. In Analytische Informationssysteme: Business Intelligence-Technologien und -Anwendungen, Hrsg. Peter Chamoni, 177–206. Wiesbaden: Springer-Verlag

Huan, Xu, C. Caramanis, und S. Mannor. 2012. Sparse Algorithms Are Not Stable: A No-Free-Lunch Theorem. IEEE transactions on pattern analysis and machine intelligence 34 (1): 187–193. doi: 10.1109/TPAMI.2011.177

Hummel, O. 2013. Aufwandsschätzungen in der Software- und Systementwicklung kompakt. Heidelberg: Spektrum, Akad. Verl.

Hummel, Oliver, und Robert Heinrich. 2013. Towards Automated Software Project Planning. Institute for Program Structures and Data Organization 2:11

ISO/IEC. 2011. Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models 35.080. https://www.iso.org/standard/35733.html. Zugegriffen: 28. Juni 2018

ISO/TC. 2012. Guidance on project management. https://www.iso.org/obp/ui/#iso:std:iso:21500:ed-1:v1:en. Zugegriffen: 2. Juli 2018

Jarosch, H. 2016. Grundkurs Datenbankentwurf. Wiesbaden: Springer Fachmedien Wiesbaden

Johnson, Eric J., und John W. Payne. 1985. Effort and Accuracy in Choice. Management science 31 (4): 395–414

Jorgensen, Magne, und Martin Shepperd. 2007. A Systematic Review of Software Development Cost Estimation Studies. IEEE Transactions on software engineering 33 (1): 33–53. doi: 10.1109/TSE.2007.256943

Jørgensen, Magne. 2016. Unit effects in software project effort estimationWork-hours gives lower effort estimates than workdays. Journal of Systems and Software 117:274–281

Kleuker, S. 2013. Grundkurs Software-Engineering mit UML. Wiesbaden: Springer Fachmedien Wiesbaden

Kocaguneli, Ekrem, Tim Menzies, und Jacky W. Keung. 2012. On the Value of Ensemble Effort Estimation. IEEE Transactions on software engineering 38 (6): 1403–1416. doi: 10.1109/TSE.2011.111

Krcmar, H. 2015. Einführung in das Informationsmanagement. Berlin, Heidelberg: Springer Berlin Heidelberg

Kupiainen, Eetu, Mika V. Mäntylä, und Juha Itkonen. 2015. Using metrics in Agile and Lean Software Development – A systematic literature review of industrial studies. Information and Software Technology 62:143–163. doi: 10.1016/j.infsof.2015.02.005

Lappi, Teemu, und Kirsi Aaltonen. 2017. Project governance in public sector agile software projects. International Journal of Managing Projects in Business 10 (2): 263–294. doi: 10.1108/IJMPB-04-2016-0031

Laux, H., et al. 2014. Entscheidungstheorie. Berlin, Heidelberg: Springer Berlin Heidelberg

Lee, Taeho, Taewan Gu, und Jongmoon Baik. 2014. MND-SCEMP: an empirical study of a software cost estimation modeling process in the defense domain. Empirical Software Engineering 19 (1): 213–240. doi: 10.1007/s10664-012-9220-1

Lusky, Maria, Christoph Powilat, und Stephan Böhm. 2018. Software Cost Estimation for User-Centered Mobile App Development in Large Enterprises. In Advances in Human Factors, Software, and Systems Engineering, 51–62, Los Angeles. 17 - 21 Juli 2017. Cham, Switzerland: Springer International Publishing

Mahboob, Tahira, Sabheen Gull, Sidrish Ehsan, und Bushra Sikandar. 2017. Predictive Approach towards Software Effort Estimation using Evolutionary Support Vector Machine. INTERNATIONAL JOURNAL OF ADVANCED COMPUTER SCIENCE AND APPLICATIONS 8 (5): 446–454

Mair, Carolyn, Gada Kadoda, Martin Lefley, Keith Phalp, Chris Schofield, Martin Shepperd, und Steve Webster. 2000. An investigation of machine learning based prediction systems. Journal of Systems and Software 53 (1): 23–29. doi: 10.1016/S0164-1212(00)00005-4

Mendes, Emilia. 2007. A Comparison of Techniques for Web Effort Estimation. In Proceedings / First International Symposium on Empirical Software Engineering and Measurement, ESEM 2007: Madrid, Spain, 20 - 21 September 2007, 334–343. First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), Madrid, Spain. 9/20/2007 - 9/21/2007. Piscataway, NJ: IEEE. doi: 10.1109/ESEM.2007.14

Müller, R. M., et al. 2013. Business Intelligence. Berlin, Heidelberg: Springer Berlin Heidelberg

Nguyen, Dan Schilling, und others. 2016. Success Factors for Building and Managing High Performance Agile Software Development Teams. International Journal of Computer (IJC) 20 (1): 51–82

North, K. 2016. Wissensorientierte Unternehmensführung. Wiesbaden: Springer Fachmedien Wiesbaden

Opelt, A., et al. 2014. Der agile FestpreisLeitfaden für wirklich erfolgreiche IT-Projekt-Verträge: Carl Hanser Verlag GmbH Co KG

Owais, Mohd., und R. Ramakishore. 2016. Effort, duration and cost estimation in agile software development. In 2016 Ninth International Conference on Contemporary Computing (IC3): 11-13 August 2016, Jaypee Institute of Information Technology, Noida, India, 1–5. 2016 Ninth International Conference on Contemporary Computing (IC3), Noida, India. [Piscataway, New Jersey]: IEEE. doi: 10.1109/IC3.2016.7880216

Özden, Müge, und Sona Mardikyan. 2016. Factors leading to the Success of Agile Project Management. akıllı teknoloji & akıllı yönetim 89–99

Pfeifer, T., et al. 2014. Masing Handbuch Qualitätsmanagement. s.l.: Carl Hanser Fachbuchverlag

Pichler, R. 2010. Agile Product Management with ScrumCreating Products that Customers Love (Adobe Reader): Addison-Wesley Professional

Pilios, Emmanouil. 2015. Contracting practices in traditional and agile software developmentMaster Thesis. Master Thesis, Universität Leiden, Leiden

Pillai, Sreekumar P., S. D. Madhukumar, und T. Radharamanan. 2017. Consolidating evidence based studies in software cost/effort estimation — A tertiary study. In TENCON 2017 - 2017 IEEE Region 10 Conference: 5-8 Nov. 2017, 833–838. TENCON 2017 - 2017 IEEE Region 10 Conference, Penang. 11/5/2017 - 11/8/2017. [Piscataway, NJ]: IEEE. doi: 10.1109/TENCON.2017.8227974

Poensgen, B. 2012. Function-Point-AnalyseEin Praxishandbuch: dpunkt. verlag

Pospieszny, Przemyslaw, Beata Czarnacka-Chrobot, und Andrzej Kobylinski. 2018. An effective approach for software project effort and duration estimation with machine learning algorithms. Journal of Systems and Software 137:184–196. doi: 10.1016/j.jss.2017.11.066

Radlinski, Lukasz. 2010. A survey of bayesian net models for software development effort prediction. International Journal of Software Engineering and Computing 2 (2): 95–109

Reichenberger, K. 2010. Kompendium semantische Netze. Berlin, Heidelberg: Springer Berlin Heidelberg

Resmi, V., S. Vijayalakshmi, und R. Subash Chandrabose. 2017. An effective software project effort estimation system using optimal firefly algorithm. Cluster Computing 1–10

Robertson, S., et al. 2013. Mastering the requirements processGetting requirements right, 3. Aufl. Upper Saddle River, N.J: Addison-Wesley

Rumsey, D. J. 2010. Statistics essentials for dummies: John Wiley & Sons

Rupp, C., et al. 2012. UML 2 glasklarPraxiswissen für die UML-Modellierung, 4. Aufl. München: Hanser

Rupp, C. 2014. Requirements-Engineering und -ManagementAus der Praxis von klassisch bis agil, 6. Aufl. München: Hanser

Rupp, C., et al. 2015. Basiswissen Requirements EngineeringAus-und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level: dpunkt. verlag

Satapathy, Shashank Mouli, und Santanu Kumar Rath. 2016. Effort estimation of web-based applications using machine learning techniques. In 2016 International Conference on Advances in Computing, Communications and Informatics (ICACCI): September 21-24, 2016, the LNM Institute of Information Technology (LNMIT), Jaipur, India, 973–979. 2016 International Conference on Advances in Computing, Communications and Informatics (ICACCI), Jaipur, India. 9/21/2016 - 9/24/2016. Piscataway, NJ: IEEE. doi: 10.1109/ICACCI.2016.7732171

Schmidt, G. 2012. Prozessmanagement. Berlin, Heidelberg: Springer Berlin Heidelberg

Schneeweiß, Hans. 1966. Das Grundmodell der Entscheidungstheorie. Statistische Hefte 7 (3-4): 125–137. doi: 10.1007/BF02922952

Schoemaker, Paul J. H. 1982. The Expected Utility Model: Its Variants, Purposes, Evidence and Limitations. Journal of Economic Literature 20 (2): 529–563

Schwaber, K., et al. 2002. Agile software development with Scrum: Prentice Hall Upper Saddle River

Sharma, Narendra, Aman Bajpai, und Ratnesh Litoriya. 2012. A Comparison of software cost estimation methods: A Survey. The International Journal of Computer Science and Applications (TIJCSA) 1 (3)

Shepperd, Martin, und Chris Schofield. 1997. Estimating software project effort using analogies. IEEE Transactions on software engineering 23 (11): 736–743

Silhavy, Radek, Petr Silhavy, und Zdenka Prokopova. 2017. Analysis and selection of a regression model for the Use Case Points method using a stepwise approach. Journal of Systems and Software 125:1–14. doi: 10.1016/j.jss.2016.11.029

Tanveer, Binish, Liliana Guzmán, und Ulf Martin Engel. 2017. Effort estimation in agile software developmentCase study and improvement framework. Journal of Software: Evolution and Process 29 (11)

tevim UG. 2017. AGB

tevim UG. 2018. Angebot

Top, Ozden Ozcan, Baris Ozkan, Mina Nabi, und Onur Demirors. 2011. Internal and External Software Benchmark Repository Utilization for Effort Estimation. In Joint conference of the 21st Int‘l Workshop on Software Measurement, 2011 and 6th Int‘l Conference on Software Process and Product Measurement (IWSM-MENSURA): 3 - 4 Nov. 2011, Nara, Japan ; proceedings, 302–307. 2011 Joint Conf of 21st Int‘l Workshop on Software Measurement and the 6th Int‘l Conference on Software Process and Product Measurement (IWSM-MENSURA), Nara, Japan. 11/3/2011 - 11/4/2011. Piscataway, NJ: IEEE. doi: 10.1109/IWSM-MENSURA.2011.41

Torrecilla-Salinas, C. J., J. Sedeño, M. J. Escalona, und M. Mejías. 2015. Estimating, planning and managing Agile Web development projects under a value-based perspective. Information and Software Technology 61:124–144. doi: 10.1016/j.infsof.2015.01.006

Tversky, Amos. 1972. Elimination by aspects: A theory of choice. Psychological Review 79 (4): 281–299. doi: 10.1037/h0032955

Usman, Muhammad, Ricardo Britto, Lars-Ola Damm, und Jürgen Börstler. 2018. Effort Estimation in Large-Scale Software DevelopmentAn Industrial Case Study. Information and Software Technology. doi: 10.1016/j.infsof.2018.02.009

Usman, Muhammad, Emilia Mendes, Francila Weidt, und Ricardo Britto. 2014. Effort estimation in agile software development. In 10th International Conference on Predictive Models in Software Engineering (PROMISE 2014): September 17, 2014, Turin, Italy, 82–91. the 10th International Conference, Turin, Italy. New York, New York: Association for Computing Machinery. doi: 10.1145/2639490.2639503

Valentini, U., et al. 2013. Requirements Engineering und Projektmanagement. Berlin, Heidelberg: Springer Berlin Heidelberg

Venkatesh, Viswanath, Arun Rai, und Likoebe M. Maruping. 2017. Information Systems Projects and Individual Developer OutcomesRole of Project Managers and Process Control. Information Systems Research. doi: 10.1287/isre.2017.0723

Wen, Jianfeng, Shixian Li, Zhiyong Lin, Yong Hu, und Changqin Huang. 2012. Systematic literature review of machine learning based software development effort estimation models. Information and Software Technology 54 (1): 41–59. doi: 10.1016/j.infsof.2011.09.002

Windeler, Jaime B., Likoebe Maruping, und Viswanath Venkatesh. 2017. Technical Systems Development Risk FactorsThe Role of Empowering Leadership in Lowering Developers’ Stress. Information Systems Research 28 (4): 775–796. doi: 10.1287/isre.2017.0716

Xue, Ling, Gautam Ray, und Xia Zhao. 2017. Managerial Incentives and IT Strategic Posture. Information Systems Research 28 (1): 180–198. doi: 10.1287/isre.2016.0660

Cohn, M., 2005. Estimating With Use Case Points. https://www.mountaingoatsoftware.com/articles/estimating-with-use-case-points. Zugegriffen: 25. Juli 2018

Decker, F., 2016. Vertragsgestaltung bei agilen IT-Projekten. http://blog-it-recht.de/2016/08/11/vertragsgestaltung-bei-agiler-softwareerstellung-teil/. Zugegriffen: 2. Januar 2018

Departamento Ciencias Computación, Universidad de Alcalá, 2012. Open Research datasets. http://www.cc.uah.es/drg/c/RHH_RAISE12_Repos.html. Zugegriffen: 20. Juni 2018

FIZ Karlsruhe , et al., 2010. zbMATH - the first resource for mathematics. https://zbmath.org/classification/?q=cc%3A62. Zugegriffen: 4. Juli 2018

Menzies, T., et al., 2017. The Promise Repository of Empirical Software Engineering Data. http://openscience.us/repo/effort/. Zugegriffen: 20. Juni 2018

Object Management Group, 2015. UML 2.5. http://www.omg.org/spec/UML/2.5/. Zugegriffen: 1. Juli 2017

University of Ottawa, 2006. PROMISE DATASETS PAGE. http://promise.site.uottawa.ca/SERepository/datasets-page.html. Zugegriffen: 20. Juni 2018

VHB, 2018. Verband der Hochschullehrer für Betriebswirtschaft e.V.: Teilrating WI. http://vhbonline.org/vhb4you/jourqual/vhb-jourqual-3/teilrating-wi/. Zugegriffen: 15. März 2018

Anhang I: Projekt Entwicklung B2B-Portal Aunex Data Service

In diesem Anhang wird das Entwicklungsprojekt Data Service Portal des Unternehmens Aunex GmbH in seinen organisatorischen und planerischen Grundlagen vorgestellt. Ihre Darstellung an dieser Stelle soll zum Verständnis der in dieser Arbeit beleuchteten Problemstellung beitragen.

Unternehmensvorstellung

Das Unternehmen Aunex GmbH (im Folgenden kurz ‚Aunex‘) wurde im November 2017 von zwei Partnern in Schwerin gegründet. Die Gründer verfügen über langjährige Erfahrungen im Bereich der industriellen Automatisierung mit Schwerpunkt Konzeption, Einrichtung und Vertrieb von Automatisierungskomponenten. Das Unternehmen bietet Dienstleistungen und Lösungen zur Erhöhung der Verfügbarkeit und Effektivität automatisierter Produktionsanlagen in der Prozess - und Fertigungsindustrie. Ihr Geschäftsmodell gliedert sich in die drei Bereiche Netzwerk-Support, Projekt-Consulting und Data Service.

Netzwerk-Support im Rahmen von Messeinsätzen vor Ort umfasst die Services Qualitätscheck, Reparaturservice sowie Abnahme und Report. Beim Projekt-Consulting werden industriellen Partnern Workshops und Projektberatungsleistungen angeboten. Die abgedeckten Themenkomplexe sind Industrie 4.0, Transformation von Profibus^[259] auf Profinet^[260], Datenakquise und Datenintegration sowie Predictive Maintenance aus der Cloud.

Der dritte Geschäftsbereich des Unternehmens, Data Service, ist eine herstellerneutrale Web-Plattform für den Bezug von Gerätebeschreibungsdateien. Gerätebeschreibungsdateien werden zur Planung, Inbetriebnahme und Wartung von netzwerkfähigen, automatisierten Komponenten industrieller Produktionsanlagen benötigt. Ähnlich wie Hardware-Treiber in einem Computer, definieren die Gerätebeschreibungsdateien die Anbindung an und die Kommunikation im jeweiligen Industrienetzwerk. Sie sind Netzwerkprotokoll-spezifisch. Die Entwicklung dieses Portals ist in einem eigenständigen Projekt organisiert und Gegenstand der nachfolgenden Betrachtung.

Projekt Data Service Portal

Das Data Service Portal stellt Nutzern Geräte-Informationen zur Anwendung in der industriellen Prozess-Automatisierung zur Verfügung. Das Portal agiert dabei protokollübergreifend und herstellerneutral. Für jeden Hersteller besteht demnach die Möglichkeit, seine Geräte-Informationen für jede Protokollart in das Portal zu integrieren.

Potenzielle Nutzer des Portals arbeiten als Projekt-Ingenieure in der Planung von industriellen Fertigungsanlagen, als Anlagen-Inbetriebnehmer bei der Projektumsetzung, Anlagenkonfiguration und Fehlersuche oder als Wartungspersonal. Diese Nutzergruppen benötigen an verschiedenen Punkten ihrer Tätigkeit den Zugriff auf gerätespezifische Informationen.

Diese Informationen werden momentan kostenfrei auf den Hersteller-Webseiten, bzw. in Portalen technologie- und protokollspezifischer Interessenverbänden in der aktuellen Entwicklungsversion angeboten. Bei dieser Bereitstellung seitens der Hersteller handelt es sich um einen für den Nutzer kostenfreien After-Sales-Service.^[261] Der Gerätekauf ist bereits erfolgt und es lassen sich durch den Service keine weiteren Erlöse erzielen. In der Konsequenz liegt auf der kundenfreundlichen Bereitstellung in den überwiegenden Fällen der Hersteller keine Priorität.

Oftmals erfordert der Zugriff auf die Geräteinformationen eine Registrierung der Nutzer auf den Hersteller-Webseiten mit eigenem Passwort-geschützen Login. Die Informationen sind zudem hinter nicht-intuitiven Menüführungen und unzureichenden Suchfunktionen versteckt. In der Konsequenz verbringt der Nutzer seine produktive Arbeitszeit mit der langwierigen und aufwändigen Suche nach den zur Geräte-Installation benötigten Dateien. Diese Suche kostet Arbeitszeit und damit Geld.

Eine zentrale und einheitliche Bereitstellung dieser Geräteinformationen in einem Portal, unterstützt durch eine intuitive und schnelle Suche, soll dem Nutzer einen signifikanten Vorteil verschaffen. Dieser liegt insbesondere in der Reduzierung des organisatorischen Aufwands und der Zeitersparnis im Vergleich zum üblichen Anmelde- und Suchprozedere auf Herstellerseiten.

Die Gründer von Aunex gehen davon aus, dass Nutzer für diesen Vorteil bereit sind, ein Nutzungsentgelt zu bezahlen. Hieraus sollen die Entwicklungs- und Betriebskosten des Portals finanziert werden. Unternehmensziel schließlich ist es, dass das Portal mithilfe der durch die Nutzer generierten Entgelte zum Unternehmensgewinn beiträgt.

Dies erfordert zunächst eine Akzeptanz bei Nutzern und Geräte-Herstellern. Daraus sollen eine konsequente Nutzung des Services und schließlich eine langfristige Bindung an das Portal erwachsen. Die Entwicklung des Portals muss diesen strategischen Unternehmenszielen Rechnung tragen.

Projektziel

Ziel des Projektes ist die Entwicklung des Data Service Portals bis zu einem Status, bei dem potenzielle Kunden für die Nutzung bezahlen, unter Einhaltung von Entwicklungszeitraum und -budget. Die Unternehmensleitung geht davon aus, dass Kunden erst ab einem bestimmten Reifegrad des Services bereit sind, für dessen Nutzung zu zahlen. Dieser Reifegrad wurde in Form einer Portal-Version 1.0 anhand von wesentlichen Anforderungen definiert.Abbildung 15fasst diese Anforderungen zusammen. Das Portal in der Version 1.0 (großer transparenter Layer mit schwarzem Rahmen) soll verschiedene Funktionen bieten, welche als Front-End-Komponenten in hellem Grau dargestellt sind. Diese Funktionen benötigen verschiedene Back-End-Komponenten (dunkles Grau). Diese Beziehungen sind durch die räumliche Nähe von Front-End- und Back-End-Komponente dargestellt. Im Zentrum des Service-Angebots stehen die Such-Funktion und die konditionierte Download-Funktion.

Abbildung 15 Avisierte Portal-Version 1.0 .

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung. Verwendete Abkürzungen und deren Bedeutung (alphabetische Sortierung): BI - Business Intelligence, CMS - Content Management System, CRM - Customer Relationship Management, DMS - Data Management System, SE - Search Engine.

Organisatorische Rahmenbedingungen

Die Unternehmensleitung von Aunex hat beschlossen, die Entwicklungsleistung durch ein externes Unternehmen durchführen zu lassen. Nach Gesprächen konnte das Unternehmen tevim UG (im Folgenden kurz ‚tevim‘) für das Projekt gewonnen werden. Im Januar 2018 wurde zwischen beiden Unternehmen ein aufwandsbezogener Vertrag geschlossen. Dieser beinhaltet, dass tevim im Entwicklungszeitraum Februar bis Mai 2018 pro Monat 136 Entwickler-Stunden erbringt. Die Entwickler haben dabei die Anwendung einer Kombination der agilen Methoden SCRUM^[262] und KANBAN^[263] vertraglich festgeschrieben.^[264] Der Vertrag beinhaltet keinerlei leistungsbezogene Absprachen. Explizit ist das zu erstellende Produkt bzw. dessen Qualität nicht Gegenstand der vertraglichen Übereinkunft.^[265] Ferner ist vereinbart, dass der Product Owner für die gesamte Dauer des Projekts von Aunex gestellt wird.

Die Kommunikation zwischen den Mitgliedern des Projekt-Teams erfolgt ausschließlich über Online-Tools. Für Web-Meetings werden Skype und Zoom, für das Projekt-, Entwicklungs- und Anforderungsmanagement wird Trello^[266] verwendet. Darüber hinaus bestehender Kommunikationsbedarf, insbesondere der Austausch von Dateien wird per Email geregelt. Ein gemeinsamer digitaler Arbeitsraum und Ablageort für Dateien ist nicht eingerichtet.

Ein Entwicklungszyklus soll eine Arbeitswoche betragen. Jeweils zu Wochenbeginn wird ein Meeting zwischen den Entwicklern und dem PO abgehalten, auf welchem die zur Entwicklung anstehenden Anforderungen besprochen werden (Planning-Meeting). Ein Entwicklungszyklus schließt mit dem Review-Meeting, bei welchem die Entwickler ihre Ergebnisse vorstellen und der PO die umgesetzten Anforderungen anhand vorher definierter Erfüllungskriterien abnimmt. Fakultativ nehmen die Shareholder am Review teil.

Projekt-Team

Das Projektteam besteht auf Seiten von Aunex aus den beiden Gründern als Auftraggeber und dem als Projektleiter eingesetzten Product Owner. Hinzu tritt das Entwicklungsteam von tevim. Die Rollen im Projektteam werden im Folgenden durch Abgrenzung von Aufgaben und Verantwortlichkeiten näher erläutert.

Product Owner

Aunex stellt im Projekt den Product Owner. Für diesen ist es das erste Software-Entwicklungsprojekt nach seinem Abschluss zum Diplom Wirtschaftsingenieur und Stationen im organisationsbezogen Projektmanagement (Logistik-Organisation) und Datenbanken-Management. Er betreut das Projekt von Aunex neben seiner wissenschaftlichen Ausbildung im Studiengang IT-Management.

Product Owner (PO) spielen eine zentrale Rolle im SCRUM-Entwicklungsprozess. Ihre Funktion ist dementsprechend in den SCRUM-Grundlagen aufgenommen.^[267] Eine eingehende Beschreibung dieser Rolle und daraus erwachsende Aufgaben und Tätigkeiten findet sich bei Pichler^[268], Cohn^[269] und Britto^[270]. Die nachfolgenden Konkretisierungen der PO-Aufgaben im Rahmen dieses Projektes orientieren sich im Wesentlichen an deren Ausführungen.

Im Projekt besetzt der PO die Schnittstelle zwischen den Produkt-Stakeholdern Auftraggeber und Portalnutzer einerseits, sowie den Softwareentwicklern andererseits. Dem PO fallen in dieser Rolle wesentliche Aufgaben zu. Zum einen verantwortet er die Ausrichtung der Entwicklung an der Produktvision, d.h. dem eigentlichen Produktentwicklungsziel. Diese Vision hat der PO im Projekt zu definieren und gegenüber sämtlichen Schnittstellenpartnern zu kommunizieren. Die Vision richtet der PO dabei an den Interessen von Shareholdern und Kunden aus. Die Leitung der Produktentwicklung übernimmt der PO durch Identifikation, Beschreibung und Priorisierung der Anforderungen in der Entwicklung und Abnahme der Entwicklungsleistungen. Damit übernimmt der PO auch die Verantwortung über die Produktentwicklung.

In der agilen Entwicklung nach SCRUM und KANBAN führt der PO den Product Backlog und priorisiert dessen Inhalte. Der Product Backlog bezeichnet einen Katalog, in welchem definierte Entwicklungsaufgaben, im Folgenden Anforderungen genannt, festgehalten werden. Diese Anforderungen folgen einer einheitlichen Formulierungsvorschrift, welche stets den Nutzenaspekt der Entwicklung für eine oder mehrere konkrete Portal-Nutzergruppen in den Vordergrund stellt. Jeder Anforderung sind zudem Akzeptanzkriterien zugeordnet, deren Erfüllung über die positive Abnahme durch den Product Owner bestimmt.

Die Priorisierung des Product Backlog wird in dem wöchentlichen Planning-Meeting mit den Entwicklern vorgestellt und besprochen. Die in einer Entwicklungsschleife erreichten Anforderungen werden im wöchentlichen Review durch den PO und nach dessen positivem Akzeptanztest abgenommen. Diese Entwicklungsergebnisse werden in regelmäßigen Gesprächsterminen mit den Auftraggebern besprochen. In diesem Zusammenhang nimmt der PO weiterführende Anforderungs- und Priorisierungswünsche auf, die er anschließend bei seiner Planung berücksichtigt. Für die Berücksichtigung der Kunden-Interessen wurde im Portal frühzeitig eine Feedback-Funktion für Nutzer eingerichtet, die der PO betreut.

Hinzu treten Aufgaben der Projektorganisation. Die im Zusammenhang mit dieser Arbeit wesentliche Aufgabe stellt die Aufwandsabschätzung von Entwicklungsleistungen dar. Üblicherweise wird sie von den Entwicklern methodenunterstützt erbracht. Im Fokus dieser Arbeit steht allerdings die Aufwandsabschätzung durch den Auftraggeber als Kontrollmöglichkeit der Entwicklungsleistung. Diese Aufgabe übernimmt der PO vollumfänglich.

Entwickler

Das Entwickler-Team besteht aus zwei Entwicklern des Unternehmens tevim, welches im Auftrag von Aunex die Entwicklungsleistung übernimmt. Beide Entwickler verfügen über eine Hochschulausbildung in den Fächern Informatik, bzw. angewandte Mathematik und mehrjährige Software-Engineering-Erfahrung im Projektrahmen. Bei ihrer Tätigkeit wenden sie aus Effizienz- und Effektivitätsüberzeugung ausschließlich eine Kombination aus den agilen Entwicklungs- bzw. Projektmanagement-Methoden SCRUM und KANBAN an.

Ihre Aufgabe besteht in der anforderungsgerechten Entwicklung der Funktionen des Data Service Portals. Zu diesem Zweck besprechen sie mit dem PO in den Planning Meetings die zur Umsetzung anstehenden Anforderungen. In Abstimmung mit dem PO wählen sie im Rahmen des Meetings Anforderungen aus dem Product Backlog und füllen mit diesen den Selected Backlog. Der Selected Backlog enthält dann den Arbeitsvorrat für den anstehenden Umsetzungszyklus^[271]. Über den Füllgrad des Selected Backlog entscheiden sie nach eigenem Ermessen.

Fertig entwickelte Anforderungen werden über das Trello-Projekt-Board dem PO zur Abnahme vorgelegt. Die Abnahme geschieht zumeist im Rahmen des Review-Meetings am Ende des Entwicklungszyklus, kann aber nach Ermessen des PO auch nach Bedarf durchgeführt werden.

Shareholder und Stakeholder des Projekts

Die Shareholder des Entwicklungsgegenstandes und gleichzeitig die Initiatoren des Projekts sind die beiden Gründer von Aunex. Beide Unternehmer verfügen über langjährige Erfahrung in der Automatisierungsbranche. Der CEO setzt seinen Fokus auf die betriebswirtschaftlichen Belange. Seine Kenntnisse reichen von der Unternehmensleitung, über den Automatisierungskomponenten-Markt bis hin zu Distribution und Akquise. Er verfügt über breite Branchenkenntnisse und ist in dieser sehr gut vernetzt. Der CTO hat als diplomierter Elektrotechnik-Ingenieur Expertise im Bereich der Automatisierungstechnik, insbesondere von industriellen Daten-Netzwerken aufgebaut. So besitzt er umfangreiches Fach- und Anwendungswissen über in der Industrie verwendete technische Standards, Geräte und Netzwerk-Architekturen.

Eine wesentliche Aufgabe der Shareholder im Entwicklungsprozess ist es deshalb, ihre Markt- und Geräteexpertise in die Entwicklung an verschiedenen Stellen einzubringen. Für den Aufbau des Portals ist eine Datenbasis von Geräteinformationen unablässig. Die Shareholder übernehmen die Kommunikation mit den Geräte-Herstellern und legen die Quellen fest. Weiterhin sind sie ausschließlich für die Bewerbung des Produkts bei Herstellern und potenziellen Nutzergruppen zuständig.

Beide Shareholder nehmen zudem fakultativ an den Review-Terminen teil, in welchem sie ihre Meinung zur Entwicklungsleistung vertreten und Anstöße für weitere Entwicklungsaufgaben geben. Sie verstehen sich in ihrer Rolle als „zu überzeugende Kunden“ des Produkts. Diese Rolle nehmen sie auch außerhalb von Review-Terminen im direkten Austausch mit dem PO regelmäßig wahr. Die Initiative zur Kontaktaufnahme ist dabei nicht festgelegt. Angestrebt wird ein offener Informationsaustausch mit dem PO, bei dem Vorschläge und Eigeninitiativen erwünscht sind. Eine direkte Kommunikation mit dem Entwickler-Team ist nur für den Fall vorgesehen, wo in der Entwicklung technische Expertise zu den Geräte-Informationen benötigt wird. Im Konfliktfall zwischen PO und Shareholder oder Entwicklung und Shareholder behalten sich die Shareholder ein abschließendes Entscheidungsrecht vor.

Zu dem Kreis der Stakeholder zählen, neben dem bereits aufgeführten Personenkreis die zukünftigen Portalnutzer. Diese lassen sich im Kern drei Gruppen zuordnen: Portal-Administration, Geräte-Hersteller als Produzenten von Geräte-Informationen sowie Automatisierungstechniker als Nutzer und Rezipienten dieser gerätespezifischen Informationen. Diese drei Gruppen bilden den Nutzerkreis des Portals, auf welchen die anwenderbezogene Entwicklung zu konzentrieren ist.

Im Rahmen der Entwicklung kommt ihnen die Nutzungsrolle des Produkts zu. Dabei sind Hersteller und Nutzer nicht organisatorisch in das Projekt integriert und bilden deshalb keinen abgeschlossenen, ex ante bekannten Nutzerkreis. Über ihre Nutzung des Produkts in den unterschiedlichen Entwicklungsphasen werden Informationen zu Nutzerverhalten und Fehlern in der Programmierung generiert. Diese Informationen werden in einem iterativen Prozess wieder in die Entwicklung aufgenommen.

Projektplan

Der Projektplan ist inAbbildung 16gezeigt. Er sieht den Entwicklungsauftakt am 01.02.2018 und insgesamt drei Entwicklungsmonate zu je 136 Entwicklungsstunden vor. Abschluss der Entwicklung im Projekt ist demnach 30.04.2018. Jeweils der Entwicklung vor- und nachgelagerte Zeiträume werden zur Vor- bzw. Nachbereitung genutzt. Somit ergibt sich ein Gesamt-Projekt-Rahmen vom 01.01.2018 bis zum 31.05.2018. Ein terminierter Meilenstein stellt die Hannover Messe (Weltleitmesse für Industrieprodukte; 23.04.-27.04.2018) dar. Auf dieser sollen Geräte-Hersteller und Kunden für die Nutzung des Portals gewonnen werden. Zu Präsentationszwecken ist die Bereitstellung eines lauffähigen Produkts mit entsprechenden Kernfunktionalitäten avisiert.

Abbildung 16 Projektzeitplan.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

Anhang II: Übersicht Entwicklungsanforderungen Data Service Portal

Abbildung in dieser Leseprobe nicht enthalten

^[1] Vgl. Britto, R., et al., An Empirical Investigation, 2015, S. 38.

^[2] Sofern nicht explizit angegeben, sind in dieser Arbeit bei allgemeinen Rollenbezeichnungen stets alle Geschlechter gemeint. Aus Gründen der Lesbarkeit wird auf die Nennung aller Formen verzichtet.

^[3] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 8.

^[4] Vgl. Atkinson, R., Project management, 1999, S. 337.

^[5] Vgl. Opelt, A., et al., Der agile Festpreis, 2014, S. 39.; Decker, F., Vertragsgestaltung bei agilen IT-Projekten, 2016.

^[6] Vgl. Book, M., et al., Erfolgreiche agile Projekte, 2017, S. 203.

^[7] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 17.

^[8] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 10.

^[9] Vgl. Cohn, M., Agile estimating and, 2005, S. 23.

^[10] Vgl. Cohn, M., Agile estimating and, 2005, S. 35.; Usman, M., et al., Effort estimation in agile, 2014, S. 85.; Baumgartner, M., et al., Agile testing, 2017, S. 10.; Tanveer, B., et al., Effort estimation in agile, 2017, S. 1.

^[11] Berichtet in Pospieszny, P., et al., An effective approach for, 2018, S. 185.

^[12] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 26.; Pospieszny, P., et al., An effective approach for, 2018, S. 185. In einer Übersichtsstudie aus 2007 wird jedoch darauf verwiesen, dass die Expertenschätzung mindestens so akkurat sind, wie modellbasierte Schätzungen (Jorgensen, M., et al., A Systematic Review, 2007, S. 39.). Dieses Verhältnis hat sich durch eine Verbesserung der Algorithmen heutzutage bereits wieder gedreht, wie aktuellere Übersichtsartikel implizieren (Usman, M., et al., Effort estimation in agile, 2014, S. 89.).

^[13] Vgl. Owais, M., et al., Effort, duration and, 2016.

^[14] Siehe dazu die in dieser Arbeit verwendete Literatur von Pilios, E., Contracting practices in, 2015; Choi, J., et al., Outcome-based Contract Model, 2016; Lappi, T., et al., Project governance in, 2017; Xue, L., et al., Managerial Incentives and, 2017.

^[15] Siehe dazu die in dieser Arbeit verwendete Literatur von Broy, M., et al., Projektorganisation und Management im, 2013; Nguyen, D. S., et al., Success Factors for, 2016; Özden, M., et al., Factors leading to, 2016; Windeler, J. B., et al., Technical Systems Development, 2017.

^[16] Siehe dazu die in dieser Arbeit verwendete Literatur Boehm, B. W., Software engineering economics, 1981; Cohn, M., Agile estimating and, 2005; Pichler, R., Agile Product Management, 2010; Hummel, O., Aufwandsschätzungen in der Software- und, 2013; Britto, R., et al., An Empirical Investigation, 2015; Rupp, C., et al., Basiswissen Requirements Engineering, 2015; Venkatesh, V., et al., Information Systems Projects, 2017.

^[17] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 26.; Usman, M., et al., Effort estimation in agile, 2014, S. 89.; Jørgensen, M., Unit effects in, 2016, S. 274.; Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 25994.; Dragicevic, S., et al., Bayesian network model, 2017, S. 110.

^[18] Siehe dazu die in dieser Arbeit verwendete Literatur von Garmus, D., et al., Function Point Analysis, 2001; Poensgen, B., Function-Point-Analyse, 2012; Garg, S., et al., PCA based cost, 2015; Kupiainen, E., et al., Using metrics in, 2015; Torrecilla-Salinas, C. J., et al., Estimating, planning and managing, 2015; Di Martino, S., et al., Web Effort Estimation, 2016; Dhir, S., et al., An estimation technique, 2017; Mahboob, T., et al., Predictive Approach towards Software, 2017.

^[19] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 110.

^[20] Vgl. Tanveer, B., et al., Effort estimation in agile, 2017, S. 11.

^[21] Vgl. Tanveer, B., et al., Effort estimation in agile, 2017, S. 13.

^[22] Vgl. Azhar, D., et al., A systematic review of, 2012, S. 56.; Usman, M., et al., Effort estimation in agile, 2014, S. 89.; Čeke, D., et al., Early effort estimation, 2015, S. 234.; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 973.; Usman, M., et al., Effort Estimation in, 2018.

^[23] So z.B. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013; Rupp, C., et al., Basiswissen Requirements Engineering, 2015.

^[24] Vgl. Usman, M., et al., Effort estimation in agile, 2014, S. 87.

^[25] Siehe dazu Usman, M., et al., Effort estimation in agile, 2014; Kupiainen, E., et al., Using metrics in, 2015; Cerpa, N., et al., Evaluating different families, 2016.

^[26] Vgl. Mair, C., et al., An investigation of machine, 2000; Satapathy, S. M., et al., Effort estimation of web-based, 2016.

^[27] Was die ‚besten‘ Schätzergebnisse ausmacht, ist im Rahmen dieser Arbeit anhand geeigneter Optimalitätskriterien noch genauer zu betrachten.

^[28] Vgl. VHB, Verband der Hochschullehrer für, 2018.

^[29] Vgl. Cohn, M., Agile estimating and, 2005, S. 50.; Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 25993.; Dragicevic, S., et al., Bayesian network model, 2017, S. 110.

^[30] Diese Reaktionsmaßnahmen sind allerdings explizit nicht Gegenstand der vorliegenden Betrachtung.

^[31] Vgl. Reichenberger, K., Kompendium semantische Netze, 2010, 18 f.

^[32] Das so charakterisierte Vorgehen ist abzugrenzen von einer planlosen und willkürlichen Ermittlung von Entwicklungsaufwänden, wie z.B. schlichtem raten.

^[33] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 109.

^[34] Vgl. Rupp, C., Requirements-Engineering und -Management, 2014, S. 268.

^[35] Vgl. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013, S. 25.

^[36] Vgl. Robertson, S., et al., Mastering the requirements process, 2013, S. 9 f.

^[37] Vgl. ISO/IEC, Systems and software engineering, 2011.

^[38] Vgl. Rupp, C., Requirements-Engineering und -Management, 2014, S. 268.

^[39] Vgl. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013, S. 26.

^[40] Vgl. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013, S. 3.

^[41] Vgl. Curcio, K., et al., Requirements engineering: A systematic, 2018, S. 32.

^[42] Vgl. Curcio, K., et al., Requirements engineering: A systematic, 2018, S. 32.

^[43] Vgl. Cohn, M., Agile estimating and, 2005, S. 23.

^[44] Vgl. Pichler, R., Agile Product Management, 2010, S. 52.

^[45] Vgl. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013, S. 125.

^[46] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 109.

^[47] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 109.

^[48] Vgl. Abrahamsson, P., et al., Agile software development, 2002, S. 49.

^[49] Vgl. Curcio, K., et al., Requirements engineering: A systematic, 2018, S. 34 f.

^[50] Vgl. Čeke, D., et al., Early effort estimation, 2015, S. 234.; Dragicevic, S., et al., Bayesian network model, 2017, S. 109.; Curcio, K., et al., Requirements engineering: A systematic, 2018, S. 48.

^[51] Vgl. Cohn, M., Agile estimating and, 2005, S. 12 f.; Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 9 ff.

^[52] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 111.

^[53] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 8.

^[54] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 30 ff.; Čeke, D., et al., Early effort estimation, 2015, S. 231.; Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 26003.

^[55] Die Korrektheit wird hier als stetiges Merkmal interpretiert. In anderen Zusammenhängen wird sie hingegen als Charakteristikum mit zwei-elementiger Ergebnismenge (‚korrekt‘ oder ‚nicht korrekt‘) verstanden, weshalb die Klarstellung an dieser Stelle erfolgt.

^[56] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 21.

^[57] Vgl. Cohn, M., Agile estimating and, 2005, S. 50.; Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 6.

^[58] Vgl. Čeke, D., et al., Early effort estimation, 2015, S. 220.

^[59] Vgl. Čeke, D., et al., Early effort estimation, 2015, S. 219.

^[60] Vgl. Torrecilla-Salinas, C. J., et al., Estimating, planning and managing, 2015, S. 124 f.; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 973.; Britto, R., et al., A taxonomy of, 2017, S. 541.; Ahram, T., et al., Advances in Human Factors, 2018, S. 52.

^[61] Vgl. Čeke, D., et al., Early effort estimation, 2015, S. 219–220.

^[62] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 116.

^[63] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 153.

^[64] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.

^[65] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 13.

^[66] Vgl. Boehm, B. W., Software engineering economics, 1981.

^[67] Vgl. Shepperd, M., et al., Estimating software project effort, 1997.

^[68] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 24.

^[69] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 13.

^[70] Vgl. Azhar, D., et al., A systematic review of, 2012, S. 53.

^[71] Vgl. Mair, C., et al., An investigation of machine, 2000, S. 23.; Mendes, E., A Comparison of Techniques, 2007, S. 334.; Azhar, D., et al., A systematic review of, 2012, S. 53.; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 973.; Mahboob, T., et al., Predictive Approach towards Software, 2017, S. 452.; Pospieszny, P., et al., An effective approach for, 2018, S. 185.

^[72] So z.b bei Sharma, N., et al., A Comparison of software, 2012; Torrecilla-Salinas, C. J., et al., Estimating, planning and managing, 2015, S. 126.; Resmi, V., et al., An effective software project, 2017.

^[73] So z.B. bei Satapathy, S. M., et al., Effort estimation of web-based, 2016 und Resmi, V., et al., An effective software project, 2017.

^[74] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.

^[75] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 110.

^[76] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 109.

^[77] Subjektive, erfahrungsbasierte Methoden basieren auf derselben Vorgehensweise. Einzig bei der Ermittlung der Größe und der daraus anschließenden Festlegung des Entwicklungsaufwands werden andere, auf subjektiven Einschätzungen beruhende Metriken eingesetzt (Cohn, M., Agile estimating and, 2005, S. 34.).

^[78] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.

^[79] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.

^[80] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.; Resmi, V., et al., An effective software project, 2017, S. 4.

^[81] Aktuelle Beispiele von Einflussfaktoren aus Primär- und Sekundärquellen liefern die folgenden Arbeiten: Usman, M., et al., Effort estimation in agile, 2014, S. 89.; Čeke, D., et al., Early effort estimation, 2015, S. 229.; Torrecilla-Salinas, C. J., et al., Estimating, planning and managing, 2015, S. 129.; Venkatesh, V., et al., Information Systems Projects, 2017, S. 1 f.; Windeler, J. B., et al., Technical Systems Development, 2017, S. 1 ff.; Usman, M., et al., Effort Estimation in, 2018, S. 1 f.

^[82] Vgl. Resmi, V., et al., An effective software project, 2017, S. 4.

^[83] Vgl. Lee, T., et al., MND-SCEMP: an empirical, 2014; Pillai, S. P., et al., Consolidating evidence based, 2017, S. 837.

^[84] Vgl. Mair, C., et al., An investigation of machine, 2000; Satapathy, S. M., et al., Effort estimation of web-based, 2016; Mahboob, T., et al., Predictive Approach towards Software, 2017; Pospieszny, P., et al., An effective approach for, 2018.

^[85] Vgl. Radlinski, L., A survey of bayesian, 2010.

^[86] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 112.

^[87] Vgl. Huan, X., et al., Sparse Algorithms Are Not, 2012, S. 192.

^[88] Vgl. Pospieszny, P., et al., An effective approach for, 2018, S. 185 f.

^[89] Vgl. Di Martino, S., et al., Web Effort Estimation, 2016, S. 107.

^[90] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 119.

^[91] Vgl. Čeke, D., et al., Early effort estimation, 2015, S. 219.

^[92] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 25.

^[93] Vgl. Hummel, O., et al., Towards Automated Software, 2013; Čeke, D., et al., Automated web application functional, 2015.

^[94] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 120.

^[95] Vgl. Usman, M., et al., Effort estimation in agile, 2014, S. 86.

^[96] Vgl. Silhavy, R., et al., Analysis and selection of, 2017, S. 2.

^[97] Vgl. Di Martino, S., et al., Web Effort Estimation, 2016, S. 108.

^[98] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 48.

^[99] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 120.

^[100] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.

^[101] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 120.

^[102] So z.B. bei Kocaguneli, E., et al., On the Value, 2012.

^[103] Vgl. Azhar, D., et al., A systematic review of, 2012, S. 53.; Čeke, D., et al., Early effort estimation, 2015, S. 230.; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 975.

^[104] Vgl. Foss, T., et al., A simulation study of, 2003, S. 985.

^[105] Vgl. Conte, S. D., et al., Software engineering metrics and, 1986, S. 276.

^[106] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 71.

^[107] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 93.

^[108] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 83.

^[109] Vgl. Čeke, D., et al., Early effort estimation, 2015, S. 221.

^[110] Vgl. Sharma, N., et al., A Comparison of software, 2012, S. 122.

^[111] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 154.

^[112] Vgl. Usman, M., et al., Effort estimation in agile, 2014, S. 88.

^[113] Vgl. Shepperd, M., et al., Estimating software project effort, 1997, S. 741.

^[114] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 24.

^[115] Vgl. Mendes, E., A Comparison of Techniques, 2007; Radlinski, L., A survey of bayesian, 2010; Azhar, D., et al., A systematic review of, 2012; Usman, M., et al., Effort estimation in agile, 2014.

^[116] Vgl. Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 978 f.

^[117] Vgl. Mair, C., et al., An investigation of machine, 2000, S. 28.

^[118] Vgl. Radlinski, L., A survey of bayesian, 2010, S. 106.

^[119] Vgl. Wen, J., et al., Systematic literature review of, 2012, S. 50.

^[120] Vgl. Di Martino, S., et al., Web Effort Estimation, 2016, S. 91.; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 973.

^[121] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, im Umschlag des Einbands.

^[122] Vgl. Di Martino, S., et al., Web Effort Estimation, 2016, S. 108.

^[123] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 121.

^[124] Vgl. Mair, C., et al., An investigation of machine, 2000, S. 28.

^[125] Vgl. Sharma, N., et al., A Comparison of software, 2012, S. 126.; Usman, M., et al., Effort estimation in agile, 2014, S. 89.; Čeke, D., et al., Early effort estimation, 2015, S. 234.

^[126] Vgl. Resmi, V., et al., An effective software project, 2017, S. 4.

^[127] Vgl. Sharma, N., et al., A Comparison of software, 2012, S. 126.

^[128] Vgl. Mendes, E., A Comparison of Techniques, 2007; Radlinski, L., A survey of bayesian, 2010, S. 95.; Wen, J., et al., Systematic literature review of, 2012.

^[129] Vgl. Mair, C., et al., An investigation of machine, 2000.

^[130] Vgl. Mair, C., et al., An investigation of machine, 2000, S. 27 f.

^[131] Vgl. Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 25995.

^[132] Vgl. Celar, S., et al., Evolutionary measurement-estimation method for, 2012.

^[133] Vgl. Azhar, D., et al., A systematic review of, 2012, S. 56.; Usman, M., et al., Effort estimation in agile, 2014; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 973.; Usman, M., et al., Effort Estimation in, 2018.

^[134] Vgl. ISO/TC, Guidance on project management, 2012.

^[135] Vgl. AXELOS Limited, Erfolgreiche Projekte managen mit, 2014, S. 4.

^[136] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 61 f.

^[137] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 62.

^[138] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 67 f.

^[139] Vgl. Opelt, A., et al., Der agile Festpreis, 2014.

^[140] Daneben existiert in einem Projekt eine Reihe weiterer Kern- und Querschnittsaufgaben, auf welche aber aus Relevanzgründen für die vorliegende Arbeit nicht weiter eingegangen wird. Eine Einführung liefert z.B. Broy, M., et al., Projektorganisation und Management im, 2013, S. 68 f.

^[141] Vgl. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013, S. 83.

^[142] Vgl. AXELOS Limited, Erfolgreiche Projekte managen mit, 2014, S. 5.

^[143] Vgl. Valentini, U., et al., Requirements Engineering und Projektmanagement, 2013, S. 83 ff.

^[144] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 249 ff.

^[145] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 111.

^[146] Vgl. Pfeifer, T., et al., Masing Handbuch Qualitätsmanagement, 2014, S. 70.

^[147] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 111.

^[148] Vgl. Mair, C., et al., An investigation of machine, 2000, S. 28.; Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 979.; Mahboob, T., et al., Predictive Approach towards Software, 2017, S. 453.; Resmi, V., et al., An effective software project, 2017, S. 9.; Pospieszny, P., et al., An effective approach for, 2018, S. 194.

^[149] Vgl. Sharma, N., et al., A Comparison of software, 2012, S. 126.

^[150] Über den Entwicklungsstand in diesem Bereich ist in Kapitel3.4berichtet worden.

^[151] Vgl. Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 25999.; Ahram, T., et al., Advances in Human Factors, 2018, S. 55.

^[152] Vgl. Schmidt, G., Prozessmanagement, 2012, S. 73.; Krcmar, H., Einführung in das Informationsmanagement, 2015, S. 4.

^[153] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 110.

^[154] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 117.

^[155] Vgl. González-Barahona, J. M., et al., On the reproducibility, 2012, S. 77 ff.

^[156] Vgl. Lee, T., et al., MND-SCEMP: an empirical, 2014; Pillai, S. P., et al., Consolidating evidence based, 2017, S. 837.

^[157] Vgl. University of Ottawa, PROMISE DATASETS PAGE, 2006; Menzies, T., et al., The Promise Repository of, 2017.

^[158] Vgl. Departamento Ciencias Computación, Universidad de Alcalá, Open Research datasets, 2012.

^[159] Vgl. Top, O. O., et al., Internal and External Software, 2011, S. 306.

^[160] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 326 f.

^[161] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 327.

^[162] Vgl. Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 25993.

^[163] Vgl. Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 25995.

^[164] Vgl. Adnan, M., et al., Ontology Based Multiagent Effort, 2017, S. 26004.

^[165] Vgl. Celar, S., et al., Evolutionary measurement-estimation method for, 2012, S. 88.

^[166] Vgl. Lusky, M., et al., Software Cost Estimation, 2018, S. 51.

^[167] Vgl. Lusky, M., et al., Software Cost Estimation, 2018, S. 56. Ihr Ansatz soll perspektivisch zu einer unternehmensspezifischen Datenbank weiterentwickelt werden, die eine Auswahl von bereits umgesetzten Komponenten zur Wiederverwendung unterstützt. Die Studie befindet sich momentan noch in der Evaluierungsphase, in welcher die Akzeptanz der Stakeholder zur Befüllung einer derartigen Wissens-DB ermittelt wird.

^[168] Vgl. Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 974.

^[169] Vgl. Dragicevic, S., et al., Bayesian network model, 2017, S. 112.

^[170] Aufgrund des fundamentalen Charakters der im Folgenden dargestellten Sachverhalte wird eine Belegung der Aussagen in diesem Unterkapitel durch vielfältige Literatur nicht für nötig erachtet. Als Quelle wird zumeist das Standardwerk Laux, H., et al., Entscheidungstheorie, 2014 verwendet.

^[171] Vgl. FIZ Karlsruhe , et al., zbMATH - the first resource, 2010.

^[172] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 4.

^[173] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 20.

^[174] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 30.

^[175] Vgl. Schneeweiß, H., Das Grundmodell der Entscheidungstheorie, 1966.

^[176] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 33.

^[177] Die Begriffe (Entscheidungs-)Alternative und Handlungsoption werden in dieser Arbeit synonym verwendet.

^[178] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 31.

^[179] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 41 f.

^[180] Zieldefinition und Präferenzbildung werden im Rahmen dieser Arbeit nicht weiter vertieft, da sie keinen entscheidenden Beitrag zum Konzept der Auswahlmethode leisten. Weiterführende Informationen zu diesem Thema finden sich z.B. bei Laux, H., et al., Entscheidungstheorie, 2014, S. 34 ff.

^[181] Prinzipiell zielt ein normativer Ansatz auf die Maximierung des Erwartungsnutzens bei der Auswahl des Schätzers ab. Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 75.

^[182] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 68 ff.

^[183] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 74 ff. Schoemaker, P. J. H., The Expected Utility Model, 1982.

^[184] Vgl. Coombs, C. H., et al., Mathematische Psychologie, 1975, S. 143 ff.

^[185] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 115. Die Existenz dieser Nutzenfunktion wird bei der in dieser Arbeit betrachteten Problemstellung vorausgesetzt.

^[186] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 76.

^[187] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 113. Dazu kann der einfachen Anwendung halber der Erwartungswert der angenommenen Ergebnisverteilung als Bewertungsmaßstab zugrunde gelegt werden. Etwas aufwändiger, aber dafür exakt, ist die Berücksichtigung sämtlicher, für die Nutzenfunktion relevanter Verteilungsparameter bei der Ermittlung des Erwartungswertes des Nutzens.

^[188] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 114.

^[189] Ihre Einfachheit liegt dabei zumeist sowohl in ihrer Anwendbarkeit als auch in den problem-vereinfachenden Annahmen, die sie treffen. Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 596.

^[190] Vgl. Tversky, A., Elimination by aspects: A, 1972.

^[191] Vgl. Fishburn, P. C., Exceptional paper—Lexicographic orders, 1974.

^[192] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 77.

^[193] Vgl. Ariely, D., et al., A timely account of, 2001, S. 195.

^[194] ML-Techniken, die entsprechende Algorithmen abbilden, stehen z.B. als fertig implementierte Werkzeuge in Matlab (R2018a) zur Anwendung bereit.

^[195] Vgl. Kapitel3.5.3.

^[196] Aufgrund des fundamentalen Charakters der im Folgenden dargestellten Sachverhalte wird eine Belegung der Aussagen in diesem Unterkapitel durch vielfältige Literatur nicht für nötig erachtet. Als Quelle wird zumeist das Standardwerk Jarosch, H., Grundkurs Datenbankentwurf, 2016 verwendet.

^[197] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 19.

^[198] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 18.

^[199] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 21.

^[200] Vgl. North, K., Wissensorientierte Unternehmensführung, 2016, S. 37.

^[201] Vgl. North, K., Wissensorientierte Unternehmensführung, 2016, S. 25.

^[202] Vgl. North, K., Wissensorientierte Unternehmensführung, 2016, S. 199.

^[203] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 29.

^[204] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 113.

^[205] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 158.

^[206] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 115.

^[207] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 116.

^[208] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 122.

^[209] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 124.

^[210] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 158.

^[211] Aufgrund des fundamentalen Charakters der im Folgenden dargestellten Sachverhalte wird eine Belegung der Aussagen in diesem Unterkapitel durch vielfältige Literatur nicht für nötig erachtet. Als Quelle wird zumeist das Standardwerk Broy, M., Projektorganisation und Management im, 2013 verwendet.

^[212] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 69.

^[213] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 94.

^[214] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 94.

^[215] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 95.

^[216] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 95 f.

^[217] Vgl. Broy, M., et al., Projektorganisation und Management im, 2013, S. 96.

^[218] Die Fragen der Checkliste können dann wie folgt formuliert werden: Ist Ziel {1, 2, 3} erfüllt? [Ja/Nein].

^[219] Sind die anderen beiden Ausprägungen ‚mittel‘ und ‚niedrig‘ gewählt, wird das Merkmal Genauigkeit nicht als notwendig berücksichtigt.

^[220] Vgl. Rumsey, D. J., Statistics essentials for dummies, 2010, S. 87.

^[221] Sind die anderen drei Ausprägungen ‚mittel‘, hoch‘ und ‚sehr hoch‘ gewählt, wird das Merkmal Schätzaufwand nicht als notwendig berücksichtigt.

^[222] Vgl. Bronštejn, I. N., et al., Taschenbuch der Mathematik, 2006, S. 788.

^[223] Vgl. Rumsey, D. J., Statistics essentials for dummies, 2010, S. 99.

^[224] Vgl. Bronštejn, I. N., et al., Taschenbuch der Mathematik, 2006, S. 802.

^[225] Z.B. in der Deskriptive Entscheidungstheorie: Johnson, E. J., et al., Effort and Accuracy in, 1985

^[226] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 56 ff. Auf diese Weise kann zudem eine konversionsbedingte Erhöhung der Unsicherheit bei der Ermittlung der Schätzwerte vermieden werden, die die Anwendung der bislang wenig akkuraten Umrechnungsfunktionen mit sich bringt (Di Martino, S., et al., Web Effort Estimation, 2016, S. 108.).

^[227] Vgl. Cohn, M., Estimating With Use Case, 2005.

^[228] Vgl. Cohn, M., Estimating With Use Case, 2005. Sie stützt sich auf die zum Zeitpunkt der Messung verfügbaren Projekterfahrungswerte. Die Berechnung ist dieser Arbeit in den Zusatzdokumenten beigelegt (20180911 Masterarbeit Datenerhebung.xlsm, Tabellenblatt ‚UWE‘).

^[229] Vgl. Satapathy, S. M., et al., Effort estimation of web-based, 2016, S. 977.

^[230] Dies betrifft besonders die Schätzfunktionen der auf die Ermittlung von Gesamtaufwänden in Projekten spezialisierten algorithmischen Kostenmodelle. Im Abschnitt0wird ein Vorschlag unterbreitet, wie deren Faktoren skaliert werden können, damit sie grundsätzlich auf das vorliegende Problem anwendbar sind.

^[231] Aus demselben Grund ist eine absolute Bewertung der Vorhersagequalität einer Schätzung, wie sie Conte et al (1986) vorschlagen, für den vorliegenden Anwendungsfall nicht praktikabel (Conte, S. D., et al., Software engineering metrics and, 1986, S. 276.). Siehe dazu auch S. 44 in dieser Arbeit. Ein alternativer Vorschlag wird deshalb bei der Berücksichtigung von Erfahrungswerten im Projekt unterbreitet.

^[232] Bei der Anpassung der Selektionsparameter an die Ziel- und Präferenzvorgaben können unterstützend Entscheidungsmodelle eingesetzt werden, aus denen entsprechende Einstellungsmuster abzuleiten sind. In jedem Fall werden durch die Abhängigkeiten zwischen den Merkmalen bestimmte Zielkonstellationen von vornherein unterdrückt.

^[233] Alle weiteren möglichen Auswahlparameter werden bei der Modellbildung aus Gründen der Vereinfachung als fest und ‚quasi-sicher‘ angenommen. Vgl. dazu Laux, H., et al., Entscheidungstheorie, 2014, S. 57.

^[234] Über das Verhalten dieser Variable können über beispielsweise algorithmische Kostenschätzer plausible Annahmen als Daumenregel getroffen werden. Auf diese Weise werden die Faktoren der Schätzfunktion bestimmt. Alternativ wird das Verhalten dieser Variable über eine Wahrscheinlichkeitsverteilung beschrieben, die auf der Grundlage von Erfahrungswerten, optional in Kombination mit ML-Techniken ermittelt wurde.

^[235] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 582. Die anschließende Komposition der resultierenden Einzelentscheidungen zu einer Gesamtentscheidung bliebe in diesem Fall noch zu diskutieren.

^[236] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 61.

^[237] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 75.

^[238] Vgl. Laux, H., et al., Entscheidungstheorie, 2014, S. 16.

^[239] Gegeben seien Kriterien . Es sei eine zufällige Betrachtungsreihenfolge mit Betrachtungsrängen () der Kriterien dergestalt festgelegt, dass jedem Kriterium genau ein Betrachtungsrang von zugeordnet ist. Dann können die Kriterien gemäß ihrem Betrachtungsrang so geordnet werden, dass gilt: besitzt Betrachtungsrang . Jedem sei eine Selektionsstufe zugeordnet.

^[240] Vgl. Hummel, O., Aufwandsschätzungen in der Software- und, 2013, S. 68.

^[241] Vgl. Dörn, S., Programmieren für Ingenieure und, 2018, S. 149 ff.

^[242] Vgl. Object Management Group, UML 2.5, 2015.

^[243] Vgl. Kleuker, S., Grundkurs Software-Engineering mit UML, 2013, S. 10.

^[244] Vgl. Rupp, C., et al., UML 2 glasklar, 2012, S. 264.

^[245] Erfahrungswerte werden in der Literatur bislang für die Durchführung von Schätzmethoden (bei der Schätzung des Entwicklungsaufwands durch Analogieschluss) verwendet. Im Ansatz dieser Arbeit sollen sie allerdings für die Vorhersage von Genauigkeit und Schätzaufwand einer Schätzmethode genutzt werden.

^[246] Aufgrund der festgestellten engen Verbindung zwischen Entwicklungsaufwand und Funktionsumfang sowie einer fehlenden einheitlichen Ermittlungsmethode beim Funktionsumfang, wird dieser im Folgenden nicht eigenständig berücksichtigt. Er sei durch die Anforderungsbeschreibung (Use Case + Akzeptanzkriterien) und den Entwicklungsaufwand implizit im Schätzobjekt abgebildet.

^[247] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 64.

^[248] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 44. Im Relationalen Datenmodell wird deshalb ein technischer Schlüssel eingeführt, um eine Eindeutigkeit zu erreichen.

^[249] Vgl. Hahne, M., Mehrdimensionale Datenmodellierung für analyseorientierte, 2006, S. 187.

^[250] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 2.

^[251] Vgl. Müller, R. M., et al., Business Intelligence, 2013, S. 59.

^[252] Für eine Einführung in ER als Designsprache wird auf die Literatur, z.B. Müller, R. M., et al., Business Intelligence, 2013; Jarosch, H., Grundkurs Datenbankentwurf, 2016 verwiesen.

^[253] Vgl. Müller, R. M., et al., Business Intelligence, 2013, S. 52.

^[254] Vgl. Jarosch, H., Grundkurs Datenbankentwurf, 2016, S. 182.

^[255] Vgl. Müller, R. M., et al., Business Intelligence, 2013, S. 53.

^[256] Vgl. Müller, R. M., et al., Business Intelligence, 2013, S. 65.

^[257] Für die zufällige Auswahl wurde zunächst jeder der 14 Schätzmethoden der vierzehnte Teil des Intervalls [0,1] zugeordnet, so dass alle Teile zusammengenommen das Intervall wieder vollständig abdecken. Anschließend wurde für jede Anforderung eine Zufallszahl aus dem Intervall [0,1] mithilfe der Funktion ZUFALLSZAHL() von Excel (2010) ermittelt. Schließlich wurde diejenige Schätzmethode ausgewählt, in dessen Teilintervall der Wert der Zufallszahl lag.

^[258] Vgl. Conte, S. D., et al., Software engineering metrics and, 1986, S. 276. Siehe dazu auch die Erläuterungen in Fußnote231in dieser Arbeit.

^[259] Abk. für Process Field Bus – ein Standard für die Feldbus-Kommunikation in der Automatisierungstechnik.

^[260] Abk. für Process Field Network – offener Industrial-Ethernet-Standard für die Automatisierung. Nutzt TCP/IP und IT-Standards, ist Echtzeit-Ethernet-fähig und ermöglicht die Integration von Feldbus-Systemen.

^[261] Ihren eigentlichen Umsatz generieren die Hersteller mit dem Verkauf ihrer Geräte der Automatisierungstechnik. Der Verkauf ist zum Zeitpunkt der Installation der Geräte in die Produktionsanlagen bereits abgeschlossen. Die Bereitstellung der Geräteinformationen ist damit ein Nach-Verkaufs-Service (engl. After-Sales-Service).

^[262] SCRUM ist eine agile Software-Entwicklungsmethode. Eine eingehende Beschreibung liefert Schwaber, K., et al., Agile software development, 2002.

^[263] KANBAN ist eine gängige Methode, die in Software-Entwicklungsprojekten zur transparenten Organisation von Aufgaben, Verantwortlichkeiten und Entwicklungsstatus verwendet werden kann. In dem vorliegenden Projekt wird diese Methode durch die Nutzung der Software Trello für das Projekt- und Entwicklungsmanagement unterstützt. Einen Einstieg in die Methode liefert z.B. Anderson, D. J., et al., Die Essenz von Kanban, 2018.

^[264] Vgl. tevim UG, Angebot, 2018, S. 1. Eine digitale Version ist der Arbeit beigefügt.

^[265] Vgl. tevim UG, AGB, 2017, S. 1. Eine digitale Version ist der Arbeit beigefügt.

^[266] https://trello.com/

^[267] Vgl. Schwaber, K., et al., Agile software development, 2002, S. 34.

^[268] Vgl. Pichler, R., Agile Product Management, 2010, Kap. 1.

^[269] Vgl. Cohn, M., Agile estimating and, 2005, S. 23.

^[270] Vgl. Britto, R., et al., An Empirical Investigation, 2015, S. 38.

^[271] Der Zyklus wird in SCRUM-Terminologie auch ‚Sprint‘ genannt. Er beträgt im vorliegenden Projekt jeweils eine Arbeitswoche.