The Journey Through Traceability to Process Control

definitions:

Hard Rule: Implemented by the CM tool or by the instantiation of the CM tool (e.g. the tool is configured from the start to support CM this way), as in the above change package example.

Policy: Configured within the CM tool. For example, a change package may link to one or more problems. Perhaps you want a policy that forces more granularity, allowing you to link to only a single problem. You might change the schema so that the "problems" field goes from a "list" value to a single value.

Convention: The CM tool allows multiple options and will support a convention that you choose to use. A common case of this is a naming convention for labels which correspond to baselines. A more critical one might be that baseline labels are not modified or applied after the baseline has been defined. The product will continue to support "abuses" to these conventions and will work well. But the users may have more difficulty in identifying their data, or in the worst case, definitions may change (e.g. what is a baseline if it can change!). Convention turns into policy when the tool is re-configured to take advantage of the convention. For example a "Display Baselines" button may show all "labels" which correspond to the Baseline naming convention. If this becomes a key step in your process, you had better start to validate the naming of baselines.

In general, Process Control needs to be made up of a combination of these three items. There are things we know and that should be enforced as hard rules. There are policies that will change over time as our process changes. And there are conventions that may or may not become policy. When we introduce them we want to start working with them before reconfiguring things to enforce them.

Process Control - Basic Functionality

Process control has many different connotations. Think of an assembly line. Then think of software development. The link between these, as far as process control is concerned, is the improvement of quality. Process control allows you to improve quality by helping you to automate, support and enforce process.

Process control can be viewed both within a function and between functions. For example, a process state diagram may be enforced for problem workflow. At the same time, checking in a source change could trigger a change in the problem state.

Process Control can take on many forms.

• Enforcing a specific workflow for an object.
• Restricting operations based on a set of rules.
• Triggering events on data state transitions.
• Protecting data based on role
• Configuring the user interface based on role

These are key elements which your SCM tool or tool suite should support. If they are not there, you're in for al lot of glue.

Talking to the Rest of the World

Process Control is going to be easy or difficult to implement, depending on your tool suite. If your suite of tools all work together to a common architecture (e.g. Unix commands), you'll be able to take the output of one tool and feed it directly into another. Even better, if you have a single tool integrating a set of functions, and with an adequate process engine and a single repository (e.g. CM+, MKS), process control among these functions will be a matter of focusing on the process, and not the implementation.

If you have a set of tools that are glued together, even if they're from the same vendor, look closely at them. Do they have a natural means to talk to one another? Is it different for each