Seven QC Tools for Process

Quality Improvement
Best Practices
of Software
Engineering
Objectives: Best Practices of Software
Engineering

Explore the symptoms and root causes of

software development problems
Explain best practices for software
development
Look at how best practices address the
root causes of software development
problems
Software Development Situation
Analysis

World economies Applications expanding in

increasingly software size, complexity, &
dependent distribution

Business demands increased Not enough qualified

productivity & quality in less people
time
Software Development is a
Job for Teams
Challenges
Performance
• Larger teams Engineer

• Specialization Analyst

• Distribution Project
Manager
• Rapid technology Developer
change Tester

Release
Engineer
How Are We Doing?

Performance

• Many Successes
Engineer
Analyst

• Too Many Failures

Project
Manager
Developer

Tester

Release
Engineer
Symptoms of Software
Development Problems

 Inaccurate understanding of end-user needs

 Inability to deal with changing requirements
 Modules that don’t fit together
 Software that’s hard to maintain or extend
 Late discovery of serious project flaws
 Poor software quality
 Unacceptable software performance
 Team members in each other’s way, unable to
reconstruct who changed what, when, where, why
 An untrustworthy build-and-release process
Treating Symptoms Does Not
Solve the Problem
Root Causes
Symptoms
insufficient requirements
end-user needs
ambiguous communications
changing
brittle architectures
requirements
overwhelming
modules don’t fit
complexity
hard to maintain
undetected inconsistencies
late discovery
poor testing
poor quality
subjective
poor performance assessment
colliding waterfall
developers development
build-and-release uncontrolled change
Diagnose insufficient automation
Root Causes of Software
Development Problems
 Insufficient requirements management
 Ambiguous and imprecise communications
 Brittle architectures
 Overwhelming complexity
 Undetected inconsistencies among requirements,
designs, and implementations
 Insufficient testing
 Subjective project status assessment
 Delayed risk reduction due to waterfall development
 Uncontrolled change propagation
 Insufficient automation
Best Practices Address Root
Causes

Root Causes Best Practices

 Insufficient requirements  Develop iteratively

 Ambiguous communications  Manage requirements
 Brittle architectures  Use component architectures
 Overwhelming complexity  Model the software visually
 Subjective assessment  Verify quality
 Undetected inconsistencies  Control changes
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
 Addressing Root Causes
Eliminates the Symptoms
Symptoms Root Causes Best Practices
end-user needs insufficient requirements develop iteratively
changing ambiguous manage requirements
requirements communications use component
modules don’t fit brittle architectures architectures
hard to maintain overwhelming complexity model the software
late discovery undetected visually

poor quality inconsistencies verify quality

poor performance poor testing control changes

colliding developers subjective assessment

build-and-release waterfall development

uncontrolled change
insufficient automation
Best Practices of Software
Engineering

Develop Iteratively

Use
Manage Model Verify
Component Visually
Requirements Architectures Quality

Control Changes
 Best Practices Enable High-
Performance Teams
Results
Performance
• More Successful Engineer
projects Analyst

Project
Manager
Developer
Develop Iteratively

Tester
Use Model
Manage Component Visually Verify
Requirements Quality
Architectures
Release
Engineer
Control Changes
Practice 1: Develop
Software Iteratively

Develop Iteratively

Use
Manage Model Verify
Component Visually
Requirements Architectures Quality

Control Changes
Practice 1: Develop
Software Iteratively

An initial design will likely be flawed with

respect to its key requirements
Late-phase discovery of design defects results in
costly over-runs and/or project cancellation

$$$
The time and money spent implementing a
faulty design are not recoverable
Waterfall Development
Requirements
Analysis

Design

Code & Unit

Testing

Subsystem
Testing

System Testing

T I M E
Waterfall Development Delays
Reduction of Risk

Requirements
R Analysis
I
Design
S
K Code & Unit
Testing

Subsystem
Testing

System Testing

T I M E
Apply the Waterfall Iteratively to
System Increments

Iteration 1 Iteration 2 Iteration 3

R R R
D D D
C C C
T T T

T I M E

 Earliest iterations address greatest risks

 Each iteration produces an executable release, an
additional increment of the system
 Each iteration includes integration and test
Iterative Development
Accelerates Risk Reduction

K Iterative Waterfall

Iteration Iteration Iteration Iteration Iteration Iteration Iteration

T I M E
Iterative Development
Characteristics

