Grundlagen der Produktlinienentwicklung

Als Konsumenten stellen wir unterschiedliche Anforderungen an die Produkte, die wir tagtäglich einsetzen. Aus diesem Grund bieten Hersteller ihre Produkte in unterschiedlichen Varianten an. Der Aufwand zur Entwicklung und Pflege eines Produktportfolios mit einer Vielzahl unterschiedlicher Produktvarianten ist viel höher. Zeitgleich ist die Entwicklung von Produktvarianten von Grund auf unmöglich, da sehr teuer. Dies ist in der Regel auch nicht notwendig, weil sich Produktvarianten häufig nur in einzelnen Aspekten unterscheiden, d.h. ein Großteil des Funktionsumfangs wird zwischen Varianten geteilt.

In diesem Artikel gehen wir auf die systematische Entwicklung von Produktvarianten ein und betrachten dabei zunächst den grundlegenden Prozess inkl. der Kernkonzepte. Darüber hinausgehende Konzepte sowie die technische Umsetzung werden in weiteren Blog-Artikeln erläutert.

Entwicklungsprozesse

Die Entwicklung von Produktvarianten besteht im Kern aus zwei Prozessen: Entwicklung für Wiederverwendung (Domain Engineering) und Entwicklung durch Wiederverwendung (Application Engineering). Beide Prozesse bilden die Grundlage für die Entwicklung einer Produktlinie, d.h. Entwicklung ähnlicher Produkte durch systematische Wiederverwendung innerhalb einer wohldefinierten Domäne (bspw. Auto oder Smartphone).

Problem Space/Solution Space

Darüber hinaus werden die beiden Bereiche Problem Space und Solution Space unterschieden. Im Problem Space wird die Produktlinie geplant und gesteuert: Variabilitätsmodellierung und Konfiguration. Im Solution Space dreht sich alles um die technische Entwicklung der Produktlinie: Methoden zur Implementierung sowie die Produktgenerierung.

Als Beispiel für eine Produktlinie nehmen wir ein Auto.

Domain Engineering

Ziel des Domain Engineerings ist die Entwicklung einer Produktlinie anstelle eines einzelnen Produktes. Im Zentrum steht die Entwicklung wiederverwendbarer Bausteine (Implementierungsartefakte), die flexibel in unterschiedliche Produktvarianten eingebaut werden können. Die Artefakte repräsentieren kein fertiges Produkt, weil sie mehr enthalten als eine einzelne Produktvariante braucht. Aus diesem Grund werden diese Artefakte auch 150% Modelle genannt. Für die Entwicklung der Produktlinie werden dabei die Anforderungen aller (auch potentieller) Kunden berücksichtigt. Grundlage für die Produktlinienentwicklung ist die Variabilitätsmodellierung. Mit ihrer Hilfe werden Gemeinsamkeiten und Unterschiede zwischen Produktvarianten erfasst und mittels Features repräsentiert.

Ein Feature ist eine optionale/inkrementelle Funktionserweiterung, die einen Kundenwunsch abdeckt. Typische Features für ein Auto sind unterschiedliche Antriebe (Benzin, Diesel, Hybrid, Elektro), Assistenzsysteme (z.B. Tempomat, Spurhalteassistent oder Berganfahrassistent) sowie weiter Ausstattungsmerkmale (z.B. Radio-Entertainmentsystem, Klimaanlage oder Dachfenster). Die modellierten Features werden in der Implementierung mit Hilfe unterschiedlicher Techniken als wiederverwendbare Artefakte entwickelt. Dies erstreckt sich über alle Bereiche in denen Variabilität zum Tragen kommt. Beispielsweise müssen für die Entwicklung eines Tempomats folgende Dinge erweitert werden:

