Definition:
Metric is a unit of measure.
(IEEE) A quantitative measure of the degree to which a
system, component, or process possesses a given attribute
Why
measure?
1. to get better understanding of the attributes of
models
2. to gain insight into the design and construction of
the software
3. focus on specific attributes of software engineering
work products resulting from analysis, design, coding, and testing
4. assess the stability of a software product
5. determine the quality of the current product or
process
6. estimate the cost & schedule of future projects
7. evaluate the productivity impacts of new tools and
techniques
8. establish productivity trends over time
9. forecast future staffing needs
10. anticipate and reduce future maintenance needs
Categories
of metrics
1.
Projects
·
Productivity and schedule related
2.
Products
·
Assesses the state of the project
·
Track potential risks
·
Uncover problem areas
·
Adjust workflow or tasks
·
Evaluate teams ability to control quality
3.
Processes
·
Activities related to production of software
·
Lead to long term process improvement
Metrics
definitions and formulae
Metric Name
|
Definition
|
Unit of Measure
|
Formula
|
||||
Project
Related Metrics
|
|||||||
Effort Variance
|
Effort Variance is used to keep
the track of the variation in effort for an activity with respect to planned
effort
|
(%) of Hrs
|
(Actual
Effort – Planned Effort) / (Planned Effort ) X 100
|
||||
Schedule (Delivery) Variance
|
Schedule Variance is used to keep
track of variation in number of days required for each deliverable in the
project with respect to planned days (%age)
|
(%) No of Days
|
(Actual
End Date – Planned End Date) / (Planned End Date – Planned Start Date +1) X
100
OR
(Actual
Duration – Planned Duration)/Planned Duration X 100
|
||||
Milestone Variance
|
Milestone Variance is used to keep
track of number of days required for difference milestones in the project in
%age
|
(%) No of days
|
Actual
End Date – Revised End Date)/
(Revised
End Date – Planned Start Date) X 100
|
||||
Productivity
|
Productivity is the effort that we
are putting in developing one unit of size which helps in planning activity
|
(%) No of Hours
|
Size / Effort
(Size
is defined here as Budgeted Hours)
|
||||
Process
Related Metrics
|
|||||||
Testing Efficiency
|
Testing Efficiency is used to
track efficiency in terms of number of test steps authored per one unit
(hr) of testing effort
|
Test Steps authored + Executed
|
Test
Steps Authored + Executed / Testing Time
(Testing
time is considered as QA’s time which include test case authoring, execution,
automating scripts and automation testing)
|
||||
Review Efficiency
|
Review Efficiency is used to keep
track of efficiency in terms of number of defects per one unit (hr) of
testing effort
|
Defects / hr
|
(Actions
+ Defects) / Review Time
|
||||
Testing Effectiveness
|
Testing Effectiveness is used to
keep track of defects that are leaked to subsequent phases with respect to
defects injected in that phase
|
Defects Rate
|
No
of Defects / (No of Defects detected + leaked to later phases) X 100
|
||||
Review Effectiveness
|
Review Effectiveness is used to
keep track of defects that are leaked to subsequent phases with respect to
defects injected in that phase
|
Defects Rate
|
No
of defects detected / (No of defects detected + leaked to later phases) x 100
|
||||
Product
Related Metrics
|
|||||||
Defect Density
|
Defect Density is used to keep the
track the product quality at the end of each phase in the project
|
(%) No of Defects
|
No
of Defects / Size
(Size
is defined here as Budgeted Hours)
|
||||
Defect Removal Effectiveness (DRE)
|
DRE is used to track the % age of
defects effectively removed during a phase
|
Defects
|
No
of Defects identified in the current SDLC stage / workstream / (No of defects
injected in the current SDLC stage / workstream phase + No of defects leaked
in to the current SDLC stage / workstream phase from previous phase) X 100
|
||||
Cost of Quality (COQ)
|
COQ is used to track effort spent
in reviews, testing, rework, defects prevention, training and audits with
respect to total project effort
|
(%) Hrs
|
Review
Effort + Testing Effort + Rework Effort
|
||||
Cost of Poor Quality (COPQ)
|
COPQ is used to track the rework
for the defects during review and testing in a project with respect to total
project effort
|
(%) Hrs
|
Rework
Effort
|
||||
Cost of Poor Quality Index (CPQI)
|
CPQI is used to track the amount
of rework effort spent against Customer Budgeted hours
|
(%) Hrs
|
Rework
Effort / Budgeted Hours X 100
|
||||