Software Engineering

Software Metrics
 Objectives

• Introduce the necessity for software metrics

• Differentiate between process, project and product metrics

• Compare and contrast Lines-Of-Code (LOC) and Function

Point (FP) metrics

• Consider how quality is measured in Software Engineering

• Describe statistical process control for managing variation

between projects
Measurement & Metrics
Against:
Collecting metrics is too hard ... it’s too time
consuming ... it’s too political ... they can be used
against individuals ... it won’t prove anything
For:
In order to characterize, evaluate, predict and
improve the process and product a metric baseline
is essential.
 Terminology
• Measure: Quantitative indication of the extent, amount, dimension, or size
of some attribute of a product or process. A single data point
• Metrics: The degree to which a system, component, or process possesses a
given attribute. Relates several measures (e.g. average number of errors
found per person hour)
• Indicators: A combination of metrics that provides insight into the software
process, project or product
• Direct Metrics: Immediately measurable attributes (e.g. line of code,
execution speed, defects reported)
• Indirect Metrics: Aspects that are not immediately quantifiable (e.g.
functionality, quantity, reliability)
• Faults:
 Errors: Faults found by the practitioners during software development
 Defects: Faults found by the customers after release
 A Good Manager
process
Measures
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
• size?
• function?
 Process Metrics
• Focus on quality achieved as a consequence of a repeatable or
managed process. Strategic and Long Term.
• Statistical Software Process Improvement (SSPI).
• Error Categorization and Analysis:
• All errors and defects are categorized by origin
• The cost to correct each error and defect is recorded
• The number of errors and defects in each category is computed
• Data is analyzed to find categories that result in the highest cost
to the organization
• Plans are developed to modify the process
• Defect Removal Efficiency (DRE). Relationship between errors
(E) and defects (D). The ideal is a DRE of 1:
DRE = E / (E + D)
DRE  E /( E  D)
 Project Metrics
• Used by a project manager and software team to adapt project
work flow and technical activities. Tactical and Short Term.
• Purpose:
 Minimize the development schedule by making the necessary
adjustments to avoid delays and mitigate problems
 Assess product quality on an ongoing basis
• Metrics:
 Effort or time per SE task
 Errors uncovered per review hour
 Scheduled vs. actual milestone dates
 Number of changes and their characteristics
 Distribution of effort on SE tasks
 Product Metrics
• Focus on the quality of deliverables
• Product metrics are combined across several projects to
produce process metrics
• Metrics for the product:
• Measures of the Analysis Model
• Complexity of the Design Model
1. Internal algorithmic complexity
2. Architectural complexity
3. Data flow complexity
• Code metrics
 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

 Normalization for Metrics

• How does an organization combine metrics that come from different

individuals or projects?

• Depend on the size and complexity of the project

• Normalization: compensate for complexity aspects particular to a

product

• Normalization approaches:
 Size oriented (lines of code approach)

 Function oriented (function point approach)

 Typical Normalized Metrics
Project LOC FP Effort R(Cost Pp. Errors Defects People
(P/M) in $) doc
alpha 12100 189 24 168 365 134 29 3

beta 27200 388 62 440 1224 321 86 5

gamma 20200 631 43 314 1050 256 64 6

• Size-Oriented:

 errors per KLOC (thousand lines of code), defects per KLOC, R per LOC, page of documentation
per KLOC, errors / person-month, LOC per person-month, R / page of documentation

• Function-Oriented:

 errors per FP, defects per FP, R per FP, pages of documentation per FP, FP per person-month
 Why Opt for FP Measures?
• Independent of programming language. Some programming
languages are more compact, e.g. C++ vs. Assembler
• Use readily countable characteristics of the “information domain”
of the problem
• Does not “penalize” creative implementations that require fewer
LOC than others
• Makes it easier to accommodate reuse and object-oriented
approaches
• Original FP approach good for typical Information Systems
applications (interaction complexity)
• Variants (Extended FP and 3D FP) more suitable for real-time and
scientific software (algorithm and state transition complexity)
 Computing Function Points
Analyze information
domain of the
Establish count for input domain and system
application and
develop counts
interfaces

Weight each count by Assign level of complexity (simple, average,

assessing complexity complex) or weight to each count

Assess the influence of Grade significance of external factors, F_i,

global factors that
such as reuse, concurrency, OS, ...
affect the application

FP = SUM(count x weight) x C
Compute function where complexity multiplier C = (0.65+0.01
points x N) degree of influence N = SUM(F_i)
 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
 Taking Complexity into Account
• Complexity Adjustment Values (F_i) are rated on a scale of 0 (not important) to
5 (very important):
• Does the system require reliable backup and recovery?
• Are data communications required?
• Are there distributed processing functions?
• Is performance critical?
• System to be run in an existing, heavily utilized environment?
• Does the system require on-line data entry?
• On-line entry requires input over multiple screens or operations?
• Are the master files updated on-line?
• Are the inputs, outputs, files, or inquiries complex?
• Is the internal processing complex?
• Is the code designed to be reusable?
• Are conversion and instillation included in the design?
• Multiple installations in different organizations?
• Is the application designed to facilitate change and ease-of-use?
 Exercise: Function Points
• Compute the function point value for a project with the
following information domain characteristics:
• Number of user inputs: 32
• Number of user outputs: 60
• Number of user enquiries: 24
• Number of files: 8
• Number of external interfaces: 2
• Assume that weights are average and external complexity adjustment
values are not important.
• Answer:
(32  4  60  5  24  4  8  10  2  7)  0.65  401.7
 Example: SafeHome Functionality
Test Sensor
Password
Zone Setting Sensors
Zone Inquiry

User Sensor Inquiry SafeHome Messages

System User
Sensor Status
Panic Button
(De)activate (De)activate

Monitor
Password, Alarm Alert and
Sensors, etc. Response
System
System
Config Data
 Example: SafeHome FP Calc
weighting factor
measurement parameter count simple avg. complex
number of user inputs 3 X 3 4 6 = 9
number of user outputs 2 X 4 5 7 = 8
number of user inquiries 2 X 3 4 6 = 6
number of files 1 X 7 10 15 = 7

number of ext.interfaces 4 X 5 7 10 = 22
count-total 52
complexity multiplier[0.65  0.01   F ]  [0.65  0.46]
i 1.11
function points 58
 Exercise: Function Points
• Compute the function point total for your project. Hint: The
complexity adjustment values should be low(Fi  10 )
• Some appropriate complexity factors are (each scores 0-5):
1. Is performance critical?
2. Does the system require on-line data entry?
3. On-line entry requires input over multiple screens or operations?
4. Are the inputs, outputs, files, or inquiries complex?
5. Is the internal processing complex?
6. Is the code designed to be reusable?
7. Is the application designed to facilitate change and ease-of-use?