Software Review

Dr. Aprna Tripathi

 Software Review
• software review is a complete process that results
in carefully examining a software product in a
meeting or at any event.
• This process is usually undertaken by project
personnel, managers, users, customers, user
representatives.
• In software engineering, this term is used to
define review of any work done by trained
personnel's who inspect the software in order to
determine the positive and negative aspects of a
program.
 Types of review
• Weigers (2002) identifies five broad types of review, based on
the purpose for which they are undertaken:
– Educational: The review is conducted to bring people up to speed with
some aspect of the project. For example, a development team might
walk through the system specification prior to commencing design, to
ensure they have a common understanding.
– Peer: The author’s peers help assess the quality of the artifact, and
identify ways in which it could be improved.
– Post project: The review is conducted after the project in order to
capture lessons for the future.
– Status: The review assesses the current status and risks for a project.
– Gate: The review provides information to senior managers to help them
decide whether the project should proceed to the next phase.
 Peer Review
• Peer review underpins most scientific and academic
progress.
• In the software engineering context, Weigers identifies
seven approaches to peer review, based on the degree of
formality applied to the review process:
– Inspection
– Team review
– Walkthrough
– Pair Programming
– Peer deskcheck
– Pass Around
– Ad hoc Review
 Inspection
• A highly formal review with well-defined roles and
procedures covering preparation for and conduct of the
review.
• Inspection techniques (e.g. Fagan, 1976; Gilb and
Graham, 1993) typically define rigorous entry and exit
criteria for each review, together with protocols for
managing checklists, capturing data, reporting,
calculating metrics, and so on.
• Inspections can be very effective at finding defects and
eliminating the root causes of these defects, but they
require substantial organizational commitment and
investment.
 Inspection
• Inspection is the most formal review type.
• The document under inspection is prepared and
checked thoroughly by the reviewers before the meeting,
comparing the work product with its sources and
other referenced documents, and using rules and checklists.
• In the inspection meeting the defects found are logged and
any discussion is postponed until the discussion phase. This
makes the inspection meeting a very efficient meeting.
• many engineering organizations have established
independent test groups that specialize in finding defects.
 Goals of inspection
• help the author to improve the quality of the document
under inspection
• remove defects efficiently, as early as possible
• improve product quality, by producing documents with
a higher level of quality
• create a common understanding by exchanging
information among the inspection participants
• train new employees in the organization's development
process
• learn from defects found and improve processes in
order to prevent recurrence of similar defects
 Characteristics of an inspection
• It is usually led by a trained moderator (certainly not by the author).
• It uses defined roles during the process.
• It involves peers to examine the product.
• Rules and checklists are used during the preparation phase.
• 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.
• Optionally, a causal analysis step is introduced to address process
improvement issues and learn from the defects found.
• Metrics are gathered and analyzed to optimize the process.
 Technical review
• A technical review is a discussion meeting that focuses on
achieving consensus about the technical content of a
document.
• Compared to inspections, technical reviews are less formal
and there is little or no focus on defect identification on the
basis of referenced documents, intended readership and
rules.
• During technical reviews defects are found by experts, who
focus on the content of the document.
• The experts that are needed for a technical review are:
– architects
– chief designers
– key users.
 Goals of a technical review
• assess the value of technical concepts and
alternatives in the product and project
environment;
• establish consistency in the use and
representation of technical concepts;
• ensure, at an early stage, that technical
concepts are used correctly;
• inform participants of the technical content of
the document.
 Characteristics of a technical review
• It is a documented defect-detection process that
involves peers and technical experts.
• It is often performed as a peer review without
management participation.
• Ideally it is led by a trained moderator, but
possibly also by a technical expert.
• A separate preparation is carried out during which
the product is examined and the defects are found.
• More formal characteristics such as the use of
checklists and a logging list or issue log are
optional.
 Walkthrough
• A walkthrough is characterized by the author of the
document under review guiding the participants
through the document and his or her thought
processes, to achieve a common understanding and to
gather feedback.
• This is especially useful if people from outside the
software discipline are present, who are not used to,
or cannot easily understand software development
documents.
• The content of the document is explained step by step
by the author, to reach consensus on changes or to
gather information.
 Goals of a walkthrough
• to present the document to stakeholders both
within and outside the soft ware discipline, in
order to gather information regarding the topic
under documentation;
• to explain (knowledge transfer) and evaluate the
contents of the document;
• to establish a common understanding of the
document;
• to examine and discuss the validity of proposed
solutions and the viability of alternatives,
establishing consensus.
 Characteristics of walkthroughs
