is enforcement of your software process. A similar term for software process that some people understand better is workflow management, where workflow pertains to the lifecycle of an object such as a configuration item, a problem report, a software baseline, etc. When I talk about a software process tool, I often get blank stares back from people as if I were talking to a group of teenagers about the joys of classical music. A process tool models your process, or simply put, it models how you do things (i.e., how issues are reported, who handles the issues, how the issues are resolved, etc.). Whether it’s good or bad, planned or unplanned, every development team has a process, it just may not be reflected in the tools that are used. When you have an effective process and it is reflected and enforced by the tools you use, you can gain a significant advantage.
Creating effective software process is one of the first steps in getting a handle on increasing productivity. The second part of that battle is getting your team members to follow it. To do this, you need to have an excellent training program and make sure everyone understands what it is they are supposed to do. You also need to back this up with the proper authority (rolled up newspaper works well). Even after you accomplish this, there will always be team members who like their way better, or they forget the proper steps and conveniently leave some out, and the list goes on. Integration of the different facets of the development lifecycle through integration of your software tools will help them follow the process without being reminded. For example, say you have a critical release coming up. You have carefully planned out what features will be added and which problems will be addressed. Internal customers are counting on you to deliver on time. At the eleventh hour, you discover one of your developers decided to add a few things that weren’t on the list. Not only do the changes not work, but they also have other repercussions that the developer never considered. It takes even more time to back the changes out, and you miss your promised delivery time. If your change tracking system was integrated with your source code control tool, you could prevent the check out of files from the source code repository that did not have an approved change request or problem report association. This protects the integrity of your baseline, and it helps you control what changes are entered as new code. Of course, the system is not perfect, for you can’t prevent what a developer will change in a file once it has been checked out, but it makes the attempt obvious and eliminates excuses if it occurs. “Gee officer, I didn’t notice that the light was red”. Most team members will not deliberately try to cheat the process, for it is probably more likely that they are in a hurry, they plain forget, or they just don’t want to be bothered. When this happens, they get a reminder from the SCM tool when they can’t check out a file without an approved change associated with it. Thus, your process was enforced without requiring any babysitting by your SCM staff, and the rolled up newspaper can be retired.
Issue management (or change management) is a key component in software development and product success. In the examples I have given thus far, issue management stands out as the one tool that should be integrated with all other tool sets. When your integrate