Global Configuration Management:
Managing Variants and Versions
at System Level

How is ‘Global Configuration Management’ (GCM)
different from 'Configuration Management' (CM)?

Consistency, transparency and stability

Configuration Management (CM) refers to the systematic process of managing and controlling changes to requirements, design elements, software, hardware and IT infrastructures. The aim is to ensure consistency, traceability and stability with regard to changes and to guarantee complete reproducibility of the product in its variants and versions. In the past, this process was seen and practised in the context of a domain or engineering discipline. Each domain has its own versioning mechanism.

Global Configuration Management

Global Configuration Management (GCM) spans the context across all domains and engineering disciplines involved in engineering, production and maintenance of a system and also takes into account the correct allocation of development artifacts across variants and versions.

Example: Freezing engineering milestones

Werkzeugübergreifend können Entwicklungsstände in einer Rolling Baseline abgelegt (Committed) werden. Was auf den ersten Blick nicht besonders anspruchsvoll klingt, hat aber einige Herausforderungen, die beim herkömmlichen Configuration Management (CM) nicht berücksichtigt werden.

A typical task of CM is freezing engineering milestones in a baseline at a certain point in time. Such a baseline represents the status in terms of a level of maturity in the engineering process. However, in the context of all the engineering disciplines involved, this status does not exist at a specific point in time. Development follows a process. On a time scale, requirements engineering first delivers the work results, e.g. as specification 1.0. Developers start working based on specification 1.0 and deliver their work results 1.0 at a later point in time, followed by testing (verification) with an even longer time delay.

Timeliness

In the meantime, a new specification 2.0 has already been handed over to development.

Timing

Hence, a baseline for V1.0 does not emerge at a specific point in time. The work results associated with V1.0 are created at different points in time, depending on the engineering disciplines involved into the process.

Solution

Mit Hilfe so genannter Rolling Baselines können Entwicklungsartefakte aus unterschiedlichen Werkzeugen zu jedem Zeitpunkt in eine bereits existierende Baseline committed werden.


This is just one of many other requirements and features that are covered by Global Configuration Management.

Further challenges are:

Cross-tool definition and management of unambiguous baselines

Link resolution between versions and variants

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:

EN