Cost Estimation in Software Product Line Engineering

Inhaltsverzeichnis

1 Einführung und Motivation
1.1 Motivation
1.2 Problemstellung
1.3 Lösungsidee
1.4 Aufbau der Arbeit

2 Softwareproduktlinien
2.1 Definition
2.2 Gründe für Softwareproduktlinien
2.3 Grundlegende Begriffe
2.3.1 Domain Engineering
2.3.2 Variabilität und Variation Points
2.3.3 Application Engineering
2.4 GoPhone – Eine Softwareproduktlinie für Mobiltelefone
2.5 DOPLER Suite – Tool Integration für Software Product Line Engineering

3 Kostenschätzung
3.1 Grundkonzepte und Motivation
3.2 Modellbasierte Techniken
3.2.1 COCOMO
3.2.2 COPLIMO
3.2.3 Kostenmodell nach Böckle et al
3.2.4 Zusammenfassung
3.3 Expertise-basierte Techniken
3.4 Regressionsbasierte Techniken
3.5 Kombinierte Verfahren
3.6 Zusammenfassung

4 Evaluierung verschiedener Skriptsprachen
4.1 Groovy
4.2 Jython
4.3 JRuby
4.4 Pnuts
4.5 Weitere Skriptsprachen
4.6 Vergleich und Auswahl
4.7 Kostenmodell in Pnuts anhand des GoPhone Beispiels

5 Grafische Oberfläche zur Erstellung eines Pnuts Skripts
5.1 überlegungen zum Design
5.2 überlegungen zur Implementierung
5.3 Begriffsdefinitionen
5.4 Beschreibung der Grafischen Oberfläche
5.5 Realisierung des Kostenmodells in Java
5.6 Pnuts Quellcode Export

6 Zusammenfassung und Ausblick
6.1 Conclusio
6.2 Erfahrungen und Erkenntnisse
6.3 Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

2.1 Variabilität, Variation Points und Assets

3.1 Historische Entwicklung der COCOMO Suite

5.1 Der Add Condition Dialog

5.2 Grafische Oberfläche des Kostenschätzungstools

5.3 GUI des Kostenschätzungstools (drei Bereiche)

5.4 Der Add Condition Dialog mit Vorbedingung und linearem Output

5.5 Die Klassen des Kostenmodells

Kapitel 1
Einführung und Motivation

1.1 Motivation

Software ist ein Produkt, dessen Preis nur schwer zu bestimmen ist. Die Softwarein- dustrie 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 [1]. 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) im- mer geringer werden, können die Herstellungskosten enorme Ausmaße annehmen. Diese Ausmaße sind zudem besonders bei neuen Softwareprodukten, für die noch keine ent- sprechende Erfahrung vorhanden ist, schwierig abzuschätzen und explodierende Soft- wareentwicklungskosten haben schon die Fertigstellung einiger Projekte gefährdet oder sogar verhindert.

Eine gute Abschätzung der Softwareentwicklungskosten ist daher bei jedem Projekt un- umgä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 Soft- ware 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ück- sichtigt. 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 kostene ziente 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 [2] 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 vorgenom- men werden. Anhand dieser Abschätzung ist es möglich, einem Kunden ein konkretes Angebot für ein neues Softwareprodukt zu erstellen. Weiters 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.

1.2 Problemstellung

Die Komplexität von Softwareproduktlinien macht es notwendig, bei der Entwicklung und Wartung dieser auf spezielle Werkzeuge zurückzugreifen. Vor allem bei großen Soft- wareproduktlinien ist die Integration der Softwarewerkzeuge unumgänglich, um Kon- sistenz über alle Bereiche der Produktlinie garantieren zu können. Dafür wurde am Christian Doppler Laboratory für Automated Software Engineering eine Tool Suite namens DOPLER (Decision-Oriented Product Line Engineering for effective Reuse) entwickelt [3] (siehe dazu auch Abschnitt 2.5). Diese Tool Suite umfasst eine Reihe von Werkzeugen für alle Phasen des Software Product Line Engineering. Die Suite ist auch nicht domänenspezifisch, sondern kann in verschiedenen Bereichen verwendet werden.

Für diese Suite soll ein Kostenschätzungmodul entwickelt werden, das sowohl stand- alone einsetzbar ist als auch in diese Suite integriert werden kann. Basierend auf den durch die Suite zur Verfügung gestellten Daten soll eine Kostenschätzung für ein be- stimmtes Produkt der Produktlinie erstellt werden.

