Produktlinienentwicklung

Eine Produktlinie beschreibt immer eine Menge von konzeptionell ähnlichen, aber doch unterschiedlichen Produkten. Aus der Perspektive der Produktlinienentwicklung ist vor allem die Unterscheidung zwischen Produktlinie als einer Menge gemeinsam verkaufter Produkte (vermarktete Produktlinie), wie sie im Marketing gebräuchlich ist, und Produktlinie als Menge gemeinsam mit dem Fokus auf Wiederverwendung entwickelter Produkte (entwickelte Produktlinie) wichtig. So können gemeinsam entwickelte Produkte in getrennten Produktlinien vermarktet werden, während Produkte einer vermarkteten Produktlinie auch aus unterschiedlichen Entwicklungen stammen können [5]. So entstammten beispielsweise die unterschiedlichen Microsoft-Betriebssysteme, die schon lange als Windows-Produktlinie gemeinsam vermarktet werden, früher verschiedenen Codebasen – und damit unterschiedlichen entwickelten Produktlinien. Hingegen sind heute sogar die Codebasen der beiden vermarkteten Produktlinien Windows 7 und Windows Server 2008 anscheinend weitestgehend identisch und können damit als eine entwickelte Produktlinie betrachtet werden.

Man kann Produktlinienentwicklung definieren als ,,Ansatz zur integrierten Entwicklung einer Menge von Systemen mit dem Ziel, ähnliche Funktionalität in unterschiedlichen Produkten durch gemeinsame Artefakte zu realisieren“. Es gibtweitere Eigenschaften, die für heutige Produktlinienentwicklungsansätze typisch sind.Wir betrachten diese hier jedoch nicht als definitorisch, sondern einfach als bewährte Realisierungsprinzipien, die wir unten darstellen werden.

Historisch lässt sich das Produktlinienkonzept erstmals bei Parnas [8] nachweisen, der eine Programmfamilie definierte als “Program families are defined (...) as sets of programs whose common properties are so extensive that it is advantageous to study the common properties of the programs before analyzing individual members.” Entsprechend war in Europa zeitweilig vor allem der Begriff Product Family gebräuchlich, was sich auch am Namen einiger Konferenzen und Forschungsprojekte zeigte. Jedoch hat sich mittlerweile auch hier der Begriff Produktlinie durchgesetzt.

Moderne Produktlinienansätze beruhen auf mehreren Grundlagen, wie den aufkommenden Softwarearchitekturkonzepten der 1990er-Jahre [4] oder den Konzepten des Domain Engineering, die ursprünglich auf die automatische Generierung aller Produkte in einer Domäne abzielten. Auch bis dahin erarbeitete Grundlagen der Softwarewiederverwendung kamen hinzu. Schließlich wurde diese Entwicklung noch ergänzt durch den expliziten Fokus auf ein konkret zu entwickelndes Produktportfolio, das Produktlinienentwicklung von Vorläuferansätzen unterscheidet.

Im Verlauf der Entwicklung von Produktlinienansätzen haben sich zunehmend gewisse Prinzipien als wichtig für eine erfolgreiche Produktlinienentwicklung erwiesen. Diese Prinzipien spiegeln sich auch inAnsätzen zurVerbesserung von Produktlinienentwicklung, wie dem Families Evaluation Framework (FEF) [7] oder der Product Line Technical Probe [9], wider.

Die wesentlichen Grundprinzipien und -ideen der Produktlinienentwicklung lassen sich anhand der folgenden vier Kategorien darstellen:

• Variantenmanagement,
• technische Realisierung,
• Prozesse und Organisation und
• wirtschaftliche Aspekte.

