Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!mcnc!thorin!coggins!coggins
From: coggins@coggins.cs.unc.edu (Dr. James Coggins)
Newsgroups: comp.software-eng
Subject: Re: Using COCOMO to estimate development schedules
Keywords: COCOMO, software development
Message-ID: <7518@thorin.cs.unc.edu>
Date: 30 Mar 89 18:49:22 GMT
References: <351@tahoma.UUCP> <4148@ttidca.TTI.COM>
Sender: news@thorin.cs.unc.edu
Reply-To: coggins@coggins.UUCP (Dr. James Coggins)
Organization: University Of North Carolina, Chapel Hill
Lines: 55

In article <4148@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes:
>
>1)  His entire system of formulas rests on a figure for the estimated
>    difficulty of the project.  My boss and I badgered him for three hours
>    to find out where this fundamental figure came from.  When we finally
>    pinned him down, the answer he gave amounted to "You take a flying
>    guess."

Ridiculous.

Computer scientists still do not appreciate the difference between
guessing and estimating.  A guess is a number produced out of thin
air.  An estimate is the result of an explicit computation based on
clearly stated, testable assumptions.  Estimates can be accompanied by
error ranges and analyses of the sensitivity of the result to the
initial assumptions. Engineers learn this as undergrads.  Computer
scientists miss it (unless they encounter a course I'm teaching).

This is not the only instance of some engineering math that computer
scientists need and usually don't get, resulting in computer scientists
writing one form of idiocy or another in project estimates or in
net postings.

>    (He actually said something about basing the estimate on past
>    experience with other projects and the programmers involved. 

That sounds more like it.

>    Given
>    that each project is different and involves a different mix of skills
>    and people, this amounts to guessing).

Both the premises and the conclusion are false.

Parnas says "All design is redesign." He's right.  It is rare and
special to be writing a truly new software product.  In reality,
almost all projects fall into some large class of projects that have
been done before.  Boehm's COCOMO technique helps you to know WHAT you
need to observe from the previous projects.  Rather than the
seat-of-the-pants guesses your boss came up with COCOMO shows a few
specific quantities that need to be observed over time.  It also helps
to focus efforts to evaluate and test programmer productivity that go
into the COCOMO equations.  A great contribution. 

>-- 
>The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com)

---------------------------------------------------------------------
Dr. James M. Coggins          coggins@cs.unc.edu
Computer Science Department   old: Data Structures + Algorithms = Programs
UNC-Chapel Hill               new: Objects + Objects = Objects
Chapel Hill, NC 27599-3175    
and NASA Center of Excellence in Space Data and Information Science
---------------------------------------------------------------------