The Journey Through Traceability to Process Control

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.

And 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 gotta talk to some other tool. So, 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 usuallly talk well. A good communicator does both. A great communicator also speaks the major integration standards lingo as well (e.g. Eclipse integration).

Summary

We've covered a lot of ground. Traceability, Process, Process Control. And we've looked at areas where you 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've not addressed a lot of key areas, but have done so in earlier articles and will continue in upcoming articles. Areas like 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, into release streams. But 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.