| 
|
Topic: software metrics
topics >
computer science >
programming >
software maintenance
Topic:
experimental results on programming
Topic:
management of large software projects
Topic:
testing testing
Topic:
program statistics
Topic:
programmer productivity
Topic:
quality assurance
Topic:
science as measurement
Topic:
software management
Topic:
software science
Topic:
statistics
Summary
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: estimate by analogy
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: milestone metrics
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: function points
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: program size
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: complexity metric, ease of change
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: bug fixing
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: studies
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: performance model
Quote: compared software metrics using 1100 program features, e.g., efficiency, reliability, uniformity [»goodJB2_1976, OK]
Subtopic: problems with metrics
Quote: should build a computer system so that it has a good performance model [»dennPJ9_1980]
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
[»shepM11_1997]
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)