Configuration Management

A software system comprises a large number of individual components that have to work perfectly together if the complete system is to function properly. In the course of development, each of these components exists in new, corrected, or improved versions. For large projects, multiple development and testing teams work in parallel, making it difficult to retain an overview of the current version of each component and which versions belong together.

Typical symptoms of inadequate configuration management

If a project’s configuration management (CM) is inadequately handled, the following issues can result:

• Because simultaneous access to the files is not managed, developers overwrite each other’s changes to source code or other documents.
• Integration is hampered because multiple versions of components exist and it is not clear which versions work together and can be integrated to form larger modules. Similar issues can occur if developers use differing versions of compilers or other development tools.
• Defect analysis and correction or regression testing are hampered because it is not obvious where and why a component’s source code has been modified, or which file is the source of a particular integrated component.
• Tests and test evaluation are impeded because it isn’t clear which test cases relate to which version of a test object or which version of a test object produced which test results.

The test process requires CM

Inadequate configuration management can have various negative effects on the development and testing processes. For example, test results can quickly become meaningless if it isn’t clear whether all the test objects on a particular test level are in the current version. Effective testing is impossible without reliable configuration management, so CM has to fulfill the following test-related requirements:

CM requirements

• Test objects, test cases, and test data must all be treated as configuration objects within the configuration management system.
• For every configuration object, you must be able to catalog, save, and retrieve all the available versions (1.0, 1.1, and so on). This version management data must also include documentation that details why any changes were made.
• Configuration management is based on effective version management. You have to be able to identify and retrieve the correct version of all the files that together make up a certain configuration.
• To support tracking of changes and corrections, defect reports should be linked to the configuration objects that are affected by the defect report.

To check the effectiveness of your configuration management it makes sense to perform occasional configuration audits. An audit checks that all relevant components are entered in the CM system and whether all configurations have been correctly identified.

Case Study: Configuration Management for VSR-II

The VSR-II user-interface modules are available in multiple languages (such as German, English, or French) and have to run on a variety of hardware and software platforms. Individual modules have to be compatible with specific versions of other components (for example, the ConnectedCar module has to be compatible with its opposite number in the vehicle, which can vary depending on the model and the year it was manufactured). Furthermore, data from various sources (such as product catalogs, price lists, and contract data) have to be imported at regular intervals, and their contents and formats can change during the system’s lifecycle. The VSR configuration management must ensure that development and testing take place using consistently valid product configurations. The same is also true for productive use of the software by end-users.

The CM process and the required CM tools will vary from project to project. In order to fulfill all the requirements listed above, you need to define a configuration management plan tailored to the project at hand. [IEEE 828] is one example of a widely used configuration management planning standard.

Side Note: Standards and norms

Relevant Standards and Norms

These days there are a great number of standards in use in software development. These define various constraints as well as the technological “state of the art”. The standards and norms mentioned in the course if this book demonstrate just how embedded such standards are, especially when it comes to software quality management and testing.

A quality or test manager’s tasks therefore also include identifying the standards and legal guidelines that are relevant to the product (product norms) or the project (process norms), and making sure they are adhered to. Potential sources of standards include:

• Company standards
  Manufacturer’s (and sometimes the customer’s) internal guidelines and procedural directives, such as quality management manuals, test frameworks, or coding guidelines.
• Best Practices
  Non-standardized but proven techniques and procedures that reflect the technological state of the art in a particular field of application.
• Quality management standards
  Cross-industry standards that specify minimum process requirements without defining implementation guidelines. For example, [ISO 9000] suggests that appropriate (interim) checks are always performed during production processes (in this case software development) without actually stipulating when and how.
• Industry-sector standards
  Sector-specific standards (for example [EN 60601] for medical products, [RTC-DO 178B] for aeronautic software, or [EN 50128] for railroad signaling systems) that define a minimum scope for tests to be performed for a specific category of product or field of application.
• Software testing standards
  Product-independent process standards that define how to perform software testing professionally. The most important of these in the context of this book is [ISO 29119].

Alignment to such standards (see also the list of standards and norms in Appendix C.3) can be useful even in situations where it is not mandatory. If a project should ever find itself in legal difficulties, it can be very important to be able to prove that development was performed in compliance with appropriate standards.