• Konkrete Anforderungen, wie z.B. “Der Tempomat muss nach dem Einschalten durch den Fahrer selbstständig die Fahrzeuggeschwindigkeit halten können.”
• Architektur, d.h. die Einbettung des Tempomats in das Auto (inkl. Anschlüsse am Lenkrad und notwendige Steuergeräteschnittstellen).
• Elektrik/Elektronik, d.h. alle Bestandteile der Hardware mit denen der Fahrer Funktionen des Tempomats steuern kann.
• Software, d.h. Programme zur Signalsteuerung und Geschwindigkeitsanzeige.
• Tests, d.h. Absicherung ob die umgesetzte Lösung den Anforderungen entspricht.
• Benutzerhandbuch, d.h. Anleitung zur Benutzung für den Fahrer.
• Reparaturanleitung, d.h. Anleitung für Werkstätten zur Fehlerdiagnose und Reparatur.
• usw.

Application Engineering

Application Engineering (Entwicklung durch Wiederverwendung) ist der Prozess zur Ableitung einer konkreten Produktvariante aus wiederverwendbaren Artefakten des Domain Engineerings. Dafür werden im ersten Schritt die Kundenanforderungen mit den bestehenden Features der Variabilitätsmodellierung abgeglichen. Der Abgleich erfolgt manuell und geschieht typischerweise in einem Konfigurationswerkzeug. Die Meisten werden bereits mit Produktkonfiguratoren in Berührung gekommen sein, bspw. bei Automobilherstellern oder Online-Shops, wo Features/Produktmerkmale im Rahmen des Bestellprozesses angepasst werden können. In unserem Beispiel wählt der Kunde die Features Tempomat und Spurhalteassistent, lässt das Feature Dachfenster jedoch außen vor. Die fertige Konfiguration ist zusammen mit den wiederverwendbaren Artefakten des Domain Engineerings Eingabe für die Produktgenerierung. In dieser wird – idealerweise vollautomatisch – aus allen relevanten Artefakten eine Produktvariante erzeugt. Weil die wiederverwendbaren Artefakte sich nicht ändern, können durch Eingabe verschiedener Konfiguration entsprechend unterschiedliche Produktvarianten erzeugt werden. Der zugrundeliegende Generator berücksichtigt alle unterschiedlichen Artefakte (konkrete Anforderungen, Architektur, usw.), die zuvor im Domain Engineering erstellt wurden.

Das Application Engineering ist über eine Feedback-Schleife mit dem Domain Engineering verbunden. D.h. Anforderungen, die während der Konfiguration nicht berücksichtigt werden können, werden in der Variabilitätsmodellierung eingesteuert. Innerhalb der Modellierung führen neue/geänderte Anforderungen zu einer Anpassung des Produktportfolios und schließlich zu neuen/geänderten Features im Rahmen der Produktlinienimplementierung.

Zusammenspiel von Domain Engineering und Application Engineering

Die Darstellung von Domain und Application Engineering in der ersten Abbildung ist losgelöst von den einzelnen Disziplinen, die innerhalb der Produktentwicklung immer noch stattfinden (Requirements Engineering, Design, Realization und Quality Assurance). Mit Blick auf die einzelnen Disziplinen zeigt sich für Domain und Application Engineering das folgende Bild:

Alle Engineering Disziplinen sind analog zur Produktentwicklung für ein einzelnes Produkt miteinander verbunden. So baut das Design auf den Ergebnissen des Requirements Engineering auf, die Realization auf den Ergebnissen des Designs, usw. Der Unterschied hier ist, dass die Bereiche zweimal auftreten: einmal im Domain Engineering mit bspw. Domain Requirements Engineering und einmal im Application Engineering mit dem Application Requirements Engineering. Fokus der Domain Engineering Disziplinen ist die Erstellung wiederverwendbarer Artefakte. So wird bei der Erstellung von Requirements Spezifikationen im Domain Requirements Engineering berücksichtigt, dass nicht alle Auto-Varianten einen Tempomaten enthalten. D.h. die Requirements für den Tempomaten sind so markiert, dass sie nur für alle Produktvarianten des Autos mit Tempomat gelten und für alle anderen Produktvarianten unberücksichtigt bleiben.

