Review Meeting is one of important and essential forms of Formal Technical Review (FTR).
FTR is usually effective when a little or small and particular part of overall software is under scrutiny i.e. Critical observation or examination. This meeting might contain some discussion related to defects or errors that are found, or some log of defects being found. The participants of meeting generally note down defects that are found for author to correct.
They can also recommend for controlling and handling or correcting defects or errors being found. At kick-off stage, approach that is needed to be taken is decided so that all of participants are simply aware of what is actually required for them. This decision of taking approach is simply based on one for several factors as given below :
- Availability of time –
If time being available is very short or less then the meeting might only identify or collect defects or errors.
- Author requirements –
Is there any requirement of author for simply correcting or fixing defects or errors.
- Review type –
Only collection of defects is allowed in an inspection. There is never any discussion done on this.
Meeting basically involves different phases where various tasks are performed that are related to document under review. Meeting includes three phases depending on review type :
- Logging Phase :
This phase is considered as initial duration of review meeting when all of members or participants of review simply mention all points i.e., defect, query, and concern that are identified during this phase. During this phase, all of issues that are being determined or identified during stage are either logged by author or scribe.
Each and every defect or error and its severity i.e. seriousness must be logged in three different classes of severity as given below :
- Critical –
his indicates a complete shut-down and causes downstream damage. It also indicates that nothing can proceed further.
- Major –
This indicates that defect is very severe and it will collapse system or might cause downstream damage. Whereas, some parts of system remain functional.
- Minor –
This indicates that there won’t be any major breakdown of system and not likely to cause downstream damage.
We basically know that participants determine or identify defects or errors in preparation step. All of these determined or identified defects are usually included and logged in this phase. We simply issue or defects that are being found and detected throughout training session.
- Critical –
- Discussion Phase :
After logging phase, team usually picks every point one by one and then discusses different aspects related to that point. All of main points like points criticality, areas that are impacted, and reasons are documented by either scribe or author.
For example, if any defect is found, then team will discuss regarding following points :
- Defect is valid or not.
- Severity and priority of defect.
- Time required to fix defect.
- Approach for fixing defect.
Moderator is generally responsible for controlling and handling all activities in this phase. Outcome of discussions is usually documented for further reference.
- Decision Phase :
After discussion phase, meeting comes under this phase. Discussion phase is ending phase of formal meeting. Different exit criteria are there of a decision phase that usually explains average number of defects being found or determined. Decision is basically taken by contestant. This decision is based on documents and sometimes depends on formal exit criteria.
Example of exit criteria –
If the number of defects found per page is more or greater than a certain limit, then moderator usually sends it for rework as rework on documentation is needed for further processing in project. It undergoes review again after rework. But, if number of defects found per page is less than a certain limit, then moderator simply checks during the follow-up.