I read Tom Gilbs article Planning to Get the
Most out of Inspection in the March 2000 issue of Software
Quality Professional (pp. 7-19). In the article he mentions
the return on investment (ROI) value. How do you calculate
such a value in case of unfound errors? You can measure the
cost of finding an error, but how do you know how much it
would have cost not to find the error?
The author replies:
Well, you have to have your own local data, of course, but using typical data from some of my customers I think that a major (defect) found and fixed saves about eight hours on average (using data from Philips UK, p. 315 in my book Software Inspection: 9.3 hours saved median, vs. one hour cost to find and fix for 1,000 majors). Also there is only about a one-third chance that a major will actually cause downstream damage because it gets correctly interpreted by people who know or ask before it becomes a defect. So ROI is about one-third of majors fixed x nine hours over one hour invested.
There are other related calculations such as
Please provide your own feedback by responding to our online survey, which is accessible directly from the online Table of Contents page for this issue. It offers a chance to rate specific articles and departments as well as to comment on the journal in general.
Some results from our latest survey:
88 percent of respondents rated their overall satisfaction with SQP at 5 (very satisfied) or 4 on a 5-point scale.
Resource Reviews were valued almost as highly as the feature articles.
Respondents preferred adding more articles or theme issues rather than recurring departments or columns.
More than 80 percent look at additional material posted online that supplements the print version of the journal.
Two-thirds responded with positive agreement to the statement that Reading SQP is causing enhancements in my on-the-job performance.
Nearly half identified their titles as director, manager, or supervisor.
Two areas recur in reader requests: focus on smaller organizations (not those 1,000-plus employee companies that can afford to play with . the latest fads), and on e-commerce applications (in Web and e-commerce development how to improve quality and process in a firefighting environment).
SQP will try to provide industry-specific material requested (healthcare, avionics, nuclear) while offering material that can be generalized to others workplaces, too.
We appreciate your encouragement:
The articles are clearly easy to understand and apply. Great source.
Ive only just received my first issue but I am so impressed!
I personally keep my SQP at my fingertips and readily accessible. It is a wonderful reference tool!
We also value your criticisms (and will strive to improve):
Anyone can reiterate published text. How about advancing the application of theory and publishing successes.
Enough of reiterating theory. How about some reality with respect to front-line problems and solutions. Everything is just rehashing problems...what are needed are solutions !!!!
Suggestions we are considering:
I would like to see articles directed at professionals with zero to three years of experience.
It might be interesting to have birds-of-a-feather groups accessed through the Web site. One of the functions could be the exchange of views and tips on software quality issues. Another function could be to set up occasional panel discussions on hot topics.
When asked what you wanted, you obviously value practicality:
Articles that provide assistance in implementing software process improvement.
More specificity in the articles...a how to do it approach. Too often the articles provide teasers that do not provide enough information on how to use the information to improve your own processes.
It has little practicality. It appears that those who are busy have little time to write.
The latter observation is all too true.so, all you successful but busy practitioners, please take the time to write up some material to share with your colleagues.
CORRECTION: Figure 8 in the article Applying Quantitative Methods to Software Maintenance (December 2000, p. 27) should have its y-axis values expressed in integers, not percentages as shown.