Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!orion.cf.uci.edu!uci-ics!zardoz!hrc!tiger!sheppards
From: sheppards@tiger.UUCP (Scott Sheppard)
Newsgroups: comp.software-eng
Subject: Re: Using COCOMO to estimate development schedules
Summary: What is a statement
Message-ID: <42507b4d.17e7e@tiger.UUCP>
Date: 29 Mar 89 14:56:39 GMT
References: <351@tahoma.UUCP> <1702@spp2.UUCP> <18252@gatech.edu>
Organization: gte
Lines: 43

In article <18252@gatech.edu>, shilling@pinto.gatech.edu (John Shilling) writes:
> I have two questions about COCOMO
> 
> 1.  Isn't the accuracy of the model limited by an initial guess of
>     DELIVERED lines of source code? Is there any reason to believe that
>     a guess of delivered lines of source code is any more accurate than
>     simply guessing at the resources required directly?  

Yes, it is limited; however, our experience here at AG Communication Systems
has been that statements counts are easier to estimate than effort. We get to
ignore complexity and concentrate on the delivered product in terms of its
statement count. Complexity is handled by the model.

>     And just what is a 
>     line     of source code anyway?  Seriously.  Is it delineated by a newline
>     character?  Is it the number of statements?  Does it include comments?

We use KNCSS - 1000 Non-Comment Source Statements. A statement is a language
statement - not a line in a file. For languages such as Pascal, we use a precise
counting mechanism that is implemented by a tool; however, a close approximation
to a Pascal statement count can be achieved by hand if one simply counts the number
of semicolons.

> 2.  In what I have seen on the COCOMO model the weights on the factors 
>     are given to two significant digits past the decimal point.  This raises 
>     all sorts of flags with me.  Back in numerical analysis I learned not to 
>     represent digits that were below the level of accuracy of the 
>     computation.  Given the level of uncertainty in the evaluation of 
>     the factors, I have a hard time believing that the computations are 
>     accurate to two decimal digits (it has to be more than crunching numbers, 
>     it has to mean something).  Does anyone out there have evidence to the
>     contrary?
> 

The degree of accuracy achieved with the model has been fair for us. The decimal
places are merely the level needed to propogate the impact of the factors. In other
words, something that has a value of 5.01 instead of 5.00 usually makes a difference
of about 1 unit since the 5.xx number gets multiplied by 100 before being used. We never
sit around and ask, Is this project really a 5.01 or is it a 5.005? The decimal points
are just part of the formulas that drive the model.
-- 
Scott Sheppard                               
  UUCP: ...!ncar!noao!asuvax!gtephx!sheppards