We have hardly seen instances of this issue being discussed. We are painfully aware of the large extent we often require of configuration management because we have to work with tools in the embedded environment called “cross-compilers.” These tools allow the developer to work in a familiar programming language such as C and then produce executable code for the target processor, a processor that is often wildly different in architecture than the one on which we do the development. We have seen cases where we needed to manage the configuration of the version of the compiler, because subsequent product changes to that compiler would no longer work with target processor.

What happens if we change our configuration management (CM) support software? Aren’t we in the same situation as we are with the cross-compiler? We suggest that, indeed, we are in an analogous situation. Hence, any time we upgrade or change our CM support software, we need to many this change also. That suggests we must follow the standard procedure:

• Identify the configuration, including components
• Create a meta-control system to provide an orderly transition
• Ensure we can provide status reports during transitions (configuration status accounting)
• Plan the audits from the beginning of the transition project
o Physical configuration audits to ensure we have documentation appropriate to both the old version and the new
o Functional configuration audits to verify the new version works as desired
• We should also create some point checks to verify the integrity of the CM support software by evaluating the results with files that we know are difficult (e.g., immense bills of material, massive and complex drawings, etc.)

To our knowledge as of this writing, no tools exist to help with these transitions. This situation makes some level of sense because we could easily end up with an infinite regression of tools to manage tools to manage tools ad nauseam. The path to success here is traditional:

• Plan
• Do
• Check
• Act