As the project progresses and the completeness and stability of baselines improve, "promotion levels" can be used to
characterize the baseline in terms of its completeness or stability. Promotion levels and other baseline
attributes should be defined as appropriate to meet the needs of the individual project, although you'll typically find
that a common set of definitions can be reused in many different projects. Here's an example of promotion levels that
might be appropriate to use:
-
Integration Tested
-
System Tested
-
Acceptance Tested
-
Production Delivered
In this example, the levels are sequenced to reflect the relative progression in completeness and stability of the
software over time. Note that while the software will usually progress forward through these levels, it can also
regress in terms of completeness or stability. The act of changing the promotion level of a baseline in the former case
is called promoting and in the latter case demoting the baseline.
On occasion, the configuration manager may need to demote a baseline by changing its promotion level to one that is
lower in the promotion level order. For example, the integrator may discover a a major bug in a newly created baseline.
To prevent developers introducing this bug into their development workspaces, the problems with the baseline can also
be more clearly indicated by adding a label to the the baseline such as "rejected".
The recommended baseline represents a system configuration that has achieved a specific promotion level. A baseline
becomes part of the set of recommended baselines when it is promoted to a certain level, for example, "Acceptance
Tested". Promotion levels can be used in project development policies. For example, a policy on a project could be that
a given baseline is considered "recommended" when it reaches a particular promotion level. This policy helps to ensure
that developers rebase their workspaces whenever a baseline passes an acceptable level of completeness and stability.
|