COCOMO - appropriate for languages like Python?

[James J. Besemer]

Skip Montanaro wrote:

> It's been many years since I've considered software cost estimation models
> like COCOMO.  Is COCOMO appropriate to apply to high-level languages like
> Python?

IMHO, Yes.

> I believe COCOMO assumes each fully debugged source line of code
> (SLOC) in any language and for any purpose costs roughly the same amount to
> produce.

Not true.  COCOMO is an elaborate model that relates quite a number of factors
pertaining to software development.  E.g., one of the general results is that
cost per LOC will be higher on a larger project than on a smaller one and that
LOC will be lower with smarter staff than with less clever members.  The COCOMO
model includes quite a few knobs and dials for understanding how your shop is
operating and, when calibrated to your way of doing things, COCOMO provides for
predicting the costs of future projects.

> The cost savings for languages like Python would come because you
> have to write so many fewer lines of code to implement the desired
> functionality.

Yes, in applications where this is true.

IIRC, COCOMO has a "knob" for how high or low level the programming language in
use happens to be.

> Are there other (more modern?) cost estimation models which don't assume
> cost-wise that a SLOC is a SLOC is a SLOC?

COCOMO does NOT make the assumption about SLOC cost that you seem to believe.
For COCOMO to work AT ALL it needs to be calibrated with historical data about
your own shop (e.g., historical average cost/LOC).  Without the historical data
then the model will be unable to predict anything meaningful about your
performance.

I'm sure there are other, much simpler methods that work OK.

Actually, COCOMO is somewhat Baroque, in that it originally attempted to take
into account all sorts of major and minor factors affecting in software
development.  After applying COCOMO to A Lot of projects, Bohem discovered that
a small number of factors made most of the difference:

     The biggest productivity factor was quality of people.  There is like
     a 1000:1 range of productivity between the top and bottom performers
     in large organizations.  This generally swamps everything else,
     including choice of language, or personnel costs (the 1000x guy does
     not cost 1000x as much as the bottom performer).

     The second biggest factor is overall size of the project.  That is,
     all other things equal, the cost per LOC is NOT constant, but it is
     higher on a large project and smaller on a small project.
     Furthermore, it appears to grow exponentially on overall project size,
     swamping all other factors on very large projects.

I forget how the others factors ranked but IIRC, choice of language (high or
low) was fairly low in the overall ranking.

>From a management standpoint, your strategy should be to always strive to hire
the very best people and to break projects into moderate sized, easily handled
chunks.

>From a schedule estimation standpoint, LOC (however you choose to count them)
appears to be a pretty good estimator to use for a fixed staff and fixed project
sizes.  How the prediction varies as you change staff or project sizes is
something you'll have to measure or guess at yourself.  At least COCOMO research
gives you some idea how the curves are shaped.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20020708/8c36fe03/attachment.html>