Part II Pre-project SQ components Chapter 5
Chapter 8 Reviews
IEEE definition Review process :
A process or meeting during which a work product or set of products is presented to project personnel , managers, users,
customers, or other interested parties for
comment or approval.
Methodologies for reviewing documents
Reviews acquire special importance in the SQA process because they provide early direction and prevent the passing of design and analysis errors
“down-stream” , to stages where error detection and correction are much complicated and costly :
The methodologies for reviewing :
Formal design review
Peer reviews ( inspections and walkthroughs )
Expert opinions
Standards for SW reviews are the subject of IEEE std
Reviews Objectives ( Direct Objectives )
To detect analysis & 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. Correction of these deviations is expected to contribute to improved communication & coordination resulting from greater uniformity of methods &
documentation style.
To approve the analysis or design product. Approval allows the team to continue to the next development phase.
Reviews 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. The
corrective actions are expected to improve
development methods by increasing effective and
quality, among other product features.
Formal design reviews ( DRs )
Formal design review, also called
Design reviews ( DRs )
Formal technical reviews ( FTR )
Without this approval, the development team cannot continue to the next phase of SW development
project.
Formal design review can be conducted at any
development milestone requiring completion of an analysis or design document, whether that document is a requirement specification or an installation plan.
A list of common Formal design reviews :
DPR - development plan review
SRSR- Software requirement specification review
PDR – Preliminary design review
DDR – Detail 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
The Formal Design Review will focus on :
The participants
The prior preparations
The DR session
The recommended post-DR activities
The participants in a DR
All DRs are conducted by
A review leader
A review team
The review leader: characteristics
Knowledge & experience in development of projects of the type reviewed.
Seniority at a level similar to if not higher than that of the project leader
A good relationship with the project leader and his team
A position external to the project team.
Small dev. Departments and software houses typically have
The Review Team
It is desirable for non-project staff to make up the majority of the review team.
The size of the review team from 3 to 5 to be
an efficient team
Preparation for a DR
A DR session are to be completed by all three main participants in the review :
Review leader , an team
Development team.
Each one is required to focus on distinct aspects of the process.
Review leader preparations (main tasks) :
To appoint the team members
To schedule the review sessions
Preparation for a DR
Review team preparations (main tasks) :
Review the design document and list their comments prior to the review session
team members may use a review checklists.
See chapter 15 ( checklists )
Development team preparations ( main tasks )
Prepare a short presentation of the design document
The presentation should focus on the main
professional issues awaiting approval rather than
wasting time on description of the project in general.
The DR session
The agenda is the issue ( a typical DR session agenda ) :
1. A short presentation of the design document
2. Comments made by members of the review team.
3. Verification and validation in which each of the comments is discussed to determine the required
actions ( corrections, changes and addition ) that the project team has to perform.
4. Decisions about the design product ( document ), which determines the project’s progress. These
Decisions forms :
Full approval : enables immediate continuation to the next phase. It may be accompanied by demands for some minor corrections to be performed by
project team.
Partial approval: approval of immediate
continuation to the next phase for some parts of the project, with major action items demanded for the remainder of the project.
Denial of approval : demands to repeat of the DR
The DR report see appendix 8A
one of the review leader responsibilities is to issue a DR report immediately after the review session.
The development team should perform the
corrections earlier and minimize the attendant delays to the project schedule.
The report major sections contain :
A summary of the review discussion
The decision of the continuation of the project
A full list of the required actions ( corr, changes, additions) and the anticipated completion dates.
The name(s) of the review team member(s) assigned to
The follow-up process
The review leader himself is required to
determine whether each action item has been satisfactory accomplished as a condition for allowing the project to continue to the next phase.
Follow-up should be documented to enable
clarification.
Pressman (2000, chapter 8 )
Pressman’s 13 “golden guidelines “ for a successful design review:
See page 157
Peer Reviews
two review methods ( Inspection and Walkthrough )
The major difference between formal design reviews and peer review methods is rooted in participants & authority.
In peer reviews, as expected, the project leader’s equals, members of his department and other units.
The other difference lies in degree of authority & the objective of each review method.
The peer review main objectives lies in detecting errors &
deviations from standards.
The appearance of the CASE tools reduce the value of manual reviews such as inspection and walkthrough.
Researches find out that peer reviews are highly efficient as well as effective method.
Inspection & Walkthrough
What differentiates a walkthrough from an
inspection is the level of formality, inspection is the more formal of two.
Inspection emphasizes the objective of corrective actions.
Walkthrough’s findings are limited to
comments on the document reviewed.
Inspection & Walkthrough
Inspection is usually based on a comprehensive infrastructure, including :
Development of inspection checklists developed for each type of design document as well as coding language and tool, which are periodically updated.
Development of typical defect type frequency tables, based past findings, to direct inspectors to potential “defect
concentration areas”.
Periodic analysis of the effectiveness of past inspections to improve the inspection methodology
Introduction of scheduled inspections into the project activity plan and allocation of the required resources, including resources for correction of detected defects.
Participants of peer reviews
A review leader
Main tasks & qualification page 161
The author
Invariably a participant in each type of peer review.
Specialized professional
For inspections:
A designer
A coder or implementer
A tester
For walkthrough:
A standards enforcer
A maintenance expert A user representative.
Team assignments
The presenter
The Scribe
Preparations for a peer review session
Leader preparation
Team’s preparation
Session Documentation
Inspection session findings report
Prepared by the scribe
Inspection session summary report
Prepared by the leader
See appendix 8b , 8c
Post-Peer review activities
Post-inspection activities are conducted to attest to :
The prompt, effective correction and reworking of all errors by the designer/author and his team, as
performed by the inspection leader in the course of the assigned follow-up activities.
Transmission of the inspection reports to the internal Corrective Action Board ( CAB ) for analysis.
See Fig 8.2 ( comparison of the peer review
The efficiency of peer reviews
Some of the more common metrics
applied to estimate the efficiency of peer reviews:
peer review detection efficiency( average hrs worked per defect detected)
Peer review defect detection density ( average number of defects detected per page of the design document )
Internal peer review effectiveness ( % of
defects detected by peer reviews as % of total defects detected by the developer).
Comparisons
See tables page 167-169
Expert opinions ( external )
It is good in the following situations :
Insufficient in-house proff.
Temporary lack in-house proff.
Disagreements
In small organizations
Chapter 9
Software testing - Strategies
Testing Definition :
Testing is the process of executing a program with intention of finding errors.
IEEEdefinition:
1. The process of operating a system or component under specified condition, observing or recording the results, and making an evaluation of some aspect of the system or component.
2. The process of analyzing a software item to detect the difference between the existing and required conditions ( that is, bugs ) and evaluate the features of the software