Short note on Reviews Guidelines
- Review the product, not the producer.
- Set an agenda and maintain it.
- Limit debate and rebuttal.
- spending time debating the question, the issue should be recorded for further
discussion off-line.
- Enunciate (Identify) problem areas, but don't attempt to solve every
problem noted.
- Review is not a problem-solving session. The solution of a problem can often
be accomplished by the producer alone or with the help of only one other
individual. Problem solving should be postponed until after the review meeting.
- Take written notes.
- Limit the number of participants and insist upon advance preparation.
- Develop a checklist for each product that is likely to be reviewed.
- Allocate resources and schedule time for FTRs.
- Conduct meaningful training for all reviewers.
- Review your early reviews.
Short note on Formal Technical Reviews. (FTR)
- Formal technical review (FTR) is a software quality control activity performed by software engineers (and others).
- The objectives of an FTR are:
- (1) To uncover errors in function, logic, or implementation for any representation of the software;
- (2) To verify that the software under review meets its requirements;
- (3) To ensure that the software has been represented according to predefined standards
- (4) To achieve software that is developed in a uniform manner;
- (5) To make projects more manageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation
- The FTR is actually a class of reviews that includes walkthroughs and inspections
The Review Meeting:
- Every review meeting should abide by the following constraints:
- Between three and five people (typically) should be involved in the review.
- Advance preparation should occur but should require no more than two hours of work for each person.
- The duration of the review meeting should be less than two hours. Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of the overall software.
- For example, rather than attempting to review an entire design, walkthroughs are conducted for each component or small group of components.
Review Summary Report
- What was reviewed?
- Who reviewed it?
- What were the findings and conclusions?
The Players of Review Meeting
- Producer—the individual who has developed the work product
- Informs the project leader that the work product is complete and that a review is required.
- Review leader—evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation.
- Reviewer(s)—expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work.
- Recorder— a reviewer who records (in writing) all important issues raised during the review.
Short note on Informal Reviews
- Informal reviews include
- A simple desk check of a software engineering work product with a colleague,
- A casual meeting (involving more than two people) for the purpose of reviewing a work product,
- The review-oriented aspects of pair programming.
- A simple desk check or a casual meeting conducted with a colleague is a review.
- However, because there is no advance planning or preparation, no agenda or meeting structure, and no follow-up on the errors that are uncovered,
- the effectiveness of such reviews is considerably lower than more formal approaches. But a simple desk check can and does uncover errors that might otherwise propagate further into the software process.
What Are Reviews?
- Introduction : Software reviews are a “filter” for the software process.
- Reviews are applied at various points during software engineering and serve to
uncover errors and defects that can then be removed.
- Software reviews “purify” software engineering work products, including
requirements and design models, code, and testing data.
- Technical reviews – TR (Peer Reviews) are the most effective mechanism
for finding mistakes early in the software process.
- Six Steps are employed (Planning-Preparation-Structuring meeting Noting
error-Making correction-Verifying correction)
What Do We Look For?
- Errors and defects
- Error — A quality problem found before the software is released
to end users
- Defect — A quality problem found only after the software has
been released to end-users
- The primary objective of technical reviews is to find errors during
the process so that they do not become defects after release of the
software.
- The obvious benefit of technical reviews is the early discovery of
errors so that they do not propagate to the next step in the
software process.
Defect Amplification (Extension / Increase)
- A defect amplification model can be used to illustrate the
generation and detection of errors during the design and code
generation actions of a software process.
