Introduction
Normally, the project the staff produces many new versions of code, documentation, drawings, etc. every single day. Controlling this workflow and creating a product from it is tedious and error prone. This is what configuration management is about.
I regard the following as the most important aspects of configuration management in Automotive SPICE:
1. Build a configuration management system that covers all development activities
A configuration management system needs to store everything needed to define a product. If a product consists of software, hardware and mechanical components, there will be bills of materials, drawings, requirements, design, code, tests, etc. Imagine that all these items are stored in different tools. How can one manage the relationships for a product version? See Figure 1.
Figure 1. Configuration management solution.
Each symbol represents an item. In our process, we:
- Mark all software elements which we will use to create the next software version. This is what we call a local baseline. We will assign a label to this baseline that uniquely identifies this baseline and its items (#1).
- Do the same for the hardware components which we will use to create the next version of the printed circuit board. We mark them with a second label and have another local baseline represented by this label (#2).
- Continue doing this for drawings, requirements, design, code, tests, etc. and we will have more labels (#3).
Now, here's the trick. We put all the labels in one configuration management tool and define the overall baseline. See Figure 2.
Figure 2. Overall baseline.
Hypothetically, you use one of the software tools as the leading tool and you can describe the complete product through local baselines and one superordinate overall baseline.
2. Decide what to place under configuration management
Sometimes projects waste their resources and put items unnecessarily under configuration management. Therefore, decisions have to be made about which items to place under configuration management based on these simple criteria:
- Do you need the item to build the product?
- Do you need the item to describe the product?
- Define how to handle branching and merging correctly
In software development it can happen that several developers work on the same code at the same time. Of course, this can lead to severe inconsistencies. How can we merge them without causing conflicts? See Figure 3.
Figure 3. Branching.
Generally speaking, here is your solution: When you merge the two versions, the configuration management tool highlights both types of changes. You have to define a rule how to handle this (e.g., “the person making the last change is responsible for performing a code review and resolving any conflicts”). And, generally, you should define rules about what types of branches and merges are allowed in what situations.
Summary
That is configuration Management in short.
By following these points, one is better enabled to:
- Build an effective and efficient configuration management system.
- Provide great support for project management and release management.
- Help the project deliver what the customer has been promised.
Configuration Management – the process according to Automotive SPICE®
The purpose of the Configuration Management Process is to establish and maintain the integrity of all work products of a process or project and make them available to affected parties.
Best practice (BP1): Develop a configuration management strategy. Develop a configuration management strategy, including.
- Responsibilities.
- Tools and repositories.
- Criteria for configuration items.
- Naming conventions.
- Access rights.
- Criteria for baselines.
- Merge and branch strategy.
- The revision history approach for configuration items.
- Note 1: The configuration management strategy typically supports the handling of product/software variants which may be caused by different sets of application parameters or by other causes.
- Note 2: The branch management strategy specifies in which cases branching is permissible, whether authorization is required, how branches are merged, and which activities are required to verify that all changes have been consistently integrated without damage to other changes or to the original software.
BP2: Identify configuration items. Identify and document configuration items according to the configuration management strategy.
- Note 3: Configuration control is typically applied for the products that are delivered to the customer, designated internal work products, acquired products, tools and other configuration items that are used in creating and describing these work products.
BP3: Establish a configuration management system, according to the configuration management strategy.
BP4: Establish branch management, according to the configuration management strategy where applicable for parallel developments that use the same base.
BP5: Control modifications and releases. Establish mechanisms for control of the configuration items according to the configuration management strategy, and control modifications and releases using these mechanisms.
BP6: Establish baselines for internal purposes and for external delivery according to the configuration management strategy.
- Note 4: For baseline issues refer also to the product release process SPL.2.
BP7: Report configuration status. Record and report status of configuration items to support project management and other relevant processes.
- Note 5: Regular reporting of the configuration status (e.g., how many configuration items are currently under work, checked in, tested, released, etc.) supports project management activities and dedicated project phases like software integration.
BP8: Verify the information about configured items and their baselines is complete and confirm the consistency of baselines.
- NOTE 6: A typical implementation is performing baseline and configuration management audits.
BP9: Manage the storage of configuration items and baselines. Support the integrity and availability of configuration items and baselines through appropriate scheduling and resourcing of storage, archiving (long term storage) and backup of the used configuration management systems.
- Note 7: Backup, storage and archiving may need to extend beyond the guaranteed lifetime of available storage media. Relevant configuration items affected may include those referenced in note 2 and note 3. Availability may be specified by contract requirements.
Output Work Products
- Handling and storage guide
- Configuration management plan
- Recovery plan
- Baseline
- Configuration management record
- Change history
- Configuration management system
Configuration management: Advanced tutorial
What is the benefit of configuration management?
Development in automotive projects is highly incremental and must continuously take into account change requests. It is not easy to keep the large number of resulting modified work products consistent to each other. This is even true beyond development, as suppliers must be able to modify their systems for up to 30 years after end of production. This can only work with a very stringent configuration management system.
What is the content of the configuration management process?
- A configuration management strategy is developed and documented, typically in a configuration management plan (BP1). BP1 lists typical elements of a strategy. This comprises also the strategy for branching and merging.
- The work products which shall be under configuration management control (see Figure 4 configuration items spreadsheet) are defined (BP2).
- Branching and merging (if applicable) needs to be done according to the strategy (BP4).
- An appropriate configuration management system is established which allows to control the changes to configuration items and building baselines and releases (BP3/5/6).
Figure 4. Example spreadsheet with configuration items and their assignment to baselines.
- Configuration management tools feature generating reports that mirror the status of configuration items with respect to a life cycle model (e.g., work in progress, reviewed, unit tested, integration tested) (BP7). This is very useful for project managers, build managers, test managers, etc.
- Checks are needed to guarantee that the product built conforms with the functional requirements (functional configuration audit) and with the design () (BP8).
- Storage and backup of configuration items, baselines and releases needs to be defined and organized. Their long-term archiving needs to be guaranteed according to customer requirements (BP9). This includes also archiving of development tools.
Considerations for typical challenges
- Configuration items are typically all relevant engineering work products (covering the entire V model) related to producing product releases. This includes also the tools used and all relevant work products from management and support processes.
- Starting parallel development of software is called branching. Whether, and in which cases, this is permissible needs to be defined. When the branches are merged again special care needs to be taken to resolve inconsistencies.
- The configuration management system needs to work for all disciplines (software, hardware, mechanics, etc.) and therefore spans different configuration management tools. A method is needed to establish cross-disciplinary baselines.
- A baseline is a precisely defined set of uniquely identified configuration items. Baselines can be used to freeze a particular state of development to protect it against uncontrolled changes (e.g., a freeze of requirements and design for a particular release in order to focus afterwards on implementation and bug fixing). At a minimum, baselines are used to produce a release of the product.
Software is supported by the traceability and consistency practices of the engineering processes. The goal is to confirm that the functionalities which should be in the build, are in fact contained in the build. The release plan, planned change requests and bug fixes are the sources for confirming this consistency.
Learn more about Automotive SPICE®
If you want to learn everything Automotive SPICE® has to offer and become an Automotive SPICE® expert, check out our ASPICE Training.
About the author
Klaus Hoermann started working with Automotive SPICE® in 1998. Since then, he has performed hundreds of assessments and trainings. His passion to bring hard-to-understand models to life so that everyone can understand them.
To access the rest of this engaging content, please fill out the form below:
Please wait…