5.4 Pitfalls in Connection with Scoping

When calculating profitability, it's necessary to consider at length what to place under configuration management and when this is going to happen in a company or a project. What you need to watch out for during these considerations is that you do not choose to be too demanding, wrong, too coarse or too fine, too embracing or too exclusive, too late or too early.

Too Demanding

Configuration management is basically a bookkeeping function. Even the best configuration management system is not able to solve planning, design, or testing issues. The order in which objects are produced and brought into usage is a planning issue. This planning can be complex, especially if the design is complex. There is no short cut through the configuration management systemat best, the system will only be able to tell the status of configuration items.

The way objects are related to and dependent on each other is a design issue. Again, there is no shortcut through the configuration management systemat best, it will only tell how configuration items are related . This implies that the order in which finished objects may be used as support in the testing of other objects is a test planning issue. It's frequently seen that module testing relies on finished objects instead of drivers and stubs. This is fine, as long as it's understood that this requires extra development and test planning for the necessary information to be accessiblepossibly, but not necessarily , through the configuration management system.

A configuration management system may be able to report on an item's state and on how deliveries are composed . It will, however, ease the work if the design is kept as simple as possible.

Wrong

It's almost automatic to think that configuration management is an unwieldy monster ready to swallow all resources and stifle employees ' creativity. This may well be the case if needs are not made clear and matched with the basic principles of configuration management. When configuration management is implemented properly and within a suitable scope, it can make everybody's job easier.

Too Coarse or Too Fine

When the decision is to be made about how fine to make the granularity of configuration management, the smallest object to be changed and traced to must be considered and the definition of configuration items tailored accordingly . It's not expedient to define an entire requirement specification document as one configuration item if you have to trace to individual requirements. Nor is it expedient to have an entire subsystem as a configuration item if individual source code modules may be subject to change. Similarly, it's not expedient to define individual chapters oras is seen occasionallyindividual lines in a document as configuration items if the document is always issued in a new version in its entirety and there is no need for a detailed tracing.

Too Embracing or Too Exclusive

Configuration management entails a certain expense, but it provides valuable security and information. Considerations for what to place under configuration management are based on "What do we want to know?" and "What is the need?" At one end of the spectrum, absolutely everything produced and received for a product may be placed under configuration management. At the other, it may be nothing at all. It's a good idea to list all potential configuration items and actively opt out of those you don't want or need. This way, the choice is a conscious one, reducing the risk of overlooking something you're later going to miss .

Also to be considered is that it's rarely necessary to place derived objects, like compiled source code modules, under configuration management. These can be reproduced from the source code using the relevant tool(s). It may, however, be more profitable in the long run to place derived objects under configuration management rather than the tool(s) used for production. But this is an individual consideration from case to case.

Too Late or Too Early

You should not place an object under configuration management before the need outweighs the effort. On the face of it, it's more trouble to have an object under configuration management than notall events are to be registered, you have to decide on the destiny of all events, and new configuration items are to be identified, created, and placed in storage when a change is implemented. The advantages are of course that the changes are under control and events may be analyzed .

It's worth noticing that the trouble and benefits are often unevenly distributedthat is, those who receive the benefits are often not those who have the trouble. The calculation of the benefit in relation to cost must be done in this larger context.