By: Ron Radice
When an old idea is a good idea that improves to become a better idea, we should all want to benefit from that evolution. Software Inspection was a good idea when started in 1972. Inspections have continued to provide a quick return on investment and perhaps one of the quickest for all the methods and processes available to the software practitioner.
In a recent editorial in Informationweek [STA02], Stephanie Stahl, the editor, says "In order to have great software, companies have to make completion dates and deadlines a matter of history." She then quotes a Steven Jones who gave her this input, "Bottom line, it will be passed to the next phase when itís right. No dates, no expectations set. When itís right, itís ready." Well, as has been known for some time, Software Inspections not only make it right, but also makes it ready at a lower cost. How can anyone in business who believes in quality resist such an offer?
The following excerpts are from my recent book, High Quality Low Cost Software Inspections, and are included here with the permission of my publisher. [RAD02] While I cannot in this brief article address all aspects of the Software Inspections evolution since 1972, I believe you will find excerpts below that may stimulate you to further exploit Software Inspections. And if you are one of those who have cast away Inspections for whatever reason, I sincerely anticipate that you will try them again to your advantage.
I have never found a manager or programmer who purposely wanted to deliver a product late, over cost, or of poor quality. Yet projects continue to ship late, with less function than committed, at higher costs, and with questionable quality. There are a number of factors that lead to these undesirable project results, but a major contributor is the lack of defect removal controls. Defects are created or injected into work products throughout the project life cycle. This seems to be an unfortunate fact of software development. It can be difficult and expensive to remove the defects in test, and when customers find defects the costs can increase by a factor of 100 or more.
These costs to remove defects are part of the Cost of Quality, or more significantly the lack of quality, and can represent as much as 65% of total project costs. Clearly there is economic opportunity to improve both the quality and consequently the return on investment (ROI) for software projects.
In the book I address both subjects using two primary processes:
1. Inspections to find defects earlier and at a lower cost
2. Defect Prevention to reduce the volume of defects injected
The software community has used Inspections for almost twenty-eight years. During this timeframe Inspections have consistently added value for many software organizations. Yet for others, Inspections never succeeded as well as expected, primarily because these organizations did not learn how to make Inspection both effective and low cost. We will see that in fact the cost of Inspections is very often paid back with a handsome return during the first projectís use.
I have seen Inspections work successfully time and time again to the surprise of some of its staunchest opponents. At the same time I have seen Inspections abused, misused, and aborted for some of the most shortsighted and irrational of reasons.
The lesson to be learned from these experiences is that methods and tools can be misapplied, treated as a failure,
and then dismissed as a bad experience by users who were not enabled for success.
The Inspection method itself is simple and straightforward, but it does require a belief in its capabilities, application of necessary preconditions, and good management support to make it work to a software organizationís best advantage. If management does not support the principles of good quality, then overworked programmers and managers will find innumerable excuses to cause Inspections to fail. If the software managers and software engineers in the organization do not believe that the process will work, then there is a good chance that they will fulfill their expectations.
On the other side, given a fair chance, support by management, a commitment of some early time investment in the project, proper training by example, and practice of proven principles, the Inspection process will take root and work effectively and efficiently. When practicing Inspections one should always work to achieve effectiveness first, then, while maintaining high effectiveness, work to improve the efficiency. Throughout the book we learn that this is the desired two-step with Inspections: first effectiveness, then efficiency.
So whatís the problem? Why do we need Inspections? We need Inspections to remove software defects at reduced cost. Inspections enable us to remove defects early in the software life cycle, and it is always cheaper to remove defects earlier than later in the software life cycle. Itís important to note that Inspections are a way to remove defects at a lower cost, not a way to prevent defects from occurring.
... to read more articles, visit http://sqa.fyicenter.com/art/