Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sun!margot.Eng.Sun.COM!donm From: donm@margot.Eng.Sun.COM (Don Miller) Newsgroups: comp.software-eng Subject: Re: SQA (was: Re: The Software Process - Watts Humphrey.) Summary: Development process efficiency is the key Keywords: SQA, quality Message-ID: <144261@sun.Eng.Sun.COM> Date: 26 Oct 90 15:24:22 GMT References: <9150@fy.sei.cmu.edu> <1711@blackbird.afit.af.mil> Sender: news@sun.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 137 In article <1711@blackbird.afit.af.mil> jcardow@blackbird.afit.af.mil (James E. Cardow) writes: >bwb@sei.cmu.edu (Bruce Benson) writes: > >>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). > Yes, Deming does focus on error prevention, rather than error detection, as a goal. Thus, the focus of the SQA group would be, in his eyes, the detection of product defects towards the correction of process defects. Deming would approve of SQA to the extent that the company climate allows the SQA group to suggest process changes which can be implemented as a result of product deficiencies. Unfortunately, as is almost universally discussed, the reputation of most SQA groups is not conducive to recommending process changes for developers. Hence, ... > >>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. I agree that it is the job of the development manager in most organizations to ensure that the tradeoffs implicit in product development between quality, cost, schedule, resources, and content are made intelligently. However, I don't believe that the things which result in quality are "things SQA is going to do". Only if the development teams themselves adopt the process improvement recommendations will an increase in quality be possible. > >>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. >> Again, quality improvements are only made possible by the creators of the product. The existence of an SQA organization assures that there are individuals who are focussed on quality and processes rather than products. The demands on development managers provide the impetus for an independent focus. > >Let's assume a few things for the sake of the argument: Pretty reasonable assumptions, I'd say. > >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). I've already commented that costs, content, and schedule are factors. The final most important factor is what I call developmental efficiency. While it is derived from the others, it is important to address. It is the quality-content produced per cost-resource-time. This seems to be the relevant figure software development organizations want maximized. Certainly, some will focus on different parts of the equation, but process change is the surest way to impact them all. > >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?). Hence the need for an independent, quality process focused organization. > >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). > What's a "sunset clause"? Why should an SQA organization achieve it? >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). > Exactly, quality is the degree to which you meet customer's requirements. These things all address that view. > >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. > Since I believe in the requirements centered approach to software development, I agree that the existence of an SQA organization can help to the degree that it ensures that the product created and the processes used truly meet the requirements of the market. On the other hand, if those who focus on such things are not able to express their findings in an acceptable way, development managers will continue "doing it" just like they always have. WHat choice do they have? Well, I'm at least one person who thinks that quality products will become a strategic competitive advantage in the 90's. What do you think? -- Don Miller | #include Software Quality Engineering | #define flame_retardent \ Sun Microsystems, Inc. | "I know you are but what am I?" donm@eng.sun.com |