Inspections for Software

a
two day workshop

If you are not yet using Inspections,
start with this course!

Why Take This Workshop?

• You want to effectively remove defects before the start of test
• You need to develop backup knowledge in software areas
• You want to learn a method that has been applied successfully for over 25 years by many different software organizations
• You want to learn how to avoid the mistakes others have made when using the Inspection method
• You want to improve the quality of your products
• You want to decrease your test costs
• You want to reduce your product maintenance costs
• You want to decrease time to delivery of software solutions
• You want to understand how to use Inspection materials

What Will You Learn?

• The essentials of the Inspection method
• How to perform effective and efficient Inspections for
  • Requirements
  • Design
  • Code
  • Documents
• How to apply Inspections to other life cycle activities and work products
• How to improve your Inspection process
• How to develop and use checklists
• How to read documents for successful Inspections
• What data to collect
• How to use Inspection data to maximize quality, cost, and cycle time objectives for your organization
• What not to inspect
• How to successfully start using Inspections
• Examples of successes others have experienced
• The roles members of the Inspection team perform
• How to develop an Inspection policy
• How to determine the effectiveness of your organization's Inspections
• How to quantify the business value of Inspections
• Inspections and Peer Reviews in the SEI's Maturity Models CMM® and CMMI
• Practical metrics for Inspections
• How to reduce Cost of Test and Cost of Quality
• How to tailor Inspections
• How to be selective in what is inspected without compromising effectiveness

Why Inspections?

So what’s the problem?  Why do we need Inspections?  The primary value that Inspections always posited is that it is cheaper to remove defects earlier in the software life cycle than later.  The question originally was not how to prevent defects from occurring, but to remove them at a lower cost.  In figure 1.1 the curve from START to Code represents the number of defects that enter into the production processes of requirements analysis, high level design, low level design, and code in a development project.  This curve shows no pre-test defect removal activities.  Consequently each test activity (unit (UT), integration (IT), and system (ST)) will find and remove some volume of generated defects.

                                                             Figure 1.1

In a well-behaved series of tests we would expect the number of defects removed to decline in each subsequent test activity as shown in figure 1.1.  The gap that remains at the end of ST represents the latent defects and the potential to be found by the users.  More will be discussed about these curves in Chapter 9, The Economics of Inspections.

Had we tried to deliver the product at the conclusion of coding, we would clearly not have had a working product due to too many defects and the resultant instability.  We can assume that the defects found by the users will usually require resolution and repair and that repair will be an added cost to the project or organization.  There is also a cost to remove defects during test and when users find defects.  These costs will vary for a number of reasons, such as, the number of defects entering from each production activity, the types and severities of defects, the quality policy in the organization.

With Inspections we can change these problems.  In figure 1.2 the same curve (A) is shown as before and an additional curve (B) represents defects remaining after  removal by Inspections prior to testing from requirements through code phases. We assume the same approximate test defect removal effectiveness for ease of presentation.  In this example the assumption is only 50% effectiveness for Inspections.  Effectiveness here means the percentage of defects removed by Inspections of all the generated defects.  In Chapter 9, The Economics of Inspections, will discuss how we can come to know the actual effectiveness.  For now, let us assume we have this knowledge.

                                                             Figure 1.2

Let us now assume that test is approximately as effective in this scenario as it was in the example shown in figure 1.1.  Thus additional defects are removed during test, but we have not removed all the injected defects.  There is still a gap of latent defects that the users could potentially find.  In this scenario the gap is smaller, however, due to the defects removed by Inspections.  This reduced gap represents a quality improvement in defectiveness delivered to the users.

The relationship of costs to remove defects in production, test, and post-test was first shown in 1976 in Mike Fagan’s article based on the study we performed in IBM during the first release of the telecommunications subsystem VTAM.  Subsequent studies reconfirmed these results with the same nominal cost relationships.  Figure 1.3 shows these relationships as factors of increasing costs.  Thus, if it costs on average $10 to remove a defect in Inspections, it will cost $100 in test, and over $1000 when a user finds a defect. 

                                                            Figure 1.3

There are other aspects that make the reasons for doing Inspections more compelling, but if it were only for cost reduction the Inspection process is well worthy of consideration.  The ancillary benefits to cost will be discussed in a later chapter.

Who Should Attend?

• Managers interested in successfully implementing Inspection programs and using the data
• Engineers and technical writers who want to learn how to maximize software quality and minimize costs
• Agents of change, including SEPG and Inspection champions, interested in introducing a method which has significant quality and productivity potential

Workshop Outline:

The two-day course has the following of modules: 

1.      Introduction

·        What are Inspections?

·        Some common concerns with Inspections

2.      Use of Inspections

·        Business reasons for Inspections

·        History of Inspections

·        Relationship to SEI 's SW- CMM®

3.      Inspection Method

·        Inspection activities

·        Selecting what to Inspect

·        Readiness criteria

·        Resources required

·        Inspection effectiveness

·        Effectiveness versus efficiency

·        Generic Reading rules

4.      The Moderator role

·        Guidelines for selecting moderators

·        Roles of Inspection team members

·        Behavior at Inspections

·        Use of Inspection data

·        Checklists

5.      Management’s Role

6.      Applying Inspections to Requirements

·        What to consider when inspecting requirements documents

·        How to read requirements documents

·        Requirements Inspection exercise

7.      Applying Inspections to Design

·        What to consider when inspecting design documents

·        How to read  design documents

·        Design Inspection exercise

8.      Applying Inspections to Code

·        What to consider when inspecting code

·        How to read code

·        Code Inspection exercise

9.      Applying Inspections to Other Work Products

·        Other types of documents

·        Test plans and test cases

·        Other types of plans

·        Maintenance

10.  Alternatives to Inspections

·        Reviews

·        Walk-throughs

·        Other approaches

11.  Introduction to Optimizing Inspections

·        Moderators

·        Analysis and use of data

·        Examples of Inspection data analysis

·        Preparations lists

12.  Starting to Do Inspections

·        What to inspect

·        ETVX description of Peer Reviews in the SEI 's SW-CMM®

·        Inspections in ISO 9001  

·        What needs to be done to make Inspections successful in your organization?

·        Doing what makes sense

·        How to schedule "Just-in-time" Inspections

·        How to inspect fixes

·        How to measure for success

·        What prevents success?

Student Materials:

High Quality, Low Cost Software Inspections by Ronald A. Radice.

Send mail to webmeister@stt.com with questions or comments about this web site.
Copyright © 2006 Software Technology Transition
Last modified: March 22, 2008