25
Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John E. Gibson [email protected]

Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

Embed Size (px)

Citation preview

Page 1: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

Statistical Process Control andSoftware System Development

American Society for Quality, Baltimore Section

Tuesday, March 14, 2006

Main Discussion John E. Gibson

[email protected]

Page 2: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 2

Topics

• Purpose• Process Improvement Definition• Shewhart, Juran Concepts• Shewhart Cycle• Causal Analysis Varieties• CA-AP1 and CA-AP2 Discussion• MAAP cycle• CA1 Template• CA1 Example• Conclusion

Page 3: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 3

Purpose

• Stir up discussion

• Introduce a new idea or two

• Share techniques as currently practiced

Page 4: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 4

PI Definitions

• Improvement is defined relative to process outcome (objectives, initial creation, etc, are separate subjects)

• Outcome is determined in two ways

– Product measurements

– Process measurements

• Process has two dimensions

– Conduct (humans)

– Definitions (intended operations)

• Improvement hierarchy

1. Ensure conduct meets expectation

2. Change the process definition after you obtain measurements for the

process operating as intended

Page 5: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 5

Process Behavior Chart(Shewhart concept)

Process Behavior Chart - Individuals

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

Product Defect rate Xbar UNL

Assignable Cause (special)

System of Chance Causes (common)

Unl

Cl

Unusualoutcomes

Normaloutcomes

Deming terms in parenthesis

Page 6: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 6

0

1

2

3

4

5

6

7

8

9

A B C D E F G H

Process Improvement Alternatives

Val

ue

Process Improvement – Pareto(Juran concept)

Vital Few

Useful Many

Unusual, anomalous behavior is treated separately.

Page 7: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 7

Shewhart + Juran

• Shewhart’s limits sharply identify potential problems that need investigation.

• We can generalize the demarcation into 1) anomalies and 2) normal behavior from which we conclude that first we remove anomalies before attempting to change normal behavior (in fact, first determine what is normal).

• For problems that don’t lend themselves to PBCs, less sharp criteria must be used to recognize anomalies hence we think in terms of trends and cumulative evidence of problems.

• The Juran’s Pareto idea complements Shewhart in that normal behavior should be improved. Using the vital few idea, helps us focus on identifying what makes business sense to change.

Page 8: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 8

Shewhart Cycle (1 of 2)

Use control charts, causal analysis + other methods

Obtain Process and

Product Measures

Establish “Intended Function”

Define Process

Perform Process

Modify Something Change

Needed?N

Y

Plan Do

CheckAct

Gibson’s version of Deming’s interpretation of Shewhart’s description of improvement cycle.

Page 9: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 9

Shewhart Cycle (2 of 2)• Intended function encompasses, intended operation, implementation, outcome,

expectation etc.• A scalable model for continuous process improvement at all levels:

organization, project, department for pilot studies or standard processes. • Plan

– Establish “Intended Function” for engineering or support operations– Define process/sub-processes and measurements.

• Do– Perform the process (in the way the designers intended).– Obtain process and product measures.

• Check– Does the outcome meet intent or expectation?

This needs to be an objective a measure.– Behavior charts, histograms, Pareto charts, etc

• Act– Modify something – measurements, measuring process, conduct of engineering

process, engineering process. • Continuous cycle ensures process is performed the way it is intended to be

conducted with decreasing variation and decreasing defect rate, for example.

Applicable to both Shewhart and Juran

approaches.

Page 10: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 10

• Two distinctly different paths are needed for Causal Analysis – Action Plans, depending on the reason this activity is required.

• Both paths should satisfy CMMI Causal Analysis and Resolution (CAR) process area even if level 5 is not the organization's goal

Use SPC charts, causal analysis + other methods

Modify Something

Need Improvement?N

Y CheckAct

Causal Analysis Varieties

Trigger?

CA-AP 1 CA-AP 2

PBC - limit Trend

Page 11: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 11

CA-AP Comparison

Attribute CA-AP1 CA-AP2

Objective Near real-time removal of an anomalous condition

A change to the process to reduce cost, decrease duration, or improve quality

Trigger 1. Control chart natural limit exceeded

