Software Engineering - Q: COCOMO II project size limitation?

Author

Q: COCOMO II project size limitation?

Gregory Seront

2004-06-30, 3:59 pm

I am using the cocomo II model for some times now, and when I look at
the equation describing the model, I can help thinking that there is a
mathematical problem with it when you are evaluating project under 1
KLOCS.
The equation is
PM = EM1 * ... * EM17 * C * (Size)^B+ ...

Since B is > 1, when Size is < 1, the effect of the exponent is the
inverse of what it is above 1.
For instance, if we take x = a^1.17, we have

x>a if a>1

but

x<a if 0<a<1

Does anyone have any opinion about this or read something related to
this?
I couldn't find any mention of this problem. Except that usualy the
model is calibrated for project far above 1 kloc. In our case we are
trying to calibrate and use cocomo for small scale project.

thanks in advance for your replies,

Grégory Seront

MON

2004-07-28, 9:04 pm

gs@cetic.be (Gregory Seront) wrote in message news:<8ceebd59.0406301123.45f63047@posting.google.com>...
> I am using the cocomo II model for some times now, and when I look at
> the equation describing the model, I can help thinking that there is a
> mathematical problem with it when you are evaluating project under 1
> KLOCS.
> The equation is
> PM = EM1 * ... * EM17 * C * (Size)^B+ ...
>
> Since B is > 1, when Size is < 1, the effect of the exponent is the
> inverse of what it is above 1.
> For instance, if we take x = a^1.17, we have
>
> x>a if a>1
>
> but
>
> x<a if 0<a<1
>
> Does anyone have any opinion about this or read something related to
> this?
I have only limited knowledge of the formulae for Cocomo II, but I
know that a project of under 1K SLOC is a difficult one to measure in
any circumstances with any tools. I use FPA to measure software since
it gives a size of the functionality that is independent of the
implementation method, so different implementation options can be
compared. While I wouldn't convert lines of code to FP or v.v., (it
isn't analogous, and the conversions are suspect), I know from
experience that a project of the size you mention will have a small FP
size too. I don't believe you will get anything to give you reliable
results for a project of that size - the relative weight of the
variables is too high in relation to the total size.
> I couldn't find any mention of this problem. Except that usualy the
> model is calibrated for project far above 1 kloc. In our case we are
> trying to calibrate and use cocomo for small scale project.
>
> thanks in advance for your replies,
>
> Grégory Seront

Doug Scott

2004-07-28, 9:04 pm

Mon,

> I
> know that a project of under 1K SLOC is a difficult one to measure in
> any circumstances with any tools.

Yes, it's a "Just Do It" project.

I'm trying to protect a junior PM at the moment who's got to provide an
MS Project timeline for something which involves sixteen tasks repeated
over six scenarios, in a w

. It's just not worth using MS Project for
such trivia.

---

Doug

dwscott@ieee.org

Alan Gauld

2004-07-28, 9:04 pm

On Tue, 27 Jul 2004 20:29:54 +0100, Doug Scott <dwscott@ieee.org>
wrote:
>
> Yes, it's a "Just Do It" project.

With this I agree.

> I'm trying to protect a junior PM at the moment who's got to provide an
> MS Project timeline for something which involves sixteen tasks repeated
> over six scenarios, in a w

. It's just not worth using MS Project for
> such trivia.

Aside from comments about MS Projects suitability for any kind of
project planning I would disagree with the last bit. If the task
has to be managed within very strict timescales (for example
cannot finish early or late) with close dependencies points on
other work then a project plan may be worth deriving.

I have been known to write project plans for bits of work that
only spanned 3 hours - but involved several parallel streams with
critical time dependencies (eg. the cut over of a legacy system
to a new one without interrupting service for more than the 3
minutes permitted downtime)

But in the general case for a few hundred lines ASAP it's usually
enough to JDI the cost of estimating is likely to be more than
the cost of the job.

Alan G.

Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Sponsored Links