How to make software peer review effective and efficient: 3 simple tips.
Peer review is a commonly used practice in the software development world. Unarguably “Two heads are better than one” principle makes your product better. The main question is if the enhancement worth the price you pay for it. In the safety critical domain such as aerospace where reviews are mandatory, this issue is of current significance. DO-178C forces us to conduct reviews for merely every single item that is produced throughout the project lifecycle and consumes up to 30% of project efforts. Thus spending time for peer reviews in an effective and efficient manner is essential.
However, the intent lying underneath peer review sometimes becomes blurred, especially to a large and complicated aerospace project. Either review process is done for the sake of the process with the focus on production of formal review records. Or process becomes inefficient when people dig too deeply into the aspects that do not contribute in ending product quality.
Consider the following easy tips to keep the balance making your DO-178C review process more valuable and to control the time spent for review cycles responsibly:
Tip #1. Foster the right attitude.
Have you ever experienced anything similar to what I call “checkbox review” when all questions are marked with “passed” without any real check? I bet you have. Especially, when the deadline is close and management is pushing. Another case of the wrong attitude is “Correct it as I say” when a reviewer has much more authority or experience than an author does.
Always remember the following simple statement to avoid such a wrong attitude: “review is an independent qualitative opinion regarding compliance and quality of your outputs, not more not less. Every single word matters in this statement.
Review should be independent. Reviewer and author shall discuss findings and provide arguments, until agreement is reached rather than one of them enforces his opinion in a peremptory manner.
Review is always qualitative. You can never prove your views with 100% strict mathematical proof. There is always room for subjectivity.
Review is aimed to confirm or disprove that the output under review complies with the standards and procedures and fulfills the requirements against which it was developed. Review is neither a brainstorming meeting, nor a research session, nor training classes.
Tip# 2. Create the right checklist.
Peer review is deemed to increase product quality. Quality, however, is a very amorphous word. Everybody feels that understands what it is but almost nobody can express it in a short and quantitative manner. In the DO-178C world we are lucky to have more or less strict guidance to define the quality of the product.
First, the product operation shall be safe.
Second and complementary to the first, the product and process shall be compliant with the standards.
Third and complementary to the first two, the product should fulfill intended functionality and shall not do anything unintended.
Fourth and complementary to all above the product shall be maintainable throughout 30+ year’s period.
Always validate any review checklist against these principles. Make sure that your checklist is specific enough. It should contain questions regarding how exactly these principles are satisfied in a work product under review rather than if those principles are superficially satisfied. On the other hand, a checklist should not be too excessive. Concentrate only on what is vital. Having a 150-question checklist for a simple unit test is a sign that you are doing something wrong. Never ignore the feedback you receive from review participants. Reconsider the checklist if a reviewer is confused with what question to choose when relating a finding or if too many findings fall into the “other” category.
Tip# 3. Establish the right process.
Be sure that only relevant participants take part in the review and that their involvement is neither excessive nor insufficient. For the example with a unit test having two inspectors, one moderator and one facilitator will be exorbitant. However, such a team may not be enough for reviewing software architecture.
The flow of the review process is very important as well. Provide the team with a well-fit infrastructure to support data exchange between the participants and review records management to make it a favorite piece of project culture rather than annoying formal activity. Usually, configuration management systems are extended with peer review plugins to make the process fast, transparent and straightforward. Investment in convenient tool setup for reviews is a wise decision. What you do not want to have is a “manual” process and record flow with review cover sheets looking like a “history book of the project”.
Taking after these three tips brings a powerful tool for project analysis in addition to making review process more adequate. The right checklists provide you with well-structured data taxonomy. The right attitude and the right participants provide confidence that data connected to those checklists is accurate and representative. Statistical analysis will help you to figure out weak or poor defined aspects of your project besides the review process itself.
DO-178C requires reviews and no one can get by without it. It is your choice to make it for compliance solely or to get real benefits. The three tips will help you to make a wise decision and maximize cost\value ratio from your reviews.