Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!mcnc!duke!crm From: crm@duke.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng Subject: Re: COCOMO Message-ID: <677256043@macbeth.cs.duke.edu> Date: 18 Jun 91 14:40:45 GMT References: <677047335@macbeth.cs.duke.edu> <1991Jun18.033606.1362@netcom.COM> Distribution: comp Organization: Duke University Computer Science Dept.; Durham, N.C. Lines: 78 In article <1991Jun18.033606.1362@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >>(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. > >The primary complaint I and others have with the COCOMO model is the >above claim. To assert that a person writing in some homebrew >dialect of FORTRAN using a line editor on an IBM mainframe with a circa 1962 >debugger is as productive (or even within two orders of magnitude as >productive) as a person using the latest-greatest software development >environment and one of the modern software engineering oriented languages >(e.g. Ada, Eiffel, C++, etc) is prima-facie absurd, claims of empiricism >notwithstanding. I always hate it when someone says something is "prima facie absurd" like this. First of all, notice the claim is not *everyone*, but that *within an organization* the productivity is roughly constant. One reason that what you suggest ddoesn't apply is that it pretty unlikely that within the same organization one programmer will be using Wylbur and the other will be using a highly-integrated environment. But secondly, "claims of empiricism" cannot be just unceremoniously dumped. The fact is that this relationship held over something like 400 projects, in dozens of different environments, with languages from assembler to the best HLL's of the time. Where is your counter evidence? How was it measured? Third, the COCMO model actually suggests that none of those factors may really influence productivity in SLOC delivierd on big projects. Recall the basic equation: MM = P K^d that is basically saying that effort MM is productivity constant times size to the diseconomy exponent. Clearly, then, MM = O(K^d) and we can see that at some point the effects of increasing size dominate the effects of anything that affects just the constant (so long as d > 1.) One supposition I've made is that the difference between programming-in-the-small and programming-in-the-large is that large scale programming is when scale dominates in this equation. [ This is my Discovery Of the Week. I can't decide if I think it's significant or not.] >... I have empirically observed exactly the opposite: >that productivity varies wildly between different software development >organizations (and that those who are more productive have a significant >competitive edge), Absolutely, but that sorta says the same thing I said above. I question your supposition that productivity gives that much of a competitive edge -- it looks to me like non-technical factors dominate -- but it's probably more of an edge in the current environment than low defect rates in the field. >and I believe any estimation model that fails to take >this into account is inherently inaccurate. At a minimum I suggest that >estimation models should contain a factor for an organization's SEI rating. You didn't read down far enough. The relation has not one but two factors that can be set or chosen to suit differences in the environment. In the Intermediate and Advanced COCOMO models there are a number of factors that model things like language chosen, environment, use of a methodology, etc. Basic COCOMO does not take these into account, and as you say is inherently inaccurate. but it works suprisingly well as a predictor -- Basic COCOMO is the one that is correct "to within a factor of two 60 percent of the time" applied post facto to big projects, and there aren't many other psychological properties that can be predicted all that well. -- Charlie Martin (...!mcnc!duke!crm, crm@cs.duke.edu) 13 Gorham Place/Durham, NC 27705/919-383-2256