1
Chapter 4Chapter 4Software Process and Project Software Process and Project
MetricsMetrics
2
Measurement & Measurement & MetricsMetrics... collecting metrics is too hard ... ... collecting metrics is too hard ...
it's too time-consuming ... it's too it's too time-consuming ... it's too political ... it won't prove anything ...political ... it won't prove anything ...
Anything that you need to Anything that you need to quantify can be measured in quantify can be measured in some way that is superior to some way that is superior to not measuring it at all ..not measuring it at all ..
Tom GilbTom Gilb
3
Why do we Why do we Measure?Measure?
To characterizeTo characterize To evaluateTo evaluate To predictTo predict To improveTo improve
4
A Good Manager A Good Manager MeasuresMeasures
measurementmeasurement
What do weWhat do weuse as ause as abasis?basis? • • size?size? • • function?function?
project metricsproject metrics
process metricsprocess metricsprocessprocess
productproduct
product metricsproduct metrics
5
Process MetricsProcess Metrics
majority focus on quality achieved majority focus on quality achieved as a consequence of a repeatable as a consequence of a repeatable or managed processor managed process
statistical SQA datastatistical SQA data error categorization & analysiserror categorization & analysis
defect removal efficiencydefect removal efficiency propagation from phase to phasepropagation from phase to phase
reuse datareuse data
6
Project MetricsProject Metrics
Effort/time per SE taskEffort/time per SE task Errors uncovered per review hourErrors uncovered per review hour Scheduled vs. actual milestone datesScheduled vs. actual milestone dates Changes (number) and their Changes (number) and their
characteristicscharacteristics Distribution of effort on SE tasksDistribution of effort on SE tasks
7
Product MetricsProduct Metrics focus on the quality of focus on the quality of
deliverablesdeliverables measures of analysis modelmeasures of analysis model complexity of the designcomplexity of the design
internal algorithmic complexityinternal algorithmic complexity architectural complexityarchitectural complexitydata flow complexitydata flow complexity
code measures (e.g., Halstead)code measures (e.g., Halstead) measures of process effectivenessmeasures of process effectiveness
e.g., defect removal efficiencye.g., defect removal efficiency
8
Metrics Metrics GuidelinesGuidelines Use common sense and organizational sensitivity Use common sense and organizational sensitivity
when interpreting metrics data.when interpreting metrics data. Provide regular feedback to the individuals and teams Provide regular feedback to the individuals and teams
who have worked to collect measures and metrics.who have worked to collect measures and metrics. Don’t use metrics to appraise individuals.Don’t use metrics to appraise individuals. Work with practitioners and teams to set clear goals Work with practitioners and teams to set clear goals
and metrics that will be used to achieve them.and metrics that will be used to achieve them. Never use metrics to threaten individuals or teams.Never use metrics to threaten individuals or teams. Metrics data that indicate a problem area should not Metrics data that indicate a problem area should not
be considered “negative.” These data are merely an be considered “negative.” These data are merely an indicator for process improvement.indicator for process improvement.
Don’t obsess on a single metric to the exclusion of Don’t obsess on a single metric to the exclusion of other important metrics.other important metrics.
9
Normalization for Normalization for MetricsMetricsNormalized 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
10
Typical Size-Oriented Typical Size-Oriented MetricsMetrics
errors per KLOC (thousand lines of code)errors per KLOC (thousand lines of code) defects per KLOCdefects per KLOC $ per LOC$ per LOC page of documentation per KLOCpage of documentation per KLOC errors / person-montherrors / person-month LOC per person-monthLOC per person-month $ / page of documentation$ / page of documentation
11
Typical Function-Oriented Typical Function-Oriented MetricsMetrics
errors per FP (thousand lines of code)errors per FP (thousand lines of code) defects per FPdefects per FP $ per FP$ per FP pages of documentation per FPpages of documentation per FP FP per person-monthFP per person-month
12
Why Opt for FP Why Opt for FP Measures?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 Computing Function PointsPointsAnalyze 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 = Fi
complexity multiplier: C = (0.65 + 0.01 x N)
function points = (count x weight) x C
where:
i
14
Analyzing the Information Analyzing the Information DomainDomain
complexity multiplier
function points
number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces
measurement parameter
3 4 3 7 5
countweighting factor
simple avg. complex
4 5 4 10 7
6 7 6 15 10
= = = = =
count-total
X X X X X
15
Taking Complexity into Taking Complexity into AccountAccount
Factors are rated on a scale of 0 (not important) to 5 (very important):
data communications distributed functions heavily used configuration transaction rate on-line data entry end user efficiency
on-line update complex processing installation ease operational ease multiple sites facilitate change
16
Measuring Measuring QualityQuality
Correctness — the degree to which a Correctness — the degree to which a program operates according to program operates according to specificationspecification
Maintainability—the degree to which a Maintainability—the degree to which a program is amenable to changeprogram is amenable to change
Integrity—the degree to which a Integrity—the degree to which a program is impervious to outside program is impervious to outside attackattack
Usability—the degree to which a Usability—the degree to which a program is easy to useprogram is easy to use
17
Defect Removal Defect Removal EfficiencyEfficiency
DRE = (errors) / (errors + defects)
where
errors = problems found before release
defects = problems found after release
Top Related