Dieses Kostenmodell soll exibel und anpassbar sein, um es wie die DOPLER Suite in unterschiedlichen Anwendungsbereichen einsetzen zu können. Da das Modell auch für Personen ohne technische Vorbildung verständlich sein soll, wurden nur Skriptsprachen für die Implementierung in Betracht gezogen. Diese sind zusätzlich leicht anzupassen und zu warten, was auch mit der allgemein geringeren Komplexität von Skriptsprachen zusammenhängt.

Weiters soll das Kostenmodell bei Bedarf auch noch nicht entwickelte Softwarekompo- nenten berücksichtigen. Dies ist vor allem deshalb wichtig, um schon im Vorhinein eine Kostenschätzung für ein Produkt abgeben zu können, für das einzelne Komponenten noch entwickelt werden müssen.

1.3 Lösungsidee

In diesem Szenario ist es sehr schwierig, eine Kostenabschätzung für die Software- produkte zu erstellen, vor allem, wenn manche Komponenten bereits entwickelt sind, während andere noch entwickelt werden müssen. Eine sehr einfache Möglichkeit wä- re, jedes Softwaremodul einzeln zu bewerten und zur Bestimmung der Gesamtkosten einfach die Kosten der enthaltenen Module zu aggregieren. Dies hat allerdings einige Nachteile: Erstens ist es teilweise schwierig, Softwaremodulen einen Preis zuzuordnen. So kann man den Wert einer Netzwerkschnittstelle nur sehr schwer bestimmen, ohne die Anwendungen, die diese benutzen, miteinzubeziehen. Damit ist auch ein zweiter, gravierender Nachteil verbunden: Eine bestimmte Kombination von Modulen ist unter Umständen mehr wert als die Summe der Teile. Ein Bluetoothtreiber für ein Mobiltele- fon mag an sich nur relativ wenig wert sein; in Kombination mit einem Headset-Modul, dass die Ansteuerung eines Headsets ermöglicht, sind beide Module sinnvoll einsetzbar und steigern damit den Wert des Mobiltelefons. Zwei Module können unter Umstän- den zusammen auch weniger wert sein als die Summe, wenn sie teilweise die gleiche Funktionalität zur Verfügung stellen. Weiters ist dieser Ansatz sehr technik- und kaum kundenorientiert: Der Kunde möchte ein Softwareprodukt mit gewissen Eigenschaften und Features, nicht eine Menge von Softwarekomponenten.

Alternativ kann man Software anhand von Eigenschaften beurteilen, etwa ob ein Mobil- telefon Unterstützung für ein Bluetooth - Headset bietet oder nicht. Die Eigenschaften werden in diesem Dokument als Decisions oder Entscheidungen bezeichnet. Anhand der Eigenschaften eines Softwareproduktes kann man dieses dann bewerten. Diese Be- wertung soll automatisch, also mit Hilfe einer Software durchgeführt werden.

Die Kostenschätzung soll also auf den Decisions basieren, welche externe Variabilität (also Variabilität für Kunden, Verkauf und Marketing) bereitstellen [4]. Diese Entschei- dungsvariablen sind nach außen sichtbar und können von Stakeholdern wie Kunden beein usst werden. Diese sind auch schon bekannt, wenn daf¨ ur benötigte Software- komponenten noch nicht entwickelt oder möglicherweise noch nicht einmal entworfen wurden. Daher sind Decisions als Datenbasis für die Kostenschätzung gut geeignet.

Genauso wie bei Modulen ist es auch bei Entscheidungen schwierig, diesen einen kon- kreten Wert zuzuordnen. Zudem ist auch hier die Aggregierung von (positiven) Ent- scheidungen nicht gleichbedeutend mit der Summierung. Um nicht jeder Entscheidung einen Wert zuordnen zu müssen, werden eigene Bewertungsobjekte eingeführt, so ge- nannte CostEntities. Ein CostEntity besteht aus einem eindeutigen Namen sowie einer Evaluierungfunktion, die einen Wert zurückliefert. Weiters haben CostEntities Kinder beziehungsweise untergeordnete CostEntities, was eine baumartige Anordnung mehre- rer CostEntities ermöglicht. Da auch bei CostEntities Synergiee ekte berücksichtigt werden müssen, ist es sinnvoll, die Aggregierung auf mehreren Ebenen durchzuführen, um diese E ekte abbilden zu können. Die dabei entstehende Baumstruktur ermöglicht es, auf jeder Ebene das Zusammenspiel der untergeordneten CostEntities zu bewer- ten.

