Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.software-eng
Subject: Re: Software QUALITY Engineering
Message-ID: <4472@ae.sei.cmu.edu>
Date: 12 Oct 89 19:35:35 GMT
References: <135@quame.UUCP> <4331@ae.sei.cmu.edu> <3806@rtech.rtech.com>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 60

In article <3806@rtech.rtech.com> Linda Mundy writes:

>In article <4331@ae.sei.cmu.edu> Richard S D'Ippolito writes:
>>In article <135@quame.UUCP> Bryan A. Woodruff writes:
>>
>>>The scary thought is that the Japanese are beginning to use this philosophy
>>>to work with software (philosophy -> Deming philosophy).
>>>If all follows, they will have perfected the software development process,
>>>and produce higher quality software (error free), faster and cheaper.
>>
>>I have to disagree here -- error free does not equate to quality.  The best
>>process in the world can not turn a poor design into a good one; all it can
>>do is produce faithful copies of the design.
>>
>I have some problems with your response.
>
>First, while "error free" is not the whole story of software quality, it's
>certainly a key element, not to be waved away lightly.

Beg pardon, but I don't see why there is a problem here -- I can't see where
I said otherwise.  We have a large process group here at the SEI.


>Second, you imply that improving the software development process somehow means
>ignoring design issues, while also managing to imply that neither the Japanese
>nor Deming's system deal with those issues.  I find this attitude both smug and
>naive.  

Indeed, it is naive, but it is not my attitude.  My comments were that
quality means more than absence of errors and that a perfect process does
not guarantee quality (nor even absence of all errors!).  Yes, I wrote
"perfect" process.


>In fact, it reinforces Mr. Woodruff's comments -- it is a scary thought
>indeed that the Japanese will proceed with improvements in the software process,
>while our own engineers sneer at "process" and believe that they can produce
>quality software while ignoring process.

I don't find that attitude prevalent in the large-system industries, and I'd
have to conclude that anyone who sneers at processes is not an engineer.
Perhaps we'd better settle on a definition of process lest we pass in the
dark.  What is it to you?  Are you refering to the design process or to the
production process?  Are methodologies included?


Later, you reproduce several quotes (from Tom Peters) that separate design
and engineering, using those quotes in an attempt to prove that for
software, production process control is the same as the design process.  As
a professional design engineer, I disagree.  Furthermore, the products cited
do not have the same kind of post-deployment modification/enhancement
requirements.  We simply can't expect to upgrade a Taurus to a Town Car.


Rich
-- 
We use kill ratios to measure how the war is going.
We use SLOC ratios to measure how our software is coming.
(Idea from Gary Seath)                                        rsd@sei.cmu.edu
-----------------------------------------------------------------------------