1 Introduction

Software inspection is a powerful tool to improve the quality and productivity of a software process. It was invented by M. Fagan at IBM in 1976 [4]. Software inspection was successfully adopted in procedural programming paradigm [1] to defect and fix defects early in the process. However, in Object-Oriented programming, benefits of software inspection have been skeptical and sometimes not cost-effective. Software inspection involves a variety of software artifacts such requirement documents, design documents, test documents, and code. These inspections contribute to the quality and production of the software process.

The scope of this search focuses only the code inspection (hereafter used interchangeably by inspection), discussing its costs and benefits, and analyzing how it is adopted to a real software development process (hereafter used interchangeably with development process).

The paper centers on: summary of literature reviews, summary of discussion with an experienced practitioner, personal experiences, discussion and conclusion. The literature review provides academic insights into a software inspection?s process, techniques, costs and benefits. The interview section discusses practical feedback of software inspection in a real project. The personal experience section shares the author?s experience in a process to integration a software inspection into a project. The discussion section centers on the pros and cons of the software inspection, and also focuses on how an inspection process can be adopted to software development process. The conclusion section summarizes of the paper.

2 Literature Review

2.1 Definition of Software Inspection

A formal software inspection is defined as a formal tool, process, or method to detect and correct errors in work products (design document, testing document, code, etc) in each phase of software development process. The inspection shall be formal, efficient and economical [2].

2.2 Objective of Software Inspection

The primary objective of the software inspection is to detect and correct defects early before they leak into subsequent phases. This improves the quality and productivity of a software development. Generally, a software inspection is used as an exit criterion for coding [4]. Coding is not considered complete unless it passes a code inspection process. A software inspection may also act as a mean to ensure that appropriate parities are technically agree on the work, and the work meets pre-defined standards or conventions [3].

2.3 Inspection Process

Fagan [2] defines an inspection process a set of five activities: overview, preparation, inspection meeting, rework and follow-up. In the overview, an owner goes over a work product under inspection, providing inspectors understanding and background of the work product. In the preparation, each inspector reviews a work product on his own, and lists down all questions and defects discovered. At the beginning of the inspection meeting, moderator collects lists of defects and questions found in the preparation, and hands over then to a owner of the work product. During the inspection meeting, a reader reads the code, and moderator instructs inspectors to perform inspections. A recorder records all defects and questions. When the meeting is over, the owner collects all questions and defects for reworks. Each session of the inspection meeting is recommended for less than 2 hours. In the rework, the owner goes back and resolves all problems found by the inspection. After all problems are resolved, the moderator decides if a follow-up session is needed. Ronald A. Radice [5] adds to Fagan?s process the following activities: planning & scheduling; analysis meeting; prevention meeting; inspection process monitoring; and data recording and reports. The inspection monitoring and data recording and reporting are performed throughout the inspection process.

In the Inspection Planning, the Project Lead is responsible for determining what to be inspected, and estimating resources for inspections allocate budges. In Inspection Scheduling, The Project Lead is responsible for requesting, selecting, or assigning Moderators when a work product approaches Inspection readiness. A notification about inspections is sent and inspection meeting date and schedule are determined. The Analysis Meeting is intended to provide inspectors a time period to analyze defects found and their causes. The Prevention Meeting is optional and held periodically after a series of inspections have been completed. The Prevention Leader for the Prevention Meeting will record result of this meeting, and propose an action plan to the management. The Inspection Monitoring is help concurrently with other activities and after inspections. The Inspection Process Coordinator or SEPG is responsible for monitoring and suggesting improvement. The Data Recording and Reporting is performed during the Overview, Inspection Meeting, and optional Analysis Meeting. The Recorder records data about the defects and the conduct of the inspection, using templates, database, etc.

2.3.1 Procedure for each activity of the inspection process

Radice [5] suggests that inspectors follow a procedure for each activity in an inspection process to gain knowledge and perform the activity effectively. This procedure includes such sections as: introduction, responsible individual, other roles, entry criteria, tasks to be performed, validation/verification, and exit criteria.

2.3.2 Techniques for Code Inspection

Dumsmore et al. [1] discusses three techniques used by inspectors to inspect code in Object Oriented (OO) paradigm. The three techniques include: checklist-driven, use-case driven, and abstraction-driven.

The checklist-driven technique has been used by software inspectors since the beginning of the inspection era in the late 1970s. This is considered as a static technique. It provides a series of specific questions on common sources of defects as for ? where to look,? and ?how to detect.? Its principle is to have inspectors to look into areas such as: inheritance, class constructor, data referencing, object messaging, selection, iteration, method behavior, and method overriding.

The use-case driven technique supports inspection of the dynamic execution of the system. It devises scenarios from use-cases and scrutinizes how an object under inspection responses to each scenario. It seeks to verify the correctness and consistency when methods are invoked, decisions are made, and states are changes. Its aim is to force an inspector to consider the context in which the object is used.

The Abstraction-Driven technique focuses on creating abstract specification of classes for the system under inspection. It checks interdependencies in classes and methods (coupling) across the system and dependent libraries. The fundamental idea is to enforce an inspector to create an abstract specification from the code, which benefits current and future inspections. This technique is attempting to address an inspection problem? the resolution of frequent nonlocal references ? caused by the concept of delocalization. The abstraction localizes the ?reference delocalization.?

