There are several types of reviews a software company might use. Using one does not prevent you from using others – in fact, the best process is to use a combination of all of them. Informal to catch easy things early on, and ensure compliance with design specifications, formal to more rigidly test and verify, and then postmortems after the fact to see what can be done better/differently next time.
Informal Reviews
Informal Reviews can be as simple as having a single person review your code to check to make sure it is meeting the requirements specified in the design phases.
This is often referred to as a desk check (someone coming by your desk to check your code) and is a core component of pair coding – often referenced in different agile development processes. With pair coding the process occurs continuously.
Various informal meetings can occur to check everything from coding logic to visual prototypes of the interface.
Formal Reviews
A formal technical review (FTR) is a software quality control activity performed by software engineers (and others). The objectives of an FTR are: (1) to uncover errors in function, logic, or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable.
As there should be multiple FTRs for a project, each FTR will be successful only if it is properly planned, controlled, and attended.
Review meetings should be composed of only a few people, and focus on a small component. For example, a section of the interface and all the code that goes with it.
During a review meeting, someone should be responsible for recording all of the notes in a written format to ensure that the nothing is missed when returned to the developers. This will include who reviewed it, what was reviewed, and the associated findings – both good and bad.
For a good review meeting, consider the following points:
- Review the product, not the producer.
- Set an agenda and maintain it.
- Limit debate and rebuttal. – especially on how big an impact this will have
- Enunciate problem areas, but don’t attempt to solve every problem.
- Limit the number of participants and insist upon advance preparation
- Develop a checklist for each product that is likely to be reviewed
- Conduct meaningful training for all reviewers.
- Review your early reviews – this will help you improve your review process.
Post-Mortem Evaluations
Many lessons can be learned if a software team takes the time to evaluate the results of a software project after the software has been delivered to end users.
Unlike an FTR that focuses on a specific work product, a PME examines the entire software project, focusing on both “excellences (that is, achievements and positive experiences) and challenges (problems and negative experiences)”
While not mentioned in the book – I like to look at this as a two step process. One from the developers on the project – what they think when right and wrong and how to fix areas of problems (not well defined designs, poor communication, lack of development resources, etc) and figuring out how to solve those issues.
The second speaks more to the end users and finding what went right and wrong from the product as a whole. What do they like about it, what do they wish was a little different.
Marrying those two together, lets you see where resources can be best spent, by identifying what the customer didn’t like with how the developers could fix if the changes they suggest were implemented.
You might wonder how to determine what the customer thinks. Well survey cards work well, talking to customers at trade shows, as do fielding calls from the customer support lines.
Review Types was originally found on Access 2 Learn
