Type Inspection Process

Contents

• Overview
• Objectives
• Entry Conditions (Pre Lab)
• Exit Conditions (Post Lab)
• Tasks

Overview

The mapping from the requirements document to the source code for the data objects/elements can be difficult. The choices the programmer makes can heavily influence the programmer's ability to write the tasks required. Typically we discuss mostly algorithms and procedures. Now, we want to look carefully a the data, early in the development process.

Objectives

The objectives of the type inspection activity are to:

• Insure that all the required data elements are present.
• Insure that choices for types are driven by the needs of the program, as seen from the requirements perspective.
• Insure that the choices for types are consistent with the data definition provided.
• Complete rough estimates on data element sizes.

Entry Conditions

The type inspection can begin when:

• The coded type definition has been prepared.

Exit Conditions

The type inspection is complete when:

• Recorder submits the notes from the inspection.

Tasks

Tasks that should be completed as part of the type inspection activity are:

1. The program author completes the type definition and submits copies to the reader and recorder. This should occur the day before the planned inspection.

2. The two readers (the recorder is a reader with added responsibilities) review the type definition against the SRD. Using the Review Checklist for guidance, prepare questions and comments for the author.

3. The inspection team meets. The author begins a general discussion of the type definition beginning from the elements proceeding down to the low level elements. Each element should be described by its purpose and how it will be used. The two readers insure the author's descriptions are consistent with the requirements. The recorder captures the remarks during the discussion.

4. The readers complete the Review Checklist which is submitted (electronically) to the author.