Subject: Software Engineering

Topic: Software Project Scheduling.

Difficulty: Medium

FORMAL TECHNICAL REVIEWS

A formal technical review is a software quality assurance activity performed by software engineers (and others).

The objectives of the 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.

Steps in FTR:-

1. The review meeting

Every review meeting should be conducted by considering the following constraints- Involvement of people

Between 3 and 5 people should be involve in the review.

Advance preparation Advance preparation should occur but it should be very short that is at the most 2 hours of work for each person can be spent in this preparation

Short duration The short duration of the review meeting should be less than two hour.

2. Review reporting and record keeping

During the FTR, the reviewer actively record all the issues that have been raised. At the end of meeting these all raised issues are consolidated and review issue list is prepared. Finally, formal technical review summary report is produced.

3. Review guidelines

Guidelines for the conducting of formal technical review must be established in advance. These guidelines must be distributed to all reviewers, agreed upon, and then followed. For example,

Guideline for review may include following things Concentrate on work product only. That means review the product not the producers. Set an agenda of a review and maintain it. When certain issues are raised then debate or arguments should be limited. Reviews should not ultimately results in some hard feelings. Find out problem areas, but don’t attempt to solve every problem noted. Take written notes (it is for record purpose)

WALKTHROUGH

Walkthrough: Method of conducting informal group/individual review is called walkthrough, in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems or may suggest improvement on the article, walkthrough can be pre planned or can be conducted at need basis and generally people working on the work product are involved in the walkthrough process.

The Purpose of walkthrough is to:

· Find problems

· Discuss alternative solutions

· Focusing on demonstrating how work product meets all requirements.It recommends three specialist roles in a walkthrough.

Leader: who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author)

Recorder: who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meeting, normally generate minutes of meeting at the end of walkthrough session.

Author: who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items.