Five steps for performing an effective software product review
Review or inspection is an important activity in any project implementation. Performing a good review of the developed product, along with capturing metrics, helps in building a quality product. In this member-submitted article, Murugan Srinivasa points out the significance of software metrics in guaranteeing an effective review of any software product.
Reviews are a vital component in assuring robust products in any domain. In software project implementation, too, a diligent review is critical as software is increasingly becoming complex. This enhanced complexity gets reflected in the development process, too. Thus, performing reviews of any software solution built or documentations created or generated is a core task.
The review activity is usually performed by an independent team or by skilled professionals. There are two types of reviews: table review and peer review. The table review is a review of the work product by a team consisting of the review team leader, reader, recorder and reviewer. This type of review typically is used in a large project. The peer review is the review of the work product by one or more peer team members other than the author.
The five steps of the review process are given below.
Step 1: Author verifies criteria is fulfilled
The review process starts when the work product is available for the reviewer with adequate quality standards. The developer or the author of the document has to go through the code review checklist or document review checklist and make sure all the criteria mentioned in the checklist is fulfilled before the assigned reviewer starts reviewing.
Tip 1: The document review checklist should be customized for each activity. For example, different review checklists should be prepared for performing design, requirement, test plan, user manual, training document reviews. The code review checklist should be prepared based on the coding standard agreed upon with the customer.
Tip 2: The author of the work product has to leverage the code review checklist or the document review checklist to perform a self-review of the work product. Updated review checklists should be shared with the reviewer. This will reduce the review effort.
Step 2: Review preparation
The review preparation is through a formal or informal meeting with the author of the work product and other stakeholders to understand the following criteria:
- The work product to be reviewed
- The importance of the work product in the larger context
- Critical aspects of the work product, the reviewer ought to focus during review activity
- Open items or known errors in the work product
Metrics 1: Depending on the type of the project, prepare a threshold value for average preparation effort required for review of the document (X minutes per page per person) or code ( X lines of code per hour) at the organization level*. Follow the defined threshold value defined during the review preparation.
*If there is no threshold value defined at the organization level, start capturing the same for one or two review activities and baseline the same for the project. Redefine the threshold value at regular intervals.
Step 3: Perform the review
Perform the work product review as per the focus area discussed during the review preparation meeting. Capture all the errors/defects/bugs/security holes and open issues in the review form. The review form should capture the error type, error source and severity of the error. The review form helps in collecting the errors and in performing analysis of the errors to take corrective action.
Metrics 2: Prepare threshold value of average review effort for document or code in line with Metrics 1.
Step 4: Capture, consolidate and analyze review comments
Capture all the review comments in the review form. Consolidate all of the review comments. Send the work product to the author with the list of review comments. Once the author fixes all the findings precisely, perform the review process again. This cycle will be repeated until all the errors are found and fixed.
Metrics 3: Review of the effort percentage gives an indication of the review effort spent on the project to the total effort. Typical review effort for a project should be around 15 % of the total effort.
Metrics 4: Capture the ratio of preparation effort to review effort for document and code separately.
Tip 3: Use proper tools or templates to capture, consolidate and analyze review errors.
Step 5: Optimize the review process
Analyze all the review comments at regular intervals and perform the following activities.
- Does any error occur frequently? Perform root-cause analysis and find out the source of the error and take corrective action.
- Call for a meeting with the entire team and share the review comments and the corrective action contemplated with the team.
Tip 4: Update the review checklist after every review cycle.
Tip 5: Project learning -- Discuss with the team what went right, what went wrong, areas of improvement, etc. during the review process. Identify corrective action for activities that went wrong in the previous phase or review cycle and implement the corrective action and update the project learning document.
Tip 6: Perform trend analysis -- Perform trend analysis over a period of time to verify whether the corrective action implemented has reduced the number of errors.
Metrics 5: Capture rework effort required to perform modification to the work product. Rework effort gives some indication about the effectiveness of the review. If the total rework effort is zero, then either your work product is of high quality or the reviews are not competent enough to capture all the visible and invisible errors. A high rework effort indicates the review is good or the quality of work product is not good. The root cause analysis has to be done on the rework effort to find out the major cause for rework and to take appropriate corrective action.