Bei der Übernahme der “variablen” Requirements aus dem Domain Requirements Engineering in das Application Requirements Engineering werden diese Requirements konfiguriert, so dass sich ein konkretes Auto daraus erstellen lässt. Im Idealfall erfolgt die Übernahme der variablen Requirements im Application Requirements Engineering rein durch Konfiguration. D.h. für die Erstellung einer Produktvariante müssen keine neuen Requirements für die neue Produktvariante erstellt werden. Gleiches gilt für die übrigen Engineering Disziplinen wie Design, Realization und Quality Assurance.

Umgang mit variantenspezifischen Erweiterungen

Mit der Aufteilung der Engineering Disziplinen auf Domain Engineering (Entwicklung für Wiederverwendung) und Application Engineering (Entwicklung durch Wiederverwendung) können variantenspezifische Erweiterung, d.h. Erweiterungen die potentiell nur für eine Produktvariante gebraucht werden entweder im Domain Engineering oder im Application Engineering umgesetzt werden. Für die Umsetzung in den beiden unterschiedlichen Prozessbereichen sind folgende Punkte jeweils zu berücksichtigen:

Application Engineering:

• Ressourcenbindung: Die Entwicklung einer Produktlinie zielt auf einen hohen Grad an Automatisierung bzgl. der Ableitung von Produktvarianten. Wie zuvor beschrieben gibt es im Idealfall keine Entwicklungstätigkeiten im Rahmen des Application Engineerings. D.h. das Application Engineering ist ein leichtgewichtiger Prozess und beschränkt sich auf Aufgaben der Konfiguration und Produktableitung. Finden Entwicklungstätigkeiten sowohl im Domain Engineering als auch im Application Engineering statt, kann es zu Problemen in der Organisation kommen (bspw. Konkurrenzsituation/Diskussion über Zuständigkeiten durch die “verteilte Entwicklung”), welche den Entwicklungsfortschritt hemmen.

• Fehlende Wiederverwendung: Falls eine produktspezifische Erweiterung doch einmal in einer anderen Produktvariante eingesetzt werden soll, dann müssen die Erweiterungen entweder zur neuen Produktvariante portiert werden, oder sie müssen in die Produktlinie selbst – im Rahmen des Domain Engineerings – einfließen.

• Vorplanung Erweiterung, Integration und Nachversorgung: Zur Umsetzung variantenspezifischer Erweiterungen müssen bereits im Rahmen der Produktlinienentwicklung (Domain Engineering) Vorkehrungen getroffen werden. D.h. mögliche Erweiterungen müssen vorgeplant werden, sodass nach Durchführung der Produktgenerierung die Erweiterungen möglichst leicht umgesetzt werden können. Darüber hinaus müssen Vorkehrungen zur technischen Integration und Nachversorgung der Erweiterungen getroffen werden. Denn mit der Weiterentwicklung der Produktlinie im Domain Engineering muss die Grundlage/Basis (Absprungpunkt) für die variantenspezifischen Erweiterungen unter Umständen auf einen neuen Stand gehoben werden. Siehe dazu das Bild unten. Nehmen wir an, dass im Master die Implementierungsartefakte des Domain Engineerings gespeichert sind. Mit der Produktgenerierung wird zum Zeitpunkt X, die Basis a für die variantenspezifische Entwicklung (b bis d). Parallel dazu hat sich die Produktlinie mit den Versionen 1 bis 3 weiterentwickelt (neue Funktionen, Fehlerkorrekturen, …). Ein “Upgrade” der Variante auf Basis der neueren Entwicklungen im Master muss berücksichtigt werden und betrifft

  • die Vorplanung: Wo werden Änderungen in der Varianten gemacht?
  • die Integration: Wie werden Änderungen – möglichst automatisiert – integriert?
  • die Nachversorgung: Wann werden Änderungen aus dem Domain Engineering übernommen?

Domain Engineering:

• Pflege: Produktspezifika müssen im Rahmen der Produktlinie mitgepflegt werden. D.h. hier sind u.U. höhere Aufwände zu erwarten.
• Variantenspezifische Features: Für Steuerungs- und Konfigurationszwecke müssen varianten- oder kundenspezifische Features, z.B. Kunde_ABC oder Modell_XYZ, im Rahmen der Entwicklung eingeführt und gepflegt werden.