Software Process and Project Metrics

1
Software Process and Project Metrics

• Outline

• In the Software Metrics Domain
• product metrics
• project metrics
• process metrics

• Software Measurement
• size-oriented metrics
• function-oriented metrics

• Metrics for Software Quality

Chapter 4
2
Measure, Metrics, and Indicator

• Measure -- Provides a quantitative indication of
  the extent, amount, dimensions, capacity, or size
  of some product or process attribute.

• Metrics -- A quantitative measure of the degree
  to which a system, component, or process
  possesses a given attribute.

• Software Metrics -- refers to a broad range of
  measurements for computer software.

• Indicator -- a metric or combination of metrics
  that provide insight into the software process, a
  software project, or the product itself.

3
In the Process and Project Domains

• Process Indicator

• enable insight into the efficacy of an existing
  process

• to assess the current work status

• Goal -- to lead to long-term software process
  improvement

• Project Indicator

• assess the status of an ongoing project

• track potential risks

• uncover problem areas before they go critical

• evaluate the project teams ability to control
  the product quality

4
Process Metrics and Software Process Improvement
Project
Customer characteristics
Business conditions
Process
People
Technology
Development environment
5
Measurement

• What to measure?

• errors uncovered before release
• defects delivered to and reported by end users
• work products delivered
• human effort expended
• calendar time expended
• schedule conformance

• At what level of aggregation?

• By team?
• Individual?
• Project?

6
Privacy Issues

• Should they be used for personnel evaluation?

• Some issues?

• Privacy?
• Is total assignment being measured?
• Are the items being measured the same as for
  other individuals being measured?
• Are the conditions of measurement the same across
  individuals?

• However, they can be useful for individual
  improvement.

7
Use of Software Metrics

• Use common sense and organizational sensitivity.

• Provide regular feedback to individuals and teams.

• Dont use metrics to appraise individuals.

• Set clear goal and metrics.

• Never use metrics to threaten individuals or teams

• Problems ! negative. These data are merely an
  indicator for process improvement.

• Dont obsess on a single metric to the exclusion
  of other important metrics.

• Do not rely on metrics to solve your problems.

• Beware of people performing to metrics rather
  than product quality or safety.

8
Typical Causes of Product Defects
9
Example of Defect Analysis
missing
ambiguous
specification defects
wrong customer queried
customer gave wrong infor.
inadequate inquiries
used outdated information
changes
incorrect
10
Project Metrics

• Software Project Measures Are Tactical
• used by a project manager and a software team
• to adapt project work flow and technical
  activities

• The Intent of Project Metrics Is Twofold
• to minimize the development schedule to avoid
  delays and mitigate potential problems and risks
• to assess project quality on an ongoing basis and
  modify the technical approach to improvement
  quality

• Production Rates
• pages of documentation
• review hours
• function points
• delivered source lines
• errors uncovered during SW engineering

11
Software Metrics

• Direct measures
• Cost and effort applied (in SEing process)
• Lines of code(LOC) produced
• Execution speed
• CPU utilization
• Memory size
• Defects reported over certain period of time

• Indirect Measures
• Functionality, quality, complexity, efficiency,
  reliability, maintainability.

12
Software Measurement

• Size-Oriented Metrics

• are derived by normalizing quality and/or
  productivity measures by considering the size
  of the software that has been produced.

• lines of code often as normalization value.

project
LOC
effort
(000)
pp.doc
errors
defects
people
alpha 12,100 24 168
365 134 29 3
beta 27,200 62 440
1224 321 86 5
gamma 20,200 43 314
1050 256 64 6
. . . . .
. . . . .
. . . . .
.
13
Typical Size-Oriented Metrics

• Errors per KLOC

• Defects per KLOC

• Dollars per KLOC

• Pages of documentation per KLOC

• Errors per person month

• LOC per person month

• Dollars per page of documentation

14
Software Measurement

• Function-Oriented Metrics

• use functionality to measure

• derived from function point

• using an empirical relationship

• based on countable (direct) measure of SW
  information domain and assessments of software
  complexity

• Use of Function-Oriented Metrics

• Measuring scale of a project

• Normalizing other metrics, e.g., /FP, errors/FP

15
Function Point Calculation
Weighting Factor
measurement parameter count simple average comple
x
number of user inputs 3 4 6
number of user outputs 4 5 7
of user inquiries
3 4 6
number of files 7
10 15
of external interfaces 5 7 10
count_total
16
Function Point Calculation
17
Function-Oriented Metrics

• FP count_total 0.65 0.01 sum of Fi

Outcome errors per FP defects per FP per
FP page of documentation per FP FP per
person_month
18
Function Point Extensions

• Function Points emphasizes data dimension

• Transformations added to capture functional
  dimension

• Transitions added to capture control dimension

19
3-D Function Point Calculation
20
Reconciling Different Metrics
21
Metrics for Software Productivity

• LOC and FP Measures Are Often Used to Derive
  Productivity Metrics

• 5 Important Factors That Influence SW Productivity

• people factors

• problem factors

• process factors

• product factors

• resource factors

22
Measures of Software Quality

• Correctness

• is the degree to which the software performs its
  required function. the most common measure for
  correctness is defects per KLOC

• Maintainability

• the ease that a program can be corrected
• adapted if the environment changes
• enhanced if the customer desires changes in
  requirements
• based on the time-oriented measure mean time to
  change.

23
Measures of Software Quality (Contd)

• Integrity

• to measure a systems ability to withstand
  attacks (both accidental and intentional) on its
  security threat and security are defined

• integrity sum 1 - threat (1- security)

• Usability - an attempt to quantify user
  friendliness

• physical/intellectual requirement to learn
• time required to become moderately efficient
• the net increase in productivity
• user attitudes toward system

24
Defect Removal Efficiency

• A Quality Metric That Provides Benefit at Both
  the Project and Process Level
• DRE E / ( E D )
• E of errors found before delivery of the
  software to the end user
• D of defects found after delivery

• More generally,
• DREi Ei / ( Ei Ei1 )
• Ei of errors found during SE activity i

25
Summary View
26
Summary

• Metrics are a tool which can be used to improve
  the productivity and quality of the software
  system

• Process metrics takes a strategic view to the
  effectiveness of a software process

• Project metrics are tactical that focus on
  project work flow and technical approach

• Size-oriented metrics use the line of code as a
  normalizing factor

• Function-oriented metrics use function points

• Four quality metrics------correctness, integrity,
  maintainability, and usability were discussed

27
METRICS

• CLCS Metrics Philosophy
• Phase 1 Provide a mandatory, nearly automated,
  metrics foundation to track lines of code and
  errors.
• Phase 2 Provide additional high-return metrics
  with recognized value.
• Schedule metrics (milestones)
• Additional S/W Problem metrics (actuals, trends,
  prediction)
• Defect correction metrics
• Run-time analysis metrics (McCabe tools,
  automated, COTS)
• Phase 3 Be driven to additional metrics only by
  absolute need.

28
METRICS