Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!samsung!usc!ucsd!network.ucsd.edu!celit!fpssun!don
From: don@fpssun.fps.com (Don Donaldson xt 2418)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Summary: Recommendation of book on software estimation
Keywords: productivity, code size, estimation, metrics
Message-ID: <8896@don.fps.com>
Date: 23 Jul 90 19:19:20 GMT
References: <31558@cup.portal.com> <27199@athertn.Atherton.COM> <1990Jul19.154906.20518@newcastle.ac.uk> <141@srchtec.UUCP>
Reply-To: don@don.fps.com (Don Donaldson)
Followup-To: comp.software-eng
Organization: FPS Computing, Beaverton,OR
Lines: 35

In article <141@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes:
>Sure, software can't be estimated with <exact> accuracy, nor can it be
>measured so.  That doesn't make it worthless to pursue software metrics
>with higher accuracy and precision than we have now...
>
>A very good book which, IMHO, builds upon and surpasses the work of the
>"COCOMO era" is "Programming Productivity" (by T. Capers Jones, McGraw-Hill
>1986, ISBN 0-07-032811-0)...

I have been reading a very good book on these subjects.  It is called
"Controlling Software Projects - Management, Measurement, and Estimation"
(by Tom DeMarco, Yourdon Press 1982).

DeMarco stresses modeling throughout the process.  For example, a
project plan is a model of the actual project.  A requirement
specification is a model of the user interface.  The software design spec
is a model of the software which will be created to fulfill the
requirement.  In each case, the model should be complete before the
actual construction is attempted.  And, as in physical
construction, metrics can be applied to the model which are roughly
proportional to the same metrics as they would apply to the actual
product, producing early estimates.

On the subject of design, here is a short quote (without permission):

	"The Did-We-Really-Do-Design Test"

1. Put the design into a sealed envelope.
2. Give the completed software to an outside expert, someone who
	is not familiar with the original design.
3. Ask your expert to derive the design implied by the implementation.
4. Compare the derived design with the design in the sealed envelope.
5. If the two are not identical, you didn't really do design.

						don