Im Product Line Engineering (PLE) entstehen Produktlinien systematisch aus einer gemeinsamen Basis. Dahinter steckt ein hochkomplexes Engineering, das wir in diesem Beitrag in der Theorie erläutern. In einem weiteren Beitrag werden wir die praktische Umsetzung aufzeigen.
Inhalt
Wie Produktlinien systematisch entstehen
Product Line Engineering (PLE) verspricht, aus einer gemeinsamen Basis effizient viele individuelle Produkte zu entwickeln. In der Regel wird dabei zwischen Domänen-Engineering und Application Engineering unterschieden. Doch was passiert eigentlich in diesen beiden Phasen und wie unterstützt iQUAVIS bei der Umsetzung dieses Ansatzes?
Zwei mal zwei Perspektiven
Im Schaubild Abb. 1 unten ordnen wir die wesentlichen Fähigkeiten von iQUAVIS ein. Das Bild ist horizontal in zwei Bereiche unterteilt: Links: Domänen-Entwicklung, die sozusagen die wiederverwendbaren Kernartefakte in den Blick nimmt. Rechts: die Anwendungs-Entwicklung, die auf ein konkretes Produkt fokussiert.
Vertikal werden zwei Ebenen unterschieden: Oben, die Marktperspektive, die Feature und Konfigurationen für die Kunden beschreibt, sowie unten die Architekturperspektive, in der es um die technische Basis geht, um ebendiese Feature realisieren zu können.

Domänen-Entwicklung: Die gemeinsame Basis schaffen
Den methodischen Einstieg in die Domänen-Entwicklung bildet das Feature-Modell. Es repräsentiert die Marktsicht einer Produktlinie. Dabei ist ein Feature ein vom Kunden bestellbares Merkmal. Ein Feature fasst inhaltlich funktionale und nicht-funktionale Anforderungen zusammen.
Folgende Fragestellungen stehen hinter der Feature-Modellierung:
- Welche Feature sind allen Produkten gemeinsam?
- Wo gibt es Variabilität?
- Welche Optionen schließen sich gegenseitig aus?
- Welche Features sind optional oder verpflichtend?
Das Feature-Modell beschreibt also nicht ein einzelnes Produkt, sondern die gesamte Lösungsdomäne. Es ist das zentrale Kommunikationsmittel zwischen Vertrieb, Produktmanagement und Technik.
Die Lösungsbausteine zu dem beschriebenen Feature-Modell finden wir in der Architekturperspektive in Form von Modulen bzw. architektonischen Bausteinen. Bei der Entwicklung dieser Bausteine zielt man auf:
- Wiederverwendbare Komponenten
- Architekturelle Muster
- Schnittstellen
- technische Variationspunkte
Jeder Baustein ist so entworfen, dass er für viele Produkte wieder verwendbar ist. Variabilität wird bewusst eingeplant – nicht als Sonderfall, sondern als Kernprinzip. Das Ergebnis der Domänen-Entwicklung ist damit:
- ein Feature Model für die Markt‑ und Produktsicht
- eine Referenzarchitektur aus Modulen/Bausteinen für die technische Umsetzung
Anwendungs-Entwicklung: Konkrete Produkte bauen
Während die Domänen-Entwicklung sozusagen die Bühne aufbaut, beginnt in der Anwendungs-Entwicklung die konkrete Ausprägung .
Im oberen rechten Bereich des Schaubildes sieht man die Konfigurationen. Hier wird das Feature Model verwendet, um konkrete Produkte zu definieren:
- Welche Features braucht Produkt A?
- Welche Variationspunkte werden wie belegt?
- Welche Optionen sind für einen bestimmten Kunden relevant?
Eine Konfiguration ist damit eine gültige Auswahl aus dem Feature Model – sie beschreibt genau ein Produkt.
Aus der Konfiguration wird auf der Architekturebene im unteren rechten Bereich die Produktarchitektur abgeleitet. Das Schaubild zeigt:
- Die Produktarchitektur entsteht nicht neu, sie wird aus den Bausteinen oder Modulen zusammengesetzt
- Die Konfiguration steuert, welche Bausteine wie kombiniert werden
- Aufgabe
So entsteht eine konkrete, lauffähige Architektur, die genau die zuvor gewählten Features unterstützt.
Zwischenfazit kurz und knapp: Die Domänenentwicklung liefert also die Bausteine – die Anwendungsentwicklung setzt sie zusammen.
Die Verbindung zwischen beiden Welten
Ein zentrales Element des Bildes sind die Verbindungen:
- Das Feature-Modell verweise auf die architektonischen Bausteine
- Die Bausteine werden in konkreten Produktarchitekuren verwendet
- Eine Konfiguration verweist auf eine (plausible) Kombination von Featuren und die daraus abgeleiteten Lösungselemente
Genau diese Durchgängigkeit unterscheidet Product Line Engineering von klassischer Wiederverwendung oder Copy‑&‑Paste‑Entwicklung. Die Verknüpfung von Marktanforderungen bis zur technischen Umsetzung erfolgt modellbasiert und ist die Grundlage für Kommunikation und Kooperation Produktmanagent und Technik. Entscheidend ist, dass das aufgebaute Beziehungswissen nun in den unterschiedlichen Phasen der Produktentstehung genutzt wird:
- Für die Produktroadmap werden Feature zeitlich aufgeplant
- Die Architektur berücksichtigt die bestehenden Feature und die kommenden Feature (Big Picture) und wird entsprechend ausgelegt
- Technische Entscheidungen finden nicht isoliert, sondern vor dem Hintergrund ebendieser Planung statt
- Auch technische Risiken für bestimmte Feature oder Opportunitäten, die sich aus einer neuartigen Kombination von Lösungselementen ergeben könnten, werden auf dieser Basis erarbeitet
- Qualitäts- oder Risikomethoden berücksichtigen, in welchen Konfigurationen sich eine bestimmte Funktion oder Lösung befindet kann
- Bereits abgesicherte Module können wiederverwendet werden
Diese Liste an Nutzungsmöglichkeiten ließe sich noch weiter fortführen.
Wie unterstützt iQUAVIS bei diesem Ansatz?
iQUAVIS bieten die notwendigen Toolfunktionalitäten, um den beschriebenen Ansatz umzusetzen. Es beinhaltet die Möglichkeit, Feature-Modelle zu definieren und entsprechende Abhängigkeiten zu modellieren. Die Feature können Lösungselementen zugeordnet werden. Bedingungen wie Exclude oder Mandatory können in verschiedenen Sichten angezeigt und bearbeitet werden. Der VariantenManager in iQUAVIS bietet darauf aufbauend die Möglichkeit, Varianten konkret auszuprägen – natürlich unter Berücksichtigung der Bedingungen des Featurebaums.



iQUAVIS auch bietet die Möglichkeit, wiederverwendbare Architekturbausteine anzulegen. Es stellt alle gängigen Modellierungsmethoden des MBSE zur Verfügung, um die Architekturbausteine in konkreten Systemmodellen zu nutzen.
Haben wir Ihr Interesse geweckt?
iQUAVIS ist ein leichtgewichtiges MBSE-Tool, mit dem Sie smart ins Systems Engineering einsteigen. Erfahren Sie hier mehr über iQUAVIS.

Dr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT und ist zuständig für iQUAVIS.
Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert.



