Separation of Reading from similar Methods/Techniques

In the software engineering community, other methods such as reviews or audits are described to verify and validate software documents. The differences between reading and those methods are discussed in this section. As there is a lot of confusion in the use of the terms review, walk-through, inspection, and audit, we will first define them and explain afterwards the differences from reading. For the definitions we follow the IEEE-standard.

• Review
  A process or meeting during which a work product, or a set of work products is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code reviews, design reviews, formal qualification reviews, requirements reviews and test readiness reviews.
• Walk-through
  A static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of documentation or code and the participants ask questions and make comments about possible errors, violation of development standards and other problems.
• Inspection
  A static analysis technique that relies on visual examination of development products to detect errors, violations of development standards and other problems. Types include code inspections and design inspections.
• Audits
  An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements or other criteria
• Reading
  A technique that is used individually in order to analyze a product or a set of products. Some concrete instructions are given to the reader on how to read or what to look for in a document. Reading is embedded in methods like inspections, audits or reviews. Therefore it is used as a technique for verification in the software development process (Here reading is used to find defects).

In order to make the differences between these terms more clear, we use a table which can be found in [Mar94] and extend that table with reading:

The verification of a software document (e.g. requirements document, design document) in either a review, audit, inspection or walkthrough starts with reading the document by each reviewer. This is done either before or throughout a meeting. At the moment there is only little support (in form of checklists) for the reader of how to read the document. After reading the document (if it is not done throughout the meeting) there is a meeting in which the reviewers analyze the software document to discuss the defects they have found during the reading process and to look for more defects. During the meeting the different defects are collected. The next step is that the defects are removed and then the process starts again.
Figure 2.1 summarizes this process:

How often this cycle is repeated depends on the method and the desired quality of the software document. The quality attributes have to be described earlier in the software development process.
There are several studies about the best way meetings should be held to be most efficient [Fag76]. It is our belief that the efficiency of the meetings is directly linked with the preparation for them by providing adequate techniques for the reading process. In that case reading should be seen as a technique to prepare for meetings.
As mentioned earlier there is no actual description of how reading is or should be performed for the inspection process. In order to achieve the desired effect, the reading technique should have certain properties. These properties are described in the next section.

Web Accessibility