formal technical review

A formal technical review is a method used to identify defects in an artifact before

progressing to the next stage of development. Unlike system testing, formal
technical reviews can take place at any stage in the development life-cycle, and as
such allow for the identification, documentation and correction of defects earlier
rather than later, therefore saving the company both time and money.
It is commonly accepted that not all organisations implement formal technical
reviews for various reasons ranging from ignorance of the benefits they provide
through to the effects they may have on time management aspects of the project.
However, standards organisations such as ISO and CMM are pushing companies in
the direction of formal technical reviews by insisting on some form of inspection to
be in place before offering certification.

FTR's must be scheduled at least a week in advance!

Be prepared: Read the presentation in Wonderful web resources, assign roles, know
your job.

Before the FTR:

 Ask for what you want. A written form is helpful, in which you prioritize your
needs, make specific requests from your reviewers about how you want them to
read your materials and the kind of critique you want.

 Limit the scope of materials to be reviewed. Be clear about the quality,

content, and focus of the feedback you would like to receive. Indicate whether
you want them to write a list of issues, put comments on the document, or
whatever.

 Don't demand more than 2 hours of preparation time from your reviewers.

 Arrange delivery of the work product in advance so reviewers have adequate

time to prepare.
  Reviewers: Spend no more than 2 hours individually critiquing the work
product. Usually you will be asked to create an issues list, referring to the
relevant QA criteria.

During the FTR:

 Moderator, usually QA leader, is responsible for running the meeting and

orchestrating how the issues are to be presented.

 Reviewers raise issues based on their advance preparation.

 Get the big problem issues on the table early. Don't get lost in minutely
small clerical details.

 Identify problems, don't solve them.

 Focus on material, not the producer

 Elicit questions, don't answer them.

 Don't explain how your product works. An FTR is not a product demo.

 Watch the clock and keep momentum to get through all the issues in the
alotted time.

 Recorder actively records all issues raised.

At the end of the FTR:

Reviewers must make a decision:

1. Accept - the product is acceptable as is.

2. Rework - accept the product provisionally, minor erors have been

encountered and must be corrected, but no additional review will be required.

3. Reject - the product has severe errors. You need to overhaul the item and
schedule another FTR.

After the FTR:

  Write up the issues list.

 Examine the issues raised, determine which to take action on.

 Assign each issue to someone as an action item and revise work product
as needed.

 Write review summary report:

 what was reviewed and when

 who were the participants and roles

 what were the findings and conclusions (especially Accept/Reject

decision)

 the issues list, and include "action taken" for each issue raised.

 Have reviewers sign off on summary report, indicating proper corrective

action has been taken for each issue.

 Include signed report in deliverable.

Review Guidelines

 Review the product, not the producer.

 Keep on track, don't drift.

 Limit debate and rebuttal.

 Enunciate problem areas, but don't attempt to solve the problems.

 Take written notes.

 Insist upon advance preparation. If your reviewers aren't prepared, cancel

the meeting and reschedule.