gjk@sisd.kodak.com (Greg Kedge ripsys) (10/16/90)
I have embarked on a study of Humphrey's work; I'm starting to read his book. Supervision seems to be loving it. I am very interested in the subject of Software Engineering but, I don't have an experienced opinion regarding what is best for particular SE situations. I am joining a SQA group in the near future that is big on this subject. Are there any sceptics out there? (I'm asking for flames!-) Greg K. (Sorry, no signature yet. I'm new at this too!-)
dwiggins@atsun.a-t.com (Don Dwiggins) (10/18/90)
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.