Questions? Arrange a call now!

Basics of product line development

As consumers, we have different requirements for the products we use every day. For this reason, manufacturers offer their products in different variants. The effort required to develop and maintain a product portfolio with a large number of different product variants is much higher. At the same time, developing product variants from scratch is impossible because it is very expensive. This is usually not necessary either, because product variants often differ only in individual aspects, i.e. a large part of the functional scope is shared between variants.

In this article, we address the systematic development of product variants, first looking at the basic process including core concepts. Concepts beyond that, as well as the technical implementation, will be explained in further blog articles.

Development processes

The development of product variants consists of two core processes: Development for Reuse (Domain Engineering) and Development by Reuse (Application Engineering). Both processes form the basis for the development of a product line, i.e. development of similar products through systematic reuse within a well-defined domain (e.g. car or smartphone).

Problem Space/Solution Space

In addition, the two areas Problem Space and Solution Space are distinguished. In Problem Space, the product line is planned and controlled: variability modeling and configuration. In Solution Space, everything revolves around the technical development of the product line: methods for implementation as well as product generation.

As an example of a product line, let’s take a car.

Übersicht Domain Engineering/Application Engineering; inspiriert von "Generative Programming: Methods, Tools, and Applications; K. Czarnecki and U. Eisenecker; 2000; Addison-Wesley"

Übersicht Domain Engineering/Application Engineering; inspiriert von "Generative Programming: Methods, Tools, and Applications; K. Czarnecki and U. Eisenecker; 2000; Addison-Wesley"

Domain Engineering

The goal of domain engineering is the development of a product line instead of a single product. The focus is on the development of reusable building blocks (implementation artifacts) that can be flexibly incorporated into different product variants. The artifacts do not represent a finished product because they contain more than a single product variant needs. For this reason, these artifacts are also called 150% models. For the development of the product line, the requirements of all (including potential) customers are taken into account. The basis for product line development is variability modeling. With its help, similarities and differences between product variants are captured and represented by means of features.

A feature is an optional/incremental function extension that covers a customer requirement. Typical features for a car are different powertrains (gasoline, diesel, hybrid, electric), assistance systems (e.g. cruise control, lane departure warning or hill start assist) as well as further equipment features (e.g. radio entertainment system, air conditioning or roof windows). The modeled features are developed as reusable artifacts in the implementation using different techniques. This spans all areas where variability comes into play. For example, to develop a cruise control system, the following things need to be extended:

Application Engineering

Application engineering (development through reuse) is the process of deriving a concrete product variant from reusable domain engineering artifacts. To do this, the first step is to match the customer requirements with the existing features of the variability modeling. The matching is done manually and is typically done in a configuration tool. Most people will already have come into contact with product configurators, e.g. at automobile manufacturers or online stores, where features/product characteristics can be adapted as part of the ordering process. In our example, the customer selects the cruise control and lane departure warning features, but leaves out the roof window feature. The finished configuration, together with the reusable domain engineering artifacts, is input for product generation. In this process, a product variant is generated – ideally fully automatically – from all relevant artifacts. Because the reusable artifacts do not change, different product variants can be generated by entering different configurations. The underlying generator takes into account all the different artifacts (concrete requirements, architecture, etc.) previously created in domain engineering.

Application Engineering is connected to Domain Engineering via a feedback loop. I.e. requirements that cannot be taken into account during configuration are fed into the variability modeling. Within the modeling, new/changed requirements lead to an adjustment of the product portfolio and finally to new/changed features within the product line implementation.

Interaction of Domain Engineering and Application Engineering

The representation of Domain and Application Engineering in the first figure is detached from the individual disciplines that still take place within product development (Requirements Engineering, Design, Realization and Quality Assurance). Looking at the individual disciplines, the following picture emerges for Domain and Application Engineering:

Zusammenspiel Domain Engineering/Application Engineering; inspiriert von "Software Product Line Engineering: Foundations, Principles and Techniques; K. Pohl, G. Böckle, and F. van der Linden; 2005; Springer"

Zusammenspiel Domain Engineering/Application Engineering; inspiriert von "Software Product Line Engineering: Foundations, Principles and Techniques; K. Pohl, G. Böckle, and F. van der Linden; 2005; Springer"

All engineering disciplines are interconnected analogously to product development for a single product. Thus, design builds on the results of requirements engineering, realization builds on the results of design, and so on. The difference here is that the disciplines occur twice: once in Domain Engineering with e.g. Domain Requirements Engineering and once in Application Engineering with Application Requirements Engineering. The focus of the domain engineering disciplines is the creation of reusable artifacts. For example, when creating requirements specifications in Domain Requirements Engineering, it is taken into account that not all car variants contain a cruise control. That is, the requirements for cruise control are marked in such a way that they apply only to all product variants of the car with cruise control and are disregarded for all other product variants.

When the “variable” requirements are transferred from domain requirements engineering to application requirements engineering, these requirements are configured so that a concrete car can be created from them. Ideally, the transfer of variable requirements in application requirements engineering is purely by configuration. This means that no new requirements have to be created for the new product variant when it is created. The same applies to the other engineering disciplines such as Design, Realization and Quality Assurance.

Dealing with variant-specific enhancements

With the division of the engineering disciplines into domain engineering (development for reuse) and application engineering (development through reuse), variant-specific enhancements, i.e. enhancements that are potentially only needed for one product variant, can be implemented either in domain engineering or in application engineering. For implementation in the two different process areas, the following points must be considered in each case:

*Application Engineering:

Integration und Nachversorgung

Integration und Nachversorgung

*Domain Engineering:

Bildnachweis Titel: © Robert Kneschke, Adobe Stock
Dr. Jörg Liebig

Dr. Jörg Liebig

Senior Consultant

+49 89 5307 44-512

liebig@4soft.de

Do you have any questions about technology or product line development? I would be happy to discuss them with you - I look forward to receiving your e-mail.