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 a 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 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 component tool? Do they share a single repository? If the answer to any of these is no, you'll want to be careful. Even a perfectly pre-packaged configuration may fall on its face when you try to change the process to meet your own corporate requirements.
Even a single integrated tool will have to talk to other external tools at some point - to pass financial data, inventory info, sales and customer info back and forth. You may be able to extend your tool suite to include some of these functions, but eventually, you have to talk to some other tool. The key will be to have tools that communicate easily. If they have command line capabilities, they usually listen well. If they can issue commands at the operating system level (e.g. from within trigger) they usually talk well. A good communicator does both. A great communicator also speaks the major integration standards lingo as well (e.g., Eclipse integration).
We have covered a lot of ground: traceability, process, process control. We've also looked at areas where SCM technology should be helping you. If you have a well-oiled process, use this article to review it and identify the areas that may need a bit of work. If you don't have a good process in place, start from the inside out as described earlier: start with changes and build your process around it.
I haven’t addressed a lot of key areas, but have done so in earlier articles. I will continue in upcoming articles, with areas such as applying change management (and even traceability) to requirements and the pervasive theme of streaming your development, from the R's through to the TR's, and then into release streams. Somehow I feel that if you start down the road in the right direction, you'll start to see your way through to the desired end point.