5.1 Level of AmbitionCostBenefit Analysis

5.1 Level of AmbitionCost/Benefit Analysis

Level of Ambition = Scope + Formalism

The benefits and costs connected with configuration management are linked to the chosen level of ambition, which may be split into two aspects: scope and degree of formalism. Scope is the number of objects placed under configuration management. Degree of formalism is the controlor, if you like, the bureaucracywith which configuration management is performed.

Configuration management as described in this book may be performed with many degrees of formalism and with many scopes. It's impossible to describe in absolute terms which scope and which formalism are the best; this depends on the requirements and possibilities.

Formalism for a Configuration Item

The degree of formalism of the configuration management for each configuration item may vary during the item's lifetime. Such a course is illustrated in Figure 5-1, where the scale for the degree of formalism is arbitrary and the activities and functions are anonymous.

Figure 5-1. Configuration Management Cost for One Item

Objects come into existence at some point during the course of the project. It may be a development-activity-specific object or an object from one of the support functions. At some point, the object is placed under configuration with a certain degree of formalism applied. This is shown in Figure 5-1 to be sometime during Activity 1, and the degree of formalism at that point is 2. Later, the degree of formalism with which the configuration management of the item is performed is augmented. In Figure 5-1 the new degree is 4. The hatched area is an expression of the costs related to placing and keeping this object under configuration management.

A more specific example could be a source code file, which is placed under configuration management when module test beginsthat is, after the developer has worked on the object for a while. When the module has passed the module test and is used in the integration test with other modules, the degree of formalism for the configuration management of the item is augmented.

Degrees of Formalism

Different degrees of formalism may be present within a single project and also within a company as a whole. A high degree of formalism may be required for safety-critical systems, while a lower degree of formalism may be the minimum you can get away with and still meet the company's basic needs.

Standards and maturity models define minimum degrees of formalism. These must be achieved before a company can claim that configuration management is performed at allfor example, to a capability level of 1 in CCMI. This is certainly of interest when considering certification or assessment. However, interest is growing in the way certification and assessments can help process improvement in general.

For "ordinary" projects, it may be an advantage to mix the degrees of formalism, using a lower degree in earlier development activities (during coding for source code and the like) and a higher degree during maintenance for deliveries. Each company must define the degrees of formalism it wants to employ and under which circumstances each degree is to be used.

Earliest and Latest Extremes for Starting Configuration Management

Configuration management for an object is said to be started when the degree of formalism reaches a defined minimum. For example, if identification is performed but controlled storage is not, this is not considered configuration management. The earliest point at which an object can reasonably be placed under configuration management is when the producer decides that the work product is in a state others can use. This may be when a source code module or document is ready for peer review. The latest point at which an object can reasonably be placed under configuration management is when it is part of a delivery to a customer.

Formalism and Tools

A tool often forces a certain degree of formalism upon a configuration management system. Most tools support a lower degree of formalism. Often, a higher degree will have to be sustained by manual procedures. Few tools are flexible enough to provide the possibility of choosing degrees of formalism according to different types of configuration items.

Expansion of Scopefrom Candidate to Item

Each project has numerous potential configuration items. In principle, every object produced or procured may be placed under configuration management. This is, however, seldom profitable. The initial cost is the largest expense (e.g., the investment in a tool and/or training courses), but the cost also depends on the number of items, because each item contributes a little bit.

Figure 5-2 presents an expression of the total cost for configuration management in a project. Items contribute to the cost depending on

• When an item is placed under configuration management (the x -axis is time)

• The degree of formalism with which configuration management is performed for an item (the y -axis is an arbitrary scale of formalism)

• Which (how many) items are placed under configuration management (the z -axis depicts the configuration itemsone for each interval)

Figure 5-2. Configuration Management Total Cost

The shaded volume is an expression of the cost of placing the chosen items under configuration management. The decision to place each type of object or individual object under configuration management must be carefully considered in light of a calculation of profitability (discussed later in the chapter).

No Rough DraftsPlease!

Objects being placed under configuration management must constitute a solution to a given assignment. The producer's "rough drafts" do not qualify. This is to say that as long as an object is in production, it must be outside the configuration management system and away from the controlled library.

Expansion from the Middle

It is a widespread practice and position that the least you can get away with in terms of configuration management is to place source code under informal configuration management. If you have started like this and not placed each work product under configuration management as it reaches the appropriate state, you may still continue from that point and place other types of objects under configuration management. The driving force in this process should be the tracing, so that what has already been placed under configuration management is traceable to other configuration items.

Source code modules may be traced backward to design and requirements. If the design and requirements are fairly stable when coding begins, it may be advantageous to place them under configuration management and start the tracing from there. Requirement specifications may be traced forward to system test specifications, which may be the next objects to place under configuration management.