2. A process anomaly validated by a designated authority

A project / organization group decision that process change is needed and warranted

Causal analysis Author performs the initial causal analysis using designated template

One or more people perform causal analysis over one or more sessions

Reaction time Causal analysis review meeting within one week of triggering event

Causal analysis review meeting dependent on improvement activity schedule

Outcome Action plan, action items assigned

Formality Process descriptions (2), templates (N), actions item tracking, document change history and formal closure.

Page 12: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 12

CA-AP Perspective

• We will concentrate on the CA-AP1 path since that is different from what most projects/organizations do.

• We can learn lessons from CA-AP1 that are useful for improving the CA-AP2 path,

• CA-AP2 is probably what most people use for the the sequence of problem identification, causal analysis, action planning, tracking/closure.

• CA-AP2 is slower to identify a problem and slower to react.

• The CMMI describes CA-AP2 (presenter’s opinion).

Page 13: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 13

MAAP = Measurement, Analysis and Action Planning

• 4-6 measurements to initiate process behavior charts

• Points added to charts until phase end is reached.

• Causal analysis and action planning happen quickly when triggered by indications of possible trouble. Short MAAP cycle is needed for near real-time incorporation of improvements.

• An activity that does not have phases is preferred because of the opportunity for multiple MAAP cycles.

PBC-Based Improvement Cycle

Process Behavior Charts

Causal Analysis Action Plan

M M M M MM M M M M M M MM

Denotes an inspection

M Denotes a measurement(s)

MAAP cycle

Example XmR-chart

0

1

2

3

4

5

6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

DefectRate

Xbar UNL

Page 14: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 14

Improvement Cycle: Two Cases

Near Real-Time• Numerous measurements within one phase (same process activity, e.g., coding)• Duration of a phase is a multiple of a single MAPP cycle.• Some number of process updates are accomplished within one engineering phase• Last MAAP cycle may not be completed with the phase

Short Run

• No MAAP cycle is completed within the engineering phase from which data is gathered and analyzed.

• Action plans must be implemented in the “next” instance of the engineering phase.

• Same process, application, team, contract involved – multiple increments, spirals

MAAP cycle MAAP cycleMAAP cycle

MAAP cycle MAAP cycle MAAP cycle

Page 15: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 15

CA-AP1 TemplateCausal analysis Id __ Date assigned __ Assignee __

Trigger (s)

Assigned cause(s)

[What]

Cause category:

Didn’t follow process

(adherence)

Couldn’t follow process

(deficiency)

Didn’t understand process

(training)

1. Measurement definition anomaly

2. Inspection / Peer review process anomaly

3. Engineering process anomaly

Prevention action: (s)

Date action implemented: _____ and brief description of how implemented was conducted.

Verification: (How do we know problem did not reoccur?)

Aspects of an assigned cause, more than one aspect possible per cause

[Why]

Copyright John E. Gibson, 2005

Page 16: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 16

Template Infrastructure

• Documented definitions, templates, descriptions, instructions, examples and training.

• Templates are online• Management enforces use, reviews

completed forms and is materially involved in improvement processes

• Templates are one method of attaining consistency in processes and process improvement

Page 17: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 17

Causal Analysis1 - Example (1 of 3)

Trigger: Defect rate out-of-limit for Design PR XmR chart.

Assignee __Date assigned __Causal analysis Id CA001

Assigned cause(s)1. First product of new graphical design process, not completely understood. Ambiguity with

respect to font size and other elements.

2. Engineering preference on drawing structure. PR interpreted ‘general’ font size guidance to require larger size font in some places.

3. Font size should have been caught by author using checklist. If one of the key reviewers had been at inspection, difference of interpretation may have been discovered earlier.

4. Notes are not standardized. Difference of opinion about what is needed or appropriate.

5. Number of defects not counted consistently. Impromptu count by five different people produced four different counts. (4,6,9,5,4)

Page 18: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 18

Causal Analysis1 - Example (2 of 3)Causal analysis Id CA001 Date assigned __ Assignee __

Trigger: Defect rate out-of-limit for Design PR XmR chart.

Assigned cause(s)

Cause category:

Didn’t follow process

