Path: utzoo!utgpu!news-server.csri.toronto.edu!umich!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!hacgate!ashtate!atsun!dwiggins From: dwiggins@atsun.a-t.com (Don Dwiggins) Newsgroups: comp.software-eng Subject: Re: The Software Process - Watts Humphrey. Message-ID: Date: 18 Oct 90 01:39:46 GMT References: <1990Oct15.223410.1838@sisd.kodak.com> <9077@fy.sei.cmu.edu> Sender: dwiggins@ashtate.UUCP Distribution: usa Organization: Ashton-Tate, Inc. Lines: 22 In-reply-to: bwb@sei.cmu.edu's message of 16 Oct 90 15:42:52 GMT In article <9077@fy.sei.cmu.edu> bwb@sei.cmu.edu (Bruce Benson) writes: I am an admitted skeptic of SQA in general, but the only book I've read that provided (for me) an acceptable approach to SQA was "Managing the Software Process" by Watts Humphrey. Nevertheless, I still think SQA is a bandage on a problem and inherently discourages quality, but y'all don't wan't to hear that :-). (No, I don't work for Watts.) 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? One practical problem I've found is that many developers (including managers) equate SQA with testing and certification -- "those are the guys you throw the product to when you think you're done, and they tell you whether you are or not" (:-). The concept of "software quality" is not well-defined in the industry. -- Don Dwiggins "If you think training is expensive, Ashton-Tate, Inc. try ignorance" dwiggins@ashtate.a-t.com -- Derek Bok, Harvard U.