Software review

With the review work products of software development are checked manually. Each work product can be subjected to a review of by another person. The or the review is a static test method and belongs to the category of analytical quality assurance measures.

Based on the IEEE Standard 729, the Review is a more or less formally planned and structured analysis and evaluation process that are in the project results presented to a team of experts and commented on by this or approved.

Of the examined object of a review may be different. A distinction is mainly between a code review ( source) and an architecture review (software architecture, especially design documents ). Associated with these areas are technical documents such as readmes, installation instructions or manuals, but also programs or scripts that are needed for installation as well as documents containing information and instructions to other similarly qualified developers to empower to this, the translation process of the sources later to a time to reproduce successfully, for example for a bug-fixing or further development.

When code review a program section is read after or during the development of one or more assessors correction to find possible errors, simplifications or test cases. Here, the appraiser can be a software developer himself. For inexperienced developer provides the code review by an experienced programmer a great way to educate yourself quickly and practically.

Benefits of reviews

Reviews the use of lead to a significant reduction in errors. According to Jones Carpers studies of approximately 12,000 projects Requirements Reviews lead to a reduction of 20 % to 50 % of the expected error, top -level design reviews between 30% and 60 %, detailed functional design reviews between 30 % and 65 % and detailed logical design reviews between 35 % and 75 %. That approximately corresponds to the efficiency of system tests (25 % to 65 % of the error). Errors that stand out in the review can be solved much cheaper than if they are only found during the test run frequently.

Various quality processes take place:

• The programmer discovers itself an improvement opportunity.
• The reviewer provides comprehension questions and the programmer can change the code so these questions are answered ( for example, through appropriate naming or documentation) and so that the course has been improved.
• The reviewer discovered opportunities for improvement and recommends these to the programmer.

Typical weaknesses that can be detected with reviews include:

• Deviations from standards, such as violation of naming conventions
• Error compared to (or in ) the requirements
• Design flaws
• Insufficient maintainability
• Wrong Interface Specification

Results from code reviews are an improved code quality in addition to the errors thus found. This in turn prevents future errors and increases efficiency; robustness; Maintainability, such as by improved code comments.

Reviews and Inspections can thus reduce the software development costs by up to 30%.

Review Process

A typical review consists of the following main phases:

• Planning Selection of the persons involved and occupation of roles
• Definition of pre-and postconditions

• Kick-Off Distribution of documents
• Explain the objectives and the process
• Examination of the preconditions

• Individual preparation Listing of potential defects, questions and comments

• Review meeting Discussion and recording the results
• Make recommendations or make decisions about error

• Revision ( rework) Fix the errors found, typically by the author

• Post ( follow up) Review of the revision
• Examination of test completion criteria

Types of review:

Reviews vary from very informal ( unstructured ) and very formal (ie deeply structured and regulated). The way in which a review is carried out depends on the set objectives of the review (eg, finding errors, the acquisition of understanding, or discussion and decision by consensus).

According to the standard IEEE 1028 there are the following four types of reviews:

• Technical Review Technical examination of a substantial document (eg architectural design ) in accordance with specification
• Purpose: discussion, make decisions, evaluate alternatives, finding fault, solve technical problems

• Informal review Mirrors the technical review, it will towards him but time can be saved and therefore it is carried out as a formal process.
• The Informal Review is not included in the IEEE Standard for Software Reviews.
• A structured logging / documentation is possible. A report is usually created in practice, only in a simpler form or partly omitted entirely.
• There is a simple way of a review, in which most " cross-reading between colleagues " is performed.
• Content of this type the following, practical types of review can be assigned (terms depending on the corporate culture different): Desk test (program author plays the code using simple test cases mentally through. )
• Peer rating ( report, which is created by equivalent anonymous programmers a program. )
• Submission of comments (Author work distributed earnings to selected reviewers for evaluation. )

• Walkthrough Discussion of scenarios, test runs and alternatives in a circle assimilated employees with as low costs held
• Purpose: To achieve learning, understanding, and find errors

• Inspection Most formal review technique using a documented procedure in accordance with IEEE 610, IEEE 1028.
• Purpose: visual inspection of documents to find defects (eg non-compliance with development standards, non-conformance against specifications, etc.).

Success Factors

Thus, reviews are carried out successfully, several conditions must be met:

• Selection of suitable persons
• Constructive criticism ( any errors found objectively raised and well received )
• Psychological aspects (in particular ensuring a positive experience for the author )
• Selection of the appropriate review technique
• Support the review process by the management
• Existence of a culture of learning and process improvement

Requirements for reviewers:

• He may not have written the code.
• He must have tact: code reviews can be unpleasant for the programmer, since he could get the impression that the native code am criticized. If the reviewer does not act tactfully, resistance and rejection of the review of the source code is built.

Reviews as philosophy

Continuous inspection of the source code, as in the pair programming is also one of the methods of Extreme Programming. The pair programming used in Extreme Programming (XP) is also referred to as a " code review during the development."

A public review is also a motivation of open source software.

Online software repositories such as CVS allow groups of individuals, community perform code reviews, thereby improving safety and quality of the program code.