Abstract

This capstone projects seeks to define, architect, and deliver a software project which assists in the automation of the software inspection process. We will define here the software inspection process, discuss motivation for automating the process, and describe at a high level the goal of project in assisting this automation.

Introduction

The software inspection is defined by Humphrey as a "detailed technical peer review of software designs or implementations." [1] While software inspection is an essential part of the software process and is effective in removing defects early in the cycle, at least three other benefits are accrued. First, the inspection ensures that any code change is in keeping with the original intent of the system, not merely a bug fix. Second, expertise is developed in the team which builds skills necessary later in maintenance activities. Third, knowing that their efforts are going to be formally inspected, the programmer is apt to do a better job in producing easier to read, better documented, and thus more maintainable code. While this project primarily focuses on the inspection of software source code, it is relevant to note that the inspection process is applicable across the range of software process activities and to their respective artifacts.

Unfortunately, software inspection is not often an activity looked on with great fondness by most programmers in spite of its many benefits. The are many reasons for which to attribute this lack of enthusiasm. Programmers are typically under time pressures for completion of software deliverables and through inspections are intensive in time needed for preparation. The results of a successful inspection are real, but intangible. Defects are removed earlier in the cycle at a lower cost, but often the exact numbers and classification of errors found by inspection are recorded by hand and filed away in a drawer. The benefits actually accrued then are not measured, and management does not recognize neither the time devoted to the review nor the precise benefits realized.

The purpose of this project is to develop automation of software inspection as a beneficial part of the software engineering process. The inspection process itself will be discussed to provide a common ground for understanding. Motivation for automation of the process will be discussed. Finally, the high-level goal for the project will be presented.

The Software Inspection

The acknowledged father of the software inspection is Michael Fagan who introduced inspections at IBM in the mid 1970's [2]. The purpose of the inspection is to identify defects in the inspected artifact, not to judge the performance of the producers of the artifact. This fine distinction is key to a successful inspection process. Since its introduction, the inspection has been adapted by many, but many of the core principles are common:

• An author of the artifact to be reviewed indicates the artifact is ready to be reviewed.
• In accordance with the software process in use, a set of roles are assigned to participants. Typically, these include:
• Inspectors - responsible for reviewing the artifacts.
• Moderator - responsible for scheduling a review meeting and ensuring the meeting follows the defined process.
• Scribe - responsible for noting issues and defects identified at the meeting and metadata concerning each item.
• Reader - responsible for presenting an understanding of the artifact at the meeting. Depending on the process used, may be indistinguishable from the Inspector role.
• Author - the originator of the software artifact. This role should not be combined with Inspector, Moderator, or Scribe, but some processes allow it to be combined with Reader.
• The inspectors of the artifact invest time preparing for the meeting by examining the artifact.
• A meeting is conducted to review the artifact where each participant performs their role as described above.
• Each issue raised at the meeting is classified by mutual agreement as a defect or not a defect. A summary of defects and issues are produced from the meeting and serve as a quality record of the inspection.
• After the completion of the inspection meeting, the author resolves each issue or defect resulting from the meeting.
• A follow-up inspection may be held depending on the process in use.

The review may be facilitated by a checklist of items that the inspectors use in reviewing the artifact. Portions of this checklist may even be assigned to specific inspectors to further focus their review efforts.

Motivation

Software inspections work to identify and correct defects early in the cycle, and increase expertise in the team, but why do inspections need help of the technology? An answer to this can be seen in the difficulties mentioned earlier which provide ample motivation for automation of the inspection process. In resolving these difficulties, certain benefits of automating the inspection process expected are:

• Collection of inspection results - this not only enables the gathering of quality metrics useful for process improvement, it could alleviate much of the redundant work of the Scribe role. In addition, the quality improvement benefits resulting from the inspection are more visible to management.
• Collection of inspected artifacts - the precise versions of software artifacts which were reviewed can be collected. Together with the above, they serve as the quality records of the inspection and are available to be audited. In addition, the repository of inspection results eases communication among participants. Viewing the artifacts and collecting comments online reduces the need for paper printouts of the artifact saving time and money.
• Support for widely distributed inspections - more and more development work is being performed intercompany in widely dispersed geographic locations. Automating the inspection process better supports these participants in today's global collaboration.
• Ensure participant preparation and contribution - with more visibility on the results of the inspection due to the automated collection of results, and with the knowledge their contributions are valued and beneficial, participants have added incentive to devote appropriate time and energy to preparation.
• Reduce administrivia and bookkeeping - the central benefit of automation should be reducing the amount of paper and record keeping required of a software professional so they may devote more time producing quality software.

Keeping these expected benefits in mind, in the next section we will establish the goals for this capstone project.

Capstone Project Goal

The goal of this capstone project is to produce the benefits listed previously by developing a software project which improves the inspection process. Given limits of resources and time, the project will not seek to automate the entire process, but will instead focus on the area which should result in the most gain from automation. This area is the inspection preparation phase where the inspectors of the software are reviewing the source and recording their comments in preparation for the inspection meeting.

A follow-on document will address the specific requirements for automating the inspection preparation phase.

References

[1]

W. Humphrey, Managing the Software Process, p. 463, Addison-Wesley, 1990.

[2]

Fagan, M., "Design and Code Inspections to Reduce Errors in Program Development." IBM Systems Journal 15, pp 182-211, Vol 3 1976.