Principles & Approaches
Management and specification of variable product properties
The precise specification and management of variable product properties in a development project requires this variability to be reflected in the development artifacts. These can be system requirements, but also models or source code modules, etc. There are different approaches for creating the planned variants of a product in an unambiguous and reproducible way, briefly introduced here.
The actual model chosen for a development project is often a combination of the principles presented here. For example, the VaMos approach is based on variation points. The aim is always to ensure the required variability with the least possible administrative effort.
Super Set (also: 150% model)
The principle
- A 150% model contains all planned variants and options of a product in a single model or code repository.
- It is structured in such a way that certain components can be switched on or off depending on the selected product variant.
- In a 150% model, all product variants are managed in a common database. Features and functions are controlled by configuration parameters. The selection is often made using feature flags, configuration files or modelling tools.
Advantages
- Avoids redundant data and code duplication.
- Standardized database ensures better maintainability.
- New variants can be derived more quickly.
Disadvantages
- High complexity, especially with many product variants.
- Risk of unexpected interactions between variants.
Clone & Own
The principle
- When a new variant is derived, it is not based on a common database for all variants.
- Instead, an existing variant is copied (cloned) and then customized.
- Each cloned variant of the system evolves independently and no longer has any connection to the origin.
Advantages
- Easy to implement, especially for extensive customizations.
- No dependencies between product variants - changes have no side effects on other variants.
Disadvantages
- Maintenance effort increases with every cloned variant and every change.
- Bug fixes or improvements in functions that are used in several variants must be added manually in each copy.
- Scales poorly with many variants.
Feature model (also feature tree model)
The principle
The feature model is a method for the structured visualization and management of the functional properties of different product variants. It describes which characteristics (features) a product can have and which dependencies exist between these features. This often results in a tree-like structure, the feature tree.
- Features have mutual dependencies. In addition to the variable features, a feature model also defines these dependencies and the configuration rules to be observed.
- For example, optional, alternative or mandatory features, as in this example:
- A car must have a motor (mandatory).
- It can either have a gasoline or electric motor (alternative features).
- It can have a navigation system, but it is not mandatory (optional feature).
- As a convertible it can not have a sunroof (excluding features).
- Feature models generally serve as the initial specification of the product variants and can be propagated to the various engineering disciplines. How features develop in the engineering disciplines can be managed very well with Global Configuration Management (GCM), GCM supports GCM.
- The feature model and GCM are not mutually exclusive, but complement each other.
Advantages
- Artefacts from all engineering disciplines involved in the project can be mapped.
- Conflicting features are recognized quickly.
- Missing features are identified more easily.
Disadvantages
- Creating a feature tree requires early and very thorough planning of the variants to be developed (may result in a delayed project start)
- It can be recommendable to use a dedicated variant management tool that can be used by all engineering disciplines involved in the project.
Variation Points
The principle
- Variation points are a way of defining variants in a SysML or UML model. IBM Rhapsody supports the use of variation points.
- A variation point defines alternative or optional variants in a model, and there can be several variation points in a system or software model.
- The configuration determines which variant or option is selected for each variation point.
- Variation points make the variability explicit: anyone reading the system model will immediately recognize where different options exist.
- In a software system model, a variation point could indicate whether a safety function is active or inactive - depending on customer requirements.
- In SysML, variation points can be mapped using stereotypes, constraints or feature models.
Advantages
- Easy to use for modellers
- IBM Rhapsody supports variation points, so no additional tool is required.
Disadvantages
- The model can become confusing with more complex products.
- Variation points can only be used in the modelling phase. Other engineering disciplines do not support variation points.
VaMoS (Variant Modeling with SysML)
The principle
VaMoS is a method developed by Tim Weilkiens to describe and control variants and product lines with the help of SysML. The method utilizes variation points at which different versions of the system can occur. The basic concept of VaMoS is based on
- Core elements: Parts of the system model that are present in every system or product variant. Core elements form the common foundation of all variants.
- Variation points: Define where and how system variants can differ.
- Variant elements: the specific characteristic at a variation point. It describes a specific option or alternative that can be selected instead of another one.
VaMoS often works with a superset (or 150% model), which initially includes all possible functions and components from which specific variants are derived later.
Advantages
- Traceability throughout the entire system model: Thanks to SysML, variation points can be linked directly to requirements, design components and test cases. Users always have a clear view on variants and their associated features, incl. implications on the architecture and tests.
- Automated derivation of variants: With the appropriate tool support, specific product or system variants can be derived automatically from the 150% model using the defined variation points. This reduces the effort required for manual adjustments and minimizes errors.
- Cross-industry use: VaMoS is used particularly in areas with high product complexity, e.g. in the automotive and aerospace industries, in mechanical engineering or in medical equipment.
Disadvantages
- VaMoS is essentially based on Core Elements and Variant Elements. Both exist only once in the model and not in different versions at the same time. This means that if an element is changed, this change is immediately reflected in all variants in which this element is used.
- This is often not desirable, as variants can be in different production statuses.
Orthogonal Variability Model (OVM)
The principle
- OVM is a stand-alone approach for modeling variability - independent of specific UML or SysML diagrams.
- Variability information is stored ‘orthogonally’ to the actual system architecture (i.e. in a separate model), which offers more flexibility for integration into different development processes.
- OVM is also based on Variation Points.
Advantages
- Better communication of variability through independent model
- Traceability by deriving relationships between artefacts
- Consistent implementation of changes and reuse through visualization of all affected requirement artifacts
Disadvantages
- A dedicated separate model must be maintained In order to document the variability.
Please contact us:
We talk Global Config
Do you have questions about Global Configuration Management?
Tap into our decades of experience from many successful projects.
Contact us by email or phone: