Introduction To Software Reviews

What are software reviews?
- serves as a “filter” for the software engineering process.

Purpose: Software reviews serve to uncover errors in analysis, design, coding, and testing and are hence invaluable.

Why do software reviews? The general principle behind doing reviews are:
- To err is human.
- It may not be easy to catch the errors in engineers’ work, the kind of errors that are not found in bugs.
- Finding errors early in the process is always more efficient than detecting errors much later in the cycle.

A review is a way to :
- identify needed improvements of the various parts and modules of a product.
- confirm the improvement areas of a product (if the improvements had been suggested by others).
- achieve technical work that can be more uniform, predicable, and manageable, making for a more better end result and a smoother cycle.

What are the different types of reviews:
- Informal reviews : informal meeting and informal desk checking.
- Formal reviews : Walkthrough, inspection, and round-robin reviews.

Formal Technical Reviews are used to improve work products. As a part of this process, any deliverable that is produced during the development life-cycle is eligible to be reviewed and should be picked up for review starting at an early stage, beginning in the specification stage and recurring at each identifiable milestone.

- A Review meeting is an important part of the of FTR (Formal Technical Review). There are are some essential parameters for the meeting, such as
1. There should be a reasonable number of persons conducting the meeting, not being a free-for-all
2. Each one of them should have done his/her homework and other preparation
3. The meeting should not be carried out for very long and should have a well defined agenda to avoid wastage of time. The duration should be just enough to churn out some constructive results.
4. The Formal Technical Review is effective when a small and specific part of the overall software is under scrutiny.
5. A review is more productive when the review artefacts have been broken down into small modules that can be reviewed independently. The target of the FTR (Formal Technical Review) is on a component of the project, a single module.

- Record keeping and reporting are additional quality assurance activities. They are applied to different stages of software development. During the FTR, it is the responsibility of reviewer (or recorder) to record all issues that have been raised.
At the end of review meeting, a review issue list that summarizes all issues, is produced. A simple review summary report is also compiled. A review summary report answers the following questions.
1. What was reviewed?
2. Who reviewed it ?
3. What were the findings and conclusions?

- Review Guidelines : A minimum set of guidelines for FTR:
* Review the product, not the producer.
* Set an agenda and maintain it.
* Limit debate and rebuttal.
* Enunciate problem areas, but don’t attempt to solve every problem noted.
* Take written notes.
* Limit the number of participants and insist upon advance preparation.
* Develop a checklist for each work product that is likely to be reviewed.
* Allocate resources and time schedule for FTRs.
* Conduct meaningful training for all reviewers.
* Review your early reviews.