2.4 Benefits of Inspection

2.4.1 Code inspection improves code quality

Don O'Neill [6] quotes that a code inspection detects and removes 50 percent of the defects present early in development phase for an organization with adequate training in an inspection process. For organization with expert practices (IBM, AT&T, etc.), detection rate is up to 83 percent (for IBM) and 92 percent (for AT&T). This early detection and removal of defects improves the code quality before the code is delivered to next phase.

An inspection also pays enormous dividends in quality of software maintenance. Watts S. Humphrey [3] quotes that 55 percent of one-line maintenance changes were in error before the introduction of inspections and, immediately after, the error rate dropped to 2 percent.

Additionally, an inspection increases the system reliability. Humphrey quotes that the inspection in software maintenance reduces the number of production crashes by 77 percent. Design quality is also improved by a code inspection. The inspection techniques improve for design quality by removing: redundant logic, unused variables, incorrect Boolean tests, comments that don't match the code, and other un-handle exception. The inspection also provides opportunity for refactoring to get better quality of code and design.

2.4.2 Code inspection increases productivity

Humphrey [3] quotes that development productivity increases by 14 percent of a project in AT&T Bell Laboratory. This project of approximately 200 professionals instituted several changes, including inspections.

2.4.3 Code inspection reduces costs

Early detection and correction of defects reduce significant number of reworks and associated costs, and also shorten software lifecycle. Don O'Neill [6] asserts that a defect leaking to the test costs 9 times to detect and correct than if it is found and fixed in the coding phase, and it costs 13 times more if it leaks to the fields.

Don O'Neill [6] also indicates that a software inspection provides a return on investment (ROI). Don O'Neill conducted a study in 1991 gathering data on defects and inspection practice in dozens of companies organized by software process maturity level, organization type, product type, programming and global region. The study has shown that companies who use inspections have a return on investment ranging from 4 to 5 dollars saved from every dollar spent.

2.4.5 Code inspection promote team relationship and education

Inspection process enable developers share their works and expertise across the team, and encourages developers to work together to deliver quality code. Discussions and defects analysis are conducted on the base of professional and team morale, not personal motivations. By integrating developers from other project, the inspection promotes relationship and close communication within a project and cross projects. Developers get to know each other and increase their relationship.

It is recommended to include one or two novices in an inspection. This enables novices learn from experienced developers, and also understand more about the project. The novices get familiar with the code quality standards and inspection process, and improve their productivity.

2.4.6 Code inspection promotes a culture of quality

Software inspection promotes a quality-oriented culture. According to Humphrey, code inspection encourages programmers to work more carefully either to avoid being embarrassed by sloppy mistakes or through the pride of exhibiting a quality work product. By enlisting others in identify their errors, developers actually end up doing better work themselves. The inspection makes it clear that quality code is what the organization expects.

2.5 Cost of Code Inspection

Although recognized as a technical best practice, inspections are slowly adopted into the software development processes. According to Don O'Neill [6], only 22 percent of organization assessed by the Software Engineering Institute practiced software inspections. This is due to the facts that software inspection is associated with costs. The following sections summarized some inspection costs observe red by practitioners.

2.5.1 Inspection direct costs

Bob McCann [7] defines a total direct cost of an inspection as a sum of costs for fixes, regression tests, preparation, meeting, and reworks. He gives the following equation:

        Total Cost = (inspection fixed cost) 
               + (regression fixed cost)
               + (inspection preparation plus meeting cost)
               + (inspection rework cost)
               + (test rework cost plus regression cost)

Each cost item in the equation includes quantified metric of times and efforts used by each activities in the inspection process. Don O'Neill [6] estimates that it costs on average two person-months to establish a functional database for storing an inspection data.

2.5.2 Inspection indirect cost

One of an indirect cost of an inspection is training moderator and participants in the inspection process. According to Don O'Neill [6], to acquire the knowledge, skills and behaviors cost about 12 hour per participant. Managers are also trained in how to initiate inspections and interpret the data they produce. This takes about four hours.

The inspection is a time consuming and labor intensive process. An inspection involves at least fix or six people which include talent and experience developers. Based on scope of work products and coverage, inspection may take multiple 2-hour sessions. To build up experiences in the process, it is time. Don O'Neill [6] asserts that it can take from 12 to 18 months to achieve expert practice which attains a defect detection rate of 60 to 90 percent.

2.5.3 Cost of an ineffective inspection

According to Humphrey [3], factors contributing to an ineffective inspection include inadequate training, lack of experiences, insufficient resources available, management inattention, and schedule pressure. Either the preparation was not enough, too many people were involved, the wrong people attended, or too much material was covered at one time.

Ineffective inspection may send misleading message to developers. Developers may consider an inspection as a mean for performance evaluation. Low-experienced developers are not comfortable to expose their works, and sensitive to an inspection report. An inspection may be turned to an offense-defense game. Inspectors are pointing out defects while the owner is defending his works. An inspection can become a pro forma exercise in which the inspection effort is expended but the desired results are not obtained [3].