Best Practices for Using and Creating a Baseline

Baselines are extremely useful for product developers, especially those who have to prove compliance or compare differences between huge releases. Information in a baseline cannot be modified, so it provides a reliable way to view historical information about products and milestones. For any reason you need to quickly review what changed, baselines can save time, provide insight, and make collaboration easier.
                                            

Baseline Meaning: What Is a Baseline?

A baseline is a preserved collection of data at a point in time, like a project milestone. This could be a full product release, for instance. The preserved data is not only useful in an audit — baselines allow you to compare differences between two major milestones. For example, you will know what revision one of a product looks like versus revision two, and you can always go back and view data at the point it was captured.

Some examples of what a Baseline might contain:

• Multiple requirements documents and all of the requirements in them.
• Contents of a folder along with all of its child folders, and all of the contents in those child folders.
• Any number of single records in your requirements management system.
• Information about all the records linked to those directly captured in the baseline

📘 Related resource: Requirements Management Software Buyer's Guide

Best Practices for Using and Creating Baselines

When creating a baseline, there are some things to know up front that can save you headaches later. Here are 4 best practices to keep in mind.

1. Establish Guidelines for When to Create Baselines
It’s good practice to always add baselines for major milestones, like full product releases. But you also have to consider whether to create minor milestone baselines. This might make sense based on the scope and cadence of your releases, but you want to keep in mind the size of your database. For minor milestones, you may want to create those baselines, run and save necessary reports on them, and then delete them. In your guidelines, then, be clear about the difference between a baseline to keep, and the kinds of reports you want to save on the baselines to remove. Also indicate when it’s safe to delete any baseline. Deleting a baseline is permanent and irreversible, and should only be done by administrators after a database backup.

2. Create a Naming Convention As you create baselines over the lifecycle of your products for many years, and for multiple releases, you may compile a very long list of them. So as a general recommendation, it will help to have some sort of naming convention. As an example, you might want to use >Product.ReleaseYear.IndividualRelease.<

If you create baseline names that start broadly and narrow down to the specific release, that will help you organize them over time. Limiting the individuals who can create baselines via security permissions also helps prevent a broad range of people naming them however they want.

3. Lock Projects or Perform Baselines After Hours
If you are creating a baseline for a hundred thousand or 500,000 records, it may take a while to create. This action is being performed in the background, so if people have access to records while you are doing this, it’s possible for them to make changes before the baseline is complete.

That means someone could modify an item that wasn’t yet captured in the baseline. Then not only is your baseline inaccurate, but you also may not know it’s inaccurate.

So you may want to choose a time when no one is around — like at the end of business on a Friday — to create your baselines. Alternatively, if it’s possible to lock the project during the process, you can ensure no one touches the information until the baseline is complete. Just be sure to let those on the project know they will be locked out, and then tell them when the project is unlocked.

4. Duplicate Baselines to Create a New One
Once you have a baseline created for one release, it’s a good practice to duplicate that baseline for the next release. This is the safest way to ensure that you replicate what you’re capturing for each release.
 

Baseline Example

Want to see how it’s done? Watch this webinar on how to create baselines in Helix ALM:

Helix ALM: Your Tool for End-to-End Traceability 

Helix ALM — Application Lifecycle Management by Perforce — gives you end-to-end traceability across the product lifecycle. It is one single, self-contained system and central database for finding, managing, tracking, and reporting on all of your data. It allows your team to easily meet and prove compliance standards, even as your data grows and relationships between requirements become more complex.

Want to learn more? Watch the product demo to see how Helix ALM:

• Automates traceability.
• Lets you easily configure any type of workflow.
• Automatically traces test cases back to requirements.
• Accommodates FMEA, ASIL, Hazard Analysis, and more with built-in risk tracking.

▶️ WATCH THE DEMO