Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!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: <4520@ae.sei.cmu.edu>
Date: 17 Oct 89 15:02:42 GMT
References: <135@quame.UUCP> <4331@ae.sei.cmu.edu> <3806@rtech.rtech.com> <4472@ae.sei.cmu.edu> <3828@rtech.rtech.com>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 49

In article <3828@rtech.rtech.com> Linda Mundy writes:
>In article <4472@ae.sei.cmu.edu> Richard S D'Ippolito writes:

[deleted -- see references]

>>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?
>>
>Okay.  Process exists at many levels:  from inception of an idea, to the more
>detailed design level, to the initial software construction (where, for 
>example, CASE tools may help to track relationships between modules, etc.),
>to the methods of building a system, to handoff/testing/CM procedures, to
>shipping.  Some of these have methodologies (e.g. CASE, CM tools) which may
>be used; some don't.

There is a rather large jump here from "inception of an idea" to "detailed
design level" that I don't know what to make of.  Furthermore, there seem to
be some initial stages missing having to do with what I would call the
design process.  Except for the first item in your list (which I am unable
to paste on a process model familiar to me), the items listed all are
post-design.  It is in this gap where quality is designed in, and the
process of design is not subject to statistical control.  Production is, and
feedback to the designer is necessary, but the optimum process does no more
than guarantee that one obtains the quality designed in.


>You say, for example, that software is unique in its enhancement requirements.

Nope -- I didn't say that!  I said that "the products cited" in your example
are not in the same league as the large systems that I refered to before
with respect to "post-deployment modification [and] enhancement."  Actually,
except for recalls to fix assembly or design errors, they are never
enhanced.  Motorcycles and cars are rather trivial systems compared to the
big boys.


>Actually, software customers don't upgrade models either --
>we send them a new model.  

Not true for many large systems having lifetimes measured in decades.


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