Allerdings hat die Darstellung als Baumstruktur den Nachteil, dass die Berechnung bei großen Bäumen ine zient ist, da alle Knoten berechnet und dann aggregiert werden müssen. Bei intelligenter Programmierung ist es denkbar, dass nur mehr der Teil des Baumes aggregiert wird, der von änderungen durch Decisions betro en ist. Dies setzt eine komplexe Software zur Berechnung voraus, schließlich muss jedes CostEntity bei jedem Durchlauf entscheiden ob der Wert der letzten Evaluierung noch g¨ ultig ist. Die- se e zientere Implementierung erhöht die Komplexität des Modells und macht eine einfache Realisierung in einer Skriptsprache schwierig.

1.4 Aufbau der Arbeit

In Kapitel 2 werden die Grundlagen des Software Product Line Engineering erl¨ autert, der Begri Softwareproduktlinie definiert und die damit verbundenen Begri e Domain Engineering, Variabilität und Application Engineering näher erläutert. Den Abschluss des Kapitels bilden ein Blick auf die GoPhone Fallstudie [2] sowie eine Einf¨ uhrung in die DOPLER Suite [3].

Kapitel 3 bietet eine Einführung in die Grundkonzepte der Kostenschätzung sowie eine Analyse verschiedener Techniken. Einige modellbasierte Techniken werden im Detail erläutert. Als Beispiel für eine expertise-basierte Technik wird das Delphi Verfahren vorgestellt.

Verschiedene Skriptsprachen, die für die Implementierung des Kostenmodells in Frage kommen, wurden in Kapitel 4 einer Untersuchung unterzogen. Das Kapitel umfasst auch ein erstes prototypisches Kostenmodell in der Skriptsprache Pnuts, die schließlich für die Entwicklung des Kostenmodells ausgewählt wurde.

In Kapitel 5 wird eine grafische Oberfläche zur Erstellung eines Pnuts Scripts entwickelt. Dabei wurden die Erkenntnisse aus Kapitel 4 berücksichtigt. Das Kapitel umfasst neben überlegungen zum Design und der Entwicklung eines GUI-Prototypen auch einen Ab- schnitt mit Begri sdefinitionen und eine Beschreibung der fertigen Implementierung.

Kapitel 6 fasst die Erkenntnisse aus diesem Projekt zusammen. Abschließend werden mögliche Weiterentwicklungen sowie die Integrationsfähigkeit des Softwaretools erläu- tert.

Kapitel 2
Softwareproduktlinien

Hochkomplexe technische Produkte stellen hohe Ansprüche an die eingesetzte Softwa- re, und das teilweise auch rund um die Uhr. Ein großer Teil der Software ist nicht auf herkömmlichen Desktop Computern, sondern in so genannten Embedded Systems im Einsatz. Dieses Szenario erfordert komplexe Software, die für jede Hardwareumgebung angepasst werden muss. Selbst bei Software für Desktop Computer geht der Trend eindeutig in Richtung individuelle Anpassung. Weiters werden immer höhere Anforde- rungen an die Zuverlässigkeit und Qualität von Softwareprodukten gestellt, während diese zunehmend komplexer werden und damit auch der Entwicklungs- und Wartungs- aufwand überproportional zunimmt.

Zudem haben die meisten Unternehmen mehrere Softwareprodukte, die zum Teil ähnli- che Aufgaben erfüllen. So gibt es Unternehmen, die mehrere Editionen desselben Soft- wareproduktes getrennt voneinander p egen. Selbst Softwarefirmen, die nur ein einziges Produkt entwickeln, verbringen of viel Zeit damit, ihr Produkt f¨ ur die verschiedenen Kunden anzupassen und spezielle Kundenwünsche zu verwirklichen [2]. Bei einem klas- sischen Portfolio an Produkten wird oft dieselbe Funktionalität für unterschiedliche Softwareprodukte mehrmals entwickelt; änderungen müssen dann auch wieder mehr- mals vorgenommen werden. Produkte, die nicht mehr weiter entwickelt werden kön- nen, müssen entweder komplett neu entwickelt werden oder die Kunden müssen zu einem Wechsel zu einem anderen Softwareprodukt überredet werden. Dies hat nicht nur negative Konsequenzen für den Kunden, sondern macht auch die Wartung für das Unternehmen ine zient und kostenintensiv.

Warum wird dann nicht einfach Code entwickelt, der wiederverwendbar ist? Zahlreiche Projekte haben in der Vergangenheit gezeigt, dass Wiederverwendung ohne Planung und Organisation selten fruchtet [5]. Diese Form der Wiederverwendung wird auch als opportunistic reuse bezeichnet [6]. Softwareproduktlinien (speziell in Europa auch als Software Families bezeichnet [6]) sollen diese Probleme lösen: Systematisches Vorgehen soll die Komplexität verringern und die Wiederverwendbarkeit erhöhen. Der kurzfris- tig höhere Entwicklungsaufwand für wiederverwendbaren Code kann als Investment gesehen werden, dass sich bereits nach kurzer Zeit durch die Möglichkeit der Wieder- verwendung lohnt.

