Cost Estimation in Software Product Line Engineering

Bachelorarbeit von Sebastian Rosensteiner

Einleitung:

Software ist ein Produkt, dessen Preis nur schwer zu bestimmen ist. Die Softwareindustrie als Teil der so genannten New Economy kann mit alten Ideen der Kosten- und Preisberechnung nur wenig anfangen. Wissen gilt als wichtigster Produktionsfaktor und die Anpassung der Produkte an Kundenwünsche wird immer wichtiger. In diesem Umfeld ist es schwierig, Preis und Kosten an den Produktionsfaktoren festzumachen; Wissen ist schließlich kaum adäquat zu bewerten.

Während die Distributionskosten (auch mit der weiten Verbreitung des Internets) immer geringer werden, können die Herstellungskosten enorme Ausmaße annehmen. Diese Ausmaße sind zudem besonders bei neuen Softwareprodukten, für die noch keine entsprechende Erfahrung vorhanden ist, schwierig abzuschätzen und explodierende Softwareentwicklungskosten haben schon die Fertigstellung einiger Projekte gefährdet oder sogar verhindert.

Eine gute Abschätzung der Softwareentwicklungskosten ist daher bei jedem Projekt unumgänglich. Dazu gibt es bereits zahlreiche Softwaretools, die anhand einer Vielzahl von externen und internen Faktoren die Kosten abzuschätzen versuchen (z.B.: Costar, Cost Xpert). Allerdings sind diese Programme in erster Linie auf die Entwicklung neuer Software ausgerichtet und bieten meist nur wenig Unterstützung, wenn bereits bestehende Softwareproduktlinien eingeschätzt werden sollen. Zudem liegt bei diesen Modellen der Fokus auf einzelnen Produkten; Wiederverwendung wird oft nur unzureichend berücksichtigt. Bei Softwareproduktlinien werden mehrere Softwareprodukte zu Produktlinien zusammengefasst und teilweise gemeinsam entwickelt. Speziell die im Voraus geplante Wiederverwendung von Code in Softwareproduktlinien ist bei vielen Kostenmodellen nur ungenügend berücksichtigt. Dies führt zu einer unpräzisen Abschätzung der Kosten und damit auch zu einer Verzerrung des Return on Investment (ROI) beim Vergleich von Einzelentwicklung und Entwicklung im Rahmen einer Produktlinie.

Um kosteneffziente Wiederverwendung zu ermöglichen, wird eine gemeinsame Software Plattform entwickelt, auf der die einzelnen Softwareprodukte aufbauen. Die Plattform enthält jene Komponenten der Software, die in mehreren Softwareprodukten verwendet werden. Wie dies im Mobilfunkbereich aussehen könnte, wurde exemplarisch in erläutert (siehe dazu auch Abschnitt 2.4).

Bei einer bestehenden Softwareproduktlinie wäre es wünschenswert, wenn Verkauf und Marketing ein Werkzeug zur Hand haben, welches eine Abschätzung der Kosten eines neuen Produktes in dieser Softwareproduktlinie ermöglicht. Diese Abschätzung könnte, wenn sie automatisiert durchführbar ist, anhand der Eigenschaften und Komponenten, die das vom Kunden gewünschte Produkt haben soll, quasi auf Knopfdruck vorgenommen werden. Anhand dieser Abschätzung ist es möglich, einem Kunden ein konkretes Angebot für ein neues Softwareprodukt zu erstellen. Weiteres steht dem Marketing ein Tool zur Verfügung, das als Unterstützung bei der Erstellung einer nachhaltigen Preis- und Marketingstrategie dienen kann.

Auch im Controlling werden Daten zur Abschätzung von Kosten benötigt, um einen Soll-Ist Vergleich im Lauf der Entwicklung der Softwareproduktlinie vornehmen zu können. Ein Kostenmodell, dass nicht nur die Kosten für bestehende Komponenten berücksichtigt, sondern auch die Kosten für noch zu entwickelnde Software abschätzt, kann hierfür wertvolle Daten liefern.

Inhaltsverzeichnis:

Textprobe:

Kapitel 3.2, Modellbasierte Techniken:

Zahlreiche Kostenschätzungsverfahren können in die Kategorie der modellbasierten Techniken eingeordnet werden. Vor allem in der Vergangenheit wurden viele modellbasierte Verfahren zu Kostenschätzung entwickelt. Im Folgenden werden COCOMO, COCOMO II, COPLIMO und ein Modell nach Böckle et al. näher erläutert.

COCOMO:

COCOMO (COnstructive COst MOdel) ist eines der wohl bekanntesten Kostenschätzungsmodelle. Die ursprüngliche Version stammt aus dem Jahr 1981, allerdings galt dieses Kostenmodell bereits in den neunziger Jahren als nicht mehr zeitgemäß, da es für neue Software Engineering Methoden nicht mehr ausreichend präzise war. COCOMO II, erstmals 1995 veröffentlicht, ist fexibel genug, um auch bei nicht sequentiellen Software Engineering Verfahren wie das Spiralmodell oder bei kollaborativen Software Engineering Verfahren eingesetzt werden zu können. Mittlerweile gibt es zahlreiche Weiterentwicklungen und Erweiterungen von COCOMO; Abbildung 3.1 gibt einen überblick über die COCOMO Suite.

