The Next Generation of Process and Quality

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 pre-requisite 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 the following: 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 which 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.

3. Identify transitions between the states.
Consider our build object and the fact that not all builds will make it all the way through. Although not every build is intended to go through production, for the most part, we still have straight-line transitions from one state to the next. Each transition has a set of properties, which include the following:

• Criteria: When to transition from one state to another
• Authority: Who is responsible for or allowed to perform the transition
• Rules: What rules can prevent the transition
• Triggers: What happens once the transition is completed

The build state might need to regress as well. For example, if the compile/link fails, it may go back to the "open" state to add or roll back some updates, or you may want to create a new build record altogether. At some point, the definition needs to be frozen, which is typically when it reaches the "compiler" and "IntTested" state or the equivalent.

The update object is even more complex. After being "reviewed," it may go back to the "open" state for additional work. If it causes the build to fail, it might be demoted from "selected" to "submitted," requiring more work or perhaps a companion update to make the change complete. You might also add or remove other states to closely reflect your actual process. In any case, you have the capability of tracking and managing the "change" in the form of an update object and its state-flow.

Putting it all together, we now have state-transition diagrams and properties for each first-order object. Even though we may understand these objects fairly well, as time goes on we may find that we need to add more states or transitions or modify the properties.