Six Sigma and Software Process Improvement

1
Six Sigma and Software Process Improvement

• by
• Nikhil Bhardwaj
• Instructor Dr. Frank Liu
• University of Missouri Rolla

2
Why use any Metric?
Key Word Measure it Quantitatively But
what to measure ? How to measure ? How will it
benefit ? One Way Six Sigma

• Measurements
• If we cant measure a process, we cannot manage
  it much less systematically improve it.
• If we do not actively manage a process, its
  performance is a matter of chance.
• Goals must be stated in terms of measurable
  quantities if we hope to achieve them.

3
What is Six Sigma(6?) ?
Originated from a CEO driven challenge in
1980s. Objective was to achieve a ten-fold
reduction in product failure in a span of 5
years. In mid 1990s Motorola gave out the
metric they have used for Quality
improvement. Motorola quality improvement
framework The Six Sigma.

• Three different but related Definitions
• Business driven multifaceted approach to Process
  improvement, Cost reduction and thereby more
  Profitability.
• Six Sigma means a quality level that insures less
  than 3.4 defects per million opportunities (DPMO)
  or product is 99.9997 error free.
• The application of DMAIC for continuous
  improvement in conjunction with a standard
  Statistical toolkit for analysis and the
  objective of producing Six Sigma processes.

4
Basic Approach - DMAIC

• Define Basic lining and benchmarking the
  process. Goals and sub-goals.
• Measurement Defects, errors, effort,
  productivity and benefits at different phases.
  Different statistical models.
• Analyze Failure mode, Decision analysis, risk
  analysis. Cause and Effect diagrams.
• Improve Experimentation and modeling to confirm
  the hypothesis.
• Control When the desired performance is
  achieved, sustain it.

5
Everything is a Process (Process Model)
Output Y can be controlled not directly but by
the Input X. Aim is to reduce the Error for
which the Statistical models are used.

• Each process at any stage can be described as a
  function of Inputs and Errors
• Output(Y) F(Input) Error

Input (X)
Output (Y)
Process
Error
6
Defect curve during the process.

• It has been inferred from models and data that
• the number of defects during the development
  process follow a normal distribution curve.
• For data that follows a normal distribution
  99.99999975 of data is within 6?.
• This forms the basis for statistical process
  control.

7
Goals of Six Sigma
Hmmmm.. Sounds good But how do we achieve
all this ? Are there ways to do all
this? Remember Statistical tools and metrics I
have been bragging about

• Reduce released Defects
• Find and Fix Defects close to Origin
• Prediction of Defect detection and Fixation rate
• Compare implementations within the Company
• Compare implementations across Companies

8
Goal 1 Reduce Released Defects

• Total Containment Effectiveness index (TCE)
• Because Key is customer satisfaction
• TCE Defects( pre release) Errors
  100
• Defects( pre release released ) Errors
• Errors accrue to the present stage or phase.
• Defects are potential errors that escape to
  another state from the one they were inserted.
• The Higher this index is the better it is as
• It represents that not many defects have been
  added between the pre-release and release of the
  Software product.

9
Goal 2 Find and Fix defects closer to origin

• The earlier the Defects are detected the easier
  it is to rectify them (less cost, less rework,
  less effort).
• Phase Containment Effectiveness Index (PCE).
  FAGANs Metrics
• PCE (phase) Errors (phase) 100
  
• Errors (phase) Defects (phase)
• It is a measure error detection.
• What percent of the total errors are detected at
  a particular phase of Software Development.

10
Goal 2 Find and Fix defects closer to origin

• A measure for the ability of each phase to detect
  the Defects that are passed to it by other
  phases.
• Defect Containment Effectiveness (DCE)
• DCE (phase) Defects (phase) 100
• Defects (phase) Defects passed
  in downstream phase
• What of the total Defects are accruing to the
  current phase.

11
Goal 3 Defect Detection rate and Defect removal
rate (Prediction)
Thus there is a need to detect the defects as
they are introduced. Remember the earlier the
better

• Why is prediction important
• There is a lag between actual insertion and
  detection of defects.

12
Goal 3 Defect Detection rate and Defect removal
rate (Prediction)

• Find out the number of defects that can accrue
  using the past data produced for similar projects
  (Similar in LOC, Effort, Schedule, Resource
  Requirement, Function Points)

13
Goal 3 Defect Detection rate and Defect removal
rate (Prediction)

• Better estimates can be made if rather than the
  total defects, we classify them according to
  insertion at different phases.

14
Goal 3 Defect detection and removal (Prediction)
Significantly higher actual Defect count provides
for an early alarm. Significantly lesser
actual Defect count can be an alarm for probable
leaks in Defect detection.

• Prepare predictive scorecards (Prediction Vs
  Actual)

15
Goal 3 Defect detection and removal (Estimating
Cost)
16
Goal 4 Compare implementations within the
company

• Comparisons can be made of the Six Sigma
  processes within different processes being
  undertaken in a Company.
• Processes can be selected on basis of Lines of
  Code or Function Points.

17
Goal 5 Compare implementations across companies

• Implementations can be compared with different
  companies which do not use the same metric.
• Some seminal work in the field of Size normalized
  metric and establishing Cross-Company benchmark
  by Capers Jones.
• DPMO- One standard for Size-Normalization.
• OFD- Opportunity for Defects.

18
References
Questions ? Thank You

• Six Sigma Software Metrics, Part 1 by David. L.
  Hallowell
• Six Sigma Software Metrics, Part 2 by David. L.
  Hallowell
• Six Sigma Software Metrics, Part 3 by David. L.
  Hallowell
• Six Sigma Software Metrics, Part 4 by David. L.
  Hallowell
• Software Six Sigma (www.Softwaresixsigma.com)
• Software process improvement(www.software.org/dcsp
  in/artifacts/Mar2004.pdf)