CM: The Nerve of Your Life Cycle Management

organization, perhaps for documents pertaining to a specific sale, but we don't require it.

We also have attachments - things like diagrams, debug output, email attachments - which need no version control, no hierarchical organization and no real identification other than to be able to reference them as an attachment.

Finally, we have "short documents" or notes. Things like problem descriptions, an email thread or chat script from a customer interaction, that sort of thing. These we attach directly to the corresponding database records as "note" fields. We don't do version control on them at all. But we still need to organize them and the database capabilities of our CM tool support that adequately. I guess we're starting to blur the distinction between data and documentation at this point.

We have all sorts of documents, and very different CM requirements for each type. If the CM tool were to force us to use "source code control" on all of these, we'd be treading water. CM must be provided as necessary, but it really needs to exist as a set of capabilities which may or may not be applied to the various documentation sets.

One last set of documentation that we'll often refer to is generated documentation . We don't need to do CM on this type of documentation unless we are unable to re-produce it at will. It's the CM and other capabilities for the underlying objects which are important here. Release note summaries, requirement baseline documents, status reports, etc. If we can't easily reproduce these, we may choose to generate them and then store them as a generic report document, similar to the Project Status Report (PSR-) documents above. Otherwise, we only need to ensure that we can reproduce them at will.

How Much CM is too Much?

So how much CM do we need to do? Should we version control all of our data? What about baselining it?

We could, if we wanted to, do version control of all of our requests so that we could go back to any point in time and tell our customers this would have been the status of your requests at this point in time. We don't find that useful so we don't do version control of our requests. Instead, at a particular point in time, say quarterly, we'll generate a report for our customer and then save it as a CUS- document, perhaps collecting all of the reports for a particular customer under a specific DIR- container. Then we have every report we've ever sent to our customers and we don't need to do any CM on their requests.

I've seen tools that will even do version control of a Problem Report rather than just maintaining a running log of events for the problem. (I'm NOT talking about tracking different instances of the problem for different products or even different releases.) For me, this is overkill. For you it may be a different story. But that's why we need CM as a capability which we can apply to various objects in different ways, according to our process requirements.

Similarly, we don't "baseline" all of our data. But we do have the capability of creating a "checkpoint" file which captures the exact state of the repository at a given point in time in just a few megabytes. That's good - if we want to prove that our data has not been tampered with after the fact, we can view our repository from the perspective of a given checkpoint file. But that's what it is. It's a snapshot in time. We don't