- Software peer review
In software development,
peer reviewrefers to a type of software reviewin which a work product (normally some form of document) is examined by its author and one or more colleagues, in order to evaluate its technical content and quality.
The purpose of a peer review is to provide "a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into field operations" according to the
Capability Maturity Model.
When performed as part of each
Software development processactivity, peer reviews identify problems and fix them early in the lifecycle. That is to say, a peer review that identifies a requirements problem during the Requirements analysisactivity is cheaper and easier to fix than during the Software architectureor Software testingactivities.
The National Software Quality Experiment, [ [http://members.aol.com/ONeillDon/nsqe-results.html National Software Quality Experiment Resources and Results] ] evaluating the effectiveness of peer reviews, finds, "a favorable return on investment for software inspections; savings exceeds costs by 4 to 1". To state it another way, it is four times more costly, on average, to identify and fix a software problem later.
Distinction from other types of software review
Peer reviews are distinct from
management reviews, which are conducted by management representatives rather than by colleagues, and for management and control purposes rather than for technical evaluation. They are also distinct from software audit reviews, which are conducted by personnel external to the project, to evaluate compliance with specifications, standards, contractual agreements, or other criteria.
Peer 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. The IEEEdefines formal structures, roles, and processes for each of the last three. [ IEEEStd. 1028-1997, "IEEE Standard for Software Reviews"]
Management representatives are typically not be involved in the conduct of a peer review except when included because of specific technical expertise or when the work product under review is a management-level document. This is especially true of line managers of other participants in the review.
"Open source" reviews
In the free / open source community, something like peer review has taken place in the engineering and evaluation of
computer software. In this context, the rationale for peer review has its equivalent in Linus's law, often phrased: "Given enough eyeballs, all bugs are shallow", meaning "If there are enough reviewers, all problems are easy to solve." Eric S. Raymondhas written influentially about peer review in software development. [cite paper|author= Eric S. Raymond|title= The Cathedral and the Bazaar]
Wikimedia Foundation. 2010.