Topic: software metrics

topics > computer science > programming > Group: software engineering

software maintenance
experimental results on programming
management of large software projects
testing testing
program statistics
programmer productivity
quality assurance
science as measurement
software management
software science


A number of metrics have been defined to measure programs and programming languages. These range from feature identification to quantitative equations. The most successful measures with the best experimental verification are Halstead's measures based on total operands, unique operands, total operators, and unique operators. He has equations for program length, complexity, and volume; all without normalization constants. Besides an academic interest, successful software metrics could be used to benchmark software quality and predict software costs. (cbb 5/80)

Function points have proven to be a useful predictor for the cost of developing a system. (cbb 12/92)

Subtopic: effective metrics up

Quote: the best use of software metrics is detecting anomalies and guiding development, testing, acquisition, and planning [»boehBW_1976]
Quote: the length of a Z specification corresponds to the testing and development effort; useful for scheduling [»tretJ9_2001]

Subtopic: estimate by analogy up

Quote: use analogy to estimate project effort: identify features, estimate effort from similar projects; outperforms algorithmic models such as COCOMO; use at least ten projects [»shepM11_1997]
Quote: effort estimation by analogy was OK even when restricted to categorical data or a single measurement [»shepM11_1997]
Quote: effort estimation by analogy and regression analysis works best for builds or enhancements to an existing system and worst for dissimilar projects from multiple organizations [»shepM11_1997]

Subtopic: milestone metrics up

Quote: Microsoft uses synch-and-stabilize, daily build, and zero-defect; work in parallel but synch and debug daily with a shippable product; common language, continuous testing, milestone and release metrics [»cusuMA6_1997]
Quote: health-of-the-model metric combines regression results, time to debug, forward progress for new functionality, high-priority bugs, and age of open bugs [»colwRP_2006]

Subtopic: function points up

Quote: found that function point measurement was consistent across raters and methods [»kemeCF2_1993]
Quote: function points are a weighted sum of numbers of inputs, outputs, master files, and inquiries
Quote: function points predict code size and programming effort; easily estimated from requirements [»albrAJ11_1983]
Quote: function points more consistent the lines of code; within organizations have about 30% variability in function point estimates [»lowGC1_1990]
Quote: the FP-S method simplifies function point counting by ignoring function classification; need to determine adjustment facts ahead of time [»bockDB7_1992]
Quote: SPQR function points use average function complexity, and logical and data complexity; original used 3 and 14 levels respectively [»jeffDR5_1993]
Quote: actual development effort and function points compared; both SPQR and old method correlated, explains <40% of variation [»jeffDR5_1993]

Subtopic: program size up

Quote: program size has a strong effect on fault-proneness and other object-oriented metrics; must control for size [»emamKE7_2001]
Quote: code size is effectively synonymous with complexity; high correlation between complexity metrics and NCSL (non-comment and non-header source lines) [»eickSG1_2001]
Quote: program length is not a useful measure; ten-to-one variation for programs in the same language written to the same specification [»demaT5_1989]
Quote: some experiments show that multi-page modules have the lowest errors per line of code [»shneB_1985]
Quote: 20% of maintenance cost due to procedure size; optimal size was 44 executable statements [»bankRD11_1993]
QuoteRef: halsMH_1975 ;;222 program length ca unique-ops log2 total-ops + unique-rands log2 total-rands

Subtopic: complexity metric, ease of change up

Quote: for white-box testing, count IF statements instead of LOC; measures the number of executable paths [»yamaT11_1998]
Quote: 12% of maintenance cost due to long goto statements to other COBOL paragraphs [»bankRD11_1993]
Quote: after each pseudocode refinement, measure its complexity to evaluate the programming process; called the Partial_Metrics_system [»reynRG11_1987]
Quote: analyze connections between modules to predicate the total number of changes required to change a set of modules [»haneFM_1972, OK]
Quote: measure language effectiveness by counting the modifications needed to satisfy a user's needs and to effect change during evolution [»blumBI_1985]

Subtopic: bug fixing up

Quote: predict software effort from regression model of software modification and modification requests [»mockA5_2003]
Quote: fixing a release bug is twice as difficult as fixing pre-release bug
Quote: only one file changed for 51% of the Initial Modification Requests and 90% of the MRs

Subtopic: studies up

Quote: compared software metrics using 1100 program features, e.g., efficiency, reliability, uniformity [»goodJB2_1976, OK]

Subtopic: performance model up

Quote: should build a computer system so that it has a good performance model [»dennPJ9_1980]

Subtopic: problems with metrics up

Quote: mixed results reported for COCOMO and function point estimates of project effort [»shepM11_1997]
Quote: use analogy to estimate project effort: identify features, estimate effort from similar projects; outperforms algorithmic models such as COCOMO; use at least ten projects

Related Topics up

Group: software maintenance   (14 topics, 368 quotes)
Topic: experimental results on programming (75 items)
Topic: management of large software projects (63 items)
Topic: testing testing (13 items)
Topic: program statistics (27 items)
Topic: programmer productivity (57 items)
Topic: quality assurance (22 items)
Topic: science as measurement (36 items)
Topic: software management (28 items)
Topic: software science (9 items)
Topic: statistics
(12 items)

Updated barberCB 2/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.