Formal Technical Review (FTR) in Software Engineering - GeeksforGeeks (2024)

Formal Technical Review (FTR) is a software quality control activity performed by software engineers.It is an organized, methodical procedure for assessing and raising the standard of any technical paper, including software objects. Finding flaws, making sure standards are followed, and improving the product or document under review’s overall quality are the main objectives of a formal technical review (FTR). Although FTRs are frequently utilized in software development, other technical fields can also employ the concept.

Objectives of formal technical review (FTR)

• Detect Identification: Identify defects in technical objects by finding and fixing mistakes, inconsistencies, and deviations.
• Quality Assurance: To ensure high-quality deliverables, and confirm compliance with project specifications and standards.
• Risk Mitigation: To stop risks from getting worse, proactively identify and manage possible threats.
• Knowledge Sharing: Encourage team members to work together and build a common knowledge base.
• Consistency and Compliance: Verify that all procedures, coding standards, and policies are followed.
• Learning and Training: Give team members the chance to improve their abilities through learning opportunities.

In addition, the purpose of FTR is to enable junior engineers to observe the analysis, design, coding, and testing approach more closely. FTR also works to promote backup and continuity to become familiar with parts of the software they might not have seen otherwise. 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 a meeting and is considered successful only if it is properly planned, controlled, and attended.

Example

Suppose during the development of the software without FTR design cost 10 units, coding cost 15 units and testing cost 10 units then the total cost till now is 35 units without maintenance but there was a quality issue because of bad design so to fix it we have to redesign the software and final cost will become 70 units. that is why FTR is so helpful while developing the software.

The Review Meeting

Each review meeting should be held considering the following constraints- Involvement of people:

1. Between 3, 4, and 5 people should be involved in the review.
2. preparation should occur, but it should be very short that is at the most 2 hours of work for every person.
3. The short duration of the review meeting should be less than two hours. Given these constraints, it should be clear that an FTR focuses on specific (and small) parts of the overall software.

At the end of the review, all attendees of FTR must decide what to do.

1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app needs to be reviewed), or
3. Accept the product provisional (minor errors are encountered and should be corrected, but no additional review will be required).

The decision was made, with all FTR attendees completing a sign indicating their participation in the review and their agreement with the findings of the review team.

Review reporting and record-keeping:

1. During the FTR, the reviewer actively records all issues that have been raised.
2. At the end of the meeting all these issues raised are consolidated and a review list is prepared.
3. Finally, a formal technical review summary report is prepared.

A review summary report answers three questions:

1. What was reviewed?
2. Who reviewed it?
3. 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. An unregistered review can often be worse than a review that does not minimum set of guidelines for FTR.

1. Review the product, not the manufacturer (producer): FTR includes people and egos. while properly conducted FTR will give all participants a good feeling of accomplishment, and when conducted improperly, the FTR team will be pointed out clearly. the meeting tone will be only loose and constructive, the review team leader will ensure that the proper way of communication will be happening or not into the team or it will get out of control.
2. Set an agenda and maintain it: one of the measure keys in the meeting is drift. FTR will always keep on track and schedule. the review leader is making and maintaining the meeting schedule and should not be afraid that many people drift sets in.
3. Limit debate and rebuttal: whenever the issue is raised by the reviewer there will not be an impact on a universal agreement. rather than spending time with the questions, then issues will be further discussed off-line.
4. Enunciate problem areas, but don’t attempt to solve every problem noted: A review is not a problem-solving session. The solution to a problem can often be accomplished for the producer alone or with the help of only one other individual. problem-solving should be postponed for a while until after the review meeting.
5. Take written notes (record purpose): it is a good idea to take notes on the wallboard so that will be wording, and priorities can be assessed by other reviewers as information is recorded.
6. Limit the number of participants and insist upon preparation: two heads are better than one, but 14 are not needed to be better than 4. We will keep the number of people involved to a minimum, all review teams must prepare in advance, and written comments will be requested by the review leader.
7. Develop a checklist for each product that is likely to be reviewed: A checklist will help to structure of Review meeting and for the review leader and help to focus the reviewer on the important issues. checklist should be developed by the analysis, design, code, and even test documents.
8. Allocate resources and schedule for FTRs to maintain schedule: it’s effective to review, they should be effective and it should be a task during the software engineering process. In addition, the time should be scheduled for modification that occurs as a result of an FTR.
9. Conduct meaningful training for all reviewers to make reviews effective: To be effective for all the reviews at first some have received formal training. it will stress both process-related and the human psychological side of the reviews. for every person who is to participate in reviews which is a one-month learning curve of 20 people.
10. Review earlier reviews that serve as the base for the current review being conducted: it can be beneficial in uncovering problems with the review process itself. the first product to be reviewed should be the guidelines themselves because many variables have a successful review, a software organization should experiment to find approaches that work best in a local context. porter and his colleagues provide excellent guidance for this type of experiment.

Conclusion

Organizations can create and follow standardized procedures since the formalized nature of FTR guarantees consistency in the review process. This helps with continuous improvement and gives teams a foundation for metrics and analysis so they can monitor the effectiveness of their reviews over time.