• The meeting is led by the authors; often a
separate scribe is present.
• Scenarios and dry runs may be used to validate
the content.
• Separate pre-meeting preparation for reviewers
is optional.
 Review Process
• Reviews vary from very informal to formal.
• The formality of a review process is related to
factors such as :
– the maturity of the development process
– any legal or regulatory requirements or
– the need for an audit trail.
• There are two types of review process
– Informal Review
– Formal Review
 Informal Review
• Informal review is the most common type of
review.
• Informal reviews are applied at various times
during the early stages in the life cycle of
a document.
• A two-person team can conduct an informal
review, as the author can ask a colleague to
review a document or code.
• Not documented
• The goal is to help the author and to improve the
quality of the document.
 Formal Review
• A typical formal review process consists of six
main steps:
– Planning
– Kick-off
– Preparation
– Review meeting
– Rework
– Follow-up
 Plannnig
• The review process for a particular review begins with a
‘request for review’ by the author to the moderator (or
inspection leader).
• A moderator is often assigned to take care of the
scheduling (dates, time, place and invitation) of the review.
• The project planning needs to allow time for review and
rework activities, thus providing engineers with time to
thoroughly participate in reviews.
• There is an entry check performed on the documents and it
is decided that which documents are to be considered or not.
• The document size, pages to be checked, composition
of review team, roles of each participant, strategic approach
are decided into planning phase.
 Kick-off
• The goal of this meeting is to get everybody on the
same page regarding the document under review.
• Also the result of the entry and exit criteria are
discussed.
• During the kick-off meeting, the reviewers receive a
short introduction on the objectives of the review and
the documents.
• Role assignments, checking rate, the pages to be
checked, process changes and possible other
questions are also discussed during this meeting.
 Preparation
• In this phase, participants work individually on the
document under review using the related documents,
procedures, rules and checklists provided.
• The individual participants identify
defects, questions and comments, according to their
understanding of the document and role.
• Spelling mistakes are recorded on the document under
review but not mentioned during the meeting.
• The annotated document will be given to the author at
the end of the logging meeting.
• Using checklists during this phase can make reviews
more effective and efficient.
 Review Meeting
• It consists of the following Three elements:-
– logging phase
• During the logging phase the issues, e.g. defects, that have been
identified during the preparation are mentioned page by page,
reviewer by reviewer and are logged either by the author or by a
scribe.
– discussion phase
• The issues classified as discussion items will be handled during
discussion phase. Participants can take part in the discussion by
bringing forward their comments and reasoning.
– decision phase.
• a decision on the document under review has to be made by the
participants, sometimes based on formal exit criteria.
 Rework
• Based on the defects detected and improvements
suggested in the review meeting, the author
improves the document under review.
• In this phase the author would be doing all the
rework to ensure that defects detected should
fixed and corrections should be properly implied.
• Changes that are made to the document should be
easy to identify during follow-up, therefore the
author has to indicate where changes are made.
 Follow-up
• After the rework, the moderator should ensure that satisfactory
actions have been taken on all logged defects, improvement
suggestions and change requests.
• If it is decided that all participants will check the updated document,
the moderator takes care of the distribution and collects the
feedback.
• In order to control and optimize the review process, a number of
measurements are collected by the moderator at each step of the
process.
• Examples of such measurements include number of defects found,
number of defects found per page, time spent
checking per page, total review effort, etc.
• It is the responsibility of the moderator to ensure that the
information is correct and stored for future analysis.
Roles and Responsibilities in a Review
• There are various roles and responsibilities
defined for a review process.
• Within a review team, four types of
participants can be distinguished:
– moderator,
– author,
– scribe
– reviewer and
– manager.
 The moderator
• The moderator (or review leader) leads the review
process.
• His role is to determine the type of review,
approach and the composition of the review team.
• The moderator also schedules the meeting,
disseminates documents before the meeting,
coaches other team members, paces the meeting,
leads possible discussions and stores the data that
is collected.
 The Author
• As the writer of the ‘document under review’,
the author’s basic goal should be to learn as
much as possible with regard to improving the
quality of the document.
• The author’s task is to illuminate unclear areas
and to understand the defects found.
 The Scribe
• The scribe (or recorder) has to record
– each defect found
– any suggestions or feedback
given in the meeting for process improvement.
 The reviewer
• The role of the reviewers is to check defects
and further improvements in accordance to the
business specifications, standards and domain
knowledge.
 The manager
• Manager is involved in the reviews as he or
she decides
– on the execution of reviews,
– allocates time in project schedules and
– determines whether review process objectives
have been met or not.