Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!apple!voder!wlbr!lonex.radc.af.mil!blackbird!jcardow From: jcardow@blackbird.afit.af.mil (James E. Cardow) Newsgroups: comp.software-eng Subject: Re: SQA (was: Re: The Software Process - Watts Humphrey.) Message-ID: <1711@blackbird.afit.af.mil> Date: 23 Oct 90 15:08:48 GMT References: <9150@fy.sei.cmu.edu> Organization: Air Force Institute of Technology; WPAFB, OH Lines: 110 bwb@sei.cmu.edu (Bruce Benson) writes: >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. > >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? Good points! However, the first response has to be "why aren't we currently developing high quality software?" This leads into a long string of interesting through totally rediculous arguments. Things like "I'll require quality software (mandate) and it will happen" often become the results. Maybe to goal of SQA should not be finding errors, but to terminate it's own existance. Now this requires some real guts on the parts of the managers and the poor soul taking on the job, but is the opportunity worth the risk? Let's assume a few things for the sake of the argument: 1) We (the software industry) are not currently producing sufficient quality software, or consistently producing quality software. (i.e. we have a problem). 2) We are not purely facing a resource based constraint (pumping money into software development will not instantly solve the problem). 3) Project management is focused on delivery (cost and schedule), as it should be. 4) Because of 3, project management cannot focus on the details of improving quality (technology innovation?). Now, how do we solve 1, within the bounds of 2-4? SQA as Bruce has pointed out is focused on self preservation. How about this: 1. Create an SQA organization with the following requirements: a. Sunset clause as part of the charter. b. Assign a "rising star" as the manager. c. Base evaluations on progress at achieving (a). 2. Define quality in terms of "user's view" not testing results. a. Delivery of product within time and cost is a plus. b. Negative value of latent defects increase with time, user identification (after delivery) being worse case. c. User requests for improvements beyond original spec counting as highly positive (indication of acceptance of product). Conclusion: I don't think that we can define quality well enough to require managers to "do it". I do think that by establishing an SQA organization we can cause the definition to be created, but only with talent and reward as the carrot. This are truely random thoughts, based on trying to define SQA value for software engineering course and thinking about the same issues that Bruce raised. I don't have any answers, just plenty of questions. I do welcome any comments and opinions. Jim Cardow, Capt, USAF Instructor of Software Engineering Air Force Institute of Technology jcardow@blackbird.afit.af.mil