CM: The Nerve of Your Life Cycle Management

requirement, a feature, or a problem report. How CM is applied to Test Case management varies more widely from project to project than its application to Source Code management. So more flexibility is required for a project to implement its CM plan for Test Case management.

Document Management and CM

So what about documentation? Isn't it just another form of source code? Well yes, and no. Let me clarify that: it depends. Documentation is complex. In fact, I'd say that we take all of the things that we're not quite sure how to characterize and call them either documents or data, and of course XML is even helping to blur the distinction. We have Product Documentation, Functional and Design Specifications, Status Reports, Process Documentation, Technical Notes, Customer Communications, and so forth. And what do we call these - documentation. So, what do we do at Neuma?

First we have our Product Documentation . This is a lot like another form of source code, other than the fact that it has to be massaged so that it can be presented in several different formats. So we treat it like source code. Change control, version control, hierarchically arranged, baselines, etc. In fact, we don't distinguish, from a CM perspective, the handling of source code and Product Documentation. They even share the same source tree. Just as with source code, we have to deal with branching at some point because the release 1 documentation is different from release 2 and may evolve separately, or will, at least, require separate maintenance.

What about Process Documentation? This is much the same. We treat our Process as a product. The difference is that it has it's own product tree, separate from the product(s) we're developing. But it still needs to be tracked much the same. It will branch on different time lines than the product(s). The "process product" road map will tell us how and when it will branch. Each application product will have it's own road map for branching. And that will be different than for the process product road map, which may well apply across all development projects.

Incremental Specifications

So, the same for Functional and Design specs? No. Whereas product documentation has a life of it's own, specifications are used to transform the product. Let me clarify something here. I'm talking about the functional and design specifications which describe Changes to the product: incremental specifications.

The full Functional Spec for the product is part of the Product Documentation. The full Design Spec for a subsystem or component should be treated much like product documentation as well. However, rather than having 25 designers, with different writing skills, trampling through the design specs as they make changes, we have them write incremental design specifications which indicate how the design is changing. That's what they know about the best. Technical writers are much more able to knit the design changes into the full Design Spec. And they can do it in batches. So if 30 changes affect a particular component, in a given release, we don't need to describe the component at each of the 30 states. Perhaps it is updated after the first 20 changes and then later on when design changes are fairly much completed for a release. That way, if a change has to be rolled back because it was decided that it was a threat to security, or to stability, we don't have to do double the work. Although this would never do in some organizations, it suits us well.

How do we handle these incremental specifications? We attach them directly to