Fagan Inspection Method

WWW.VIETNAM.ECCINTERNATIONAL.COM


Workshop on Software
Inspection
1

 

Myths of Peer Reviews

 

Need for Software Inspection

 

Types of Reviews

 

Inspection Team

 

Inspection Process

 

Individual Responsibilities

 

Exercise: Overview
2

 

Exercise: Preparation Time

 

Exercise: Defect Logging Meeting

 

Exercise: Causal Analysis Meeting

 

Exercise: Summary Presentation

 

Inspection metrics

 

How to make Inspection happen


 

Closing Session
3

1


 

M. Rajamanickam (Raja) has more than 20 years experience in all
facets of Quality Management and Process Improvement. 

 

Practitioner of Fagan Inspection for more than 15 years and
conducted Inspection training to many prestigious clients in India,
Japan and Vietnam.

 

Process improvement consultant, who helps clients in the
countries like India, USA, Japan, China, Taiwan, Brazil, Australia,
Malaysia,Vietnam, etc.

 

Visiting faculty in many universities and business schools including
Great Lakes Institute of Management, Chennai, India.


 

Lean Six Sigma Corporate Champion, Certified Scrum Master,
Certified CMMI Lead Appraiser, and a passionate trainer. 

 

Earlier jobs include Vice President of Corporate Quality at HCL
Technologies and Manager, Quality at Oracle India.

 

Holds ME (Industrial Engineering) from PSG College of
Technology and Exec. MBA from Great Lakes Institute of
Management.

 

Raja can be reached on his email:
4

4

  Participate

and share
reserve your questions at any time
  Maintain punctuality during the start and
breaks

  No web browsing/mails/skype during the
the session pls!
  Mobiles in silent mode?
  Don’t

  Anything

else to be added?
5

  Let

us understand your specific
expectations from this workshop

 

6

2


7
Quality Dept.

  Verify

that specifications are satisfied

  Verify


conformance to standards

  Identify

deviation from standards and

specifications
  Collect

data for improvement

8

  Reviews

waste lot of time

  Reviews

are costly

  Hard

work alone results in quality

  Everyone

always tries to produce high


quality products
  Reviews

can be done only by Senior

Staff
9

3


Please follow the instructions of the
faculty

10

Rework
Requirement

Development

Product

11

Source : Software Inspection - An Industry Best Practice, IEEE Computer Society Press, 1996
12

4



Source : Software Inspection - An Industry Best Practice, IEEE Computer Society Press, 1996
13

Source : Software Inspection - An Industry Best Practice, IEEE Computer Society Press, 1996
14

Catching Defects early in the Development Process is
Economical
15

5


How about Testing?
System Test

Requirements

Integration
Test

Design

Coding

 
 
 


Unit Test

Testing starts too late in the development process
In testing, you find only symptoms, not defects
Testing is expensive
16

 

According to studies, Inspection is three times more effective
in finding defect than testing
 

Inspection finds most of the problems testing would find, and does so more
efficiently

 

However, some subtle bugs may escape inspection, and could
only be detected through testing by executing the software
code
 

So, inspection and testing should be considered as complementary processes

17

Without Inspections
20
Requirements

40
Design
Code
100
50
Unit Test
Integration Test

20
System Test

10

240 Total Defects
10 Defects goes to the customer
Source : Software Inspection - An Industry Best Practice, IEEE Computer Society Press, 1996

6


With Inspections
5
20
Requirements
10
40
Design
15
Code
100

7
50
Unit Test
3
Integration Test
20
System Test 10
Reduced Defects (Total 41)
Improved Product Quality
Reduced Rework Costs

1

Source : Software Inspection - An Industry Best Practice, IEEE Computer Society Press, 1996

Without Inspections
Requirements

6

Design
Code

With Inspections
3
6

15

18


145
72
Unit Test
Integration Test

Reduced Defects (292 – 42)
Improved Product Quality
Reduced Rework Costs

9
4

36

System Test

18

2

Source : IBM Corp., Software Product Assurance, NY, 1987

Source: A history of Software Inspections – Michal Fagan

7


 Introduction


of Inspections in each phase of
the Development Process reduces Defects
and Rework Costs

 Inspection

Process works regardless of

o Type of Software
o Type of Design
Methodology
o Programming Language
22

  Development

productivity improvement (30% to

100%)
  Calendar

time reduction (10% to 30%)

  Reduction

in development effort (9% to 40%)

  Reduction

of testing costs and time


  Maintenance

cost reduction (35% to 65%)
23

Raytheon
  Reduced "rework" from 41% to 20%
  Reduced effort to fix integration problems by 80%
IBM

1 hour of inspection saved 20 hours of testing
Saved 82 hours of rework in released product
  Inspections Resulted in
 
 

 

23% increase in coding productivity

 

38% reduction in defects detected after unit test

AT & T
 

Inspections Resulted in
 


10 fold increase in quality
24

8


IBM Santa Teresa Lab
  3.5 hours to find bug with inspection, 15-25 through
testing
C. Jones
  Design/code inspections remove 50-70% of defects
  Testing removes 35%
Paulket al.:
  Cost to fix a defect in space shuttle software
