Six Sigma and/For Software Engineering

CSN2501 RTSE Presentation
Six Sigma and/for Software Engineering

Anshuman Biswal
PT 2012 Batch, Reg. No.: CJB0412001
M. Sc. (Engg.) in Computer Science and Networking

Module Leader: N. D. Gangadhar
Module Name: Real-Time Software Engineering
Module Code : ESD2525

M. S. Ramaiah School of Advanced Studies 1

Marking

Head Maximum Score

Technical Content 10

Grasp and Understanding 10

Delivery – Technical and 10
General Aspects
Handling Questions 10

Total 40


Presentation Outline
• What is Six Sigma ?
• Evolution of Concepts behind Six Sigma
• Six Sigma at Motorola
• History of Six Sigma
• Statistics behind Six Sigma
• What is Six Sigma Performance?
• Relationship between Sigma Level and defect
• Six Sigma methodologies
• Define
• Measure
• Analyze
• Improve
• Control
• Conclusion
• References


What is Six Sigma

A Metric ?

A A
Philosophy What is Methodology
? Six Sigma ?

A
Management
System


Six Sigma- A Metric
A metric that encourages measurements of process performance.

Sigma is the Greek letter representing a statistical unit of measurement that
defines the standard deviation of a population. It measures the variability
or spread of the data.

6 sigma is also the measure of variability. It’s a name given to indicate how
much of the data falls within the customers requirements. The higher the
process sigma, the more of the process outputs, products and services,
meets customers requirements – or fewer the defects

The term sigma is often used as the scale for levels of “goodness” or
quality. Using this scale, “ Six Sigma” equates to 3.4 defects per million
opportunities (DPMO).


Six Sigma – A business methodology
A methodology that focuses on the following

Utilizing
Driving rapid
Understandin Aligning key rigorous data
and
g and business analysis to
sustainable
managing processes to minimize
improvement
customer achieve those variation in
to business
requirements requirements those
processes
processes


Six Sigma – A management system
Six Sigma is management system for executing business strategy. Six Sigma is a
solution to help organizations to:

Align their
Govern efforts to
business strategy Mobilize teams Accelerate
ensure
to critical to attack high improved business
improvements are
improvement impact projects results
sustained
efforts


Six Sigma – A Philosophy

Business Excellence
Inferential Statistics Customer Focus
Transition from
Basic statistical intuition towards
analysis inferential statistics in
decision making
Basic Charts and First time right at
Graphs source
Zero defect
Brainstorming Tools Extra ordinary
processes that deliver
Intuition or Gut predictable results
feeling


Evolution of concepts behind Six Sigma
FMEA was formally
introduced in 1940’s for
military usage by US
armed forces. Later it
was used for
aerospace/rocket
Ronal Fisher development. Example of
introduced Design this is Apollo space
In 1920’s , Walter A
of Experiment program. The primary
Carl Friedrich Shewart showed that push came during 1960’s
3 sigma, from the through a book in
Gauss (1777-1855) ,while developing means
mean is the point 1935. This was a
introduced the to put a man on the moon
where a process result of series of and return him back
concept of Normal
requires correction. studies that started safely. In 1970 Ford
Curve
This finally led to with study of introduced FMEA in
Control Charts variation in crop automotive industry
yield

Automotive Industry Action Group ( AIAG) published the most accepted document on
Measurement Systems Analysis (MSA). MSA is an essential step in 6 sigma methodologies
and is used to ensure reliability of data.

Six Sigma at Motorola

In the late 1970’s Dr. Mikel Harry, a senior staff engineer at Motorola’s
Government Electronics Group ( GEG),experimented problem solving through
statistical analysis. Using this approach, GEG’s product were being designed and
produced at a faster rate and at lower cost.

Subsequently Dr Harry began too formulate a method for applying six sigma
through out Motorola.



In 1987 when Bob Galvin was the chairman, Six Sigma was started as a
methodology in Motorola.

Bill Smith, an engineer and Dr. Mikel Harry together devised a 6 step
methodology with the focus on defect reduction and improvement in yield
through statistics.

The term Six Sigma was coined by Bill Smith, who is now called
the Father of Six Sigma.
 Terms such as Black belt and Green belt were coined by Mikel
Harry in relation to martial arts
Using this methodology the company saved $16 billion in 10
years


History of Six Sigma
1987 Motorola Strength in Manufacturing

1994 Allied Signal Linked to Financial Returns

General Electric Linked to Design and Service
1996
3M / Phillips Linked to Sales and Product
Commercialization

Sony, Seagate, Raytheon, Toshiba and many other
2000
companies

