[comp.software-eng] Metrics

UH2@PSUVM.BITNET (Lee Sailer) (02/25/88)

The most recent article of CACM has a good article on a new software
metric called NPATH that addresses exactly the issues that were
discussed here a few netweeks ago.

Also, I got a demo package of a program that computes several well-known
metrics for C, M2, Pascal, Fortran, and (rsn) COBOL and Ada.  Though
I've only fooled with it a few minutes, it seems to do just what you'd
want.  (It reads your mind a outputs corrct code 8-).

The compaany is SET Labs, in Portland Or, 503-289-4758.  It runs on
msdos and (rsn) Macintosh.

                          lee

kww@cbnews.ATT.COM (Kevin W. Wall) (11/23/89)

Before we are all at each other's throats arguing how programmer productivity
should be measured, I suggest you all check out the book "Programming
Productivity" by T. Capers Jones (1987 ??).  It points out the many apparent
paradoxes of using SLOC as a metric for measuring productivity -- most of
which are very non-intuititve.  It is the ONLY book that I've seen on software
metrics which I think contains the STRAIGHT SCOOP (i.e., no hype) on this
crucial area.  I highly recommend it.

Now getting back to SLOC, let's face it -- the general reasons that SLOC still
being used as a measure of programmer productivity are:
	1) management demands some quantitative measurement (& rightfully so).
	2) SLOC is a very easy thing to measure.
	3) other possible software metrics (e.g., Halstead's, McCabe's,
	   function points, etc.) are either difficult to calculate, or
	   difficult to interpret, or both.

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.).

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.?

-- 
In person: Kevin W. Wall			AT&T Bell Laboratories
Usenet/UUCP: {att!}cblpf!kww			6200 E. Broad St.
Internet: kww@cblpf.att.com			Columbus, Oh. 43213
		"Death is life's way of firing you!" -- Hack rumor

crm@romeo.cs.duke.edu (Charlie Martin) (11/25/89)

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) 

gt@hpfcmgw.HP.COM (George Tatge) (11/28/89)

From a business perspective there is only one meaningful measure of 
productivity for programmers or EE's or ME's or whatever.  Unfortunately,
it is a measure that includes a huge number of other factors such as marketing,
sales, support, etc.  That measure is return on investment (ROI).  How much 
did it cost to write this code; how much did we make from it?  

From other perspectives (eg. social benefits, advancement of the human race,
etc.) it doesn't really matter if we measure productivity.  Results of such
long term benefits are all that matter, the cost is insignificant.

gt