Workshop [SEW]), which they called "scenario-based" inspection. With this approach, each inspector looked for certain kinds of errors. Once again, the scenario inspectors outperformed the Fagan/process inspectors.
The bottom line of this issue is that inspections that focus on the product clearly outperform those that focus on inspection process. Fagan is by no means the final word on inspections.
To Meet, or Not to Meet?
Is it really important to conduct inspections in a meeting at all? How effective would it be, for example, to turn a bunch of skilled inspectors loose individually on the artifact to be examined?
There are, once again, a number of research studies addressing this question. Bruce C. Hungerford reported at the 1997 Association for Information Systems conference that inspection meetings tend to slow project progress by an average of two weeks, and that the meetings found no more errors than the most competent participant did (although Hungerford admitted he was concerned with the accuracy of that particular finding).
Other studies have found up to an 8 percent improvement benefit in meetings over individual inspections.
What's the bottom line? The jury is still out, but it is safe to conclude at this point that inspection meetings are little better than individual inspections.
How Many Inspectors?
There's another interesting issue here. How many inspectors does it take to do an inspection optimally? There have been lots of research studies of this issue, perhaps surprisingly, and there are several different conclusions. But the answers tend to a fairly clear trend. It doesn't take very many inspectors to begin to approach the optimum point for error detection. One study suggests two inspectors, for example; another suggests three or more, and yet another found that four was no more effective than two.
Based on all of that, you could safely guess that three inspectors is as good an answer as you are going to find.
Inspections are under utilized in practice. To be done properly (that means with intense rigor), they require exhausting, grubby-detail work. It takes a set of experts who really understand both the proposed software solution and the problem domain to do a good job of inspection. Many say that one inspection can only cover about 100 lines of code (again, note that most of what I am saying is about code inspection) before the participants are mentally exhausted. And that translates, generally, into a one- or perhaps two-hour inspection session. Anything longer is counter-productive.
At that rate, doing a thorough inspection of a significant software product could take many hours-hours that the typical project may not allow. Yet those errors not found through inspections must be found later in laborious testing efforts.
In other words, inspection is not an error-removal breakthrough. It is simply the best of a costly collection of alternatives. If you really want to produce software with a minimal number of errors in the production version, use inspections. You may find it painful in the short term, but the long-term payoff is worth it. I hope this column helps point you to some nice ways to minimize that pain.
Pages
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
