Producing software from a specification is like walking on water - it's easier if it's frozen. Barry Boehm
A baseline is a reference point in the software development life cycle marked by the completion and formal approval of a set of predefined work products. The objective of a baseline is to reduce a project's vulnerability to uncontrolled change by fixing and formally change controlling various key deliverables (configuration items) at critical points in the development life cycle. Baselines are also used to identify the aggregate of software and hardware components that make up a specific release of a system.
Baseline purpose. The purpose of a baseline is to provide:
- Measurable progress points within the system development lifecycle (if it's baselined it's finished!)
- A basis for change control in subsequent project phases
- A stable reference for future work
- Intermediate and final points for assessing the fitness for purpose of project work products.
Effective baselines have the following characteristics:
- A baseline must be associated with the production and formal approval of a physical deliverable such as a document or hardware/software component
- All items associated with a baseline must be placed under formal change control.
Examples of baselines (refer figure). Typical baselines include:
- The statement of system requirements (functional baseline)
- High level design (allocated baseline)
- Detailed design (design baseline)
- The software product at the completion of system test (product baseline)
- The software product in its operational environment (operational baseline).
Specifying a baseline. Baselines are defined by:
- The names of the physical item(s) which constitute the baseline (e.g. design document, code unit)
- The point in the project where the baseline is expected to be complete (e.g. at the end of a project phase)
- The method to be adopted to approve baseline items
- The individuals responsible for approving baseline items (approval authorities).
Typical Baseline Components
||Completion of software requirements review
||Concept of Operations Document, Software Requirements Specification
||Completion of preliminary design review
||High level design documents, interface control documents
||Completion of design review
||Detailed design documents
||Completion of a set of module tests where the modules comprise a unit
||Source and executable code modules
||Completion of a set of unit tests where the units can be integrated
||Source and executable code units, unit test plans, test procedures, test cases and data sets and test reports
||Completion of integration testing
||Source and executable code units, integration test plans, test procedures, test cases and data sets and test reports
||Completion of acceptance testing
||Source and executable code units, final system specifications, user and maintenance manuals, acceptance test plans, test procedures, test cases and data sets and test reports
||Completion of deployment
||Source and executable code units, final system specifications, user and maintenance manuals, acceptance test plans, test procedures, site integration test cases and data sets and test reports
Other Contexts of the Term - Baseline
The verb "to baseline" refers to the act of placing an approved item under formal change control. A baselined item cannot be changed without the approval of its designated approval authority.
A work product is referred to as a "baseline" when it has been formally reviewed and agreed upon and can only be changed through formal change control procedures. A baseline work product may form the basis for further work activity(s). For example, a Software Requirement Specification (SRS) creates a baseline for the development of a design. Once baselined the SRS cannot change randomly thus providing a stable reference for design effort.