Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!europa.asd.contel.com!gatech!mcnc!duke!crm From: crm@duke.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng Subject: Re: COCOMO Message-ID: <677047335@macbeth.cs.duke.edu> Date: 16 Jun 91 04:42:16 GMT References: Distribution: comp Organization: Duke University Computer Science Dept.; Durham, N.C. Lines: 68 In article ahl@technix.oz.au (Tony Landells) writes: >I'm looking for opinions of COCOMO. I was on a course about software >quality assurance and they mentioned it as a methodology which >produces a lot of useful figures, but the comments were accompnied by >the disclaimer "I haven't used it, but people that do seem to think >it's pretty good". > >I believe it's completely described in "Sofware Engineering Economics" >by B.W.Boehm, Prentice-Hall 1987; but the book isn't readily available >here in Australia (lead time for order is 12-14 weeks) and it is >extremely expensive, so... > >I'm looking at this almost purely for a UNIX/C environment, since >that's the field I work in, in case this affects people's comments. > >Thanks kindly, >Tony Landells I've done at this point some pretty extensive work with COCOMO as a model, and a fair bit of work with it trying to use it to make estimates to help my wife, who manages a big project (1+ million SLOC). My experience is that it isn't a bad model at all, with a little calibration, and that simply choosing the right parameters for the basic COCOMO model is pretty predictive, probably within the accuracy of estimation at the beginning of a project. In other words, your error in estimating SLOC is probably the driver in estimation of total staff months. Here's the basic scheme: (1) Empirically, in any organization, man-months per 1000 lines of code (K SLOC) is roughly constant, no matter what language or environment is used. So, we can always assume that effort in man-months is proportional to size in KSLOC. (2) All of the COCOMO effort models have the basic form MM = P * K^d where MM is man-months P is productivity in man-months per KSLOC (ignore that exponent) and d is an exponential-fit value found empirically, that represents the way that bigger projects are harder. Call this thing the 'diseconomy exponent'. If you can keep this to exactly 1, you can be rich. If you can get it below 1, you can be really rich. For most monolithic non-systems programs, I have found that you get good fits with Boehm's Basic COCOMO values, P=2.4, d=1.05. Be careful that you remember K is size in *thousands*, so using a test value like K=1 tells you that MM = 2.4 man-months for 1000 lines of code (fully documented and tested.) (3) If you're doing something intrincially hard, like a real-time program, you need to use different values. For real-time or embedded programs, reasonable values are in the neighborhoods of P=3 and d=1.3; if you are doing anything much hard-core you should get Boehm's book for all the weighting factors etc. Applying the weighting factors is what makes the model Intermediate or Advnaced COCOMO. (4) Some of the work I've been doing involves estimating the effect of reuse. I've got a whole technical report inpreparation on this, but preliminary results suggest that the COCMO model is very predictive for compiler-writing reuse (retargeting GNU CC). -- Charlie Martin (...!mcnc!duke!crm, crm@cs.duke.edu) 13 Gorham Place/Durham, NC 27705/919-383-2256