The Next Generation of Process and Quality

Figure 1 shows what a typical state-transition flow diagram for a problem report might look like. This example, taken from Neuma's CM+ (full disclosure: The product I'm responsible for developing), assigns a color to each state so that you can make sense of the data just by looking at the colors of the records.

Figure 1. Problem Report State-flow diagram from CM+

4. Identify relationships between objects.
When we consider the broader impact of objects beyond their own individual state-flow, we are looking at a wider view of the process—the work flow.

When a build has been fully integration tested, the build record's updates (i.e. those updates referenced by the build record) should advance in status to indicate that they have been integration tested as well. In this case, a change of state to one object (e.g., the build record) should trigger a change of state to other objects (e.g., the updates). At the same time, any features referenced by the updates might be advanced to an "implemented" state indicating that the same features might appear on the verification team’s to-do list.

These  are just a few examples of a work flow that goes beyond the object's own flow (i.e., state/ transition flow). There are many such relationships in CM:

• a successful test case run indicates that the related requirements have passed
• the check-in of an update which references a problem report indicates the problem fix has been implemented
• the completion of a document review may cause a new feature to appear on a developer's to-do list

Workflow diagrams integrate the state flow with the inter-object flow that belong with these relationships.  You see the state flow, but you also see the side-effects on other objects and their state flows. In the last example above, you may see the document moving through creation and review, but on the final review you'll see a feature assigned to a developer and then an update created to implement the feature as well as test cases being developed to test the feature. The work flow links these objects (documents, feature, update and, test cases) and shows the bigger picture, whereas the update state-flow shows only how the update progresses.

For each transition of an object, you must ask, “As a result of this transition, who needs to do what?” Though specifics will differ from one organization to the next, a few examples might be as follows:

Feature specification completed and approved for release

• Feature appears on the developer or design manager to-do list
• Feature appears on the tester or test team to-do list for test case implementation
• Feature appears on the technical writer to-do list for feature documentation

Update checked in

• Run build to verify basic integration of update
• Notify developers who were waiting to modify some of these files (if using exclusive checkout) Add update to the quality review to-do list

Build approved for production

• Generate a new baseline definition for the production build
• Ensure all affected updates have advanced to the production state
• Generate "release notes" and send to the tech writer's to-do list for edits

Whereas the state/transition flow dealt with the lifecycle of individual types of objects, these workflow relationships knit the objects together to form your complete SCM process, perhaps more accurately referred to as the application lifecycle management (ALM) process.