2.1 Definition

Unter einer Produktlinie versteht man eine Gruppe von Produkten, die über eine ge- meinsam verwaltete Menge an Features (oder Artefakten) verfügen, um damit die Be- dürfnisse eines klar abgegrenzten Marktsegments erfüllen zu können [7]. Analog dazu definieren Geyer und Becker [8] eine Softwareproduktlinie als eine Gruppe von software- intensiven Systemen mit diesen Eigenschaften. In [9] wird diese Definition noch um die Bedingung erweitert, dass diese Produkte in bestimmter Art und Weise, basierend auf einer gemeinsamen Menge von Core Assets, entwickelt werden. Core Assets sind dabei wiederverwendbare Artefakte und Ressourcen, die die Basis der Softwareproduktlinie darstellen. In der Literatur wird dies teilweise als Software Product Family bezeichnet [6] [8]. Softwareproduktlinien werden hingegen nur als Portfolio von Produkten gese- hen, die nicht notwendigerweise gemeinsam entwickelt werden müssen. In dieser Arbeit werden die Begri e Software Product Line und Software Product Family synonym ver- wendet.

2.2 Gründe für Softwareproduktlinien

Softwareproduktlinien beruhen wie klassische Produktlinien auf dem Prinzip der indi- viduellen Massenfertigung (Mass Customisation) [10]. Dabei wird versucht, die Vor- teile der Massenfertigung (kostene ziente Produktion, kostengünstige Wartung) mit der vom Kunden geforderten individuellen Anpassung des Produktes zu kombinieren. Erreicht wird dies durch die Verwendung von Software Platforms (in der Fachliteratur teilweise auch Core Asset Base genannt [5]). Darunter versteht man eine Sammlung von Artefakten, die speziell für die gemeinsame Verwendung in einem Portfolio (einer Produktlinie) entworfen und entwickelt wurden [5].

Zur Plattform gehören jene Artefakte einer Softwareproduktlinie, die für mehrere oder alle Softwareprodukte gemeinsam entworfen, entwickelt und gewartet werden. Die Ver- wendung einer gemeinsamen Plattform reduziert (bei entsprechender Portfoliogröße) nicht nur die Entwicklungskosten der einzelnen Softwareprodukte, sondern hat zudem positive Auswirkungen auf die Qualität der Softwareprodukte. Die Artefakte der Platt- form werden in mehreren Softwareprodukten verwendet und dabei öfter und eingehen- der getestet als Artefakte, die nur in einem Softwareprodukt Verwendung finden. Einen weiteren wichtigen Vorteil, der vor allem in hoch kompetitiven Märkten von Bedeu- tung ist, stellt die kürzere Time to Market dar. Diese kommt allerdings erst bei der Weiterentwicklung (also nach der Einführung der Softwareproduktlinie) zum Tragen [10].

Ein weiterer Vorteil ist die Reduktion der Komplexität, die durch den Einsatz von Platt- formen erreicht werden kann. Zusätzlich kann der Wartungsaufwand reduziert werden, da die Wartung für gemeinsam verwendete Artefakte nur einmal und nicht für jedes Softwareprodukt extra durchgeführt werden muss. Weiters erleichtert eine bestehende Plattform die Kostenschätzung für neue Softwareprodukte, die zur Produktlinie hinzu- gefügt werden sollen. Dabei können auch Schätzungen von Produkten verbessert wer- den, die neue Artefakte benötigen, also nicht gänzlich aus der bestehenden Plattform heraus entwickelt werden können [10]. Darauf wird im Detail in Kapitel 3 eingegan- gen.

2.3 Grundlegende Begri e

Bei der Entwicklung von Softwareproduktlinien werden zwei Prozesse unterschieden:

Domain Engineering und Application Engineering [10] [6]. Während Domain Enginee- ring die Entwicklung der Artefakte der Plattform umfasst, versteht man unter Ap- plication Engineering die Entwicklung der Softwareprodukte und aller dazu nötigen Artefakte sowie die Verwendung der Plattform als Basis für das Softwareprodukt. Eine entscheidende Rolle spielt hier auch die Variabilität der Artefakte [10]. Die Variabilität ist ein wesentliches Merkmal jener Artefakte, die zur Plattform gehören. Unter einer Plattform versteht man eine gemeinsame Basis von Komponenten, die f¨ ur mehrere Produkttypen verwendet werden [10]. Die Plattform umfasst die vielfach auch als Core Assets bezeichneten Artefakte, die eine gemeinsame (technologische) Grundla- ge für Produkte einer Produktlinie bilden. In dieser Arbeit werden die Begri e Plattform und Core Asset Base synonym verwendet.

