Path: utzoo!attcan!uunet!motcid!murphyn
From: murphyn@motcid.UUCP (Neal P. Murphy)
Newsgroups: comp.software-eng
Subject: Re: SQA (was: Re: The Software Process - Watts Humphrey.)
Message-ID: <4893@bone13.UUCP>
Date: 25 Oct 90 16:14:33 GMT
References: <9150@fy.sei.cmu.edu>
Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL
Lines: 77

bwb@sei.cmu.edu (Bruce Benson) writes:

>...
>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 is often true. Also true is that the manager is focused on his
people and their work - keeping them from getting stuck, overwhelmed,
etc. He is dealing with people, who can have inexplicable reactions
to most anything. It is extremely helpful to have a seperate group
handling the paperwork.

>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?   

Perhaps. Perhaps upper management still pushes cost/schedule, while
not realizing/accepting that software design/development can't be
scheduled.

>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.

A large SQA organization would be obsolete. A smaller one would still
be required to handle the paperwork, handle oversight (making sure
the manager and his people are following the development process
correctly.)

>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.
>...
>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).

Independent testers serve a very useful purpose. The developers/designers
are too close to the work to spot errors and problems. Too often they
automatically use an easy workaround to bypass the problem. Independent
testers catch all problems. However, if you have a fair number
of customers using your product, they become your independent testers;
your official tester can be freed up to work on some other project.

>...
>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?

I agree. But the operative word is `can'. The ability to do something
and actually doing it are usually miles apart. Often, software development
groups do not employ rigid-enough SQA-like processes, thereby leaving
an opening for an official SQA group.

What you've said here iseffectively true, but not often seen in reality.
Perhaps, with more people like you in industry, we can change reality.

NPN