Last week we looked at the different kinds of configuration management and compared the differences between configuration management in software and in hardware.
This week, we look at the commonalities between them and how best to approach configuration management when software and hardware are concerned.
There are a lot of commonalities between software and hardware when it comes to configuration:
- Test cases design documents.
- Customer requests.
- User documentation.
- Problem reports.
- Engineering activities and requests.
- Waivers and deviations.
- Item hierarchies.
- Impact analysis.
- Change packages/ECNs.
- Test results.
- As-designed and as-built baselines.
These elements are quite similar in both disciplines, but also have many differences.
Taking the above into consideration, it becomes clear that a two-prong approach in configuration management is needed to accommodate both the differences and the similarities between the two. For example, let’s look at problem reports.
The key is to be able to reproduce a problem based on the problem report itself. Software problem reports are virtually always functional in nature: “The feature doesn’t work the way it should”, e.g. a display may have more bad pixels per unit than specified. With hardware, “feature” is usually replaced with “specification”.