Identification of configuration baselines

Configuration baseline s should be established by formal agreement at specific points in time and used as departure points for the formal control of a configuration. Configuration baselines plus approved changes to those baselines together constitute the currently approved configuration. Specific examples of baselines that may be identified include:

• A particular ‘standard’ CI needed when buying many items of the same type (e.g. desktop computer) over a protracted period; if some are to include additional components (e.g. a DVD writer), this could correspond to ‘baseline plus’; if all future desktop computers are to have features then a new baseline is created
• An application release and its associated documentation.

Several baselines corresponding to different stages in the life of a ‘baselined item’ can exist at any given time – for example, the baseline for an application release that is currently live, the one that was last live and has now been archived, the one that will next be installed (subject to change under Configuration Management control), and one or more under test. Furthermore, if, for instance, new software is being introduced gradually regionally, more than one version of a baseline could be ‘live’ at the same time. It is therefore best to refer to each by a unique version number, rather than ‘live’, ‘next’ or ‘old’.

By consolidating the evolving configuration states of configuration item s to form documented baselines at designated points or times the Configuration Management will be more effective and efficient. Each baseline is a mutually consistent set of CIs that can be declared at key milestones. An example of a baseline is an approved description of a service that includes internally consistent versions of requirement s, requirement traceability matrices, design, specific service component s and user documentation.

Each baseline forms a frame of reference for the service lifecycle as a whole. Baselines provide the basis for assessing progress and undertaking further work that is internally self-consistent and stable. For example, the Service Portfolio and the Business Case for a Service should present a consistent and clear definition of what the service package is intending to deliver. This may form the ‘ scope baseline’ for the service(s) and give internal and external parties a clear basis for subsequent analysis and development. An example of the baseline points is shown in Figure 4.12.

Baselines are added to the CMS as they are developed. Changes to baselines and the release of work products built from the CMS are systematically controlled and monitored via the configuration control, Change Management and configuration auditing function s of SACM. In configuration identification, define and record the rationale for each baseline and associated authorizations required to approve the configuration baseline data.

Figure 4.12 Example of service lifecycle configuration levels and baseline points, represented by the numbered triangles

As a Service progresses through the service lifecycle, each baseline provides progressively greater levels of detail regarding the eventual outputs to be delivered. Furthermore, this hierarchy of baselines enables the final outputs to be traced back to the original requirement s.

It needs to be kept in mind that earlier baselines may not be totally up to date with changes that have been made later, e.g. ‘ course corrections ’ to requirements documentation may be reflected in the release documentation.

Дата добавления: 2015-10-29