◦  $1 if found in inspection
◦  $13 during system test
◦  $92 after delivery

HP
◦  80 % of defects detected by Inspections were unlikely to be
detected by other methods
25

  Review
  Use
  Set

the product, not the producer


standards to avoid disagreement over style

an agenda and maintain it

  Identify

problems, but don’t attempt to solve

them
  Take

written notes

  Limit

the number of participants

27

9


  Develop

a checklist for each product to be

reviewed
  Review
  Insist


complete pieces of a product

upon advance preparation

  Allocate
  Avoid

resources and time schedule

consecutive Peer Reviews

  Review

your early reviews

28

  Offline

Review

  Peer

Review – Walkthrough

  Peer

Review – Inspection

29


Work
Product

Review Type

10


Work product, Input documents,
Supporting document, Standards,
Appropriate checklists, if any

Depending on
the domain
knowledge

32

  Depends

on reviewers domain knowledge

and ability to spot defects
  Considered

as NOT part of reviewers regular

activity
  Not


very effective process

  Not

repeatable

33

11


  Planning

phase

  Walkthrough
  Rework

phase

phase

  Follow-up

phase

34

Resubmit


Accept
Conditionally

Author calls for
another
walkthrough
meeting & the
cycle continues.

Author
explains
fixes to
Review team
& his
Manager..

Depending on the
domain
knowledge & total
No. will be from 3
to 7

  Formal

process, gets the perspective of team of

reviewers
  Advantage
  “None

  More

of synergy

of us are as good as all of us”

effective than offline review

36

12


  No

advance preparation by the reviewers

  Review

team understands and reviews the work

product simultaneously
  Team
  Get

may lead to diverse controversial issues

to know ONLY the author’s view of the

work product

  Author

leads the show
37

Method

Cost

Effectiveness

Inspection

Medium - High

>60%

Walkthrough

Medium

<50%

Offline Review

Low

<35%

Self Checking


Low

<20%

Source: Capers Jones, Software Measurement and Estimation

Reasons:
More formality and rigor
Well defined Inspection Methodology
All participants are active and responsible
Requires preparation
Repeatable process
38

  Reviews
  Offline

reduce rework

is the simplest one

 To be used for less critical work products
  Walkthrough

 More Effective compared to Offline reviews
 Often used for code reviews
  Inspections

 The most beneficial (to be discussed extensively now on)

39

13


40
Quality Dept.

 Inspection Guidelines
 Inspection Teams
 Inspection Process
 Individual Responsibilities
 Exercises

41

 To understand the process of software
Inspections
 To apply the process learned to a work
product
 Quantify benefits

42

14


A formal process requiring advance
preparation, planned and scheduled as mile
stone to detect defect in work products


43

Meets Entry Criteria

Yes

for Inspection?

Planning

Overview Meeting

Preparation
Defect Logging
Meeting
Defect Log
Causal
Analysis Meeting

Process
Improvement
Recommendations

Rework
No
Follow-Up

Meets Exit Criteria


Yes

for the work?

44

 Process focused on detecting defects as soon
as possible
 Clearly defined roles for each member of the
Inspection team
 Emphasis on advance preparation
 Inspection Process designed to provide
continuous process Improvement
45

15


Guidelines on :
  Duration on Inspection Meeting
  Size of Inspection team
  Size of documents that can be inspected in one
meeting

46

 Inspect the Work Product - Not the Producer
 Focus on detecting as many defects as possible
 Choose the right participants
 No management participation (even if the

manager participates, he acts only as a ‘peer’)
 Focus on playing the assigned roles
 Promptly follow the start & end time for all the
meetings
 Spend quality time on preparation
47

  Leave the egos at the door of the Inspection meeting
  Limit the inspection meeting time (not to exceed 2
hours)
  Inspector’s Job is only to report defects (do not try to
solve them)
  Author - & only Author - is responsible for fixing defects
  Inspection meeting discussion is only to make author
understand the issue
  Discussion on Inspection to be confined to Inspection
team
48

16


Primary Roles
 Moderator
 Author
 Reader
 Inspector
Additional role of Recorder during the defect
logging meeting
50


 Moderator
o  Leads the Inspection team through the
Inspection Process
o  Keeps the team Focused
o  Not necessarily the senior most member of
the Inspection Team
o  Plays an active role as an Inspector
51

17


 Author
o  Developer of the work product being Inspected
o  Plays an active role as an Inspector
 Reader
o  Paraphrase the work product in the defect
logging meeting to provide an exact view of the
work product
52

o  Plays an active role as an Inspector
o  Usually belongs to the same development team
as the author
 Inspector

o  Inspects the work product - Not the author

53


 Recorder
o  Act as an Inspector and record errors as
detected
o  Classify errors (must know classification)
o  After each recording, read out to inspection
team for confirmation
o  Read out/present full list to inspection team
at the end of the Review
54

18


  Peer

Process

  Based
  Each

on trust

member of the team is involved in

detecting defects
  Process

creates at least one person who is as


well informed about the work product as the
author
56

  Planning
  Overview

Meeting

  Preparation
  Defect

Logging Meeting
Meeting
  Rework
  Verification
  Causal Analysis

57

19