PLE glossary

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

Artifact

Synonym for Engineering Asset

Application Engineering

Application engineering is the creation of an individual variant based on the toolkit that domain engineering has created. If domain engineering is called "engineering for reuse", application engineering can be called "engineering with reuse" or "engineering benefitting from reuse". Application engineering basically involves creating a configuration for the desired variant and then deriving the engineering assets according to that configuration. If all the needs of the variant have already been foreseen by domain engineering, the derived assets already constitute the solution variant. The usual case, however, is to take the derived assets as the basis and to complement them with application-specific assets in order to produce the full solution variant.

Domain Engineering

Domain engineering is the production and management of the toolkit of feature models, family models, and engineering assets from which various product variants (aka applications) can be built. Differently from application engineering, which focuses on a single variant, domain engineering keeps all the variants in the scope of the product line in perspective. This is why domain engineering can be called "engineering for reuse."

Engineering Assets

Any (typically digital) asset which the product is composed of or which is used to help create the products. Typical engineering assets are requirements, models, code, test cases and documentation. These are usually created and maintained as part of the engineering process.

Family Model

Family models provide the link between problem space (the world of features and attributes) and solution space (the world of requirements, architecture models, and other engineering assets). More specifically, a family model is a representation of an engineering asset that allows you to control the variation points in this asset.

For example, if your engineering asset is a requirements module, then the corresponding family model will represent each chapter and each individual requirement as a so-called family model element. You can then connect the family model elements to your feature models and define rules such as "if feature A and B are selected, chapter 3 shall be included; otherwise, the chapter shall be excluded". But instead of defining such rules, you can also select (or exclude) family model elements directly when you configure your variant. Which way is better depends on your use case.

Feature Model

A feature model is a means to organize features and express the relationships between them. Feature models are usually represented as trees, in which the more general features appear closer to the root, and the more specialized features appear further away, as so-called "child" features of a more general "parent" feature. Besides generalization and specialization, feature models also express other kinds of relationships between features. For example, some features are options - they can be freely selected, independently of other features - whereas other features are alternatives - if one is selected, then its alternatives cannot be selected at the same time. These relationships (and more) are encoded in a feature model, and together, they form a rule set that describes whether a feature configuration is valid (corresponds to a valid product variant).

Holistic Product Line Engineering

Modern systems engineering requires various kinds of shared engineering assets (building blocks) such as requirements, models, code, tests. Instead of managing variability and product configurations separately for each kind of asset, using vendor-specific concepts and tools, the goal of Holistic Product Line Engineering is to maintain all variability-related information in a single source of truth, and to apply this information across all assets in a unified way. This includes not only the management of variability and product configurations, but also the (automated) derivation of variant asset. This way, holistic product line engineeringt helps to give all stakeholders (managers, engineers, customers) access to the same consistent information regarding variability and product configuration(s).

Product Line Engineering

Product Line Engineering (PLE) is used to identify engineering approaches which focus on the development of multiple similar products as a single product line. Often PLE is a shorthand for Systems and Software Product Line Engineering, where the focus is on engineering physical products which are complex and software-intensive such as cars, control systems or automation components.

Variant Assets

Variant Assets are the assets which a variant (product) is composed of. Variant assets can be either (derived from) shared assets (source code, specifications, etc.) or assets which are unique to a given product (e.g. the variant configuration [ISO25680: bill-of-features]).  

Variant Management

Holistic variant management is an important part of PLE. Modern systems engineering requires different types of shared engineering assets (building blocks) such as requirements, models, code and tests. Instead of managing variability and product configurations for each type of asset separately, using vendor-specific concepts and tools, the goal of holistic variant management is to manage all variability-related information in a single source of truth and apply this information to all assets in a consistent way. This includes not only the management of variability and product configurations, but also the (automated) derivation of variant values. In this way, holistic variant management helps to ensure that all stakeholders (managers, engineers, customers) have access to the same consistent information about variability and product configuration(s).

Variant Management vs. Configuration Management

Although variant management and configuration management are often used interchangeably, there is a clear distinction between these terms. While variant management covers the variability in space (what at a given point in time is configurable and how different product instances aka variants are configured), configuration management covers the variability in time (records different states of assets over time). Effectively, variant management and configuration management complement each other. And they are strongly linked as well, because each change in variability (for example, the addition or removal of a feature) also affects the assets maintained and tracked through configuration management.

Variant Model

A variant model is a configuration of a (part of a) product variant. It holds the information about which features are selected or excluded, as well as which values are given to the configurable attributes in the feature models. Furthermore, the variant model also holds the information how variation points in the engineering assets are configured.

Mapped to the models in pure::variants, a variant model contains configuration choices for both feature models and family models.

You might also want to have a look at