2006 Motorola Begins Lean Transformation
Uses Lean concepts in 6 Sigma
2008 Motorola methodologies and termed it as Lean
6 sigma

Statistics behind Six Sigma
pizza
santas pizza hut
21 17  If two pizza delivery outlets have
9 18 same average delivery time of 20
11 21 minutes, against the promised
12 22
29 23 delivery time of 30 minutes then
14 16 would you say that they are equally
28 24 good?
26 23
20 19
24 18
22 21
23 16
23 21
7 19
29 22

average 19.8666667 20

santas pizza pizza hut
21 17
9 18
 To comment on which one is
11 21 better would you like to consider
12 22 variation in delivery time? If yes
29 23
how would you like to measure
14 16
28 24 variation?
26 23
20 19
24 18
22 21
23 16
23 21
7 19
29 22
2.618614
standard deviation 7.42454103 7


santas pizza pizza hut
21 17
9 18
11 21  Can we find a single measure for
12 22 process performance that
29 23
14 16 incorporates the central tendency,
28 24 variation and specification limits?
26 23
20 19
24 18
22 21
23 16
23 21
7 19
29 22
average 19.8666667 20
standard deviation 7.42454103 2.6186147
Upper Specification Limit 30 30
sigma level 1.36484306 3.8188131
Probability 91.384881% 99.99330%


What is Six Sigma performance ?
 Your process is performing at sigma level of six if the difference
between the mean and the specification limit is six times the standard
deviation.

 To get a six sigma performance the variation should be as small as
possible so that we can fit six standard deviations between the mean
and the USL.


Sigma level vs. Defect
DPMO = [ D ( N * O ) ] * 1 Million Sigma DPMO
2 308770
where: 2.25 226716
– D = total number of defects 2.5 158687
counted in the sample – 2.75 105660
3 66811
a defect is defined as failure to meet 3.25 40060
a Critical Customer 3.5 22750
Requirement or CCR 3.75 12225
– N = number of units of product or 4 6210
4.25 2980
service 4.5 1350
– O = number of opportunities per 4.75 577
unit of product or service for 5 233
5.25 88
a customer defect to occur 5.5 32
– M = million 5.75 11
6 3.4


Six Sigma methodologies
DMAIC
Define – Measure – Analyze – Improve – Control
Structured and repeated process improvement methodology
Focuses on Defect reduction
Improves existing products and processes
DMADV
Define – Measure – Analyze – Define – Verify
Strict approach to design so as to exceed customer expectations
Focuses on preventing errors and defects
Develop new product/process or redesign existing
product/process


DMAIC and Problem Solving Flow

Define Measure Improve Control
Analyze
Opportunities Performance Performance Performance
Opportunity
(Establish (Characterize (Modify) (Ensure
(Decompose)
Requirements) Performance) Consistency)

Practical Quantitative
Quantifiable Practical
Problem Problem Analysis
Conclusion Conclusion
statement Statement

Key Questions to Ask

How do we
What is How are we What is What needs to
guarantee
important? doing? wrong? be done?
performance?


Define – The improvement Opportunity
Select the Define and Develop the
Map the
improvement scope the team
process
opportunity project charter

•Business leaders identify Six Sigma projects with Master Black
Belts supporting the project portfolio process.
• Black Belts, Green Belts and Six Sigma Teams with Sponsors &
Champions are other sources of projects in the portfolio.
• A continuous review of Scorecard Goals, dashboard metric
results, and audit results suggest possible projects/opportunities for
Improvement.


Map the
process

Translating Voice of the Customer (VOCs) to
Critical Customer Requirements (CCRs)
Often the voices of customers (VOC) are not clear and not in
technical language. Therefore VOC needs to be translated to the
Critical Customer Requirements (CCR) which can be translated
into the technical requirements known as Critical to Quality (CTQ),
and Critical to Process (CTP)

Tools: QFD/ House of Quality
Input Process Output Measures


Example of Input Process
Output measures CTQ CCR CUSTOMER ISSUES VOC
Defect 1> Defect back log Defect back log Higher
Reduction needs to be cleared by increased so more staff number of
June 2012. count were needed defects
2> Not more than 100 and also some defects found in XXX
VOC: Voice Of Customer defects in XXXX r3.0 were pushed to next R1.0
CCR: Critical Customer Requirement 3> Try to attain virtual release by
CTQ: Critical To Quality zero goal at the end of compromising with
the release of the certain features that
product. got pushed to next
release

