Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!mdcbbs!system
From: jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.)
Newsgroups: comp.software-eng
Subject: Re: Programmer productivity
Message-ID: <463.256f438b@devsim.mdcbbs.com>
Date: 26 Nov 89 01:59:38 GMT
References: <16170@duke.cs.duke.edu> <34819@regenmeister.uucp> <16186@duke.cs.duke.edu>
Distribution: na
Organization: McDonnell Douglas M&E, Cypress CA
Lines: 57

In article <16186@duke.cs.duke.edu>, crm@romeo.cs.duke.edu (Charlie Martin) writes:
> 
> The source line of code measure is used precisely BECAUSE it is simple
> and objective (see e.g. _Software Engineering Metrics and Models_, Conte
> et al., or _Software Engineering Econonics_, Boehm.)  One reason it is
> objective is that it presumes that the source code being counted fits
> other constraints on its form that constrain away pathological cases
> like the above.

While I hate to rain on your parade, In 1984 Dr. H. Callisen and S. Colborne 
of Magnavox Advanced Products and System Company in Torrance Ca. puplished 
a paper in Europe (I have a copy of it somewhere... ) on 'S.A.F.E. Syntatical 
Analysis For Estimation'. I presented a paper that was related to it (I was 
also working on the project) in October 1984 to the International Society of 
Parametric Analysts called 'Designing and Creating an Expert Opinion Database 
Using Delphi Techniques'. 

In both of these papers the core of the presentation was that B. Boehm was on 
the right track, but he had chosen the wrong metrics. Using lines of code to 
determine the cost of creating a software application is about the same as 
having a contractor estimate the cost of your new home by computing the number 
of nails he will have to use to build it.

The basis of SAFE and the EODB is that any and every requirements document can 
be broken down into processes that act upon other processes and that these can 
be interlinked to create a heirarchical model (gee, structered analysis and 
design concepts use for defining software estimation metrics in 1984 :-) ). 
Then values can be associated to the various processes and the linkages between 
those processes act as mutipliers of complexity to the overall structure. 
Using this algorithm every branch of the tree will generate a numerical value 
for the total complexity for that branch, and that, in turn can be translated 
into the manmonths required to perform the creation of that branch. Once all 
branches have been computed the root will have an associated value and the 
estimation process will be completed.

The EODB acts as a filter on the values that are associated to the individual 
process models, thereby allowing each process model to develop a more accurate 
weight value for that modules complexity based upon the prior estimated values 
that were set for that particular process model and the actuals recorded.

This entire process was to take place on-line, with the computer using state 
transition tables as it scanned the requirements document for process 
definitions and the associated linkages and broke these out into the 
heirarhical tree (a working prototype was developed before funding for the 
project ran out). 

If this seems rather sketchy, I apologize, but getting the concepts of a major 
published paper and a two hour talk into a few lines of bandwidth at 0200 in 
the morning isn't the easiest task in the world. If you are interested in 
obtaining a copy of the SAFE paper, send me Email and I will attempt to get the 
Library of Congress identifier to you (or at least the name of the Journal that 
it was published in). 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| J.M. Ivler at Douglas Aircraft in Long Beach, CA  - VOICE: (213) 496-8727 |
| INTERNET:  jmi@devsim.mdcbbs.com  | UUCP:  uunet!mdcbbs!devsim.mdcbbs!jmi |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~