What Are Reviews
What Are Reviews
This involves examining the software, its documentation and records of the process to discover errors
and omissions and to see if quality standards have been followed.
Reviews are used alongside program testing as part of the general process of software verification and
validation.
During a review, a group of people examine the software and its associated documentation, looking for
potential problems and non-conformance with standards. The review team makes informed judgments
about the level of quality of a system or project deliverable. Project managers may then use these
assessments to make planning decisions and allocate resources to the development process.
Reviews are based on documents that have been produced during the software development process.
As well as software specifications, designs, or code, process models, test plans, configuration
management procedures, process standards, and user manuals may all be reviewed. The review should
check the consistency and completeness of the documents or code under review and make sure that
quality standards have been followed.
Reviews are not just about checking conformance to standards. They are also used to help discover
problems and omissions in the software or project documentation. The conclusions of the review should
be formally recorded as part of the quality management process. If problems have been discovered, the
reviewers’ comments should be passed to the author of the software or whoever is responsible for
correcting errors or omissions.
Every firm takes review approach as per their needs. Three major types of review are following:
Quality review
Technical review
Progress review
A software technical review is a form of peer review in which "a team of qualified personnel ... examines
the suitability of the software product for its intended use and identifies discrepancies from
specifications and standards. Technical reviews may also provide recommendations of alternatives and
examination of various alternatives".
What is the purpose of review?
The purpose of reviews and inspections is to improve software quality, not to assess the performance of
people in the development team. Reviewing is a public process of error detection, compared with the
more private component-testing process. Inevitably, mistakes that are made by individuals are revealed
to the whole programming team. To ensure that all developers engage constructively with the review
process, project managers have to be sensitive to individual concerns. They must develop a working
culture that provides support without blame when errors are discovered.
Although a quality review provides information for management about the software being developed,
quality reviews are not the same as management progress reviews. Progress reviews compare the
actual progress in a software project against the planned progress. Their prime concern is whether or
not the project will deliver useful software on time and on budget. Progress reviews take external
factors into account, and changed circumstances may mean that software under development is no
longer required or has to be radically changed.
The Decision Maker (the person for whom the technical review is conducted) determines if the
review objectives have been met.
The Review Leader is responsible for performing administrative tasks relative to the review,
ensuring orderly conduct, and ensuring that the review meets its objectives.
The Recorder documents anomalies, action items, decisions, and recommendations made by
the review team.
Technical staff are active participants in the review and evaluation of the software product.
Management staff may participate for the purpose of identifying issues that require
management resolution.
Customer or user representatives may fill roles determined by the Review Leader prior to the
review.
Although there are many variations in the details of reviews, the review process is normally structured
into three phases:
Pre-review activities These are preparatory activities that are essential for the review to be
effective. Typically, pre-review activities are concerned with review planning and review
preparation. Review planning involves setting up a review team, arranging a time and place for
the review, and distributing the documents to be reviewed. During review preparation, the
team may meet to get an overview of the software to be reviewed. Individual review team
members read and understand the software or documents and relevant standards. They work
independently to find errors, omissions, and departures from standards.
Reviewers may supply written
comments on the software if they cannot attend the review meeting.
The review meeting During the review meeting, an author of the document or program being
reviewed should ‘walk through’ the document with the review team. The review itself should be
relatively short—two hours at most. One team member should chair the review and another
should formally record all review decisions and actions to be taken. During the review, the chair
is responsible for ensuring that all written comments are considered. The review chair should
sign a record of comments and actions agreed during the review.
Post-review activities After a review meeting has finished, the issues and problems raised
during the review must be addressed. This may involve fixing software bugs, refactoring
software so that it conforms to quality standards, or rewriting documents. Sometimes, the
problems discovered in a quality review are such that a management review is also necessary to
decide if more resources should be made available to correct them. After changes have been
made, the review chair may check that the review comments have all been taken into account.
Sometimes, a further review will be required to check that the changes made cover all of the
previous review comments.