BUSINESS
VOB ISSUES CBR CTP
Quality of To clear the Staff count can not Minimize
product back log increase which can the rework
needs to be more staff increase cost cost by
improved i.e. counts reducing
Defects needed and Identify defects in early the defects
Backlog more effort phase before build going by 80%
needs to be needs to be to BT
cleared put.
without Reduce number of defects
increasing in Some ,so it reduces the rework
staff count features had cost
to be pushed
to next
release.

VOB: Voice Of Business
CBR: Critical Business Requirement
CTP: Critical To Process


Map the
process

Team Charter is a business document that communicates leadership
expectations, expected business outcomes and personal relevancy
of the project in order to focus and motivate team.
Purpose of the Team Charter
• Communicate leadership expectations, expected business
outcomes and personal relevancy of the project in order to motivate
and focus team.
• Clarify the scope, resources and deliverables of improvement
project.


Project Title: XXX R3.0 Defect Reduction
Business Case Opportunity Statement
The number of defects ,raised by the Box Test team in the XXX R1.0 is In the past seven months ( April 2011 to November
on the higher side resulting in massive rework and need of more 2011), which was the XXX R1.0 phase had a total of 532
resource working to clear the backlog. This accounts to USD 618K of BT SR out of which UI SR were 169, which was
costs and out of which UI defects accounts to USD 196K. We need to approximately 80% greater than expected.
reduce the number of defects by at least 80% in XXX R3.0 which will Improvement Opportunity is targeted at the front end
help us to achieve virtual zero goal for future releases phase of the UI Dev ( Req., Design, Code and Unit test
phases ) to achieve defect reduction from 169 to 32.
Estimated Savings = USD 37K( Cost per defect taken as
USD 1162). So a total of USD 138K can be saved if the UI
defects is controlled to 32 numbers or less in future
releases.

Goal statement Project scope
Reduce the BT defects against UI development in XXX R3.0 at least This project will involve review of main reasons for UI
by 80% by November 2012. development bugs raised during Box test. It will not
examine phase after the box test like system tests and
also it will not examine the bugs raised in the stack and
middle ware development.

Project plan Team Selection
Phase Start End Remarks Sponsor: Mr. X
Define 4/30/2012 5/18/2012 Champion: Mr. Y
Measure 5/21/2012 7/27/2012 MBB: Mr Z
Analyze 7/30/ 2012 9/28/2012 MBB : Mr. A
Black Belt Mentor : Mr. B
Improve 10/1/2012 10/31/2012 Project Manager: Mr. C
Project Lead: Mr. D
Control 11/1/2012 11/30/2012
GB Candidate : Mr. E
Team Members: Mr. F


Map the
process

Process Mapping
Purpose
– Understand the relationships among inputs and outputs of a
process
– Identify non-value added activities so they can be eliminated
Types of Process Maps
– SIPOC
– Top-down chart
– Functional Deployment Chart
– Value Stream Mapping
– Spaghetti Diagram

Example of SIPOC- Development Process
SUPPLIER 1. INPUT OUTPUT CUSTOMERS
1.

PDM
Raw
Requirement
s Development
Process CAB file
Marketing Team Release
1. Notes Box Test Team

1. L3
Requirement
Development Design
Team Documents
SUB PROCESSES

Requirement Design
Coding Testing (BT) Release
Analysis Analysis

Start Boundary: End Boundary:
Requirement Gathering by PDM CAB file delivered to BT team

TOP DOWN CHART
Start Boundary: End Boundary:
Requirement Gathering by PDM CAB file delivered to BT team

Process: Software Development

Requirement Design
Coding Testing (BT) Release
Analysis Analysis

Design Write source code
Collect architecture Develop test cases
requirements from Write comments for
Perform impact each source code Release test results
field, customer,
competitor analysis as per standards
Develop test scripts
product, external Prepare design Achieve in clear and automation
demos doc case
Perform code
Prepare L3
Collect internal reviews
document Review test cases
and customer
defects Review and Perform Unit Testing Raise defects if any
Update L3 Req to fix in next build
Perform Tests
Review and Perform integration
Update Testing
Release L3 req.
requirement spec,
and Design doc Review test results
UB Spec Prepare build


Key Take Away
INPUTS PROCESS OUTPUTS
• Select the
• Strategic priorities • Team charter
improvement
• Scorecard development • Project Plan
opportunity
• Core process selections • Prepared team
• Define and scope the
• Improvement • Critical to customer
project
expectations requirements
• Develop the team
• Improvement project • Process Map (As-Is)
charter
team sponsor, • Risk and mitigation plan
• Map the process
champion, team leader • Quick win opportunities
• Identify quick wins


