What’s the ultimate goal of every software development project? Unless you just inherited a fat sum of dough from your late Uncle Milton, it’s probably to make money. The faster you can turn your project into a quality product in the marketplace, the more money you will make. Using a Software Configuration Management (SCM) tool will help you achieve that goal, and integrating that tool with other development tools can help get you there even faster.
Of course, the best software tool sets in the world will not make up for poor process and lack of planning, but an integrated tool set can take a well-oiled machine and make it even more efficient. Software tool integration can also help you receive certification of software engineering models such as the Software Engineering Institute’s Capability Maturity Model (CMM) by automating many of the requirements. Even smaller projects can benefit from integration of software tools by replacing manual processes. The following article gives some examples on how this type of integration could benefit your organization.
Integrated Development Environment Tools
One of the most common integrations with SCM tools is through the developer’s Integrated Development Environment (IDE) tool. This simple integration enables most SCC (Source Code Compliant) IDEs and SCM tools to communicate with each other. This allows developers to check code in and out of the software repository without exiting their IDE. An IDE integration with a change control tool and the version control tool extends this to allow association of checkouts with issue management objects such as change requests and problem reports. This can make any process rules enforced by your tools more palatable and it saves the developers a great deal of time. And, according to Einstein’s lesser known but nonetheless brilliant Cousin Melvin, Time = Money.
Requirements Management Tools
The planning phase of a project is a key factor in the overall success of a project, especially when it comes to pleasing your customer and getting the product out when promised. There are many strong requirements management tools that can help you plan your requirements and relate them all in a way that shows how making changes impacts the entire system. Unfortunately, many of these tools don’t let you create different versions of the requirements that can be recreated or included in software baselines. Some have their own change control features, but they might not tie into the issue management too you use for code changes. The physical separation of your requirements from you code base can contribute to unplanned and expensive changes to the original product requirements. Does the saying “this took twice as long and cost twice as much as we planned” ring any bells? Having a requirements tool that integrates with your version management and change tracking system can help overcome these deficiencies. Requirements should be considered configuration items because changing them must be controlled. When your create a software baseline, you can “check in” all of your requirements documents in their current state along with the code that is also included in the baseline. This helps in satisfying CMM SCM Goal Number 2 (selected software products are identified, controlled and available) and Number 3 (changes to identified software work products are identified). This enforces the connection between the requirements and the actual code. To take this even further, integration with your issue management and testing tool ties the whole thing together. A change request is made, it is linked to a requirement, and then approved or rejected by the designated change control board. If approved, the requirement can be changed, a new test case can be written to test for the change, and finally the code that implements the request can modified. Integrating all these changes can help assure that features of your product will not change unless they are linked to approved changes to the requirements. The link also provides a means of traceability and accountability if the correct process is not followed and assists in change control auditing.
Process or Workflow Management
One of the best examples of effective integration 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
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 change management with version control and requirements management, you can effectively track what is changing in the design and in the software and how it ties into approved changes. This is useful information after the fact, but this kind of integration can also help enforce change control as a preventative measure, e.g., code can’t change unless it’s an approved change. Integration with source code management also is also a tremendous help with baseline audits. A good integration should show complete traceability between each file check out (i.e., a change to your software baseline) and a problem report or change request. This is another time saver on whoever is conducting your baseline audits and assists in meeting CMM SCM Level 2 requirements that pertain to changes to your baseline.
It’s Not a Perfect World
So, will using tool integration make you rich and famous? Probably not. It’s easy to talk about the theory of how integration can solve all your problems (just ask any software salesperson), but there are many issues that can discourage this type of approach. It is difficult to find a solution that integrates all of your tools. You just love your requirements management tool and the team has been using the same issue management tool since the dawn of time (somewhere in the mid 80’s, according to some), but they come from competing companies. Trying to change tools could cause severe unrest in your development staff. You might also have tools that are supposed to integrate, but the integration is weak and sometimes doesn’t even work. Integrated tools can also be pricey and might exclude smaller companies and those with limited budgets. It is also important to remember that purchasing an integrated solution won’t fix any fundamental process problems you might have. Remodeling your house won’t stop the termites from eating your foundation.
As the demand for software process improvement increases, the supply of process oriented tools and integration between related software applications also increases. This will encourage the introduction of newer and cheaper tool suites that are designed with integration as a key requirement. Existing tool integrations will also continue to improve over time, and partnerships between different companies are forming to create new integrations to existing tool sets. The companies who continue to improve their process and enhance it with SCM tool integration will no doubt be the companies who survive the longest in today’s low margin, dog-eat-dog software development environment.
Matthew K. Johnson is a Contributing Editor for CM Crossroads and is a Software Configuration Manager responsible for several commercialization software projects for his Rochester, NY based employer. Mr. Johnson has a BA in Economics and a BS in Computer Science.
You can reach Mr. Johnson by email at [email protected]
