Configuration management, a simple example… really!

Now that the DOORS Next Generation V6.0 has been out for a little while, I thought I should share some of my thoughts on how and why to use configurations.
I am pleased to see that from an end user perspective, this is really easy to use – you get a work item linking to a change set and you go do your work there, no need to understand the big picture.
There are two main reasons for wanting the CM capability, one is variant management and the other is version management. Variant management is the more complex of the two, so consider for now just the version management. This is where you have two (or more) versions of the requirements that are live at the same time. Unless you are working in a pure waterfall then you are very likely to want this. A version for the current iteration of the work, and a version for the next iteration of the work. We need to keep them separate because the design, test and other project documentation can be very different as the project develops.
My personal opinion is that the ‘base configuration’ or the world at the start of the project before you turn on configuration management, should be used for a big picture either of the last full released iteration, or for the most up to date picture available. In either case, it is not really considered in the following discussion.
Create a baseline from the base configuration and from that create a working stream for the iteration. In the diagram this is the top two lines, in grey (Base, and Iteration 1).
From this iteration stream, create a working stream for the highest level requirements document. This is where all changes to that document will be carried out – all within change sets. The Stakeholder line on the diagram. For the sake of simplicity, suppose that all the work on this document is contained within a single change set, CS1. This is reviewed as necessary and delivered to the Iteration 1 stream.
Once the highest level requirements document is issued for the iteration, a sub-stream for each dependent document can be created – these are also created from the Iteration stream, following a baseline. Now work can continue in these streams, the final two lines in the diagram (System and Validation Plan), again in change sets. Change sets CS2 and CS3 are created for this purpose, and when complete, are delivered to the Iteration 1 stream.
Once CS1 is delivered to the Iteration 1 stream, work can start on Iteration 2 of that document, so an iteration 2 stream is created and a Stakeholder I2 working stream is created from it.
This is all looking quite complicated, and there are deliveries between streams that are not covered in this description, or on the diagram, but this does give the individual engineer working on any one of these documents a clean area in which to work, unambiguously against a defined parent document version. The end user can even be directed into a particular change set. Some form of integration engineer or systems engineer will need to deliver the change sets between streams under controls defined by the organization, following appropriate review and approval processes.
This also allows for panic updates to the stakeholder requirements to go into iteration 1 after work on iteration 2 has started, just create another change set in the Stakeholder requirements iteration 1 stream. Nothing else is affected, and once this work is complete it can be delivered down to dependent streams, and up to the Iteration stream.
Naming conventions are important here, for the streams and for the change sets. Somebody, the configuration manager, has to see the full picture here and that is not simple. Fortunately it is complicated rather than complex, a distinction that is appreciated by systems engineers, if not by the rest of the world.
Someone is going to complain about the explosion of data in the database, but DOORS Next Generation doesn’t make a complete copy for each stream, it works some magic behind the scenes to keep track of differences and keeps the database at a sensible size even when I go and create a gazillion streams to run a real world project.
We all operate in blissful ignorance of some larger picture when we catch a train and don’t see the scheduling of freight and other routes using the same line, or when we buy a pint of milk and ignore the logistics of how it arrived at the shop. If you give me a link to a change set and tell me what work to carry out, I don’t need to see any of the baffling larger picture. Meanwhile the configuration manager is looking at the larger picture of iterations and work products without needing to understand the detail of what is being designed. Nobody is given more than one headful of information to comprehend.
I could now extend the picture to inclusion of other tools and what we call ‘Global Configurations’ but maybe that is best left for another day.