It has been suggested that Programming Complexity be merged into this article or section. (Discuss)

This article or section reads like an editorial or opinion piece and may require cleanup. Please improve this article by rewriting this article or section in an encyclopedic style to make it neutral in tone. See Wikipedia:How to edit a page and Category:Wikipedia help for help, or this article's talk page. (documentation, talk)(May 2008)

A software metric is a measure of some property of a piece of software or its specifications.

Since quantitative methods have proved so powerful in the other sciences, computer science practitioners and theoreticians have worked hard to bring similar approaches to software development. Tom DeMarco stated, “You can’t control what you can't measure.”^[1]

Modern software development practitioners are likely to point out that naive and simplistic measurements can cause more harm than good.^[2]

Contents 1 Common software measurements 2 Limitations 3 See also 4 References 5 External links

[edit] Common software measurements

Common software measurements include:

• Code coverage
• Cohesion
• Comment density^[3]
• Coupling
• Cyclomatic complexity
• Function point analysis
• Instruction path length
• program load time
• Number of classes and interfaces
• Number of lines of customer requirements.
• program size
• Robert Cecil Martin’s software package metrics
• Bugs per line of code
• Source lines of code
• execution time

The definition of many of these measurements is often imprecise, and consequently it is often unclear how tools for computing them arrive at a particular result ^[4].

[edit] Limitations

It is very difficult to satisfactorily define or measure "how much" software there is in a program, especially when making such a prediction prior to the detail design. The practical utility of software measurements has thus been limited to narrow domains where they include:

• Schedule
• Size/Complexity
• Cost
• Quality

Too much emphasis on any one of these aspects of performance is likely to create an imbalance in the team’s motivations, leading to a dysfunctional project.

The Balanced scorecard is a one tool for managing a suite of measurements that address multiple performance perspectives.

[edit] See also

• Software development effort estimation
• Software engineering
• Computer science
• Software quality
• Software package metrics
• Goal Question-Metric
• Ohloh: quantitative analysis of hundreds of open source projects
• List of code quality management dashboards
• Software crisis

[edit] References

1. ^ DeMarco, Tom. Controlling Software Projects: Management, Measurement and Estimation. ISBN 0-13-171711-1. 
2. ^ Dr. Cem Kaner, Software Engineer Metrics: What do they measure and how do we know?
3. ^ http://mip-site.lsec.dnd.ca/qsd_current_version/eng_support/di/metrics.htm Descriptive Information (DI) Metric thresholds
4. ^ Rüdiger Lincke, Jonas Lundberg, Welf Löwe: Comparing software metrics tools. ISSTA 2008: 131-142

[edit] External links

• International Function Point Users Group
• What is FPA at Nesma website
• Estimating With Use Case Points by Mike Cohn. Describes the process to measure the size of an application modeled with UML, using use cases.
• OO & Agile Metrics Resources - includes workshop material on gaming metrics to improve their design
• Further defines the term Software Metrics with examples.
• Software Engineering Metrics: What do they measure and how do we know - An intellectually rigorous treatment of software engineering metrics