From: ZUSE@tubvm.cs.tu-berlin.de (Dr. Horst Zuse) Date: 7 Aug 91 11:02:46 GMT Organization: Technical University BerlinThere is a software metric tool called: QUALMS. The address is: Robin Whitty, CSSE, Southbank Polytechnic, Borough Road, Londo SE10AA, UK, Phone: +44-71-928-8989 ext. 2589.
From: warren@eecs.cs.pdx.edu (Warren Harrison) Date: 23 Aug 91 07:43:09 GMT Organization: Portland State University, Portland, ORIn article <125@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
We are looking for a reasonably priced, network licensable, too to perform basic complexity analysis on C (and perhaps Pascal) source code.Try SET Laboratories at 503-829-7123 (FAX: 503-829-7220). The PC version of the SET Labs' analysis tool is $199-$274 depending on whether you want the optional report query tool or not. The UNIX version (SunOS, UNIX/386) is $450 per seat (price goes down as quantity goes up for either). You could probably license the entire shop for a $10K site license. Metrics include Cyclomatic Complexity, Software Science, Span of Data Reference, Size, Comment Density, Avg. Variable Name Length, etc. Versions for C, C++ and Pascal (Ada, dBASE, COBOL, FORTRAN, Jovial, Basic too, but you just asked about C and Pascal :-) Also versions for the Mac and VMS.We are currently using McCabe's analysis tool, but we are quite fed up with the stinking CPU-locked licensing arangement on our 400+ workstation network. (Having to log into another workstation as a particular user just to get a complexity analysis is a pain in the a***).
So does anyone out there know of an aproximately equivalent tool that has better licensing arangements for large networks?
From: ZUSE@tubvm.cs.tu-berlin.de Date: 20 Jan 92 00:00:00 GMT Organization: IBM 370 VM/SP, TU-Berlin, GermanyMETKIT is a collaborative project part-funded by the European Commission under their ESPRIT programme. The aim of METKIT is to raise awareness and increase usage of software metrics within European industry by producing educational material aimed to both industrial and academics audiences. METKIT will offer 13 software metric tools. If you want to have more informations, please write to:
Brameuer Mike Kelly 237 High Street Adlershot - Hants GU11 1TJ UK Fax: +44-71-928-1284
These tools are constructed for the static and dynamic analysis of programs: They contain several complexity measures.
Herrn H. Sneed Rosenheimerlandstra`se 37 8012 Ottobrunn GermanyFor the Languages: C, COBOL, DBASE III, FORTRAN, PASCAL, PDL, PL/1, PLM,
For the Languages:
ADA,
ASSEMBLER,
ATLAS,
C,
COBOL,
FOCUS,
FORTRAN,
LTR2, LTR3,
MODULA-2,
PASCAL,
PDL,
PL1,
PLM
Output with Kiviat Diagrams
For the Languages:
C,
CORAL,
FORTRAN,
KINDRA,
LOTOS,
PASCAL,
Z.
QUALMS is based on the prime decomposition of programs in
primes.
Since some people would like to know what responses I got for the posting,
I summary them as follows:
The tool needs to at least be able to trace variables forward and
backward, i.e. where is X used, which other variables influence it,
is it used at all, in this procedure/module/whole program.
The VMS environment doesn't seem to have as much public domain software
available as the Unix environment. Possibly it could be that the tools
that DEC supplies are good enough. I haven't used any of these tools
myself, so I don't know.
"I recommend that you investigate the LSE (language sensitive editor) and SCA
(source code analyzer) products from Digital Equipment Corporation. Both
of them are packaged together with other programming productivity tools into a
product called DECset, so you may want to look at that as well (it might
save you some money to purchase DECset rather than the individual
products).
With SCA, I can find all occurances of a symbol (identifier, routine, constant)
in any lexical scope that I want: program, module, routine, block, etc;
it can recursively build a call tree as many levels deep as you want. SCA can
even combine the results of a query with another query to form a third.
This is just a brief example of the kinds of queries that can be formed
with SCA. I've appended some HELP text below to give you a better idea of how
it works. SCA also has a callable interface, so you can write programs to query
SCA's database and customize the information to suit your needs.
SCA is integrated with Digital's compilers today: you simply add the
/ANA qualifier to your PASCAL command line to generate a .ANA file which you
then load into an SCA database.
SCA is also integrated with LSE, Digital's Language Sensitive Editor. You can
query the SCA database within LSE and then use a single keypress (CTRL/G) to
go to the actual spot in the source code where the symbol occurs! If the query
results in multiple occurances, CTRL/F (forward) and CRTL/B (backward)
navigate through the list.
The metrics package also has Mccabe and Halstead analysers. Pretty good stuff
for free.
I have not read this, but understand it has some insight into OOP metrics. I
am currently starting some thesis research in the subject of C++ metrics and
would be extremely interested in any feedback you receive. So far the only
metrics I have seen documented are counting metrics, such as number of methods
per class, number of classes, number of messages per class, etc. I am
looking for a complexity metric similar to McCabe's for functional programming.
Chris Kemerer and an associate presented a paper on design metrics an the
recent OOPSLA conference....
I have been working with ParcPlace systems and the International Function
Point User group to put together a working group to develop standards for
measurement in OOPS environment. Please let me know if you'd be interested in
participating..
Regarding the inquiry by Crichton, I don't recall what was posted in
response. But at Ohio State, our reusable components research group has
recently done some empirical study of the benefit of reuse. It will be
published in the Proceedings of the 4th Annual Workshop on Software Reuse
in November. The paper is by Hollingsworth, Weide, and Zweben and is
called "Confessions of Some Used-Program Clients."
I can send you a copy if you provide a mailing address.
There is a recent paper: "Towards a metrics Suite for Object
Oriented Design" by Shyam R. Chidamber and Chris F. Kemerer
that was given at the OOPSLA/91 conference. (The proceedings
in SIGPLAN Notices 26(11), November 1991; the paper is on pages
197-211.)
In the bibliography of that paper several OO metrics references
given:
The "Logiscope" tool from Verilog will generate, among other things,
McCabe and Halstead metrics for programs written in Ada and many other
languages (C, FORTRAN, various assemblers,...). It runs on quite a few
machines, including Sun-3 and Sun-4. We are using it where I work
(see .sig). No, Verilog pays me nothing.
Hope this helps.
-- Allan Plumb (adplumb@deltahp.jsc.nasa.gov)
I personally have been concentrating on measurements/metrics that
can be gathered from our central problem reporting system (SPECS)
and can be used as "barometers" to improve different phases of the
development cycle (measures such as fault, failure, reliability,
coverage etc).
Galen has been working more on the type of measures you are
requesting (programmer production etc). He has some data that may
be of interest to you. It relates some internal NCR developments
against the SPR suggested levels (SPR is a company owned by
Capers Jones and concentrates on gathering reams of data pertaining
to industry wide software development efforts). He also has some
data from the SQE Xerox study.
If you could provide us with an address and a FAX number we
would be glad to send you this information. Also, if your interested
in what we are doing relating to the in-process development
measures (I described above) I have quite a bit of data.
You can reach Galen and me at:
I've argued (confidently and persuasively) that good software metrics are a
Good Thing. Trying to manage a project without good metrics is like trying to
lose weight without ever getting on a scale. You may do well, you may do
poorly; but how will you ever really know?
The problem is, there are a lot of bad software metrics. MOI is the ultimate
metric for a commercial software project. It's a terrible software
development metric. If all you know is that a product lost a ton of money,
that's not enough to fire all the programmers and apologize to all the
marketeers. (Vice versa doesn't work, either!)
Now, let me answer your question: NO!!! There is absolutely no "standard"
number of lines of code (LOC) or non-commentary lines of source code (NCSL)
per programmer per day, period. There's no standard even if you know:
(There are no "standards" for function points, either.)
There are some people (and I lean toward this direction) who say that LOC and
NCSL are *bad* metrics, and should never be considered. Has someone who's
cut-and-pasted ten lines a hundred times done a better job (or more work) than
someone who's written thirty lines of reusable code? (Whose would you rather
maintain?-) Even if some rough measurement of code "bulk" might be helpful at
some level, most people think LOC and NCSLs should *NEVER* be used for
performance review.
There are word-of-mouth stories of people within AT&T who have done all kinds
of songs-and-dances, fraudulently producing the "right" LOC/NCSL metrics just
to look good. Not enough progress? Take a function, make a copy (or several
copies of it) throughout the code, and count all the lines in all the copies.
Code considered too bulky? Combine functions into giant switches (huge
modules that should be separate; can you say "coincidental or temporal
cohesion"?), or join statements into long text lines. (If your management is
measuring LOCs instead of NCSLs, blank lines can twist the metrics as fast as
you can type.)
(One of the comp.software-eng Frequently Asked Questions is, "Are LOCs/NCSLs a
good software metric?" I'll see if I can repost the answer to the AT&T/NCR
groups.)
At this point, I can imagine what you think my answer will be. You're
wrong; it's not even that simple.
First and foremost, according to every book, article, memo, and BCP on the
subject: Upper CASE tools do not, repeat ***NOT***, have any impact on
productivity. (This is *not* a sermon against upper CASE tools, which I think
can be useful.) Re-read that sentence.
What *can* impact productivity are methods and methodologies of software
development. (I know the difference, but let's discuss that via e-mail if at
all.) Upper CASE tools can automate, ease, speed up, and generally improve
the way people carry out a method.
IF YOU BUY A CASE TOOL WITHOUT PICKING A METHOD, THE TOOL WILL NOT WORK!
There's a Bell Labs "Best Current Practices" (BCP) that says this in almost so
many words. If management is committed to looking better, but not to working
differently, nothing happens. There is no "Software through Pictures
methodology". If dataflow diagrams and data dictionaries and the StP realtime
models aren't what your project is producing (and what it needs), it doesn't
matter that StP is the package best suited to those tasks. (I also speak from
bitter personal experience on this one.)
(Sidebar: upper CASE tools are not word processors. In comparison, the upper
CASE tools are poorly integrated, nearly impossible to learn, and terribly
awkward to use. The "best" such tools are merely less bad than their
competition.) (This is a personal opinion.-)
How do things change with lower CASE tools? In ways that are very hard to
measure. If your lower CASE tool generates code, the volume of that code
shouldn't be compared to hand-written code. It's just too different. Many
lower CASE tools don't generate code at all. What do you count now?
Hey, if there were hard numbers showing CASE tools (or *anything*) always
increased software development productivity, we'd all have changed years ago.
There is no silver bullet to slay the monster of software development
complexity. That's why they pay us the big bucks (at least as compared to the
people who flip hamburgers).
Essentially, it measures the branchiness of the code. If I recall
correctly, McCabe's metric is strongly correlated with number of lines
of code, though I can't cite the studies. Like all metrics, it's only
an indirect measure of what you really care about (true "complexity").
There is evidence that fault density increases with increasing
cyclomatic complexity: larger routines are more error prone. But
there's also evidence that very small routines increase the fault
density as well, probably because of interface faults. See Carol
Withrow, "Error Density and Size in Ada Software". IIEEE
Software, Vol. 7, No. 1, pp. 26-30, January, 1990.
Here we tend to have a large number of small methods in our code to date so
the cyclomatic complexity tends to be very low and of limited predictive value
so far. There are some companies, writing C++ code for medical applications,
that have developed guidelines for maximum allowable complexity, demonstrating
that they believe the numbers are highly predictive.
A paper was presented at OOPSLA 91 that outlined six candidate metrics to
specifically address the OOD paradigm. Chidamber and Kemerer of MIT believed
that the number of methods, the depth of the inheritance tree, the number of
derived classes, etc. will all have an impact on complexity. Lake and Cook of
Oregon State concentrated on the inheritance tree and designed a tool to
capture some of the C++ metrics they believed relevent.
In addition to the articles mentioned by Horst, you may want to read
Csize performs lexical analysis on C source files to collect
various size measures, namely total lines, blank lines, lines
with comments, nonblank noncomment lines, semicolons, and
preprocessor directives. The program was designed to measure
the source as the programmer sees it, not the version that is
fed to the compiler. Here is the output from the program when
run using two of its files as input:
QUALMS
Distribution:
Since 1988: Distributed by Southbank Polytechnic in London
by Robin Whitty, Southbank Polytechnic, Borough Roda,
SE1@0AA, London, UK, Phone: +44-71-928-8989 ext. 2589.
Summary of Source Code Analysis Tools for C++
From: ching@hal.com (Qingmin Wang)
Organization: HaL Computer Systems
Hi,
SET Laboratories, Inc.
P.O. Box 868
Mulino, OR 97042
(503)829-7123
Static analysis of Pascal: summary
From: arndt@c3consult.comm.se (Arndt Jonasson)
Date: 11 Mar 92 07:51:27 GMT
Organization: Communicator C3Consult AB
In a previous article, I wrote
I'm looking for information on static analysis tools for Pascal. The
system of interest is VAX/VMS, but our software doesn't use most of
the extra features of VAX Pascal.
and promised a summary. Here it is. Thanks to all who answered.
$ help sca
SCA
The VAX Source Code Analyzer is an interactive, multilanguage,
source code cross-reference and static analysis tool that is
designed to aid developers in understanding the complexities of
large-scale software systems.
The DCL command line has the form:
$ SCA [command [/qualifier,...]]
For basic information on using SCA, type "New_Users"; for a listing
of commands, type "Commands"; for tutorial information, type
"Topics".
Additional information available:
CHECK CREATE DELETE EXIT EXTRACT HELP LOAD
REORGANIZE Sca_Example SET SHOW VERIFY VIEW
FIND Commands New_Users Release_Notes Topics
SCA Subtopic? topics query
SCA
Topics
Querying_libraries
1. You can selectively display information about modules in the
current SCA library with the SHOW MODULE command. The
command has the form:
SHOW MODULE [/qualifier...] [module-name-expr[,...]]
Example:
$ SCA SHOW MODULE
Module Ident Compiled
SCA$$DBGETFILE X0.6 3-APR-1985 14:04
SCA$$DBGETFILEOCC X0.6-1 3-APR-1985 14:04
SCA$$DBGETFILESPEC X0.4 3-APR-1985 14:04
Complete (/FULL) or partial (/BRIEF) information about all
(/ALL) modules, or selected (/VISIBLE or /HIDDEN) modules,
can be displayed. The terms "visible" and "hidden" refer to
the results of the module selection process that occur when
multiple libraries are accessed.
2. You can obtain cross-reference information about program
symbols and source files by using the FIND command. The
command has the form:
FIND [/qualifier...] name-expression[,...]
Example:
$ SCA SET LIBRARY SCA$EXAMPLE
%SCA-S-LIB, your SCA Library is
SYS$SYSROOT:[SYSHLP.EXAMPLES.SCA]
$ SCA FIND max*
Symbol Class Module
MAX_CODE constant BUILD_TABLE
BUILD_TABLE CONST
declaration
BUILD_TABLE
BUILD_TABLE
MAX_CODE constant TYPES
TYPES
MAX_RECORD_LEN constant COPY_FILE
COPY_FILE CONST
declaration
COPY_FILE
COPY_FILE
MAX_RECORD_LEN constant TYPES
%SCA-S-OCCURS, 11 occurrences found (4 symbols, 2 names)
Notice that the SCA commands are entered at the DCL level and
all occurrences of symbols that begin with MAX are displayed.
3. You can selectively display call information related to
specified routines in the current SCA library with the VIEW
CALL_TREE command. The command has the form:
VIEW CALL_TREE [/qualifier...] routine-name-expr[,...]
Example:
$ SCA
SCA> VIEW CALL_TREE BUILD_TABLE
BUILD_TABLE
unknown
BUILD_TABLE
%SCA-S-ROUTINES, 3 routines found (no recursive, depth
undetermined)
SCA> EXIT
$
In this example, the library used in the last session is
queried for calls related to the BUILD_TABLE routine.
Lines of Code Metric
From: wright@jpl-devvax.jpl.nasa.gov (Steve Wright)
Organization: Jet Propulsion Laboratory (NASA)
Date: Thu, 2 Apr 1992 23:03:39 GMT
There is a package called metrics put together by Brian Renaud. I think I
ftp'ed it from gatekeeper.dec.com. It contains a program called "kdsi" which
strips comments and blank lines from a source file and counts whats left (it
counts blanks and comments seperatly). "kdsi" was mentioned by Carl Dichter
in a "Unix Review" article on code imspections.
Software metrics for object-oriented programs
From: rajar@herky.cs.uiowa.edu
Date: Thu, 4 Jun 1992 13:32:23 -0500
Warren DeVilbiss
devilbis@csd4.csd.uwm.edu
warren@point.cs.uwm.edu
You might try Brian Barry's paper "Prototyping a Real-Time Embedded System
in Smalltalk" from the Proceedings of OOPSLA 89, New-Orleans, LA, ACM SIGPLAN.
From: edwin@is.Morgan.COM (Ed Bergman)
There's not too much out there for OOPS.... Dr. James Palmer of George Mason
and SHari Pfleeger of Contel presented a paper on estimation within and OOPS
environement in 1990. It based its estimation of the number of nouns (Classes)
and verbs (methods) determined from the parsing of a text requirements
document.
From: Stu Zweben <zweben@cis.ohio-state.edu>
Regarding your recent posting to comp.software-eng:
There's an article in the 1988 Int'l Conf on Software Engr. by Embly
and Woodfield that proposed some design quality metrics a la coupling and
cohesion. I haven't seen it used much since then, but it's there.
James Bieman Email: bieman@cs.colostate.edu
You may find my recent paper useful:
"Deriving measures of software reuse in object oriented systems."
Proc. British Computer Society Workshop
on Formal Aspects of Measurement, London, 1991,
to appear in Springer LNCS.
Also avail. as a technical report CS-91-112.
Associate Professor Brian Henderson-Sellers
School of Information Systems
UNSW
Australia
I recently noted your request for information on OOmetrics.
This is an area in which I, colleagues and students are working at the
Univrsity of New South Wales. We had an undergraduate complete an extremely
successful project on complexity metrics last year, which we have just written
up and submitted for publication. I will also be presenting the first
results on reuse metrics at TOOLS in Sydney in December. The Proceedings
will be p;ublished by Prentice Hall. If you have any problem obtaining
that paper I can send you a copy once published (next month). I will also
be presenting some further work in this area at the OO Workshop in
Denver in February.
Unrecorded author:
I just got your email address via Brian. I saw your summary posting on
comp.software-eng. The responses that I got were similar to yours except that
I got one more paper and one thesis reference:
McCabe and Halstead metrics for SUN4
Date: Thu, 18 Jun 92 13:21:03 EDT
From: gdb@cs.wvu.wvnet.edu (Gary D. Boetticher)
From adplumb@deltahp.jsc.nasa.gov Wed Jan 22 17:03:18 1992
Hello.
FTP TO THE FOLLOWING SITES TO GET SOME METRIC PROGRAMS:
ftp wuarchive.wustl.edu
CHANGE TO ONE OF THE FOLLOWING DIRECTORIES:
cd /pub/ada/metrics
or
cd /mirrors2/ada/metrics
YOU OUGHT TO FIND BOTH THE MCCABE METRICS PROGRAM AND THE HALSTEAD
METRIC PROGRAMS. BOTH SETS WILL NEED TO BE UNPAGED AND COMPILED.
BOTH PROGRAMS ARE ORIENTED TOWARDS THE VAX/VMS. GOOD LUCK!!
From grebyn!margono@uunet.UU.NET Thu Jan 23 14:22:48 1992
Contact EVB Software Engineering, Inc. (1-800-877-1815). They have
a complexity tool that also runs on UNIX platforms.
From elkes@sun1.is.battelle.org Thu Jan 23 16:25:00 1992
Try looking through the archives of comp.sources.unix -- volume 20i008
for a program called "metrics". I haven't unpackaged it yet but I
believe the code is in C, not ADA.
ftp shape.mps.ohio-state.edu
cd /pub/archives/comp.sources.unix/Vol20
Values for development metrics
From: scuzzy!rosen
Hello,
Does anyone know the values for the current development
metrics? I.e. How many debugged and documented lines of
code should be produced by a programmer per day? How do
"Function Points" fit into the picture - Is there an
industry standard for these too?
Date: Tue Feb 11 09:44:07 GMT 1992
From: attmail!attbl!mlgtw!mltsa!djones (David Jones )
I would be interested in any info you get. As far as Function Points
are concerned you might like to look at :
(Albrecht developed FPs ate IBM in the late 70's)
Date: Mon Feb 10 08:02:00 GMT 1992
From: attmail!attbl!cbnewsb!att!ncrsoph.sophia.ncr.fr!dnadler (dnadler@ncrsoph.sophia.ncr.fr )
There is a "Function Point" coordinator within the US Group ISS
organization. Her name is Nancy Shultz. Try nancy.shultz@daytonoh
(including whatever NCR extra stuff you need). If you don't have
luck getting through to her, let me know, and I'll track down her
complete address you need.
Date: Sat Feb 8 14:14:49 EST 1992
From: attmail!attbl!cbnewsk!hansen (Tony L Hansen )
The values are mostly worthless. I suggest you read
available at your local company library.
Tony Hansen
hansen@pegasus.att.com, tony@attmail.com
att!pegasus!hansen, attmail!tony
Date: Mon Feb 10 09:15:00 EST 1992
From: attmail!ncrcom!cqa2.daytonoh.ncr.com!nyoung (cqa2.daytonoh.ncr.com!nyoung )
I read your newsline requesting information concerning development
metrics. Along with Galen Roth, I work in a small group known as
Systems and Software. Our charter is to investigate, recommend and
help NCR plants implement measurements/metrics that may improve
the software development process.
NCR Corporation
1700 S. Patterson Blvd
WHQ-4
Dayton, OH 45479
Fax: (513) 445-2824
Ned: (513) 445-3002
Galen: (513) 445-2805
ned.young@dayton.ncr.com
galen.roth@dayton.ncr.com
Date: Wed Feb 12 00:18:06 EST 1992
From: attmail!attbl!cbnewsl!psrc (Paul S R Chisholm )
Mr. Rosen, welcome to the landfield. You've just stumbled into one of
the loudest, most violent controversies of software engineering.
In fact, since most of those factors are impossible to quantify, you can't
quantify their results. (I haven't even mentioned things such as familiarity
with the domain, or organizational churn and morale.)
Now for the punch line - How do these figures change when upper &
lower CASE tools are implemented?
Date: Mon Feb 10 13:31:51 GMT 1992
From: attmail!attbl!cbnewsb!att!ddbeano.dundee.ncr.co.uk!tonyg (TONY GOWLAND )
This is not a direct answer to your question, but an interesting discussion
on kloc/day and function/feature points is contained in 'Programming
Productivity' by Capers Jones, McGraw-Hill
Info on McCabe metric?
From: marick@m.cs.uiuc.edu (Brian Marick)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Mon, 8 Jun 1992 14:23:15 GMT
T. McCabe. "A Complexity Measure".
IEEE Transactions on
Software Engineering, vol. SE-12, No. 4, December, 1976.
Metrics for C++ in large scale OO projects
From: ZUSE@tubvm.cs.tu-berlin.de
Date: 13 Jul 92 00:00:00 GMT
Organization: IBM 370 VM/SP, TU-Berlin, Germany
Hello, there are some papers in the area of metrics for object-oriented
programming.
From: colson@.uucp (Garrett Colson)
Date: 20 Jul 92 20:22:05 GMT
Organization: Project Canada
It is probably useful to track any and all complexity measurements initially.
There are a number of low cost tools to collect the numbers making it an easy
task. Experience and analysis will tell you which ones are useful for your
particular style of code.
Towards A Metric Suite For Object Oriented Design,
Shyam Chidamber and Chris Kemerer,
MIT Sloan School of Management,
Cambridge Ma 02139.
Csize static measure tool for C
Date: Mon, 24 Oct 1994 08:37:27 +0100
From: Christopher Lott
Csize is a program which I developed and which recently was posted to
the group comp.sources.reviewed. I developed it based on a need for
size measures of C code which I could understand; I felt that the
tools which were freely available to me were either underdocumented (I
didn't understand their counting rules) or overloaded with features
that didn't interest me (complexity of all sorts).
% csize -h csize.h csize.c
total blank lines w/ nb, nc semi- preproc. file
lines lines comments lines colons direct.
--------+--------+--------+--------+--------+--------+----
19 4 5 10 4 0 csize.h
117 12 10 96 43 3 csize.c
136 16 15 106 47 3 total
Documentation and sources are currently available via anon ftp
from the comp.sources.reviewed archives.
To compile the program, you will need a C compiler and flex.
The fileset has been placed under the GNU General Public License.
Christopher Lott / Email: lott@informatik.uni-kl.de / Tel: +49 (631) 205-3334
Address: FB Informatik - Bau 57 / Universitaet KL / D--67653 Kaiserslautern