Formal Technical Review (FTR) is a software quality control activity performed by software engineers.
Objectives of formal technical review (FTR):
Some of these are:
- Useful to uncover error in logic, function and implementation for any representation of the software.
- The purpose of FTR is to verify that the software meets specified requirements.
- To ensure that software is represented according to predefined standards.
- It helps to review the uniformity in software that is development in a uniform manner.
- To makes the project more manageable.
In addition, the purpose of FTR is to enable junior engineer to observer the analysis, design, coding and testing approach more closely. FTR also works to promote back up and continuity become familiar with parts of software they might not have seen otherwise.
Actually, FTR is a class of reviews that include walkthroughs, inspections, round robin reviews and other small group technical assessments of software. Each FTR is conducted as meeting and is considered successfully only if it is properly planned, controlled and attended.
The review meeting:
Each review meeting should be held considering the following constraints-
Involvement of people:
- Between 3, 4 and 5 people should be involve in the review.
- Advance preparation should occur but it should be very short that is at the most 2 hours of work for every person.
- The short duration of the review meeting should be less than two hour. Gives these constraints, it should be clear that an FTR focuses on specific (and small) part of the overall software.
At the end of the review, all attendees of FTR must decide what to do.
- Accept the product without any modification.
- Reject the project due to serious error (Once corrected, another app need to be reviewed), or
- Accept the product provisional (minor errors are encountered and are should be corrected, but no additional review will be required).
The decision was made, with all FTR attendees completing a sign-of indicating their participation in the review and their agreement with the findings of the review team.
Review reporting and record keeping :-
- During the FTR, the reviewer actively records all issues that have been raised.
- At the end of the meeting all these issues raised are consolidated and a review list is prepared.
- Finally, a formal technical review summary report is prepared.
It answers three questions :-
- What was reviewed ?
- Who reviewed it ?
- What were the findings and conclusions ?
Review guidelines :-
Guidelines for the conducting of formal technical reviews should be established in advance. These guidelines must be distributed to all reviewers, agreed upon, and then followed. A review that is unregistered can often be worse than a review that does not minimum set of guidelines for FTR.
- Review the product, not the manufacture (producer).
- Take written notes (record purpose)
- Limit the number of participants and insists upon advance preparation.
- Develop a checklist for each product that is likely to be reviewed.
- Allocate resources and time schedule for FTRs in order to maintain time schedule.
- Conduct meaningful training for all reviewers in order to make reviews effective.
- Reviews earlier reviews which serve as the base for the current review being conducted.
- Set an agenda and maintain it.
- Separate the problem areas, but do not attempt to solve every problem notes.
- Limit debate and rebuttal.
Don’t stop now and take your learning to the next level. Learn all the important concepts of Data Structures and Algorithms with the help of the most trusted course: DSA Self Paced. Become industry ready at a student-friendly price.
- Software Engineering | Software Review
- Difference between Software Engineering process and Conventional Engineering Processs
- Software Engineering | Requirements Engineering Process
- Software Engineering | Reverse Engineering
- Software Engineering | Introduction to Software Engineering
- Software Engineering | Re-engineering
- Software Engineering | Schick-Wolverton software reliability model
- Software Engineering | Jelinski Moranda software reliability model
- Software Engineering | Role and Responsibilities of a software Project Manager
- Software Engineering | Software Project Management Plan (SPMP)
- Software Engineering | Software Project Management Complexities
- Software Engineering | Identifying Software Development Metrics
- Software Engineering | Responsibilities of Software Project Manager
- Software Engineering | Software Quality Assurance
- Software Engineering | Classification of Software Requirements
- Software Engineering | Software Quality Assurance (SQA) Set 2
- Software Engineering | Software Design Process
- Software Engineering | Software Quality Framework
- Software Engineering | Agile Software Development
- Software Engineering | Software Business and Development
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.