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
| Attribute | Informal | Formal |
|---|---|---|
| Objective | Identify errors and issues. Examine alternatives. Forum for learning. | Evaluate conformance to specification and plans. Ensure change integrity. |
| Delegated Controls | ||
| Decision Making | The designer makes all decisions. Change is the prerogative of the designer. | Review team petitions management or technical leadership to act on recommendations. |
| Change Verification | Change verification left to other project controls. | Leader verifies that action items are documented; incorporated into external processes. |
| Group Dynamics | ||
| Recommended Group Size | 2-7 people. | 3 or more people. |
| Attendance | The designer and any other interested party. | Management and engineering leadership. |
| Leadership | The designer or designate. | Lead engineer. |
| Procedures | ||
| Artifact Volume | Low | Moderate to high, depending on the specific "statement of objectives" for the meeting. |
| Presenter | The designer. | Engineering team lead or representative. |
| Data Collection | As desired. | Meeting minutes. |
| Outputs and Artifacts | As desired. | Review report. |
[Source]
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