Baselines. Record the Intermediate States of Software Development.
What are baselines in software development? What are their advantages? And how do you establish a baseline?
A baseline ensures an intermediate state between work results, like your requirements, documents or test cases. That means: They "freeze" the versions of these elements at a certain point in time and version the entire element with a baseline.
This is why you should establish baselines for milestones or releases, on the foundation of which you will further the development or return to an earlier one.
What Is a Baseline in Software Development?
The term baseline comes from configuration management. Configuration management describes activities that lead and steer configurations. A configuration represents all the work results described by a product. According to the IEEE, a baseline, also called a reference configuration, is:
“A specification or product that has been formally reviewed and agreed to by responsible management, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures.”
To put it more simply: Establishing a baseline creates an unchangeable “snapshot” of your work or product at a certain point in time.
Baselines in Software Configuration Management
Configuration management also takes place in software development. Software configuration management is a method of controlling the development of software and changes throughout the entire life cycle. It makes sure, for example:
- every change to the software has been confirmed and documented,
- changes don’t get lost,
- the who and the what of a change are documented and
- a previous version of the software can be returned to at any time.
So it develops software from baseline to baseline. In this case a baseline corresponds most often with a milestone or a release: All work results that belong to a release are “frozen” in their current version – so for example, existing requirements, test cases or documents. Based on the unchangeable state of release 1, release 2 can be developed.
Baselines in Requirements Management
Baselines are often found in requirements management. There, they are only a snapshot of your requirements. These preliminary states can then be used to check the quality of the requirements with your stakeholders, to give them to another team or to have a foundation for the design development. Above all, the quality assurance of the requirements is important to stop the scope creep:
Stakeholders change their desires and goals over the course of the project, and this results in new requirements. Through this, the project schedule and costs increase. If baselines are regularly established for your requirements, then you can also regularly gather feedback from the stakeholders and clarify the requirements with them. Another advantage: When you delete a requirement accidentally, you can always return to the state of the baseline.
Learn more about requirements engineering with a tool here »
Definition of baseline:
A baseline is an intermediate status of your work results that you record/save and approve at certain points in time. It serves to provide a fixed reference point for change management.
Draw Baselines with a Tool
Try it out. 30 days free of charge.
With objectiF RM – for your requirements management »
Examples of Baselines
- Initial requirement specification is complete
- Design is complete
- Integration test is complete
- Acceptance test is complete
- Release 1 is complete
- Software is rolled out
Advantages of Baselines
- They provide “frozen” intermediate states of work results that can be used as reference points, for example, for comparing the planned and current states
- They facilitate project control and monitoring
- They create (secure) versions of all the work results that can be returned to at any time
- They prevent a scope creep in the requirements
- They create a consistent understanding for stakeholders about artifacts, like requirements
Naming Conventions for Baselines
To make baselines uniquely distinguishable, they need a naming convention – so a rule as to how you name baselines. This naming convention plays an important role particularly for restoring versions. Baselines in the sense of releases often follow a three number scheme like 1.2.0 for example, whereby:
- the first number is an important, external release (to customers),
- the second number is subordinate, internal release (between developers),
- the third is a small revision (by one developer).
Establish Baselines – Example from Requirements Management
As previously mentioned, you can establish a baseline for your requirements before you present them for an acceptance review. The true and more important requirements baseline, which also follow the definition of the IEEE, can be established after the review. Because this baseline is accepted by all participants and counts as the first foundation with which the development can progress.
To be able to successfully establish baselines for requirements, the following things – amongst others – should be ensured:
- The most important risks regarding the requirements are identified and recorded.
- Measures to prevent and avoid risks have been identified.
- The product that the requirements define is implementable.
- Methods and procedures for verifying and validating each requirement have been defined – for example, acceptance criteria and test cases.
How to Establish a Baseline in objectiF RM
To baseline elements, it only takes 2 steps:
- You create an element group.
- You create a revision of this group.
In an element group, you reference all work results that you want to baseline. The original elements are still in the place you have saved them.
In the next step, you create a revision of this element group and give it an appropriate name such as “Release 2”. And that was it – you have baselined your work results. All group elements have now automatically received a version that is labeled with the baseline’s name in their history.