Ein wesentlicher Schritt für eine erfolgreiche Produktlinienentwicklung ist es, ein integriertes Verständnis (und Modell) der relevanten Anforderungen zu erhalten. Dies ist Aufgabe des Variantenmanagements und wird meist an den Aktivitäten des Scoping (Abgrenzung) der Produktlinie und der Domänenanalyse festgemacht. Zwar kann ein Scoping noch als Aufzählung möglicher Produkte funktionieren, spätestens in der Domänenanalyse wird jedoch ein integriertes Modell erstellt, das Gemeinsamkeiten und Unterschiede der Anforderungen an die Produkte darstellt. Genau betrachtet entstehen zwei Modelle: das Variabilitätsmodell und das Domänenmodell .Während das Domänenmodell die Anforderungen auf Ebene der Produktlinie beschreibt, definiert das Variabilitätsmodell ausschließlich die Unterschiede zwischen Produkten und beschreibt deren Abhängigkeiten. Damit stellt es letztlich ein Konfigurationsmodell dar und ist das zentrale Element des Variantenmanagements.  Es wird meist auch in den folgenden Entwicklungsschritten erweitert, sodass es auch Variation in Architektur, Realisierung, usw. beschreibt. Für die Produktlinienentwicklung wurden verschiedene Ansätze zur Variabilitätsmodellierung, wie z. B. Featuremodellierung oder Entscheidungsmodellierung entwickelt [6, 10].

Meist geht man davon aus, dass die gesamte Produktlinie durch das Variabilitätsmodell beschrieben wird. Aus praktischen Gründen ist aber oft eine Dreiteilung in Gemeinsamkeiten, Variabilitäten und produktspezifische Teile sinnvoller. Die meisten Variabilitätsmanagementansätze erfassen jedoch nur die ersten beiden Teile explizit.

Auch wenn in der Praxis Domänenmodell und Variabilitätsmodell oft vermischt werden, ist eine klare Trennung sinnvoller, da das Variabilitätsmodell dann auf den gesamten Lebenszyklus und die entsprechenden Artefakte erweitert werden kann. Es ist meist nicht möglich, alle relevanten Produkte genau vorherzusagen und im Variabilitätsmodell darzustellen. Vielmehr ist es meist sinnvoller, wesentliche Eigenschaften zu bestimmen und dann das Modell evolutionär weiterzuentwickeln. In diesem Zusammenhang werden oft auch die Begriffe der Variabilität in der Zeit und der Variabilität im Raum gebraucht. Ersteres beschreibt die Evolution von Systemen, denn auch dies kann als Variantenbildung beschrieben werden. Das zweite beschreibt dann die Bildung verschiedener Varianten zum gleichen Zeitpunkt. Beides zusammen spannt dann einen zweidimensionalen Raum auf, der die Evolution von Produktlinien und – als Grenzfall – von Einzelprodukten beschreibt.

Für die technische Realisierung sehen die meisten Ansätze zur Produktlinienentwicklung (und viele erfolgreiche Unternehmen) ein systematisches Architekturmanagement als einen wesentlichen Bestandteil der Produktlinienentwicklung an [3]. Dieses beruht auf einer konfigurierbaren Architektur, die für die verschiedenen Produkte angepasst (instanziiert) werden kann, aber zugleich für alle Produkte einen gemeinsamen Rahmen bietet. Eine solche Architektur wird auch als Referenzarchitektur bezeichnet. Idealerweise ergibt sich die Anpassung durch Konfiguration der Referenzarchitektur auf Basis des Variabilitätsmodells. Dabei können z. B. bestimmte Komponenten entfernt oder in passender Weise parametrisiert werden. Produktspezifische Erweiterungen können durch zusätzliche Komponenten realisiert werden, wenn geeignete Schnittstellen vorgesehen wurden.

Die Realisierung von Variabilität kann nicht ausschließlich auf Architekturebene erfolgen, vielmehr müssen auch in Komponenten Anpassungen der Implementierung für die jeweils ausgewählten Produkteigenschaften durchgeführt werden. Idealerweise geschieht dies so, dass kein Code im fertigen Produkt enthalten ist, der nicht benötigt wird. Dies ist insbesondere im Bereich eingebetteter Systeme wichtig, z. B. um Performanz und Speicherbedarf zu optimieren. Es ist aber auch im Bereich der Informationssysteme von Interesse, um die Komplexität der Systeme zu verringern oder um sicherzustellen, dass der Kunde sich keinen Zugang zu Funktionalität, die ihm nicht zur Verfügung stehen sollte, verschaffen kann (z. B. durch Eingabe eines anderen Lizenzschlüssels). Im Laufe der Zeit wurde eine Vielzahl von Ansätzen zur Implementierungsanpassung entwickelt. So sind beispielsweise bedingte Übersetzung, Kollaborationen oder Aspektorientierung in diesem Kontext verwendet worden [11].  Es ist auch zu beachten, dass die Implementierung von Produktvarianten, basierend auf einer Codekopie mitmanueller Anpassung, die ebenfalls häufig in der Praxis zu beobachten ist, keine Produktlinienentwicklung darstellt. (Diese Vorgehensweise wird auch als Clone-and-Own bezeichnet.)

