CSE3019: Software Quality and Reliability

L7 & L8: Reviews

Outline
• Review Definition
• Review Objectives
• Review Categories
• Formal Design Reviews/Formal Reviews/ Design Reviews (DRs)
• Peer Reviews
• Expert Opinions
Outline
• Review Definition
• Review Objectives
• Review Categories
• Formal Design Reviews/Formal Reviews/ Design Reviews (DRs)
• Peer Reviews
• Expert Opinions
Review Definition
IEEE (1990) Definition:
“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.”
Outline
• Review Definition
• Review Objectives
• Review Categories
• Formal Design Reviews/Formal Reviews/ Design Reviews (DRs)
• Peer Reviews
• Expert Opinions
Review Objectives
• Direct Objectives
• Indirect Objectives
Review Objectives
• Direct Objectives
• To detect analysis and design errors as well as subjects where corrections,
changes and completions are required with respect to the original
specifications and approved changes.
• To identify new risks likely to affect completion of the project.
• To locate deviations from templates and style procedures and conventions.
• To approve the analysis or design product.
Review Objectives
• Indirect Objectives
• To provide an informal meeting place for exchange of professional knowledge
about development methods, tools and techniques.
• To record analysis and design errors that will serve as a basis for future
corrective actions.
Outline
• Review Definition
• Review Objectives
• Review Categories
• Formal Design Reviews/Formal Reviews/ Design Reviews (DRs)
• Peer Reviews
• Expert Opinions
Review Categories
• Formal Design Reviews/Formal Reviews/ Design Reviews (DRs)
• Peer Reviews
• Expert Opinions
Formal Design Reviews (DRs)
• Mandatory
Some for approval
Common Formal of the
Design Reviews: design product.
DPR – Development Plan Review
•SRSR
May be conducted
– Software at any development
Requirement Specification Review milestone requiring
completion
PDR of an
– Preliminary Design analysis or design document
Review
DDR – Detailed Design Review
DBDR – Data Base Design Review
TPR – Test Plan Review
STPR – Software Test Procedure Review
VDR – Version Description Review
OMR – Operator Manual Review
SMR – Support Manual Review
TRR – Test Readiness Review
PRR – Product Release Review
IPR – Installation Plan Review
Formal Design Reviews (DRs)
• Participants in a DR
• The review leader
• The review team
Formal Design Reviews (DRs)
• Participants in a DR
• The review leader
• Should be knowledgeable and experienced in developing similar type of project
(preliminary acquaintance with the current project is not necessary)
• Should be a senior person at least equivalent to the project leader
• Should have a good relationship with the project leader and his team
• Should not be from the project team
Formal Design Reviews (DRs)
• Participants in a DR
• The review team
• Should be selected from among the senior members of the project team together with
appropriate senior professionals assigned to other projects and departments, customer–
user representatives, and in some cases, software development consultants
• Should be of size 3-5 max
Formal Design Reviews (DRs)
• Preparation for a DR (before meeting)
• Review leader preparation
• Appoint the team members
• Schedule the review sessions
• Distribute the design document among the team members (hard copy, electronic file,
etc.)
• Review team preparation
• Review the design document (or a portion of it) and list their comments
• Development team preparation
• A short presentation of the design document focusing the main professional issues
awaiting approval (without the detailed project description), assuming that the review
team members have read the design document thoroughly
Formal Design Reviews (DRs)
• DR session (during meeting)
• A short presentation of the design document.
• Comments made by members of the review team.
• Verification and validation in which each of the comments is discussed to
determine the required actions (corrections, changes and additions) that the
project team has to perform.
• Decisions about the design product (document), which determines the
project’s progress
• Full approval
• Partial approval
• Denial of approval
Formal Design Reviews (DRs)
• Post-review activities (after meeting)
• The DR report
• A summary of the review discussions.
• The decision about continuation of the project.
• A full list of the required actions – corrections, changes and additions that the project
team has to perform.
• The name(s) of the review team member(s) assigned to follow up performance of
corrections.
• The follow-up process
• To determine whether each action item has been satisfactorily accomplished as a
condition for allowing the project to continue to the next phase (generally by the team
leader)
Formal Design Reviews (DRs)
• Summary flow diagram for the entire process
Peer Reviews
• Two types
• Inspection – formal, rigorous, in depth group review
• Walkthrough – informal meeting or presentation by the author to get
feedback for improvement
Peer Reviews
• Two types
• Inspection – formal, rigorous, in depth group review
• Walkthrough – informal meeting or presentation by the author to get
feedback for improvement
Peer Reviews
• Participants of peer-review
• Review leader (“moderator” in inspections, “coordinator’ in walkthroughs)
• Expert, from outside the project team
• The author (who prepare the documents)
• Specialized professionals
• In case of inspection
• A designer (system analyst), a coder (implementer), a tester
• In case of walkthrough
• A standard enforcer, a maintenance expert, a user representative
Peer Reviews
• Preparation for a session
• Review leader (“moderator” in inspections, “coordinator’ in walkthroughs)
• Decide the section to be reviewed (whether the most critical/ complex/ error prone one)
• Select the team members, and presenter
• Schedule the sessions, and distribute the documents to the team members
• The author (who prepared the documents)
• Specialized professionals
• In case of inspection
• Take part in an overview meeting
• Read the document sections to be reviewed and list their comments – they use a specific
checklist as the tool for documenting their comments and other formalities
• In case of walkthrough
• NIL
Peer Reviews
• The session
• The presenter reads a section of the document (sometimes with an
explanation)
• Participants deliver their comments
• The scribe (most of the time the leader) document each error identified
during the discussion, mentioning severity and corrective action
• The leader make a session report based on an available template
Peer Reviews
• Post peer-review activities
• Applicable for inspection only (walkthrough does not have any post review
activity)
• The prompt, effective correction and reworking of all errors by the designer/author and
his team, as performed by the inspection leader (or other team member) in the course
of the assigned follow-up activities.
• Transmission of the inspection reports to the internal Corrective Action Board (CAB) for
analysis. This action initiates the corrective and preventive actions that will reduce future
defects and improve productivity
Question
• What are the basic differences between formal design review (DR)
and peer-review?
Expert Opinions
• Prepared by outside experts
• Support quality evaluation by introducing additional capabilities to
the internal review staff
• Organization’s internal quality assurance activities are thereby
reinforced
• Preparing an expert’s judgement about a document or a code section
• Participating as a member of an internal design review, inspection or
walkthrough team
Expert Opinions
• When outside experts are required?
• Insufficient in-house professional capabilities in a specialized area.
• Temporary lack of in-house professionals for review team participation due to
intense workload pressures during periods when waiting will cause
substantial delays in the project completion schedule.
• Indecisiveness caused by major disagreements among the organization’s
senior professionals.
• In small organizations, where the number of suitable candidates for a review
team is insufficient.
Summary
• Review Definition
• Review Objectives
• Review Categories
• Formal Design Reviews/Formal Reviews/ Design Reviews (DRs)
• Peer Reviews
• Expert Opinions
Reference
• Daniel Galin, “Software Quality Assurance: From Theory to
Implementation”, Pearson Education, 2004.
• Ch-8: Sec 8.1 – 8.5
• Self reading: Ch-8 (Whole Chapter)
Next
• Software Testing
Thank You