Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!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: <4602@ae.sei.cmu.edu>
Date: 20 Oct 89 17:47:35 GMT
References: <3828@rtech.rtech.com> <4520@ae.sei.cmu.edu> <1989Oct18.223311.6954@ico.isc.com>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 37

In article <1989Oct18.223311.6954@ico.isc.com> Steve Shapland writes:

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

Partly right -- the code is not part of the design; it is the
implementation of the design.


>Consider the following metrics (to mention just a few):
>	1) Differences from the functional specifications.

Which functional specs?  Design or implementation?

>	2) Design complexity
>		(number of modules, control parameters, etc)

At what level are you measuring this?  Many of these items are
implementation dependent.

>	3) Amount of "re-used" concepts/code

Again, the level and quality of the reused material matters.  One should
also measure this against the potential of reuse.

>	4) Design flaws found "down stream"

Sure, as long as those errors can properly be attributed to design and not
production.

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