Die Entwicklung einer Produktlinie hat auch Einfluss auf Prozesse und Organisation in einem Unternehmen. Man spricht im Kontext der Prozessdefinition für Produktlinien oft von einem 2-Lebenszyklusmodell. Die Grundidee ist dabei die klare Trennung zwischen wiederverwendbaren und produktspezifischen Artefakten. Diesen beiden Kategorien entsprechen zwei verschiedenen Lebenszyklen (Abb. 1).  Das Domain Engineering (Entwicklung für Wiederverwendung) ist dabei für die Realisierung und Evolution der Produktlinieninfrastruktur verantwortlich.

Dieser Lebenszyklus wird ein Mal für die gesamte Produktlinie instanziiert und existiert so lange, wie die Produktlinie existiert. Das Application Engineering (Entwicklung mit Wiederverwendung) hat hingegen die Aufgabe, unter Nutzung der wiederverwendbaren Artefakte die gewünschten Produkte zu erstellen. Dieser Lebenszyklus wird ein Mal je Produktentwicklung (Projekt) instanziiert. Die jeweilige Instanz deckt die entsprechende Produktlebensdauer ab. Theoretisch können die Vorgehensmodelle für beide Lebenszyklen gänzlich unterschiedlich sein. Entscheidend ist, dass die Zusammenarbeit (Collaboration) zwischen beiden sichergestellt wird. Gerade in kleineren Organisationen werden beide Prozesse von den gleichen Personen in integrierter Weise durchgeführt. Entscheidend ist dann, dass am Ende noch eine klare Trennung der Resultate in wiederverwendbare und produktspezifische Artefakte möglich ist. Domain Engineering und Application Engineering kommunizieren auch über die wiederverwendbaren Artefakte. Während das Domain Engineering diese verantwortlich produziert, werden diese vom Application Engineering instanziiert. In umgekehrter Richtung existiert auch ein Feedback vom Application Engineering zum Domain Engineering.

Es gibt unterschiedliche Ansätze zur Organisation von Produktlinienentwicklung. Eine Typologie findet sich beispielsweise in [1]. Eine zentrale Frage ist dabei, ob entsprechend den beiden Lebenszyklen auch eine organisatorische Trennung durchgeführt werden soll. Es gibt erfolgreiche Beispiele sowohl mit einer solchen Trennung als auch ohne eine solche Trennung. Die Frage nach der idealen Organisationsstruktur für eine Produktlinienentwicklung ist daher auch heute noch nicht eindeutig zu beantworten.

Die Einführung eines Softwareproduktlinienansatzes ist immer auch eine wirtschaftliche und strategische Entscheidung, schließlich hat dies Auswirkungen auf eine Vielzahl zu entwickelnder Projekte und bedeutet eine langfristige Investition in den Kompetenzaufbau des Unternehmens. Maßgeblich wurde daher von Philips das sogenannte BAPO-Modell entwickelt, dabei steht BAPO für Business, Architecture, Process, Organisation.

Dieses Modell charakterisiert die Aspekte, auf die im Rahmen einer Produktlinieneinführung besonders zu achten ist. Man kann dies auch als Reihenfolge betrachten, in der diese Aspekte betrachtet und angepasst werden sollten. Diese Kategorisierung wurde auch als Grundlage des Families-Evaluation-Frameworks (FEF) gewählt [7], das sowohl einen Bewertungsansatz als auch eine Leitlinie zur Einführung eines Produktlinienansatzes darstellt.

