Lecture Software process improvement: Lesson 43B - Dr. Ghulam Ahmad Farrukh

Strategic Application of Software 
Metrics
Lecture # 43­B

1


Strategic Application of Software 
Metrics

2


Strategic Application of Software 
Metrics
• Sensitive usage of metrics data
• Process improvement through defect 
analysis
• Validation of best practices

3


4


Use the concept of public and 
private data to drive your 
decisions on how to collect and 
analyze data

5


Private Data
• Understanding of who owns what data and 
when it is appropriate to share the data with 
others
– People prefer to keep defect data private
– How do we analyze defects to improve 
processes rather than blame people?
– Private data becomes public at well­defined 
handoffs or transitions
– Accountability
6


Inspections
• Inspections are such transitions
• If inspections are properly run, these defects 
are less embarrassing than defects that are 
found later
• Data is no longer private
• Focus of accountability shifts from 
individual to team
7


Project’s Private Data
• Time data
• Principle of “Information Hiding” is applied

• “Information Hiding” during project review

8


Public Data
• Metrics for public data
–
–
–
–

Calendar times
Defect rates
Project costs
Measure of functionality

9


Private and Public Data

10


Private and Public Data
Private

Private

Public

(to individual)

(to project team)

(to company)

Public
(to team members)

Defect rates (by 

Defect rates (beyond 

individual)

individual)

Defect rates (by 

NCSS/module
Estimated 
NCSS/module
No. of re­
inspections
Defects/modules 

module)

Defect rates (under 
development)

Number of 
compiles

Defect rates (by project)
NCSS (by product)
Effort (by project)
Calendar times
Defects/module 
(post­release)
Effort/defect (average)

(pre­release)
11


Apply your best management 
sensitivity to the interpretation 
and use of software metrics data

12


Functional Management ­ 1
• Don’t allow anyone in your organization to 
use metrics to measure individuals
• Set clear goals and get your staff to help 
define metrics for success

• Understand the data that your people take 
pride in reporting; don’t ever use it against 
them; don’t ever even hint that you might
13


Functional Management ­ 2
• Don’t emphasize one metric to the 
exclusion of others
• Support your people when their reports are 
backed by data useful to the organization

14


Project Management
• Don’t try to measure individuals
• Gain agreement with your team on the 
metrics that you will track, and define them 
in a project plan
• Provide regular feedback to the team about 
the data they help collect
• Know the strategic focus of your 
organization and emphasize metrics that 
15
support the strategy in your reports


Project Team
• Do your best to report accurate, timely data

• Help your managers to focus project data on 
improving your processes
• Don’t use metrics data to brag about how 
good you are or you will encourage others 
to use other data to show the opposite

16


Use software failure analysis to 
help drive process improvement 
decisions and to measure the 
impact of those decisions

17


Dissecting Software Defects
• Customer’s view of defects
• Development engineer’s view of defects
• Support engineer’s view of defects

18


Defect Cube

19

Defect Cube
Customer
View

e.g.
Design defect,
Wrong data
Definition,
Coding defect,
Missing logic

n
io ms
t
rip pto n
c
s m  o r
De  Sy fort ome
  ­  Ef ust
  ­    c
   

Analysis/Action/
  Disposition
  ­ Actual cause
  ­ Source
  ­ Type
  ­ Resolution

Development

Engineer
View

e.g.
Critical
Serious
Medium
Low
tus
a
t
S
 
  
      
use
a
c
 
d
ecte ility
p
s
­Su eatab
d
p
­ Re karoun
r
­Wo

Support
Engineer
View

e.g.
Hardware subsystem,
Operating sys. Component,
Application component,
Documentation
20


Key Questions to Learn from 
Mistakes
• What development or maintenance process 
failed?
• How often do such failures occur?
• How expensive is it to fix such failures?
• Which components are most subject to 
failures?
• What process change will detect or 
eliminate these failures?
21


Evaluate all software process 
changes in terms of measurable 
ROI

22

Cost/Benefit Analyses
• Analysis of savings from use of design 
inspections
• Analysis of savings from use of structure 
methodologies (analysis and design)
• Analysis of savings from use of complexity 
analysis
• Analysis of savings from use of 
certification process for a single project
23


Help your boss’s boss to better 
understand software process 
issues through tracking a 
balanced set of metrics

24


Hierarchy of Metrics Acceptance

25