Software Inspections

Lecture # 13

1
Inspections
• An inspection is a rigorous team review of a work
product by peers of the producer of the work product
• The size of the team will vary with the characteristics of
the work product being inspected; e.g., size, type
• The primary purpose is to find defects, recording as a
basis for analysis on the current project and for historical
reference and for improvement for future projects,
analyzing them, and initiating rework to correct the
defects
• Direct fault detection and removal
• Inspections are most effective when performed
immediately after the work product is complete, but they 2
can be held any time the work product is deemed ready
for inspection
Inspections, Cont…
• Inspections are critical reading and analysis of software
code or other software artifacts, such as designs, product
specifications, test plans, etc
• Inspections are typically conducted by multiple human
inspectors, through some coordination process. Multiple
inspection phases or sessions may be used
• Faults are detected directly in inspection by human
inspectors, either during their individual inspections or
various types of group sessions
• Identified faults need to be removed as a result of the
inspection process, and their removal also needs to be 3
verified
Inspections, Cont…
• The inspection processes vary, but typically
include some planning and follow-up activities in
addition to the core inspection activity
• Developed by Michael Fagan at IBM and were
first reported in public domain in 1976
• Inspections remove software defects at reduced
cost
• Inspections enable us to remove defects early in
the software life cycle, and it always cheaper to
4
remove defects earlier in than later in the
software life cycle
What we know
• We know that defects are injected in every
software life cycle activity
• We remove some of these defects in testing
activities after code is completed
• We also know that all defects are not removed at
shipment time, and these are known as latent
defects

5
What we want to do
• We want to eliminate or at least minimize latent
defects in the shipped software product
• It is expensive to find and remove defects in the
testing phase, and even more expensive after
shipment of the software
• We can use inspections to reduce these costs
and improve the timelines also

6
How Defect Removal is Cheaper for
Inspections as Compared to Software Testing

7
 Defect Cost Relationship
Relative Costs to Remove a

10000
Defect

1000
100

Pre-Test Test Users

8
Major Defect Removal Area
Reported Cost Relationship - 1
Company Cost in Cost in Test Cost With
Inspections Customer
Discovery
IBM $48/defect $61-$1030 / $1770 /
defect defect

AT&T 1 unit 20 units --

ICL 1.2-1.6 8.47 --

hours/defect hours/defect 9
Reported Cost Relationship - 2
Company Cost in Cost in Cost With
Inspection Test Customer
s Discovery
AT&T 1.4 hours 8.5 hours --

JPL $105/defe $1700/defe --

ct ct
IBM 1 unit 9 times 117 times 10
more more
Reported Cost Relationship - 3
Company Cost in Cost in Cost With
Inspection Test Customer
s Discovery
Shell 1 unit 30 units --
Thorn EMI 1 unit 6.8-26 units 96 units

Applicon, 1 hour -- 30 hours

Inc.
Infosys 1 unit 3 – 6 units -- 11
Defect Origins and Discovery Points
Without Usage of Formal Inspections

Defect Origins
Requirements Design Coding Documentation Testing Maintenance

Requirements Design Coding Documentation Testing Maintenance

Defect Discovery
Chaos Zone 12
• This situation is a mess
• If only we were able to detect defects in the
same life cycle activity, we can eliminate the
chaos zone, and bring some sanity back to the
project team and project management
• If we introduce software inspections, we can do
that

13
Defect Origins and Discovery Points
With Usage of Formal Inspections

Defect Origins
Requirements Design Coding Documentation Testing Maintenance

Requirements Design Coding Documentation Testing Maintenance

Defect Discovery
14
Why Isn’t Everyone Using
Inspections?
• Now we are convinced that inspections have a
clear value independent of any model or
standard for software development, so why isn’t
everyone using it?

15
Reasons for Not Using Inspections
• There is resistance to Inspections because people
view them as if they are not easy to do well
• Management often views Inspections as an added
cost, when in fact Inspections will reduce cost during
a project
• Development of new tools and environments
• Inspections are not the most enjoyable engineering
task compared to designing and coding
• Inspections are labor intensive and low-tech
• Programmers/designers are possessive about the
16
artifacts they create
Inspection Preconditions
• Clear and visible management support
• Defined policy
• Good training for all
• Effective procedures
• Proper planning
• Adequate resources

17
Entry-Task-Validation/Verification-eXit
(ETVX) technique

