Path: utzoo!attcan!uunet!van-bc!ubc-cs!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!rochester!pt.cs.cmu.edu!sei!bwb From: bwb@sei.cmu.edu (Bruce Benson) Newsgroups: comp.software-eng Subject: Re: SQA (was: Re: The Software Process - Watts Humphrey.) Message-ID: <9150@fy.sei.cmu.edu> Date: 22 Oct 90 15:00:33 GMT Reply-To: bwb@sei.cmu.edu (Bruce Benson) Organization: Software Engineering Institute, Pittsburgh, PA Lines: 86 In article dwiggins@atsun.a-t.com (Don Dwiggins) writes: >In article <9077@fy.sei.cmu.edu> bwb@sei.cmu.edu (Bruce Benson) writes: > > Nevertheless, I still think SQA is a bandage on > a problem and inherently discourages quality .... > >Could you expand on this a bit? What characteristics of SQA do you feel >cause the problems? How should it be changed, or what should it be replaced >by, to improve the situation? Deming said it well when he suggested that if part of your organization is devoted to finding errors than that's exactly what they'll do, find errors. It's their job and they are rewarded for "catching" the mistakes. This part of the organization has a strong interest (their jobs, promotions, bonuses) in errors (buggy software). Of the 12 odd books I've looked at on SQA, the following two concepts are consistently used as the core basis for SQA: 1. Put your "best" people in SQA to leverage their expertise against all projects. 2. Provide dedicated and independent "judgement" so management knows "quality" is being built into the product. Contrast this with the job of the software development manager. His or her job is to produce a quality product (meets requirements) on a given cost and schedule. If all the neat things SQA is going to do (reviews, evaluations, etc) will really result in quality - why is the manger not doing them? Often claimed is the manager is completely focused on cost/schedule. Assume SQA can delay a project for poor quality or poor practices. This means the software manger can't meet the target cost/schedule. If SQA can delay a project then top management has agreed that quality is more important than cost/schedule. Therefore, why is the software manager totally focused on cost/schedule? Habit? What I'm suggesting is that if SQA really worked, then it would become obsolete almost immediately. If the manager can unswervingly focus on cost/schedule, (s)he can unwaveringly focus on quality/cost/schedule. Let me try to illustrate my argument with an example: For many reasons we were in a situation where if we produced buggy software we would no longer be doing software. We defined and evolved a software process and had some pretty spectacular results: less than a handful of errors over three years. During this period our independent testers showed signs of strain. They would write up several pages of "errors" and give these directly to top management without discussing them with us. More and more "error" reports were design and usability related. It stretched from days, to weeks, and then months before test would get around to testing new batches of enhancements. Given the actual number and severity of real errors identified by testers and users, we did not need independent test (to catch errors). Living through the above example (and a few others) convinced me that SQA/test is like the evening news, you get 30 minutes of news regardless of worth. Of course these folks are a victim of the situation, not the cause. This example illustrates two beliefs 1) software management can do quality without an SQA; and 2) "error finding" organizations can cause more harm than good. Given that any organization attempts to justify and perpetuate it's own existence, I can't see purposely creating an SQA group (as defined by points 1 and 2 above). Conclusion: If you can define and measure quality well enough to create an effective SQA, then you can use these definitions and measures directly without an SQA. In an improving organization, SQA and independent test will diminish in importance with time. If this is not happening, you are not improving. Comments? * Bruce Benson + Internet - bwb@sei.cmu.edu + + * Software Engineering Institute + Compuserv - 76226,3407 + >--|> * Carnegie Mellon University + Voice - 412 268 8469 + + * Pittsburgh PA 15213-3890 + + US Air Force