During software development it is possible to perform technical reviews for every piece of software, whether it is a document (e.g. specification or design) or any program unit. Thus, we have to decide how many reviews should be conducted for a particular project. Before you can answer this question and determine a reasonable strategy for your project, you have to make observations about the effort and benefit of reviews.
After this, some criteria are given to determine those results for which a review should be performed.
Effort for Technical Reviews
| Maximum Document/Code Size for one Review
|| 50 pages
| Number of Reviewers
Review Preparation (relative)
Effort Review Preparation
Effort Review Session (absolute)
Total Review Effort
5 person days
3 person days
| Effort for Document/Code Creation (relative)
Effort for Document/Code Creation (absolute)
| 2 pages/day
25 person days
| 1 page/day
20 person days
| Review Effort vs. Effort for Document/Code Creation
|| 20 %
|| 15 %
Benefit of Technical Reviews
Errors Found/Document (relative)
| 60-70 %
| Reduction of Error Costs
|| 75 %
| Total Savings/Complete Development
| Netto Improvement/Complete Development
| Netto Improvement/Maintenance
Reviews Determination Checklist
The following criteria may help you to decide for which results a review should be performed.
Reviews should be performed for
Altogether about 50 % of all results should be reviewed. Thus, about 10 % of the total development time will be spent on reviews. But
- results that are visible to the users or purchaser. At least, this includes the requirements document, acceptance test plan, and user documentation.
- results that define essential interfaces, e.g. system design.
- results that are afflicted with high risk, e.g. complex parts, user critical functionality.
- central parts, used by several components.
- time and memory critical parts of the software.
The smaller the project, the more results should be reviewed!