A Software Inspection Exercise for the Systems Analysis and Design Course

Journal of Information Systems Education, Fall 2006 by Tyran, Craig K

ABSTRACT

Software inspections have been found to be one of the most effective ways to promote quality and productivity in software development. Inspections are an especially important tactic to use during the analysis and design phases of software development since the correction of a defect found early in development can be 10 to 100 times less expensive to fix than rework performed at the system testing stage. Given its prominence within the software field, it is surprising that the software inspection process does not receive more attention with respect to education in the area of Systems Analysis and Design. The purpose of this article is to present an experiential exercise for the Systems Analysis and Design course that may be used to promote learning with respect to the software inspection process. The focal point of the exercise is a system specification document that describes the user requirements for a system for a fictional real estate company. The specification document includes three components that are typical of a specification document: a descriptive narrative overview, a project dictionary, and data flow diagrams (DFDs). Survey results regarding students' perceptions of the exercise are also discussed.

Keywords: software inspection, software quality, systems analysis, education, data flow diagram, system specification

1. INTRODUCTION

Software inspections have been found to be one of the most effective ways to promote quality and productivity in software development (Gilb and Graham, 1993; Laitenberger and DeBaud, 2000). The software inspection is a peer review in which a small group of software developers examine another software developer's work. The primary purpose of a software inspection is to identify defects existing within software work products developed throughout the development process (e.g., user requirements specifications, design documents, code). Data collected during the inspection process is used not only to correct defects, but also to evaluate and improve the development process itself. Reports from industry indicate that inspections have gained wide acceptance as a development tactic and can take up to 15 percent of the time allotted to a software project (Ackerman, Buchwald, and Lewski, 1989). Based on the demonstrated value of software inspections, more than one industry expert has listed the software inspection process at the top of the list of desirable software development practices (Boehm, 1987; Glass, 1999).

While inspections have been found to be worthwhile for all phases of the development process, it is an especially important tactic to use during the analysis and design phases of software development since the correction of a defect found early in development can be 10 to 100 times less expensive to fix than rework performed at the system testing stage (Boehm and Basili, 2001; Doolan, 1992; Pagan, 1986). Given its prominence within the software field, it is somewhat surprising that the software inspection process does not receive more attention with respect to education in the area of Systems Analysis and Design. The purpose of this article is to present an experiential exercise for the Systems Analysis and Design course that may be used to promote learning with respect to the software inspection process. The next section provides a brief overview of the stages and guidelines for the software inspection approach. Second, the experiential exercise and the associated exercise materials are discussed. Third, survey results regarding students' perceptions of the exercise are summarized. The article concludes with summary comments.

2. SOFTWARE INSPECTION PROCESS: STAGES AND GUIDELINES

Software inspections were initially introduced and formalized by an employee of International Business Machines (IBM) named Michael Pagan in the early 1970s (Pagan, 1976). As described by Pagan, the software inspection process is a formal process encompassing six stages (Pagan, 1986). While some aspects of the inspection process have evolved over the years, Pagan's stages continue to serve as the basis for software inspections. Pagan's six stages are:

* Planning: Determine that the materials that will be inspected will be suitable. Also, arrange the participation of the appropriate people and a meeting place and time.

* Overview: Educate the inspection meeting participants about the piece of work that will be inspected. Assign roles to the participants (e.g., scribe, moderator).

* Preparation: Participants do their "homework" and work individually to get familiar with the piece of work.

* Inspection: The sole purpose of the inspection stage of the process is to find defects. Developing alternate solutions or redesigning the materials under inspection is strongly discouraged.

* Rework: The author resolves all of the defects documented.

* Follow-up: The team moderator or the entire inspection team checks on the author's rework to make sure that all of the corrections are effective and that no new defects have been introduced.