This week I’d like to talk in larger conceptual terms about the Software Development LifeCycle (SDLC) process and the benefits of integrating tools associated with this process. To start off, let’s identify the four kinds of tools that are important to a fully integrated SDLC. They are:
- Source Control Management (SCM) – Track and control software changes, usually by means of revision control and the creation of software baselines.
- Defect Tracking (DT) – Tying a group of changes to individual files back to a specific defect record.
- Requirements Management (RM) – Much like DT, RM includes documenting and agreeing on requirements for a project, along with a process for controlling and updating project requirements.
- Testing Management (TM) – TM involves managing test cases, and recording the results of test runs against a given code baseline. But more importantly, TM should integrate with RM so that for every requirement, there is a test case to validate that requirement. In addition, for each defect in DT, a test case should be created that verifies the efficacy of efforts to fix that defect.
Let’s first talk about the above four tools in terms of two pairs of tools. In the first case, integration between SCM and DT is a highly desirable objective. In the second case, RM and TM are processes that are closely tied to each other and an integration between the two is very important.
Source Control Management (SCM) and Defect Tracking (DT) Tools Integration:
With a SCM and DT integration, what we want to see is every code change tied to a DT ticket. Of course, DT is a larger process than just tracking software changes. Tickets may be opened to track hardware issues, documentation problems, and even process changes. But here we are focusing on what DT and SCM integration buys us. The short answer is: increased information.
What I mean by increased information is that DT and SCM integration allows us to more easily answer certain important questions. Here are some often asked questions:
“Build Y is displaying different behavior, what has changed between the previous X and our current Y build?”
While it is true that an SCM system alone can provide an answer to this question by querying all files changed after some given timestamp, a list of files doesn’t really allow us to understand the motivation for the changes. What defects were addressed in build Y? What files were changed for defects A, B, and C that were included in build Y? These are the kinds of things that an effective DT/SCM integration can provide insight into.
“What builds contain the fix for defect D?”
Again, one can get such information by querying developers about when a defect was submitted, but being able to run a quick standardized report is really a boon for someone trying to manage a release cycle.
“Did defect E make it into our current build?”
For anyone who has ever sat through Change Control Board (CCB) meetings with printed lists of defects that eventually need to be included in an upcoming release, that person understands the importance of having a ready answer. Sure, lists and spreadsheets and whatnot can kind of get the job done. But here’s the thing. Those lists and spreadsheets are always out of date. Maybe only slightly out of date; and effort needs to be expended to keep them up to date. How about being able to open your laptop, and then run a report that provides the lay of the land right NOW?
So maybe I’ve beaten this one to death. Let’s now mention a few specific tools. On the open source front, I’ve had good experiences with SubVersion (SVN) as an SCM and I’ve heard good things about Jira as a DT. (Yes, I know Jira in some cases is proprietary, but license costs are quite modest.) Bugzilla is also widely used, and doesn’t have any proprietary taint. There are existing integrations available for both of these DTs and SVN. For a shop that isn’t swimming in venture capital cash (how many are these days?) going with an open source solution can make a lot of sense.
At the other end of the spectrum, IBM provides a widely used and venerable solution with ClearCase (SCM) and ClearQuest (DT). The integration is robust and quite customizable. Be prepared to shell out some serious money if you go this direction, though. When I refer to these tools as “venerable” I don’t exactly mean long-in-the-tooth, but they have been around quite awhile.
More recently, IBM has been moving in a new direction with their Jazz platform. Jazz is intended to fully integrate all SDLC tools from the ground up, vs. patching together different tools after the fact. As of 2010, they hadn’t really come up with solutions for all four functions in Jazz, but they were headed that way. When they are ready, I expect Jazz to be a contender in the SDLC fully integrated toolset space.
Requirements Management (RM) and Testing Management (TM) Tools integration:
Let’s move on now and talk a bit about RM and TM. As a project starts to acquire a level of even moderate complexity, tracking the project requirements becomes increasingly important. It is usual for requirements to constantly be in flux, so having a system that tracks the various versions and history of each requirement can be important, especially for regulated areas like medical devices (regulated by Food and Drug Administration –FDA) and other government projects.
And for each requirement, we want to be sure that it matches the specification and functions as expected. So again we need one or more test cases to satisfy the need for validating that requirement. Test cases can change, so versioning of the test case, and any associated test scripts becomes important. At some point, using a spreadsheet just isn’t going to cut it anymore. And as we have previously said, requirements can be changing. When that happens, how are we going to insure that any associated test cases also change to match the need for validating any modifications?
By now, I think you get the idea. In the past, IBM had an “integrated” solution with RequisitePro and TestManager. Note that I use the word past, since support for TestManager has been dropped. I also have the word “integrated” in scare quotes because although the integration was functional and had value, it always had the feel of two dissimilar tools being patched together. It looked that way, and had various glitches, because that’s what IBM had done.
But the world moves on, and as I said earlier, IBM is now touting their Jazz platform, which includes Rational Quality Manager (RQM) as a replacement for the defunct TestManager. They also have Requirements Composer and other tools which integrate with the Jazz platform, and which by our current date should be more than adequate to address the needs of most engineering shops.
But just to show I’m not totally in the tank for IBM, I’ll mention that MKS Integrity has all four SDLC functions fully integrated in their product offering. They didn’t patch together acquired tools, but built an integrated toolset from the ground up. The result is a very flexible tool with a single database which contains record types for all four SDLC tools.
There are a few other commercial offerings out there as well which claim a fully integrated toolset. Maybe I need to get out more, but I’m unaware of anything similar in the open source space. In any case, this concludes our thumbnail sketch of SDLC functions and the need for integration of these tools. Certainly we have only scratched the surface with this article, but hopefully it might serve as a starting point for further investigation.