Measure – Measure The Process Performance
Create Collect Establish
Select Define MSA- MSA-
Measu and Baseline
Measur Measu Variabl Attribu
rement validat performan
es res e Data te data
plan e Data ce

Example of Input Process Output Indicators
Process Output
Input Indicators Indicators Indicators
Number of cust omer Number of FTR comment s on
requirement s Document reviews Reduce t he number of SR

Number of change requirement Availabilit y of resources Cust omer sat isfact ion
Lines of Code Types of int ernal defect s Reduce t he Rework effort s
Number of BT Sr's raised in
R1.0 Project Schedule R1.0 in each module
Planned Effort Act ual Effort s
Number of design review
comment s
Number of code review
comment s
Act ual size of each module
Number of int ernal Defect s


Cause and Effect Diagram


Cause and Effect Matrix

High priority indicators for analysis
a. Number of internal defects
b. Types of internal defects
c. Number of change requirements
d. Number of BT Sr’s


Measu and Baseline
plan e Data ce

Once the team knows what to measure, they need to further define
the measurement.
• This definition is called an operational definition.
( A operational definition is a precise description of
What ? The specific criteria used for measurement
How? The methodology to collect the data
How much? The amount of data to be collected
Who? Who has responsibility to collect data )
• The operation definition helps assure the data is:
– Collected and measured in a consistent way
– Representative of the process


Measu and Baseline
plan e Data ce

•Determining current process performance usually requires the collection of data.
When developing a measurement plan ensure that:
– The data collected is meaningful
– The data collected is valid
– All relevant data is collected concurrently
• Before data collection starts, classify the data into different types: continuous or
discrete. This is important because it will:
– Provide a choice of data display and analysis tools
– Dictate sample size calculation
– Provide performance or cause information
– Determine the appropriate control chart to use
– Determine the appropriate method for calculation of Sigma Level


Measurement Plan


Measu and Baseline
plan e Data ce

What is MSA?
The study of the extent to which systematic and random factors are affecting our
ability to correctly measure some phenomenon.
When MSA is done?
Before data collection.
 For variable data use Gage R and R test, Bias and Linearity Test and
Repeatability and reproducibility test
For attribute data use Kappa analysis


Measu and Baseline
plan e Data ce

P value is 0.095 which is greater than 0.05 hence we conclude that
data is normal

Measu and Baseline
plan e Data ce

What is Process Performance?
• Process performance is defined as the ability of a process to
produce outputs that meet engineering and/or customer
specifications.
• For continuous data we measure the process capability by
calculating Cp and Cpk
•For attributes data we calculate the process capability by DPMO
method


Process capability analysis


DPMO – For attribute data
Total number Defects- UI D 283
SR’s caught internally in
R1.0 in different phases(
code review, Unit Test,
Design)
Number of Units N 11
processed- Modules
Number of defect O 164
opportunities- Test cases

DPMO = 1M *[D/(N*O)] = 1000000*[283/(11*164)] = 156874

Current Sigma level = 2.51


Key Take Away
• Team charter •Select Measures • Input, Output, and
• Project Plan •Define Measures Process Measures
• Prepared team •Create Measurement Plan • Operational Definitions
• Critical to customer •Conduct MSA
Collect and Validate Data
• Data collection plan
requirements
•Establish Baseline • Capable measurement
• Process Map (As-Is)
Performance system
• Risk and mitigation plan
• Baseline Performance
• Quick win opportunities


Analyze – Analyze the Opportunity

Validate Root
Map the process Focus on Vital Few
Cause

•During the measurement phase, the team learned about the critical
x’s and collected measurements on these x’s.
• During the analysis phase, we need to understand the root cause(s)
of the variation affecting the critical x’s.
– Requires a more detailed level of investigation.
• A detailed process map helps the team identify all the x’s and use
this as a guide to get to root cause(s).


A detailed process map example



Validate Root
Cause

Determine critical inputs
– Cause and Effect Matrix
– 5 Why’s
– FMEA
• Stratify data and narrow the focus
– Pareto
– Sources of Variation
• Validate root cause statistically
– Comparative Methods
– Regression
– DOE

Pareto Chart


5 why



Validate Root
Cause

Comparative methods


Regression Analysis : Scatter Plot interpretation


Regression Analysis : Residual Plot


