CM: The Nerve of Your Life Cycle Management

• an old one and a newer one. Expand them and subtract the history of the older one from the history of the newer one. This should give me a set of intermediate (and final) file revisions. Convert these to a set of change packages and identify the features implemented by those change packages, the problems fixed by them, the developers who performed the changes, etc. Now I've got the basis for generating my release notes in terms of one build and an older one.
• Layering for Re-use. Take a layer of a product that you want to share in the development of another product. Identify all of the files not in that layer that the files of the layer depend upon, within a given context. That will show me the obstacles to re-use of that layer of software in another product. As soon as I eliminate those "upward" dependencies, I have a potentially re-usable layer of software.
• Customer Request Progress. Take a customer's current build and the build you're planning to deliver. Compute the set of problems reports and features addressed between these two builds, as above. Now trace these back to the requests that have been raised by that customer which have spawned problem reports and feature activities. This intersection identifies for the customer which requests have been addressed in the new build.

I've had the pleasure, over the past quarter century, of working with environment tools having a healthy interaction between CM and DM. There's no doubt that each of the ALC management components has benefited. If your CM solution is currently just one component of your management suite, you may have room to make some quantum leaps. What forms the nervous system of your management environment?