Baselines
Definition
According to IEEE 828-2012, a baseline is defined as:
- specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.
- formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item's life cycle. (ISO/IEC 24765:2009)
The same standard provides an example of a software baseline:
A software baseline is a set (one or more) of software configuration items formally designated and fixed at a specific time during the software life cycle. A baseline, together with all approved changes to the baseline, represents the current approved configuration. The term is thus used to refer to a particular version of a software configuration item that has been agreed on, e.g., as a stable base for further development or to mark a specific project milestone. In either case, any new baseline is agreed through the project’s agreed change control procedures.
With an analogy, a baseline is like a photo that captures the subject at a specific time. Like a photo, a baseline can be taken from a different angle or can focus on a part of the subject.
| Overview at time 1 | Detailed view at time 1 | Detailed view at time 2 |
|---|---|---|
 |  |  |
Baseline planning
Baselines are planned and created at specific points in time, for example, at Milestones/Gates or at the end of Iterations. Baselines are defined for the project and planned, for example in the CM plan or a related document, or as a set of work items.
The scope (types of configuration items) and representation of baselines is also planned, according to their purpose.
At specific formal Milestones, a full Project Baseline can be created, which includes all applicable configuration items at that specific time as defined in the Configuration Management Plan (e.g. Requirements, Architecture, Design, Technical Documentation, User Documentation, Test Descriptions and Records, Source Code, Work Items, Release Artifacts).
At the end of Iterations, a simpler baseline can be created to be used internally, focusing on Release Artifacts, Source Code, and Work Items.
In applicable projects, the baselining requirements of the Safety Handbook must be followed to plan baseline times, scope, and management that support functional safety assessment.
Baseline creation
The techniques to create a baseline depend on the types and storage of configuration artifacts to baseline.
For example:
- Documents in a Document Management System -> DocSet
- Source Code (or document wiki) in a Source Code Management tool -> Branch, Commit, Tag, Checkin, Label
- Release artifacts -> Build Number/Build ID, Feed, package and version, deliverables path
- Hardware baseline -> Parts List based on Product article number, Product Revision
Good practices
-
Given that a baseline can contain different types of configuration items possibly stored in different places, it is recommended to make baselines easy to navigate to reduce the complexity of finding all the content.
-
The criteria for baselines to be acceptable are defined for each stage or baseline type. It is recommended to automate and visualize the criteria as much as possible to facilitate tracking baseline review, approval, and audit.