2.3.1 Domain Engineering

Domain Engineering umfasst nicht nur die Entwicklung der gemeinsamen Artefakte, sondern auch die Definition der Plattform sowie die Festlegung der Gemeinsamkeiten und der Variabilität der einzelnen Artefakte und der Plattform als Ganzes. Weiters muss hier der Anwendungsbereich der Softwareproduktlinie abgegrenzt werden [10] (auch als Scoping bezeichnet [11]). Wesentlich ist, dass die Grenzen nicht zu weit gesteckt werden, um überproportionalen Wartungsaufwand und unnötige Komplexität zu vermeiden.

Ist der Anwendungsbereich festgelegt, so können die wiederverwendbaren Artefakte definiert und entwickelt werden. Dies geschieht in mehreren Subprozessen, die speziell die Bereiche Requirements Engineering, Design, Entwicklung und Quality Assurance abdecken [10].

2.3.2 Variabilit¨at und Variation Points

Variabilität ermöglicht es, ein System zu ändern und anzupassen. Eine verbesserte Variabilität erleichtert das Durchführen von änderungen und Anpassungen [12]. Damit im Zusammenhang stehen auch die so genannten Variation Points : diese bezeichnen Stellen, an denen eine bestimmte Variation möglich ist [8]. Das Variabilitätsmodell legt dabei fest, welche Teile variieren können. Weiters beinhaltet es Abhängigkeiten und Beschränkungen der Variabilität, um eine konsistente Definition der Variabilität in allen Core Assets zu ermöglichen [10]. In Abbildung 2.1 werden die Zusammenhänge zwischen Variabilität, Variation Points und (Core) Assets dargestellt. Im Application Engineering werden die Variation Points an eine bestimmte Variation gebunden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Variabilität, Variation Points und Assets [8]

2.3.3 Application Engineering

Jedes Softwareprodukt besteht nicht nur aus Artefakten der Software Plattform, son- dern besitzt auch einige Komponenten, die einzigartig sind und daher auch zus¨ atzlich entworfen und entwickelt werden müssen. Dies ist die Aufgabe des Application En- gineering [10]. Ziel ist es, die im Domain Engineering entstandenen Artefakte so gut wie möglich in den Software Produkten zu verwenden. Dabei sollen die Gemeinsamkei- ten (Commonality) und die Variabilität (Variability) bestmöglich ausgenutzt werden.

Um eine Softwareproduktlinie kostene zient entwickeln zu können, müssen daher die Vorteile aus der Wiederverwendung der gemeinsamen Artefakte größer sein als der zu- sätzliche Aufwand, der zur Entwicklung wiederverwendbarer Artefakte notwendig ist [2] (siehe dazu auch Abschnitt 3.2.3). Analog zum Domain Engineering gibt es auch beim Application Engineering entspre- chende Subprozesse. Diese korrespondieren mit den Subprozessen des Domain Engi- neering. So versucht etwa Application Requirements Engineering, die fix vorgegebenen und die variablen Requirements, die im Domain Requirements Engineering definiert wurden, e ektiv und möglichst e zient zu verwenden. Dabei sollten bereits bei die- sem Subprozess etwaige Unterschiede zwischen den Application Requirements und den Domain Requirements entdeckt und entsprechend reagiert werden.

Die Variation Points der Plattform werden für jedes Softwareprodukt an eine konkrete Lösung gebunden. Welche Lösungen möglich sind, wird durch das Variabilitätsmodell eingeschränkt [8]. Jede Lösung (und damit jedes Softwareprodukt) ist somit eine Vari- ante der Variabilität, die im Variabilitätsmodell festgelegt ist. Typischerweise kann ein neues Softwareprodukt nicht komplett aus einer bereits beste- henden Plattform gebildet werden. In diesem Fall kann es notwendig sein, neue Variabi- litäten und Bedingungen in die Plattform zu integrieren, um die Bedürfnisse des neuen Produktes abdecken zu können. Dies hat zur Folge, dass einzelne Core Assets adaptiert werden müssen. Dieser Schritt gilt als kritisch und zeitaufwendig, da Ideen in die Platt- form integriert werden müssen, für die diese ursprünglich nicht vorgesehen war. Zudem ist dieser Schritt fehleranfällig und hat daher unter Umständen auch Auswirkungen auf andere Produkte der Softwareproduktlinie [8].

[...]