Eine Produktlinienentwicklung verändert die wirtschaftliche/finanzielle Situation oftmals fundamental, denn einerseits lassen sich Projekte rentabel entwickeln, die in einer Einzelentwicklung nie rentabel wären und zum anderen erfordert eine Produktlinienentwicklung signifikante Investitionen für Aufbau und Weiterentwicklung. Eine solche Investition ist nur sinnvoll, wenn es eine strategische Entscheidung für die vielfache Entwicklung von Systemen in diesem Bereich gibt.

Softwareproduktlinienentwicklung steht für einen Paradigmenwechsel in der Softwareentwicklung: Weg von der Entwicklung einzelner Systeme und hin zur integrierten Entwicklung einer Menge von Systemen. Viele Unternehmen stellen sich dieser Situation heute schon, meist auf Basis ihrer jeweils eigenen Vorgehensweisen. Dadurch, dass existierende Ergebnisse aus dem Bereich der Produktlinienentwicklung oft nicht bekannt sind und die Entwicklung entsprechend ad hoc erfolgt, erzielen die Unternehmen meist nicht den Grad der Effizienzsteigerung und Wiederverwendung, der eigentlich möglich wäre. Das prinzipielle Verbesserungspotenzial wird mittlerweile durch eine Vielzahl von Firmenerfahrungen belegt [2, 7]. So werden regelmäßig deutlich verkürzte Entwicklungszeit (Faktor 2–4), verbesserte Qualität (halbierte Fehlerrate) und deutlich verringerte Kosten (Faktor 2–4) beobachtet.

Doch auch auf der Forschungsebene wurde dieser Paradigmenwechsel bisher kaum berücksichtigt. Entwicklungen im Bereich der Vorgehensmodelle beziehen sich meist noch immer auf ein unabhängiges Projekt, auch wenn es das in der Praxis immer seltener gibt.

Aktuelle Forschungsthemen im Bereich der Produktlinienentwicklung sind beispielsweise die Kombination von Produktlinienentwicklung mit modellbasierter Entwicklung oder mit serviceorientierter Entwicklung. Parallel ist auch ein immer stärkeres Interesse an Ansätzen zu einer späteren Festlegung der Systemvarianten (z. B. während der Systeminitialisierung oder gar zur Laufzeit) zu beobachten. Dies wird oft auch unter dem Stichwort dynamische Softwareproduktlinien zusammengefasst. Doch nach wie vor befassen sich eine Vielzahl von Forschungsarbeiten auch mit konzeptionellen Grundlagen der Produktlinienentwicklung, wie beispielsweise dem Variantenmanagement.

1. Bosch J (2001) Software Product Lines: Organizational Alternatives. Proceedings of the 23rd International Conference on Software Engineering (ICSE), pp 91–100

2. Catalog of Software Product Lines. www.sei.cmu.edu/productlines/ casestudies/catalog/index.cfm, letzter Zugriff 29.7.2010

3. Clements P, Northrop L (2002) Software Product Lines: Practices and Patterns. Addison-Wesley

4. Hasselbring W (2006) Software-Architektur. Informatik-Spektrum 29(1):48–52

5. Helferich A, Schmid K, Herzwurm G (2006) Product management for software product lines: an unsolved problem? Commun ACM 49(12):66–67

6. Kang K, Cohen S, Hess J, Novak W, Peterson A (1990) Feature-Oriented Domain Analysis (FODA) Feasibility Study. Software Engineering Institute Carnegie Mellon University, Tech. Report Nr. CMU/SEI-90-TR-21

7. van der Linden F, Schmid K, Rommes E (2007) Software Product Lines in Action – the Best Industrial Practice in Product Line Engineering. Springer

8. Parnas D (1976) On the design and development of program families. IEEE Trans Softw Eng 2(1):1–9

9. Product Line Technical Probe. www.sei.cmu.edu/productlines/consulting/ techprobe, letzter Zugriff 21.7.2010

10. Reuse-Driven Software Processes Guidebook (1993) Version 02.00.03, Software Productivity Consortium 

11. Svahnberg M, van Gurp J, Bosch J (2005) A taxonomy of variability realization techniques. Softw Pract Exper 35(8): 705–754

Prof. Dr. Klaus Schmid
Universität Hildesheim
Institut für Informatik, Software Systems Engineering
Marienburger Platz 22
31141 Hildesheim
E-Mail

© Springer-Verlag 2010