18
ETVX Representation
• The model expressed as a set of interconnected
activities each of which has four sets of
attributes
• Entry (E)
• The Entry section defines the entry criteria that
must be satisfied for the process to be initiated, and
list the work products that must be available as
inputs to the process
• Task (T)
• The Task section defines work to be carried in
performing the process. The order of the task is
generally, but not strictly sequential. Some tasks 19
may be concurrent with other tasks
• Validation/Verification (V)
• The validation/verification section defines steps for
validating/verifying that the process has been
properly executed, and that the associated work
products meet project objectives
• Exit (X)
• The Exit section defines the exit criteria that must
be satisfied for the process to be terminated. The
exit criteria usually define completion and
verification work products, in terms of qualitative
aspects of the products 20
The ETVX Process Definition Paradigm

T
E X

21
 Practices in the Inspection Process
Work Entry Tasks eXit
product
to be - Inspections are planned
inspected - Policy - Perform inspections - Record process
- Procedures - Record data on conduct data
- Resources - Record data on results - Record defect
- Training - Plans are documented data
- Moderator - Rework
- Inspectors completed
Validation/Verification Inspected
work
- Reviews with management product

- Inspection activities
measured
22
Software Inspections
Ancillary Purposes
• Improvement in productivity
• Education and increased knowledge sharing
• Developing backup/replacement capability
• Process improvement
• Early product quality visibility
• Product re-development
• Building team spirit

23
Software Inspections
What Inspections Are Not
• A review of the style of a work product
• A review of the producer, and especially not a means
to evaluate the producer by management
• An impromptu meeting; it is a scheduled meeting
with resource considerations to enable effectiveness
• A casual or informal meeting; there is structure and
rigor for a purpose
• Typically the time or place to fix defects or discuss
possible solutions
• Free! But they do yield a high return on investment
• A vehicle for shifting responsibility to inspectors for
quality of the work product 24
• Quality assurance performed at the end of
development
Inspection Process Flow

25
Inspection Process
• Planning and scheduling
• Overview
• Preparation
• Inspection meeting
• Analysis meeting
• Rework
• Follow-up
• Prevention meeting
• Data recording and reports
26
• Inspection process monitoring
• We’ll be using the ETVX model to describe the
steps in the inspections process

27
Inspections Process
Planning and Scheduling
• To ensure adequate time and resources are
allocated for inspections and to establish
schedules in the project for work products to be
inspected, to designate the inspection team, and
to ensure the entry criteria are satisfied
• All project plans exist at three levels of
knowledge as the project progresses
• Those things that are unknown
• Those things that are becoming known
• Those things that are known
• Plan details reveal themselves to the planner as 28

a rolling wave
Inspections Process
Planning and Scheduling
• The project lead must plan which inspections are
to be performed at the initial stages of the
project
• Unknowns become knowns
• Has two sections
• Inspection planning
• Inspection scheduling

29
Inspections Process
Inspection Planning: Responsibility
• The project lead or whoever is responsible for managing the
work for a specified software project is responsible for
performing the activities for Inspection Planning

30
Inspections Process
Inspection Planning: Entry Criteria
• A policy exists for inspections in the project’s organization
• Planning procedures, including planning for inspections exist
• A project begins and includes the requirement to plan for
inspections
• Work product types to be inspected are identified in the
project plan
• Well-defined work product completion or readiness
criteria are available
• Initial estimates are provided for the size of the work
products to be inspected
• Expected project participants have been trained or a
training plan is defined
31
• Goals and targets have been established for the volume
or percentage of work products to be inspected
Inspections Process
Inspection Planning: Tasks
• Determine what will be inspected
• Estimate resources for inspections and allocate
budget
• Set milestones for the inspections
• Identify dependencies on other groups

32
Inspections Process
Inspection Planning: Validation/Verification
• The SQA group in the organization should assure
that the project plan has been documented and
includes planned inspections as required by the
organization policy and procedures
• Data to be gathered during this activity
• Which work products are planned for inspection
• The estimated size of work products to be inspected
• Risks
• The number of planned inspections
• Planned effort to be spent on inspections 33
Inspections Process
Inspection Planning: Exit Criteria
• There is a project plan showing the inspections
to be held, including resources and milestones
that may be known in the early stages of the
project
• Where milestones may not be known a
boundary of probable dates should be noted in
the plan for the inspections
• Adequate resources are allocated in the project
plan for inspections
34
Inspections Process
Inspection Scheduling: Responsibility
• The project lead is responsible
• For requesting, selecting, or assigning Moderators
when a work product approaches inspection readiness
• For ensuring the work product will be ready for
inspection
• For ensuring that the participants are made available
• For making known to a qualified Moderator that an
inspection is to be scheduled

