3.    Approval and Baselining Standard

3.1.     Introduction

IT systems are composed of many objects and may be constructed using one or more devel­opment tools.

A baseline is a description of an application or any of its components that identifies its constitu­ent objects at a given moment in time, e.g. a baseline may be composed of three program code objects, “a”, “b” and “c” with versions “1.0”, “2.1” and “3.0” respectively.

A product, e.g. an object that is constructed from two or more program code objects, should not be formally released (refer to the Release Control Standard) until it has been baselined.  This is necessary to enable the documentation of the product’s contents when released, e.g. release 6 of the product “X” is composed of program code objects “a”, “b” and “c” with versions “1.0”, “2.1” and “3.0” respectively.

Baselines are generally produced at predetermined QA milestones, e.g. quality review or testing. A baseline produced following a QA milestone is generally known as an approved baseline.

Once a baseline is achieved, all modifications to its constituents must be author­ised using change control (refer to the Change Control Standard).

3.2.     Baseline Life-cycle

All objects shall have a defined approval and baseline life-cycle that specifies the approval process, e.g. QA review, to be used and the sign-off authority. Figure 3.1 is a schematic that identifies the main activities in a baseline life-cycle.


Figure 3.1 : Approval and baseline life-cycle

3.3.     Create Baseline

3.3.1.      Construct New Baseline

A baseline should be constructed using its constituent objects.

If an object is required to construct more than one component of a new baseline, then all these components must use the same version of this object.

3.3.2.      Approve New Baseline

The approval process shall start once the new baseline is con­structed.

The constituent objects shall be baselined when the approval process is completed successfully.

3.3.3.      Document New Baseline

Once the approval process is completed, the objects being baselined shall be marked as “Approved” and their records in the configuration log updated (refer to the Configuration Management Standard).

3.4.     Baseline Identifiers

Each object shall have a record in the configuration log. Figure 3.2 shows the mandatory and desirable identifiers for a configuration record.


Figure 3.2 : Baseline Identifiers

3.4.1.      Mandatory Identifiers

Rules defining the format and contents of the following identifiers shall be defined in appropriate procedures

•         Title: A short description to identify the baseline..

•         Version: The version number assigned to the base­line.

•         Status: This shall be “Approved” to indicate the comple­tion of the approval process.

•         Constituents: A list of all the objects that form the baseline. For each Con­stituent the following shall be documented:

1.   Title.

2.   Version Number.

3.   Status: This must be ‘Approved’, i.e. an application cannot be baselined if any of its constituents is still in “Draft” status.

4.   Constituents: This may be a component or a single object.

3.4.2.      Desirable Identifiers

•         Reference to the development tools used to construct the baseline.

•         Reference to the quality records produced during the ap­proval process.

•         Reference to the description of the environment in which the approval process was per­formed.