Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Software Reviews: Page 1 of 2

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 2

Software Reviews

Software reviews are used for quality assurance. Software reviews are a process or meeting during which a
work product, or set of work products, is presented to project personnel, managers, users, customers, or
other interested parties for comment or approval. Types include code review, design review, formal
qualification review, requirements review, test readiness review. There are several varieties of software
review; they differ according to the size of the review group and the formality of the review meetings.

Types of Software Reviews

Some might think that if only we didn’t make mistakes, reviews would not be necessary. But, even
experienced programmers typically make about 100 defects per thousand lines of code. Early discovery
and removal of defects is vital so these defects do not propagate to the next step in the software process.
We now describe three different types of software reviews for removing defects: personal reviews,
walkthroughs, and software inspections.

1. Walkthrough:
 It is not a formal process
 It is led by the authors
 Author guide the participants through the document according to his or her thought process to
achieve a common understanding and to gather feedback.
 Useful for the people if they are not from the software discipline, who are not used to or cannot
easily understand software development process.
 Is especially useful for higher level documents like requirement specification, etc.

The goals of a walkthrough:


 To present the documents both within and outside the software discipline in order to gather the
information regarding the topic under documentation.
 To explain or do the knowledge transfer and evaluate the contents of the document
 To achieve a common understanding and to gather feedback.
 To examine and discuss the validity of the proposed solutions

2. Inspection:
 It is the most formal review type
 It is led by the trained moderators
 During inspection the documents are prepared and checked thoroughly by the reviewers before the
meeting
 It involves peers to examine the product
 A separate preparation is carried out during which the product is examined and the defects are
found
 The defects found are documented in a logging list or issue log
 A formal follow-up is carried out by the moderator applying exit criteria

The goals of inspection are:


 It helps the author to improve the quality of the document under inspection
 It removes defects efficiently and as early as possible
 It improve product quality
 It create common understanding by exchanging information
 It learn from defects found and prevent the occurrence of similar defects

3. Technical review:
 It is less formal review
 It is led by the trained moderator but can also be led by a technical expert
 It is often performed as a peer review without management participation

Page 1 of 2
 Defects are found by the experts (such as architects, designers, key users) who focus on the content
of the document.
 In practice, technical reviews vary from quite informal to very formal

The goals of the technical review are:

 To ensure that an early stage the technical concepts are used correctly
 To access the value of technical concepts and alternatives in the product
 To have consistency in the use and representation of technical concepts
 To inform participants about the technical content of the document

Pair Programming

Pair programming is a technique that can be used to complement software reviews or, sometimes, as an
alternative to reviews. Pair programming is a style of programming in which two programmers work side-
by-side at one computer, continuously collaborating on the same design, algorithm, code, or test. Pair
programming has been practiced sporadically for decades; however, the emergence of agile methodologies
and Extreme Programming has recently popularized the pair programming practice. Pair programming has
been shown to have many of the benefits of reviews while also eliminating the programmer’s distaste for
reviews so that at least one form of review is actually performed.

Some people think that having two people sit down to develop one artifact must be a big waste of
resources. Managers are especially concerned about this since they think they Software Reviews and Pair
Programming will have to pay two programmers to do the work one could do. Even students are concerned
about this because they think they might have to spend twice as long on their homework. However, some
research results show that these concerns do not materialize.

Code Review

Code review is systematic examination (often known as peer review) of computer source code. It is
intended to find and fix mistakes overlooked in the initial development phase, improving both the overall
quality of software and the developers' skills.

Code review practices fall into two main categories: formal code review and lightweight code review.
Formal code review, such as a Fagan inspection, involves a careful and detailed process with multiple
participants and multiple phases.

A code review is a special kind of inspection in which the team examines a sample of code and fixes any
defects in it. In a code review, a defect is a block of code that does not properly implement its
requirements, that does not function as the programmer intended, or that is not incorrect but could be
improved (for example, it could be made more readable or its performance could be improved). In addition
to helping teams find and fix bugs, code reviews are useful for both cross-training programmers on the
code being reviewed and for helping junior developers learn new programming techniques.

Page 2 of 2

You might also like