(adherence)

Couldn’t follow process

(deficiency)

Didn’t understand process(training)

1. Measurement anomaly

5) Explicit guidance for counting defects missing. PA 1, PA 2

2. Inspection process anomaly

3) Key reviewer not at inspection (domain expertise missing at inspection?) PA 4

3. Engineering process anomaly

1) Either the author or the PR moderator didn’t follow the intent of the process. PA 3

2) Process may be ambiguous and need clarification. PA 1

4) Standard notes are not defined, so difference of opinion of what is needed.. PA 2, PA 4

1) Either the author or the PR moderator didn’t follow the intent of the process. PA 3

Page 19: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 19

Causal Analysis1 - Example (3 of 3)

Causal analysis Id CA001 Date assigned __ Assignee __

Trigger: Defect rate out-of-limit for Design PR XmR chart.

Assigned cause(s):

Cause Category:

Prevention action: (s)

1. Applicable process documentation should be reviewed and any ambiguities and missing standards or guidance should be added. Later other documents not directly associated with this trigger should be reviewed and updated.

2. Authors and reviewers should be required to use same standards.

3. Training in or e-mail notice of revisions is required after modifications.

4. Analyze the inspection process and revise process to ensure a moderator, key reviewers, adequate preparation time and standardized procedures & measurements.

5. Define a standard note list.

Page 20: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 20

CA-AP1 Measurements (1 of 2) (arbitrary data)

Causal Analysis Summary

0

5

10

15

20

25

1.Measurement anomaly

2.Inspection process anomaly

3.Engineering process anomaly

(adherence) (deficiency) (training)

Define a measurement strategy when you first define

a Shewhart cycle.

Page 21: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 21

CA-AP1 Measurements (2 of 2) (arbitrary data)

Time to Implement Last 20 Action Plans

0

1

2

3

4

5

6

7

8

9

10

<=7 <=14 <=21 <=28 <=35 <=42 <=49 >50

MAAP Days

Cou

nt

MAAP denotes measurement, analysis, action plan cycle time.

Page 22: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 22

CA-AP1 Experience

• Action plans begin to reinforce prior actions. For example, the need for design process specs and a design best practices will occur again until the two examples are published and understood by the SW engineers.

• The number of action plans (items) do not grow uncontrollably. There are usually a reasonable number (say 10) principal actions that address the majority of anomalies.

• Anomalies caused by engineers not following a process that they understand will not be corrected by suggesting further training.

• First-level managers chair the causal analysis review and therefore interact with the presenting engineer (an employee). A better understanding of each other’s concerns are obtained over time.

• Author’s try to “game” the defect counts to avoid “tripping” and thereby triggering casual analysis and a visit to the review meeting. However, awareness of the need for improved quality is increasing.

Page 23: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 23

CA–AP2 (1 of 2)

• The CA-AP2 cycle is a process that most organizations likely have in place.

• A project ‘SEPG’ or Organization SEPG is likely to be the owner of these type of process improvements (change to improve performance).

• A Shewhart cycle meshes with a Juran cycle when a stabilized process is analyzed for improvement.

• A Configuration Control Board (CCB) is likely needed for CA-AP2 actions since these change the definitions of a process.

Page 24: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 24

CA–AP2 (2 of 2)

• PBC Analyses of process / product measurements are a small subset of all measurements collected.

• A CA-AP2 may be improved if a Juran-style Pareto chart is used to distinguish between essential few and the useful many process improvements.

Page 25: Statistical Process Control and Software System Development American Society for Quality, Baltimore Section Tuesday, March 14, 2006 Main Discussion John

March 14, 2006 25

Conclusion

• In this presentation, process improvement involves process change and this follows removal of process anomalies.

• Analyzing measurements with control charts is a small subset of all analyses performed.

• Shewhart, Deming and Juran only advocate process improvement activities that make economic sense.

• Process improvement is a business process as vital as making widgets for sale.

• Evolving business environments require processes to be reviewed periodically and changed to stay in tune with their environment.

• Process improvement requires human behavior changes, this is the hard part of process improvement.

• Human behavior changes require the continued, meaningful involvement of management, much more than delegation.