Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!ico!vail!sps
From: sps@ico.isc.com (Steve Shapland)
Newsgroups: comp.software-eng
Subject: Re: Software QUALITY Engineering
Message-ID: <1989Oct18.223311.6954@ico.isc.com>
Date: 18 Oct 89 22:33:11 GMT
References: <135@quame.UUCP> <4331@ae.sei.cmu.edu> <3806@rtech.rtech.com> <4472@ae.sei.cmu.edu> <3828@rtech.rtech.com> <4520@ae.sei.cmu.edu>
Reply-To: sps@ico.ISC.COM (Steve Shapland)
Organization: Interactive Systems Corp., Boulder CO
Lines: 27

In article <4520@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>In article <3828@rtech.rtech.com> Linda Mundy writes:
>>In article <4472@ae.sei.cmu.edu> Richard S D'Ippolito writes:
>
>[deleted -- see references]
>
>>...  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.  ...
>
>...  the process of design is not subject to statistical control.

Perhaps the process of design is not subject to statistical control,
but it CAN be measured.  The "products" of the design process are
documents describing the design and the resulting code.
Consider the following metrics (to mention just a few):
	1) Differences from the functional specifications.
	2) Design complexity
		(number of modules, control parameters, etc)
	3) Amount of "re-used" concepts/code
	4) Design flaws found "down stream"
Once these metrics are being collected, they may be used to monitor
the design process.  The process may be altered, and the metrics
may be used to determine if the modification has improved the process.
(This is a basic process improvement technique.)