35
Inspections Process
Inspection Scheduling: Other Roles
• The moderator with the project lead is
responsible for completing inspection scheduling
• This includes
• Agreement on a specific date
• Ensuring that entry criteria is met
• Completing all logistics requirements
• Scheduling the participants and inspection activitites

36
Inspections Process
Inspection Scheduling: Entry Criteria
• A work product is approaching inspection
readiness
• Resources are available
• The project lead makes a request to a moderator
for an inspection or a set of inspections

37
Inspections Process
Inspection Scheduling: Tasks
• Send a notification that an inspection will be
needed
• Determine the inspection meeting date
• Ensure that the work product to be inspected
meets entry criteria
• Schedule the inspection meeting

38
Inspections Process
Inspection Scheduling: Validation/Verification
• The moderator remains actively involved during
the inspection scheduling period and is
responsible for assuring that all tasks up to
completion of the inspection meeting are
performed
• The SQA groups ensures that a moderator has
been assigned
• Data gathered during this activity includes
• How much in advance the project lead is sending
notification to the moderator
• How long is the period between notification and the
inspection meeting 39
• How many inspections required postponement
• Actual versus planned inspections
Inspections Process
Inspection Scheduling: Exit Criteria
• The inspection activities have been recorded as
Performed on the scheduled dates and Closed
within the dates determined at the inspection
meeting or rework

40
Inspections Process
Overview
• Provides the inspection participants a background
and understanding, when warranted, of the
scheduled inspection material
• An overview is not an inspection meeting
• If inspectors are sufficiently familiar with the work
product, the overview can be skipped
• Another reason for an overview meeting, is to
identify any open issues in the work product
• An open issue is an acknowledgement of the fact
that a subpart of the work product is not complete
for some reason
• The producer may want focus the inspectors on 41
subparts that are problematic or of some concern
Inspections Process
Overview : Responsibility
• The producer’s primary responsibility for the
success of the overview meeting is to deliver the
presentation
• If overview material is provided, it is the
producer’s responsibility to make sufficient
copies for the meeting either directly or via the
moderator

42
Inspections Process
Overview : Other Roles
• The moderator determines with the project lead
whether an overview is necessary, schedules the
overview meeting, obtains the meeting room,
and records the time of the meeting, the
number of participants, and the results of the
meeting
• Inspectors participate during the overview
meeting and must concur that the overview met
the exit criteria
43
Inspections Process
Overview : Entry Criteria
• A project lead has sent notification for an
inspection
• The inspection requires a mandatory overview,
or criteria for an optional overview has been
satisfied; e.g.,
• Complexity of the work product solution
• Volume of material in the work product
• Criticality of the work product
• Customer requirements
• The producer is ready to present the overview
44
• Open issues and any potential problem areas are
highlighted
Inspections Process
Overview : Tasks
• Producer prepares for the overview using a format
and style that will best convey the information to the
participants
• Moderator invites the participants to the overview
meeting
• Producer presents the overview
• Inspection team members concur that the overview
satisfies the needs for preparation and inspection
meeting
• Any open issues are documented in the inspection
report
• If the overview is used to familiarize the participants
with their roles, the inspection process, or some
other aspect key to this inspection, the moderator 45
will provide this briefing
• Defects, if any, are documented
Inspections Process
Overview : Validation/Verification
• The moderator uses the work product overview
meeting entry criteria and procedure to
determine if a meeting is necessary
• The inspection team is in concurrence with the
decision taken to have an overview or not
• The inspectors have the responsibility to state
that the overview, when held, is satisfactory for
their preparation and subsequent inspection
meeting
46
Inspections Process
Overview : Validation/Verification
• The SQA group ensures that the moderator has
used the overview meeting criteria and ensures
an appropriate decision was made to have an
overview or not. This can be done via audits of
the process records or sampling of inspections
• Data gathered during this activity
• How much participant time was spent in the overview
• The clock time for the overview
• Time between notification and the overview meeting
• How many overviews required rescheduling
• How many defects were identified at the overview 47
Inspections Process
Overview : Exit Criteria
• The overview meeting was determined to be
satisfactory by the inspectors and SQA
• Open issues are documented
• Potential problems areas are noted to the
participants for preparation and for the reader
for the inspection meeting
• Defects, if any, are documented

48