Featured

    Featured Posts

The role of Formal Technical Review (FTR) as a quality assurance activity in software engineering concepts.


Formal Technical Review (FTR):

               The FTR is a software is a software quality assurance activity with the objectives to uncover errors in function, logic or implementation for any representation of the software, to verify that the software under review meets its requirements, to ensure that the software has been represented according to predefined standards, to achieve software that is developed in a uniform manner and to make projects more manageable.  FTR  activities include walk-through, inspection and round robin review and other technical assessments.
             Review meeting is important  form of FTR and there are some essential parameters for the meeting such as there should be reasonable number of persons conducting the meeting and that too after each one of them has done his/her homework i.e some preparation and the meeting should not be carried out very long which may lead to wastage of time but rather for duration just enough to churn out some constructive results.  FTR is effective when a small and specific part of the overall software is under scrutiny.  It is easier and more productive to review in small parts like each module one by one rather than to review the whole thing in one go.  The target of the FTR is on a component of the project, a single module.

Record Keeping and Reporting :  Record keeping and reporting are another quality assurance activities.  It is 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 summarizes all issues, is produced.  A simple review summary report answers the following questions.
     A review summary report answer the following questions :

  1. what was reviewed?
  2. who reviewed it?
  3. what were findings an conclusions?

 
FTR can be conducted as follows :

Before the FTR :

  1. Ask for what you want.  A written 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.
  2. 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.
  3. Don't demand more than 2 hours of preparation time from your reviewers.
  4. Arrange delivery of the work product in advance so reviewers have adequate time to prepare.
  5. Reviewers:  Spend no more than 2 hours individually critiquing the work product.
During the FTR :

  1. Moderator, usually QA leader, is responsible for running the meeting and orchestrating how is issues are to be presented.
  2. Reviewers raise issues based on their advance preparation.
  3. Get the big problem issues on the table early.  Don't get lost in minutely small clerical details.
  4. Identify problems, don't solve them.
  5. Focus on material, not the producer.
  6. Elicit questions, don't answer them.
  7. Don't explain how your product works.  An FTR is not a product demo.
  8. Watch the clock and keep momentum to get through all the issues in the allotted time.
  9. Recorder actively records all issues raised.
At the end of the FTR:  Reviewers must make a decision :

  • Accept - the product is acceptable as is.
  • Rework - accept the product provisionally, minor errors have been encountered and must be corrected, but no additional review will be required.
  • 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 neede.
  • Write review summary report.
  • Have reviewers sign off on summary report, indicating proper corrective action has been taken for each issue.
  • Include signed report in deliverable.

Post a Comment

www.CodeNirvana.in

www.posthatke.com. Powered by Blogger.

Google+ Followers

Copyright © www.posthatke.com | Blogger Templates | Designed By posthatke.com