Regression Analysis : Residual Plot
Normality plot for the residuals. Points (residuals) falling along a
reasonably straight line indicates that residuals are normally
distributed.
• Residuals versus fitted values showing no pattern, funnelling out,
curvature, etc. indicating constant variance assumption is not
violated. A curvature in this plot indicates that the model is not
good and higher orders in the model may be needed. A funnelling
out indicates variation is not constant and needs a transformation
(square root, log, etc.)
• Histogram is skewed to the left. However, this is not uncommon
with a small number of observations. As long as the other three
charts look okay, the skewing is probably acceptable.
• Residuals versus order of the observation showing no pattern,
funnelling out, curvature, etc. No obvious violation of the
independence assumption.


Regression Analysis


Key Take Away
• Input, Output, and
Process Measures • Develop Detailed Process • Data analysis
• Operational Definitions Map • Process FMEA
• Determine critical inputs
• Data collection plan • Stratify the data
• Sources of Variation
• Capable measurement • Identify and Validate • Standardized Work
system Root Causes • Validated root causes
• Baseline Performance


Improve – Improve Performance

Identify and
Full scale
Select Best
implementation
Solution

Brain Storming
AFFINITY Diagram
Solution Mapping



Identify and
Full scale
Select Best
implementation
Solution

Brainstorming : Problem1 : Long Approval Time
Suggestions from Brainstorming Session:
Use informal meeting procedure than formal for review meeting
Not all test cases should be given for review to Test lead
Peer review should be encouraged
Define review frequency and time for final approval
Use review tool to monitor and track review comments status
Automatic assignment of test cases on completion using review tool
Independent reviews by test lead
Communicate review time to customer and hence include in project plan
Provide training on using review tool and to perform reviews
Improve review checklists and guidelines
Approve test cases in batch and not all at once
Communicate product critical review results to customer
Review tool should email review results on review completion
Improve Review tool interface for user friendly


Affinity Diagram: Problem1 : Long
Approval Time


Solution Mapping


Solution Selection Matrix



Identify and
Full scale
Select Best
implementation
Solution

 using the best solutions change the process and draw the new
process map
 Do a pilot solution plan
Run the project and collect data again.
Calculate the capability index and sigma level (DPMO) of the
current process. Nevertheless the current process should be better
than the previous process. Else do Analyze phase again and find for
another set of root causes and repeat the improve phase. Keep on
repeating this step until the new process is not improved .


Key Take Away

• Data analysis • Solutions
• Process FMEA • Identify and Select the • Process maps and
• Sources of Variation Best Solution documentation
• Standardized Work • Plan for Full-Scale • Cost/benefit analysis
• Validated root causes Implementation • Improvement impacts
and benefits


Control – Control Performance

Develop Evaluate
Transfer
integrated project
Ownership
control plan results

A Control Plan documents the data needed to accurately measure the
process on an ongoing basis and react to out of control processes.
• Based on the work performed during the improve phase, your organization
implemented your team’s recommendations and verified the impact they actually
made on the process you targeted.
• At this point, the objective is to sustain the gains (i.e., to make sure that the
changes you helped to make become an integral part of the way your organization
operates).
• This is done by making sure we have a thorough control plan, which should
address four different areas: error proof, measure and monitor, communicate, and
document



Develop Evaluate
Transfer
integrated project
Ownership



Develop Evaluate
Transfer
integrated project
Ownership

Checklist for Transition to Original Owner(s)
• Has the original owner been made aware of the changes and the needed controls
to maintain the process?
• How will the owner monitor these improvements over time?
• Is there a recommended audit plan for follow-up by the team / experts to assure
that the process is still being maintained?
• Have employees effected by the change been trained?
• Did we have a good change plan?
• Has the change been embraced by the owner and employees effected by the
process?


Key Take Away

•Develop a Detailed
•Solution process maps and •Process Control Plan
Control Plan
documentation •Updated Standardized
•Document final
•Cost/benefit analysis Work
implementation results
•Improvement impacts and •Project Final Report /
•Transfer ownership
benefits Closure
back to


Conclusion
• What is Six Sigma?
• History of Six Sigma?
• Methodologies of Six Sigma?
• DMAIC process with examples from the real case studies


References
[1] Pyzdek,T., The Six Sigma Hand Book, Revised and
Expanded,New Delhi:McGraw-Hill
[2] CIC2000: Six Sigma Green Belt Training, Motorola
University
[3] Benbow,W.D.,Kubiak,T.M.,The Certified Six Sigma
Blackbelt Handbook,2005,USA,ASQ Quality Press


Six Sigma and/For Software Engineering

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (14)

Similar a Six Sigma and/For Software Engineering

Similar a Six Sigma and/For Software Engineering (20)

Más de Anshuman Biswal

Más de Anshuman Biswal (13)

Último

Último (20)

Six Sigma and/For Software Engineering