Xref: utzoo comp.software-eng:2500 comp.misc:7472
Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!xanth!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Metrics (was "Re: Programmer productivity")
Keywords: programming productivity, metrics, lines of code
Message-ID: <16187@duke.cs.duke.edu>
Date: 24 Nov 89 17:38:00 GMT
References: <34819@regenmeister.uucp> <11690@cbnews.ATT.COM>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Distribution: na
Organization: Duke University CS Dept.; Durham, NC
Lines: 38

In article <11690@cbnews.ATT.COM> kww@cbnews.ATT.COM (Kevin W. Wall,55212,cb,1B329,6148604775) writes:
>....
>I assume that most readers of this newsgroup are well aware of the shortcomings
>of using SLOC as an accurrate software metric.  (If not, see T. Caper Jones'
>book, mentioned above.)
>
>Instead of pointing out are the things that are wrong with SLOC, how about
>hearing some success stories using some other software metric (e.g., McCabe's
>complexity metric, etc.).
>

The funny thing about the other measures (e.g. McCabe and Halsted) is
that they don't seem to be a lot more predictive than weighted SLOC
models like COCOMO.  Also, just like SLOC, they can be confounded by
pathological programs:  Elliot Soloway has a perfectly hilarious
comparison of two programs with the same McCabe complexity, but where
one is instantly and obviously much harder to code or maintain than the
other.  (This was done by choosing odd names, odd loop bounds and array
indicises, that sort of thing.  Another example of a way to confound
McCabe or Halstead is programming with variable names like O0OO0.)

>Also (surprise, surprise), not all of software development consists of
>programming.  That is just the implementation phase.  What metrics do you
>use (or "should be used") for measuring productivity of those involved in
>design, testing, requirements, etc.?

There is plenty of work to be done in this, no  question.  Common
assumption is that, given the time for the whole thing guessed by SLOC,
you can then guess the time for a phase by taking a proportionate slice
of the total for that phase.  But those time to complete SLOC rules of
thumb, like 3-4 SLOC per staff day, represent total time to complete,
not just implementation.

Another good book on software engineering metrics is the Conte, Dunsmore
and Shen book _Software Engineering Metrics and Models_.


Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)