Defining a Software Configuration Management Process to Improve Quality

However, in the more general case, I suggest the following steps:

1. Identify “first-order objects” and those that should be, such as change packages or updates.
In a typical SCM shop, the product team manages the following processes and items: problem reports, defects, and bugs; feature requests, requirements, and user stories; files and directories; file and directory branches; file and directory revisions and versions; change packages and updates; baselines; builds; test cases; and verification sessions and test results.

These “first-order objects” have properties that can be tracked. In subversion, files checked in through a commit are considered a “change package.” However, you can't attach a prerequisite to this “change package,” and you can't assign it a promotion status or link it to a problem report.  A first-order object can be referenced, can reference other objects, can have a state-flow, and can have other data associated with it. An “update” in CM+ is an example of a change package that is a first-order object.

There are many additional first-order objects that you might consider tracking as well, including: CM users, customer requests and issues, customer sites, projects, portfolios, and contracts.

When considering using a specific tool, make sure that it can support these first-order objects as well as other items or processes that you may need to manage along the way.

2. Identify the various states of a given object as it moves through in its lifecycle.
Each object should have its own lifecycle. You need to know how the object begins, the states it moves through in its lifecycle, and where it ultimately ends up. In some cases, you might have different kinds of objects—for example, emergency problems may follow a different path than non-emergency problems.

A software update (i.e., change package) might go through the following states:

• Originated: Basic work intent traceable to specific problems, features, etc.

• Open: Some work or perhaps checkouts have been done against the update.

• Coded: The files modified for the update are in the repository but not finally checked in. They are shelved.

• Reviewed: The update has been peer reviewed with action items, but no full re-review is required.
• Submitted: The files have been submitted and committed to the repository and are checked in.

• Ready: The update is ready to go into the next integration build.

• Selected: The update has been selected to go into the next integration build.

• Tested: The system integration build containing the update has been successfully tested.

• VerTested: Full verification of the feature or problem implementation has been completed.
• Production: The changes applied by the update are in production use or at least available.

Although this is a successful path if you follow it straight through, you may come across some obstacles that prevent the success path from being followed. For example, the update may cause a compile error that forces it to be moved to a “failed” state or rolled back to “open.”

Here's a similar set of states for a build record, an object used to track the definition and progress of a formal software build:

• Open: The build record is being defined.
• Defined: The build record is fully defined.
• Compiled: The build has been successfully completed (compile/link).
• IntTested: A basic system integration test suite has confirmed the sanity of the build.
• VerTested: The build has completed its system verification.
• BetaTested: The build is deployed in some customer beta sites.
• Production: The build is ready for production use.