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.

1 comments:

IEEE Project Domain management in software engineering is distinct from traditional project deveopment in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and faculty feedback. A IEEE Domain project Final Year Projects for CSE system development life cycle is essentially a phased project model that defines the organizational constraints of a large-scale systems project. The methods used in a IEEE DOmain Project systems development life cycle strategy Project Centers in Chennai For CSE provide clearly defined phases of work to plan, design, test, deploy, and maintain information systems.


This is enough for me. I want to write software that anyone can use, and virtually everyone who has an internet connected device with a screen can use apps written in JavaScript. JavaScript Training in Chennai JavaScript was used for little more than mouse hover animations and little calculations to make static websites feel more interactive. Let’s assume 90% of all websites using JavaScript use it in a trivial way. That still leaves 150 million substantial JavaScript Training in Chennai JavaScript applications.

Reply

Post a Comment

www.CodeNirvana.in

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