Critical risks are resolved before making large

investments
Initial iterations enable early user feedback
Testing and integration are continuous
Objective milestones provide short-term focus
Progress is measured by assessing
implementations
Partial implementations can be deployed
Apply Best Practices Throughout
the Life Cycle
Phases
Process Workflows Inception Elaboration Construction Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
Problems Addressed by Iterative Development

Root Causes Solutions

 Insufficient requirements
 Ambiguous
communications
 Brittle architectures
 Overwhelming
complexity
 Subjective assessment
 Undetected
inconsistencies
 Poor testing
 Waterfall development
 Uncontrolled change
 Insufficient automation
Enables and encourages user
feedback
Serious misunderstandings
evident early in the life cycle
Development focuses on critical
issues
Objective assessment thru
testing
Inconsistencies detected early
Testing starts earlier
Risks identified and addressed
early
Practice 2: Manage
Requirements

Develop Iteratively

Use
Model Verify
Manage Component Visually Quality
Architectures
Requirements

Control Changes
Practice 2: Manage
Requirements

Elicit, organize, and

document required
functionality and
constraints
Evaluate changes and
determine their impact
Requirements are dynamic --
Track and todocument
Expect them change during software development
tradeoffs and decisions
Definitions: Requirements
and Their Management

A requirement is a condition or
capability to which the system must
conform
Requirements management is a
systematic approach to
Eliciting, organizing, and documenting the
requirements of the system, and
Establishing and maintaining agreement
between the customer/user and the project
team on the changing requirements of the
 Agreement on What the
System Should Do
The Goal

Customer System
User Community To Be Built

Requirements Surrogate
Verification Goal

Requirements
Adapted from Al Davis
Requirements Trace To
Many Project Elements
How To Catch
Requirements Errors Early

Effective problem analysis and elicitation

of user needs
Gain agreement with the customer/user
on the requirements
Model interaction between the user and
the system
Establish a baseline and change control
process
Maintain forward and backward
Problems Addressed by
Requirements
Root Causes Management
Solutions
Insufficient A disciplined approach
requirements is built into
requirements
Ambiguous
management
communications
Brittle architectures Communications are
based on defined
Overwhelming requirements
complexity
Requirements can be
Subjective
prioritized, filtered,
assessment
and traced
Undetected
inconsistencies Objective assessment
of functionality and
Component-Based
Architectures

Develop Iteratively

Manage Use Model Verify

Verify Visually Quality
Requirements Component
Quality
Architectures

Control Changes
Software Architecture
Defined

Software architecture encompasses

significant decisions about the
organization of a software system
Selection of the structural elements and their
interfaces by which a system is composed
Behavior as specified in collaborations among
those elements
Composition of these structural and
behavioral elements into progressively larger
subsystems
Architectural Concerns

Software architecture is concerned with

structure and behavior and context:
Usage
Functionality
Performance
Resilience
Reuse
Comprehensibility
Economic and technological constraints and
tradeoffs
Resilient, Component-
Based Architectures

Good architectures meet their

requirements, are resilient, and are
component-based
A resilient architecture enables
Improved maintainability and extensibility
Economically-significant reuse
Clean division of work among teams of
developers
Encapsulation of hardware and system
dependencies
Example: Component-
Based Architecture
Lead Tracking Licensing
User Interface User Interface

User Interface
Mechanisms

Customer Product License

Key:
- Purchased Oracle Vantive
- Built
- New
Problems Addressed by
Component
Root Causes Architectures
Solutions
Insufficient Components facilitate
requirements resilient architectures
Ambiguous Reuse of
communications commercially
Brittle available components
architectures and frameworks is
Overwhelming facilitated
complexity Modularity enables
Subjective separation of
assessment concerns
Undetected
Components provide
Practice 4: Visually Model
Software

Develop Iteratively

Use
Manage Component Verify
Model Quality
Requirements Architectures Visually

Control Changes
Practice 4: Visually Model
Software

Capture the structure and behavior of

architectures and components
Show how the elements of the system fit
together
Hide or expose details as appropriate for
the task
Visual modeling improves our ability
Maintain consistency between
to manage software complexitya design
and its implementation
Promote unambiguous communication
What Is the UML?

The Unified Modeling Language (UML) is a

language for
Specifying
Visualizing
Constructing
Documenting
the artifacts of a software-intensive
system
 Diagrams Are Views of a
