Smartpedia: Configuration management manages and labels related work results – the so-called configurations – in the course of product or software development.
Configuration Management – The administration of related work results
During product and software development, many different work results such as programs and components, files like requirement specifications and architectural sketches, release notes or change logs, test specifications and test data, change requests or source code are generated. Configuration management manages and labels related work results as so-called configurations.
In the 24765-2017 – ISO/IEC/IEEE, which defines terms for system and software engineering as an international standard, configurations are described as follows:
- arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts
- the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product
- arrangement of a system or network as defined by the nature, number, and chief characteristics of its functional units
- requirements, design, and implementation that define a particular version of a system or system component
- manner in which the hardware and software of an information processing system are organized and interconnected
- collection of objects able to interact at interfaces
Whoever talks about configuration or configuration management should make sure that all participants share the same understanding of the term.
The four-pillar model in Configuration Management
Configuration management is often used synonymously with version management, which focuses on managing individual files rather than related work results. In some publications, configuration management is also presented as a four-pillar model:
The four pillars address the documentation of all changes in the development of software and systems with the aim of continuously monitoring and controlling adjustments, corrections and enhancements.
Terms in Configuration Management
Important terms in configuration management are
- the atom as an element without further parts,
- the baseline as the name of a version of a configuration,
- the basic configuration as the name of the configuration created first,
- the configuration element as part of a configuration,
- the release as a configuration that is delivered to customers and marketed accordingly,
- the revision as a means of identifying the status of a configuration element and
- the target configuration as the desired result of a product or software development.
What answers does Configuration Management provide?
Through configuration management, organisations can answer the following questions, for example:
- If a component is changed, which elements are affected?
- What are the differences between two configurations?
- In which configuration did an identified error occur first and what effect does this have on subsequent configurations?
Audits often reveal typical problems with configuration management. Thus, not all artefacts are put under version control, since it is unclear which artefacts are to be versioned when. Even decisions about measures, the release of changes or the proof that adaptations fulfill concrete requirements are often not comprehensible.
Requirements management also speaks of configurations – the so-called requirement configurations. Requirement configurations must be clearly identifiable, they cannot be subsequently changed and offer the possibility of resetting requirements to versions within a defined configuration.
Errors in Configuration Management
There are some “typical” errors that often become apparent in the context of audits:
- Not all artifacts are under version control. Or only the “last” state before a release was versioned.
- Code recovery fails. Even the match between test code and product code cannot be restored, especially if the test and development environments are not under version control.
- Explicit change approvals are missing or reasons why submitted change requests have not been implemented. Evidence is also often missing that changes actually meet specific requirements.
An additional difficulty lies in the validation of the used tools. It is often difficult for manufacturers to have their tools validated. And for users, it is difficult to provide proof of complete versioning.
Impulse to discuss:
Why is the topic very present in many disciplines, but often completely unknown in other areas?
Here you will find additional information from our Smartpedia section: