Configuration management is one of the most important core processes of Automotive SPICE. It allows you to manage how you can decouple customer-specific releases in the regular day-to-day R&D, while still maintaining transparency over the development project. You can always find out how to do this in our video and free whitepaper.
Back to Automotive SPICEWould you like to learn more about the Automotive SPICE process Configuration Management (SUP.8) from the VDA Scope? In our free whitepaper you will find all information summarized and a reading sample from the book Automotive SPICE® Essentials, the book for beginners in the topic of process improvements.
Automotive SPICE is a trademark of VDA QMC.
The configuration management process in Automotive SPICE® (also referred to as SUP.8) helps your organization ensure the integrity of all work products.
Typically, project team members create many new versions of code, documentation, drawings, etc. every day. Managing these changes and monitoring their consistency, as well as subsequently building a product from them, is tedious and error-prone. That's what configuration management is all about.
These are the most important aspects of configuration management in Automotive SPICE®:
Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.
Steffen Herrmann and the sales team
Your Configuration Management system needs to store everything needed to define your product. If your product consists of software, hardware and mechanical components you will have bills of materials, drawings, requirements, design, code, tests, and so on. Imagine that all these items are stored in different tools. How can you manage the relationships for a product version? For the solution, refer to the picture below.
Each symbol represents an item. 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).
We 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).
We continue doing this for drawings, requirements, design, code, tests, and so on 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.
This is shown here.
You use one of the SW tools as the leading tool and you can describe the complete product through local baselines and one superordinate overall baseline. That’s it!
Sometimes projects waste their resources and put items unnecessarily under configuration management. Therefore, you have to decide which items to place under configuration management based on these simple criteria:
The pocket guide Automotive SPICE goes Mechatronics can be downloaded in digital format (PDF) or purchased in printed form with a practical ring binding via our webshop or in your specialist bookstore.
This is the point: 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?
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.
These three simple aspects form the configuration management.
If you follow these points