Model
A model is a complete
description of a system
from a particular
State
perspective State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Activity Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Sequence
Diagrams State
Diagrams
Diagrams Model Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Component
Collaboration
Diagrams Deployment Diagrams
Diagrams Diagram Diagrams
Visual Modeling Using UML
Diagrams Use-Case Diagram Class Diagram State Diagram add file

Writing
add file [ numberOffile==MAX ] /
flag OFF

Openning

Use Case 1
close file
Actor A Actor B
close file
Closing
Reading

Use Case 2
<<entity>>
Customer
name
addr
receive()
Use Case 3 withdraw()
Domain fetch()
Expert UI
send()
Deployment
MFC Class Diagram
DocumentApp

ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨

- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼ -¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö

Rog ueWave

Repository DocumentList Window95 Windows95

9: sortByName ( ) Persistence Windows95

g lobal

¹®¼-°ü¸®

FileManager Ŭ¶óÀ̾ðÆ®.EXE
¹®¼-°ü¸® ¾ÖÇø´

User Interface mainWnd : MainWnd Windows

NT

Package
1: Doc view request ( ) L

Document
Definition
Solaris

2: fetchDoc( )
¹®¼-°ü¸® ¿£Áø.EXE

4: create ( ) gFile : GrpFile

Alpha
8: fillFile ( ) UNIX

Diagram
ÀÀ¿ë¼-¹ö.EXE

Windows
NT

user : »ç¿ëÀÚ GraphicFile IBM

fileMgr : FileMgr Mainframe

3: create ( )
File FileList
6: fillDocument ( )
µ¥ÀÌŸº£À̽º¼-¹ö

7: readFile ( )

5: readDoc ( )
document : Document
repository : Repository

Component Forward Engineering (Code Generation)

Collaboration Diagram Diagram and
Reverse Engineering
mainWnd fileMgr : document : gFile repository
user FileMgr Document

ƯÁ ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view reques t ( )

»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.

2: fetc hDoc ( )

3: c reate ( )

4: c reate ( )
Source Code edit, compile, debug, link
5: readDoc ( )

È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fil lDoc um ent ( )

¹®¼-À Ç Á ¤º ¸¸¦ ÇØ´ç ¹®¼-
°´Ã ¼¿¡ ¼³Á ¤À» ¿äà »ÇÑ´Ù.

7: readFile ( )

8: fil lFile ( )

È-¸é °´Ã¼´Â À оîµéÀÎ 9: s ortByName ( )

°´Ã ¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·Ä À» ½Ã ÄÑ È-¸é¿¡
º¸¿©ÁØ´Ù.

Sequence Diagram

Executable System
Practice 5: Verify Software
Quality

Develop Iteratively

Use
Manage Model
Component Visually Verify
Requirements Architectures Quality

Control Changes
Practice 5: Verify Software
Quality
Software problems are 100 to 1000 times more
costly to find and repair after deployment

Cost

Development Deployment
Permits Continuous
Testing
Iteration 1 Iteration 2 Iteration 3
R R R
D D D
C C C
T T T

Test Test Test

T I M E
 Testing in an Iterative
Environment
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Requirements
Automated Tests

Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4

Automation Reduces
Testing Time and Effort
One Manual Test Cycle
13,000 Tests 2 Weeks 6 People

Test
Automation
13,000 Tests
6 hours Run More Tests More Often
1 Person
Dimensions of Software
Quality
Type Why? How?
Reliability Does my app leak memory? Analysis tools and code
instrumentation

Functionality Does my app do what’s Test cases for each scenario

required? implemented

Application Does my app respond Check performance for each

Performance acceptably? use case/scenario implemented

Test performance of all use

System Does my system perform cases under authentic and
Performance under production load? worst-case load
Problems Addressed by
Verifying
Root Causes Quality
Solutions
Insufficient Testing provides
requirements objective project
Ambiguous status assessment
communications
Objective assessment
Brittle architectures exposes
Overwhelming inconsistencies early
complexity
Subjective Testing and
assessment verification are
Undetected focused on high risk
inconsistencies areas
Practice 6: Control
Changes to Software

Develop Iteratively

Use
Manage Model Verify
Component Visually
Requirements Architectures Quality

Control Changes
Practice 6: Control
Changes to Software

