Total Quality Management For Software Development

1
Total Quality Management For Software Development

• CS2335
• Fall 2001

2
Agenda

• Lab 8 Demo
• Lab 9
• This is Lab 10!
• TQM

3
Total Quality Management
TQM
Statistical Process Control
Continuous Process Improvement
Customer Satisfaction 100 Compliance with
Expectations
4
So What?

• We build software using processes
• Our processes are not always perfect
• How can we improve while avoiding the Dilbert
  syndrome?
• Remember, we cant test quality into our
  software, we design it in!

5
Shewart (PDCA) Cycle
Try improvement Small test
Whats the next problem?
What can we do?
Adopt new process
Gather data And analyze
6
Dilbert Cycle
Act
Make wild guess At what is wrong
Adopt new Unproven process
7
Seven Basic Tools

• Quantitative Techniques to support PDCA cycle
• Control (Run) Charts
• Pareto Charts
• Ishikawa Diagrams
• Histograms, Scatter Charts, Flow Charts,
  Checksheets

8
Pareto Analysis

• The Pareto Principle (80/20 rule)
• Put our effort on most significant problem
• Collect data using checksheets

9
Pareto Example
100
96
82
N123.5
67
Percent of Total
Time Worked (Hours)
34
42.2
40.8
18.5
15
7
icongen
hud_ipc
huddsply
hud_proc
hud_boot
10
Lab 10, Part I

• Take your defect data
• Group by defect category (next slide)
• Draw Pareto Chart of your defects

11
Error Categories
10 Documentation problem 20 Syntax 30 Build 40
Assignment 50 Interface 60 Error Handling 70
Data 80 Function 90 System 100 Environment
12
Bobs Error Chart
Number of Errors
13
Ishikawa Diagrams

• AKA Cause-Effect, fishbone Diagram
• Root Cause Analysis
• Dont treat symptoms!
• Uses diagram plus brainstorming
• 4 Ms Manpower, Machines, Methods,Materials
• 4 Ps Policies, Procedures, People, Plant

14
Basic Syntax
Process
Environment
Symptom/ Problem
People
Equipment
15
Example Ishikawa
Measurement
People
Poor change tracking
Inexperienced manager
Inexperienced developers
Icongen used 34 of all effort
Poor IDE
Hard to modify
Bad design
Process
Equipment
16
Lab 10 Part II

• Now select your most critical category from the
  Pareto Analysis
• Formulate a problem symptom
• Draw Ishikawa Diagram
• Select appropriate categories (M,E,P)
• Brainstorm causes (try to go at least 2 deep on a
  few)

17
Bobs Ishikawa
18
Lab 10, Part III

• Now analyze the Ishikawa diagram to pick the most
  likely cause
• Formulate a short plan (PDCA) to address
  correcting the cause
• What metrics (checksheet) would you select to
  determine whether this solution worked?

19
Control Charts

• To improve a process, it must be in control
• In control repeatable
• How do we know?
• Collect data, draw control chart.
• Shows changes over time

20
Control Chart
Upper Control Limit (UCL)
Specification Limit (Optional)
Range of Values
Average
Lower Control Limit (LCL)
21
Control Chart Values
Spec Limits are provided (normally as goals or
standards)
Center line sum(values)/N where N is sample size
UCL Avg 3sqrt(Avg) LCL Avg - 3 sqrt(Avg)
(if impossible value then zero)
Process in control when all points between
UCL and LCL. May still be poor and outside spec,
just means that it is predictable.
22
Control Chart Data
MODULE
DEFECTS/KLOC
23
Sample Control Chart
50
X
UCL
X
Defects per KLOC
X
LCL
X
SPEC
0
Avg(15104025)/425 UCL253(SQRT(25)) LCL25-
3(SQRT(25))
24
Summary

• Processes need to be continually improved
• Dont follow the Dilbert Model
• The people who do the work usually know best how
  to improve it
• Collect data to support decisions
• Use quantitative methods when possible to support
  decisions
• Plan the flight, Fly the plan

25
NEXT TIME
Last Class!!!! Review for Final Pulling entire
class together Feedback for course improvement