Die grundlegende Formel des COCOMO Modells ist in (3.1) dargestellt. In diese Formel fließen mehrere Faktoren ein: size ist ein Maßstab für die Größe eines Softwaremoduls. Unter b sind Skalierungsfaktoren summiert, welche einen exponentiellen oder zumindest nicht linearen Einfluss auf den Entwicklungsaufwand haben. Unter E M sind Aufwandsmultiplikatoren (e ort multipliers) zusammengefasst; a ist ein Kalibrierungsfaktor. PM steht schließlich für die Personenmonate, die zur Entwicklung benötigt werden (siehe 3.1).

Anhand der Formel kann man die unterschiedlichen Auswirkungen der Einflussfaktoren erkennen: Während die Faktoren in b eine exponentialen Effekt im Bezug auf die Größe der Softwaremodule haben, hat EM nur multiplikativen Einfluss. Die Faktoren in E M dienen dazu, das Entwicklungsumfeld zu beschreiben. Hier können Faktoren wie Softwarekomplexität und Wiederverwendung einbezogen werden.

Ein wichtiger Schritt bei der Entwicklung eines Modells ist die Kalibrierung der Faktoren, im Fall von COCOMO des Faktors a. Bei COCOMO wurde für die Kalibrierung sowohl auf historische Projektdaten als auch auf Daten von Experten zurückgegriffen. Letztere wurden mit Hilfe der Delphi Methode gewonnen; siehe dazu auch Abschnitt 3.3.

COPLIMO:

Bei COCOMO stehen wie bei den meisten Kostenschätzungsmodellen die Entwicklungskosten und Ersparnisse durch Wiederverwendung im Vordergrund. Allerdings wird Aufwand bei der Erstellung von wiederverwendbarem Code oft überschätzt, da dieser Faktor auf die Gesamtgröße angewendet wird und nicht nur auf die Module, die für Wiederverwendbarkeit entwickelt werden. Weiteres wird auch der Softwarelebenszyklus in vielen Modellen nicht oder nur unzureichend berücksichtigt.

COPLIMO (COnstructive Product Line Investment MOdel) ist eine Weiterentwicklung von COCOMO II, die die Kosteneffekte des Softwarelebenszyklus und der Wiederverwendung von Quellcode speziell bei Softwareproduktlinien besser abbilden soll. Um dies zu erreichen, werden zwei weitere Faktoren im Modell eingeführt: Relative Cost of Writing for Reuse (RCWR) und Relative Cost of Reuse (RCR).

RCW R steht für den zusätzlichen Aufwand, der nötig ist, wenn Software für möglichst kosteneffziente Wiederverwendung entwickelt wird. Dabei werden die Kosten für diese Entwicklung in Beziehung zu den Kosten für die Entwicklung der Software ohne Wiederverwendbarkeit gesetzt. Dies wird in (3.2) verdeutlicht (siehe 3.2).

RCR soll die Kosten der Wiederverwendung von Software berücksichtigen. Beim diesem Faktor werden die Kosten der Wiederverwendung in Relation zu jenen Kosten gesetzt, die bei der Neuentwicklung der Software anfallen würden (sieh 3.3).

Allerdings ist es schwierig, diese Faktoren genau zu berechnen, da die jeweiligen Kosten natürlich im Voraus nicht bekannt sind. Um eine adäquate Abbildung des Faktors RCW R zu erreichen, haben Boehm et al. einen zusätzlichen multiplikativen Kostenfaktor Development for Reuse (RUSE) eingeführt. Der RUSE Faktor berücksichtigt die Kosten des Domain Engineering, zusätzlichen Aufwand für Dokumentation und Zuverlässigkeitstest (Reliability Testing) ausgenommen. Der zusätzliche Dokumentationsaufwand wird berücksichtigt, indem der DOCU Faktor in COCOMO II, welcher die zusätzlichen Kosten für die Dokumentation wiederverwendbarer Software berücksichtigt, auf die Werte Nominal und größer beschränkt wird. Analog dazu darf der RELY Faktor, welcher die zusätzlichen Kosten für die Verifizierung und Validierung von wiederverwendbarer Software abbildet, maximal eine Stufe unter dem RUSE Faktor liegen.

Beim RCR Faktor wird zwischen einer Black Box und einer White Box Lösung unterschieden. Bei der Black Box Variante, die keine Veränderung des wiederverwendeten Codes vorsieht, wird nur der Faktor Assessment and Assimilation (AA) für die Berücksichtigung des zusätzlichen Aufwands verwendet. In AA ist der Aufwand für die Überprüfung möglicher wiederverwendbarer Komponenten, die Einbindung der ausgewählten Komponente in das neue Softwareprodukt und die Ergänzung der Dokumentation enthalten.