Multiple developers
Multiple teams
Multiple sites
Multiple iterations
Multiple releases
Multiple projects
Without explicit control,
Multiple
parallel platforms
development degrades to chaos
Three Major Aspects of a
CM System
Concepts of Configuration
& Change Management

Decompose the architecture into

subsystems and assign responsibility for
each subsystem to a team
Establish secure workspaces for each
developer
Provide isolation from changes made in other
workspaces
Control all software artifacts - models, code,
docs, etc.
Establish an integration workspace
Change Control Supports
All Other Best Practices

Develop To avoid scope

Progress creep, identify,
is incremental only if
iteratively assess and
changes approve are
to artifacts all changes
Components must be reliable,
controlled
i.e., the correct versions of all
Manage constituent parts found
requirements To assure convergence,
Use incrementally control models
Tests are only
as designs meaningful if
stabilize
component the versions of the items under
architectures test are known and the items
protected from changes
Model visually
Problems Addressed by
Controlling
Root Causes Changes
Solutions
Insufficient
requirements
Requirements change
Ambiguous workflow is defined
communications and repeatable
Brittle architectures Change requests
facilitate clear
Overwhelming communications
complexity Isolated workspaces
Subjective reduce
interference from
assessment parallel work
Undetected Change rate statistics
inconsistencies are good metrics for
objectively assessing
 Summary: Best Practices
of Software Engineering

The result is software that is Performance

Engineer

On Time Analyst

On Budget
Project
Meets Users Needs
Develop Iteratively
Manager
Developer

Use Model
Manage Component Visually Verify Tester
Requirements Architectures Quality

Control Changes Release

Engineer
Seven Major Tools

1) Flowchart or process mapping

2) Check Sheet
3) Histogram
4) Pareto Chart
5) Cause and Effect Diagram
6) Scatter Diagram
7) Control Chart
Flowcharts or Run chart

 Used to explore if there is a process

 A Flow Diagram, also known as a flow chart,

is a diagramatic technique to document a
procedure, within a role or department.
"Structured" flow diagrams are created using a
single entry (with inputs), a single exit (with
outputs), and a combination of three building
structures:
Building structures

 sequence - any series of 1-n sequential

steps can be represented as a single
step
 choice - a decision between two or more
paths (structured subpaths) [e.g., if-
then, case/select]
 loop - a structured subpath (single entry
and single exit) that is executed 0-n
times
Example of a process flow
chart
Contractor submits
report for review
Yes
Is data approved

Log report in
No

Develop Sign the approve

Assign control letter
clarification
number
request

Review and Contractor receives

comment Sign the approve letter
( CC Divi) disapproval
letter

