1. Lecture 4 Software Metrics
Software Engineering
Lecture 4
Software Metrics

2. Why do we Measure?
To characterize
To evaluate
To predict
To improve

3. A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
• size?
• function?

4. Process Metrics
majority focus on quality achieved as a consequence of a repeatable or managed process
statistical SQA data
error categorization & analysis
defect removal efficiency
propagation from phase to phase
reuse data

5. Project Metrics Effort/time per SE task
Errors uncovered per review hour
Scheduled vs. actual milestone dates
Changes (number) and their characteristics
Distribution of effort on SE tasks

6. Product Metrics focus on the quality of deliverables
measures of analysis model
complexity of the design
internal algorithmic complexity
architectural complexity
data flow complexity
code measures (e.g., Halstead)
measures of process effectiveness
e.g., defect removal efficiency

7. Metrics Guidelines
Use common sense and organizational sensitivity when interpreting metrics data.
Provide regular feedback to the individuals and teams who have worked to collect measures and metrics.
Don’t use metrics to appraise individuals.
Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.
Never use metrics to threaten individuals or teams.
Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement.
Don’t obsess on a single metric to the exclusion of other important metrics.

8. Normalization for Metrics
Normalized data are used to evaluate the process
and the product (but never individual people)
size-oriented normalization
— the line of code approach
function-oriented normalization
— the function point approach

9. Typical Size-Oriented Metrics
errors per KLOC (thousand lines of code)
defects per KLOC
$ per LOC
page of documentation per KLOC
errors / person-month
LOC per person-month
$ / page of documentation

10. The LOC-based Estimation (p. 128)
Determining the major software functions
Develop an estimation table based on historical data
An Example: Estimated lines of code (total): 33,200 LOC Average productivity: 620 LOC / pm Labor rate: $8000 per month Cost per LOC: $13 (8000 / 620) Total estimated project cost: $431,000 (13 x 33200) Estimated effort: 54 pm (33200 / 620)

11. Typical Function-Oriented Metrics
errors per FP (thousand lines of code)
defects per FP
$ per FP
pages of documentation per FP
FP per person-month

12. Why Opt for FP Measures? independent of programming language
uses readily countable characteristics of the
"information domain" of the problem
does not "penalize" inventive implementations that
require fewer LOC than others
makes it easier to accommodate reuse and the
trend toward object-oriented approaches

13. Computing Function Points
Analyze information
domain of the
application
and develop counts
Weight each count by
assessing complexity
Assess influence of
global factors that affect
the application
Compute
function points
Establish
count
for input domain and
system interfaces
Assign level of complexity or
weight
to each count
Grade significance of external factors, F
such as reuse, concurrency, OS, ...
degree of influence: N = F i
complexity multiplier: C = ( x N)
function points = (count x weight) x C
where:

14. Analyzing the Information Domain
weighting factor
measurement parameter
count
simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
function points

15. Taking Complexity into Account
Factors are rated on a scale of 0 (not important)
to 5 (very important):
data communications
on-line update
distributed functions
complex processing
heavily used configuration
installation ease
transaction rate
operational ease
on-line data entry
multiple sites
end user efficiency
facilitate change

16. FP-based Estimation (p. 129)
Estimating the information domain values (input, output, inquiries, files, external interfaces), calculating the count-total
Calculating the complexity adjustment factor ( x S Fi)
FP estimated = count-total x complexity adjustment factor.
An Example: Estimated FP (total): 375 FP Average productivity: 6.5 FP / pm Labor rate: $8000 per month Cost per FP: $1230 (8000 / 6.5) Total estimated project cost: $461,000 (375 x 1230) Estimated effort: 58 pm (375 / 6.5)

17. Measuring Quality
Correctness — the degree to which a program operates according to specification
Maintainability—the degree to which a program is amenable to change
Integrity—the degree to which a program is impervious to outside attack
Usability—the degree to which a program is easy to use

18. Defect Removal Efficiency
DRE = (errors) / (errors + defects)
where
errors = problems found before release
defects = problems found after release

19. Summary
Measurement enables managers and practitioners to improve the software process; assist in the planning, tracking, and control of a software project; and assess the quality of the product (software) that is produced.
Both size and function oriented metrics are used throughout the industry.
Size oriented metrics use the LOC.
Function oriented metrics use the information domain and a subjective assessment of problem complexity.

20. References
Pressman, Chapter 4