Friday, March 19, 2010

Difference between Formal & Informal Reviews

Difference between Formal & Informal Reviews

The primary differences between the formal and informal reviews are:

> Typically fewer people participate in the informal reviews. There isn't the structured meeting led by an appointed chairman. Meeting minutes are not prepared & distributed. [Source: Design assurance for engineers and managers By john A.Burgers]

> "Formality" identifies the degree to which an activity is governed by agreed (written) rules. Software review processes exist across a spectrum of formality, with relatively unstructured activities such as "buddy checking" towards one end of the spectrum, and more formal approaches such as walkthroughs, technical reviews, and software inspections, at the other. IEEE Std. 1028-1997 defines formal structures, roles, and processes for each of the last three ("formal peer reviews"), together with software audits.[1]

Research studies tend to support the conclusion that formal reviews greatly outperform informal reviews in cost-effectiveness. Informal reviews may often be unnecessarily expensive (because of time-wasting through lack of focus), and frequently provide a sense of security which is quite unjustified by the relatively small number of real defects found and repaired. [Wikipedia]

Table depicting differences between Formal & Informal Reviews

ObjectiveIdentify errors and issues. Examine alternatives. Forum for learning.Evaluate conformance to specification and plans. Ensure change integrity.
Delegated Controls
Decision MakingThe designer makes all decisions. Change is the prerogative of the designer. Review team petitions management or technical leadership to act on recommendations.
Change VerificationChange verification left to other project controls. Leader verifies that action items are documented; incorporated into external processes.
Group Dynamics
Recommended Group Size2-7 people. 3 or more people.
AttendanceThe designer and any other interested party. Management and engineering leadership.
LeadershipThe designer or designate. Lead engineer.
Artifact VolumeLow Moderate to high, depending on the specific "statement of objectives" for the meeting.
PresenterThe designer. Engineering team lead or representative.
Data CollectionAs desired. Meeting minutes.
Outputs and ArtifactsAs desired. Review report.


Also See:

Technical Review
Importance of Review
Pair Programming Review
Types of Review Process Structures
Deciding Whether to do Formal or Informal Reviews
Software Design Reviews
Formal Review & Informal Review
Walkthrough and Inspection
Peer Review
Software Management Reviews
Test Case review
Code Review