Review and
comment
( Technical)
Contractor receives
the disapprove
letter
Review and
comment
( Legal
Check Sheets

 Also called: defect concentration

diagram

 A check sheet is a structured, prepared form

for collecting and analyzing data. This is a
generic tool that can be adapted for a wide
variety of purposes.
Example :
The figure below shows a check sheet used to collect data
on telephone interruptions. The tick marks were added as
data was collected over several weeks.

Source:
http://www.hci.com.au/hcisite3/tool
kit/data.htm
Data organizing tools

Once collected, raw data is typically

summarized (reduced, or compacted) –
this can be done in several ways

Histograms
The Frequency Distribution
and Histogram

A frequency distribution shows how often each

different value in a set of data occurs.

A histogram is the most commonly used graph

to show frequency distributions.

It looks very much like a bar chart, but there

are important differences between them.
 Histogram

Parts of a Histogram
Days of operation prior to
100 1
F failure for an HF receiver
R
80
E
Q 60
4 3
U
E 40

N 20 2
C
Y 0
0 5 10 15 20 25 30 35 40 45 50 55 60

1. Title , 2. Horizontal / X -axis , 3. Bars, 4. Vertical / Y -axis

 Histogram

EXERCISE 1:

The source of data for the first exercise is the following scenario.A
list of the data collected follows this description

 Recorded are the percentages of code defects for 80 personnel

during development of s/w application.These are the data collected:
EXERCISE 1: Histogram

PERCENT defects RECORDED

11 22 15 7 13 20 25 12 16 19
4 14 11 16 18 32 10 16 17 10
8 11 23 14 16 10 5 21 26 10
23 12 10 16 17 24 11 20 9 13
24 10 16 18 22 15 13 19 15 24
11 20 15 13 9 18 22 16 18 9
14 20 11 19 10 17 15 12 17 11
17 11 15 11 15 16 12 28 14 13
 Histogram

 Step 1 -Count number of data points ANS : Total - 80

 Step2 -Summarize on a tally sheet

 Step3 -Compute the range

Largest value = XY Percent defect

Smallest value = XY Percent defect

Range of values = xyz Percent defect

EXERCISE 1: Histogram

Step 1 Count number of data points

PERCENT Defects RECORDED

11 22 15 7 13 20 25 12 16 19
4 14 11 16 18 32 10 16 17 10
8 11 23 14 16 10 5 21 26 10
23 12 10 16 17 24 11 20 9 13
24 10 16 18 22 15 13 19 15 24
11 20 15 13 9 18 22 16 18 9
14 20 11 19 10 17 15 12 17 11
17 11 15 11 15 16 12 28 14 13
ANS : Total - 80
EXERCISE 1:

Step 1 Summarize the data on a tally sheet

%Deft No.Of.Pers %Deft No.Of.Pers %Deft No.Of.Pers

0 0 11 9 22 3
1 0 12 4 23 2
2 0 13 5 24 3
3 0 14 4 25 1
4 1 15 7 26 1
5 1 16 8 27 0
6 0 17 5 28 1
7 1 18 4 29 0
8 1 19 3 30 0
9 3 20 4 31 0
10 7 21 1 32 1
 Histogram
 Step3 -Compute the range

Largest value = 32 Percent Defects

Smallest value = 4 Percent Defects

Range of values = 28 Percent Defects

 Histogram

 Step 4 -Determine number of intervals

IF YOU HAVE THIS USE THIS NUMBER OF

MANY DATA POINTS INTERVALS:

Less than 50 5 to 7 intervals

50 to 99 6 to 10 intervals
100 to 250 7 to 12 intervals
More than 250 10 to 20 intervals

ANS : Select 6 to 10 intervals - 8

 Histogram

 Step 5 -Compute interval width

Range 28
Interval = = = 3.5
Width 8
Number of Intervals

Use 8 for the number

of intervals
Round up to next
whole number
 Histogram
 Step6 -Determine the starting point of each interval
 Step7 -Count the number of points in each interval

INTERVAL STARTING INTERVAL ENDING NUMBER

NUMBER VALUE WIDTH VALUE OF COUNTS

1 4 +4 8 3
2 8 +4 12 20
3 12 +4 16 20
4 16 +4 20 20
5 20 +4 24 10
6 24 +4 28 5
7 28 +4 32 1
8 32 +4 36 1
 Histogram
 Step8 -Plot the data
 Step9 -Add the title and legend

Critical Defects
20
18

16
14

12

10
8

6
4

2
0
0 4 8 12 16 20 24 28 32 36
PERCENT Defect
The Frequency Distribution
and Histogram

Frequency Distribution
Arrangement of data by magnitude
More compact than a stem-and-leaf
display
Graphs of observed frequencies are
called histograms.
Pareto Chart

 A Pareto chart is a bar graph. The

lengths of the bars represent
frequency or cost (time or money), and
are arranged with longest bars on the
left and the shortest to the right. In this
way the chart visually depicts which
situations are more significant.
Pareto Chart

 The Pareto chart is a frequency

distribution (or histogram) of attribute data
arranged by category.
 Plot the frequency of occurrence of each
defect type against the various defect types.
 Also called: Pareto diagram, Pareto analysis
 Variations: weighted Pareto chart,
comparative Pareto charts
 Pareto

Why use Pareto chart

 Breaks big problem into smaller pieces

 Identifies most significant factors

 Shows where to focus efforts

 Allows better use of limited resources

 Pareto

Example
Individual category
Pareto
Cumulative Cost
45 40 120.00
40

Cumluative Cost
Cost Amount $$

100.00100.00
35 28 92.23
30 80.58 80.00
25 66.02
60.00
20 15
15 38.83 12 40.00
8
10
20.00
5
0 0.00
Product

Others
Delivery
Packages
Documents

Quality

Category of Cost
Example Pareto
 Figure 2 takes the largest category, “documents,” from Figure 1, breaks it down into
six categories of document-related complaints, and shows cumulative values.
 If all complaints cause equal distress to the customer, working on eliminating
document-related complaints would have the most impact, and of those, working on
quality certificates should be most fruitful..

Individual cause Pareto

Cum cause

35 32 120.00
30 100.00100.00

Cum u value of
Values in cost

90.70
25 21
79.07 80.00

Costs
20 61.63 15 60.00
15 10
10 37.21 8 40.00
5 20.00
0 0.00
problem
Version

Training
approved
PMP error
OD errors

not

Category of Cause
Cause and Effect Diagram

 A Cause-and-Effect Diagram is a tool that helps

dentify,sort,and display possible causes of a specific problem
or quality characteristic (Viewgraph 1).It graphically illustrates
the relationship between a given outcome and all the factors
that influence the outcome.

 This type of diagram is sometimes called an "Ishikawa

diagram” because it was invented by Kaoru Ishikawa,or a
"fishbone diagram"because of the way it looks.
 Cause and Effect
Cause and Effect Diagram

 Variations: cause enumeration diagram, process

fishbone, time-delay fishbone, CEDAC (cause-and-
effect diagram with the addition of cards), desired-
result fishbone, reverse fishbone diagram

 The fishbone diagram identifies many possible

causes for an effect or problem. It can be used to
structure a brainstorming session. It immediately
sorts ideas into useful categories.
 Cause and Effect
When should a team use a Cause-And-Effect
Diagram?

 Identify the possible root causes ,the basic

reasons,for a specific effect, problem,or condition.

 Sort out and relate some of the interactions among

the factors affecting a particular process or effect.

 Analyze existing problems so that corrective action

can be taken.
Why should we use a Cause-and-Effect Cause and Effect

Diagram?

 Helps determine the root causes of a problem or quality

characteristic using a structured approach.

 Encourages group participation and utilizes group

knowledge of the process.

 Uses an orderly,easy-to-read format to diagram cause-and-

effect relationships.

 Indicates possible causes of variation in a process.

 Increases knowledge of the process by helping everyone to
learn more about the factors at work and how they relate.
 Identifies areas where data should be collected for further
study.
Benefits of Using a Cause-and-Effect Cause and Effect

Diagram

 Helps determine root causes

 Encourages group participation
 Uses an orderly,easy-to-read format
 Indicates possible causes of variation
 Increases process knowledge
 Identifies areas for collecting data
 Cause and Effect

Step 1- Identify and Define the Effect

 Decide on the effect to examine

 Use Operational Definitions
 Phrase effect as
 >positive (an objective)or

 >negative (a problem)
 Cause and Effect

Step 2

1. Brainstorm the major categories of causes of the

problem. If this is difficult use generic headings:

 Methods
 Machines (equipment)
 People (manpower)
 Materials
 Measurement
• Environment
Step 3 Cause and Effect

1. Write the categories of causes as branches from the main

arrow.

CAUSE A CAUSE C

EFFORT

CAUSE B CAUSE D
Computational Hardware I/O and file Library-function
problem problems problems problem

Insufficient disk File does not exist

Divide by zero Standard libraries
space
File permissions not available
Uninitialized incorrect
variable Power outage
Spurious File corrupted Standard libraries
interrupts modified
Square root of a File moved
negative number
Disconnected / Incorrect return code
Invalid
dismounted from external function
Type mismatch filename
Timeout
Output file Incorrect parameters
Insufficient Corrupt memory already exists passed to external
precision function
Crash File locked by
another
Over flow / Transient errors
program
underflow
Exception
Failure
Empty data file Incorrect
Failure to handle command line Illegal access
Incorrect delimiters error return code arguments
Buffer overflow
Non-numeric in
numeric field Erroneous Corrupt memory
Values of arguments response to
Non-ASCII Non- allocated
invalid prompt
memory accessed
Extraneous data
Insufficient memory
Missing data Wrong number of Later response
argument to prompt Memory allocation error
Data values outside
of range Array boundary violation
Wrong type of No response to
Missing end of File arguments prompt
Invalid pointer dereferenced

Data-input Return-value problem External user / Null pointer and

problem function/procedure call client problem memory problems
Scatter Diagram
 The scatter diagram is a plot of two variables that can be
used to identify any potential relationship between the
variables

 The shape of the scatter diagram often indicates what type

of relationship may exist

 The scatter diagram graphs pairs of numerical data, with one

variable on each axis, to look for a relationship between
them. If the variables are correlated, the points will fall along
a line or curve. The better the correlation, the tighter the
points will hug the line.

 Also called: scatter plot, X–Y graph

 Scatter
Scatter plot for relationship between apartment
size and its rent (n=25)

2500
2300
2100
1900
1700
Rent

1500
1300
1100
900
700
500
500 700 900 1100 1300 1500 1700 1900 2100
Size

Scatter plot suggests that there is a positive, linear relationship between Rent and Size
 Scatter

Example
If there are 24 data points.

 To test for a relationship, they calculate:

A = points in upper left + points in lower right = 8 + 9 = 17
B = points in upper right + points in lower left = 4 + 3 = 7
Q = the smaller of A and B = the smaller of 7 and 17 = 7
N = A + B = 7 + 17 = 24

 Then they look up the limit for N on the trend test table. For N =
24, the limit is 6.

 Q is greater than the limit. Therefore, the pattern could have

occurred from random chance, and no relationship is demonstrated.
Control Chart
 The control chart is a graph used to study how a process changes
over time. Data are plotted in time order. A control chart always has
a central line for the average, an upper line for the upper control
limit and a lower line for the lower control limit. These lines are
determined from historical data. By comparing current data to these
lines, you can draw conclusions about whether the process variation
is consistent (in control) or is unpredictable (out of control, affected
by special causes of variation).

 Control charts for variable data are used in pairs. The top chart
monitors the average, or the centering of the distribution of data
from the process. The bottom chart monitors the range, or the
width of the distribution. If your data were shots in target practice,
the average is where the shots are clustering, and the range is how
tightly they are clustered. Control charts for attribute data are used
singly.
 Control Chart

What is control chart

A statistical tool used to distinguish
between process variation resulting
from common causes and variation
resulting from special causes.
Analyzing Process Performance

Why Control Charts?

Notice what the control charts do—they seek to identify if

the process is behaving one way or another. This, in
effect, is the same as asking if the process exists as a
well-defined entity, where the past can be used to predict
the future, or if the process is so ill-defined and
unpredictable that the past gives little clue to the future.

Donald J. Wheeler, 1995

 Control Chart

Variations
 Different types of control charts can be used, depending upon the
type of data. The two broadest groupings are for variable data and
attribute data.

 Variable data are measured on a continuous scale. For

example: time, weight, distance or temperature can be
measured in fractions or decimals. The possibility of
measuring to greater precision defines variable data.

 Attribute data are counted and cannot have fractions or

decimals. Attribute data arise when you are determining only
the presence or absence of something: success or failure,
accept or reject, correct or not correct. For example, a
report can have four errors or five errors, but it cannot have
four and a half errors.
Variables charts
Control Chart

 –X and R chart (also called averages and range chart)

 –X and s chart
 chart of individuals (also called X chart, X-R chart, IX-
MR chart, Xm R chart, moving range chart)
 moving average–moving range chart (also called MA–
MR chart)
 target charts (also called difference charts, deviation
charts and nominal charts)
 CUSUM (also called cumulative sum chart)
 EWMA (also called exponentially weighted moving
average chart)
 multivariate chart (also called Hotelling T2)
Attributes charts
Control Chart

 p chart (also called proportion chart)

 np chart
 c chart (also called count chart)
 u chart
Charts for either kind of data
 short run charts (also called stabilized charts
or Z charts)
 group charts (also called multiple
characteristic charts)
 Control Chart
Why should teams use Control
Charts?
 Monitor process variation over time.
 Differentiate between special cause
and common cause variation.
 Assess the effectiveness of changes
to improve a process.
 Communicate how a process
performed during a specific period.
 Control Chart

Why to use
 Monitor process variation over time

 Differentiate between special cause and common cause variation

 Assess effectiveness of changes

 Communicate process performance

 When controlling ongoing processes by finding and correcting problems as

they occur.

 When predicting the expected range of outcomes from a process.

 When determining whether a process is stable (in statistical control).

 When analyzing patterns of process variation from special causes (non-

routine events) or common causes (built into the process).

 When determining whether your quality improvement project should aim to

prevent specific problems or to make fundamental changes to the process
 Control Chart

What are the types of Control Charts?

There are two main categories of Control Charts,those that

display attribute data ,and those that display variables
data .

While these two categories encompass a number of different types of Control

Charts,
there are three types that will work for the majority of the data analysis cases
you will encounter.
In this module,we will study the construction and application in these three
types of Control Charts:
X-Bar and R Chart
Individual X and Moving Range Chart for Variables Data
Individual X and Moving Range Chart for Attribute Data
 Control Chart

Chart types studied in this module:

X-Bar and R Chart
Individual X and Moving Range Chart
-For Variables Data
-For Attribute Data

Other Control Chart types:

X-Bar and S Chart u Chart
Median X and R Chart p Chart
c Chart np Chart
Analyzing Process Performance
Analyzing Process Performance
Analyzing Process Performance

Detecting Signals

The simplest rule for detecting a signal (possible

assignable cause): a point outside the 3-sigma control
limits.

Many other sets of detection rules proposed.

makes the control chart more sensitive to signals
also leads to more false alarms decision on detection
rules should be based on economic trade-offs
Analyzing Process Performance

Stability Concepts

Stable process = Process In Statistical

Control

= Sources of Variability
Due to Common
Causes only
Analyzing Process Performance

Control Charts

Two broad classes of control charts

variable data, which is continuous
attribute data, which is discrete

Choice of what control chart to use should be based on

knowing the right assumptions!

Use the correct formulas for the kind of control

chart selected!
Analyzing Process Performance

The Distinction Between Variables Data and Attributes

Data

Variables data (sometimes called measurement data)

are usually measurements of continuous phenomena.

Examples: measurements of length, weight, height,

volume, voltage, horsepower, torque, efficiency,
speed, and viscosity.

Software examples: elapsed time, effort expended,

years of experience, memory utilization, CPU
utilization, and cost of rework.
Analyzing Process Performance

The Distinction Between Variables Data and Attributes Data

Attributes data occur when information is recorded only

about whether an item conforms or fails to conform to a
specified criterion or set of criteria.
Attributes data almost always originate as counts.

Examples: the number of defects found, the number of

defective items found, the number of source statements of
a given type, the number of lines of comments in a module
of n lines, the number of people with certain skills or
experience on a project or team, and the percent of
projects using formal code inspections.
Analyzing Process Performance

Average - Range Control Charts

Control Limits for Mean:
X  A2 R
where X =
X
number of samples

R =
R
number of samples

Control Limits for Range: D3 R and D4 R

 Sample
Size d2 A2 D3 D4
------------------------------------------------------------------
2 1.128 1.880 0 3.267
3 1.693 1.023 0 2.575
4 2.059 0.729 0 2.282
5 2.326 0.577 0 2.116
6 2.534 0.483 0 2.004
10 3.078 0.308 0.233 1.777
15 3.472 0.223 0.348 1.652
20 3.735 0.180 0.414 1.586
25 3.931 0.153 0.459 1.541
 UCL
MEANS

CL

LCL

UCL
RANGES

CL
LCL

0 1 2 3 4 5 6 7 8 9 10
Sample Number
Analyzing Process Performance

Detecting Instabilities and Out-of-

Control Situations

To test for instabilities in processes, we examine

control charts for instances and patterns that signal
nonrandom behavior.

Values falling outside the control limits and unusual

patterns within the running record suggest that
assignable causes exist.
Analyzing Process Performance

Detecting Instabilities and Out-of-

Control Situations
Test 1: A single point falls outside the 3-sigma control
limits.
Test 2: At least two of three successive values fall on the
same side of, and more than two sigma units away from,
the center line.
Test 3: At least four out of five successive values fall on
the same side of, and more than one sigma unit away
from, the center line.
Test 4: At least eight successive values fall on the same
side of the center line.
Useful Control Charts

Most likely to be of value for software processes

u-chart

XmR chart
XmR Chart

When measurements are spaced widely in time or

when each measurement is used by itself to
evaluate or control a process, a time-sequenced
plot of individual values, rather than averages,
may be all that is possible.
 XmR Chart
Control limits for Individuals Chart:
X-bar  3(MR-bar/d2)

Upper limit for Moving Range Chart:

D4 MR-bar
 Week 1 2 3 4 5 6 7 8 9 10 11 12

First Quarter 19 27 20 16 18 25 22 24 17 25 15 17
Second Quarter 20 22 19 16 22 19 25 22 18 20 16 17
Third quarter 20 15 27 25 17 19 28

Each week, a system test organization reports the

number of critical problems that remain unresolved.
There is concern that week 31 value of 28 is higher than
would have been expected.
A control chart is constructed to investigate this possibility.
Calculation of Rework Effort :

Percentage of rework effort against development effort =

Rework Effort in Person min

________________________

Actual Effort in Person min