SQA and Reviews 1

SOFTWARE QUALITY
ASSURANCE AND
REVIEWS
SOBIA USMAN
SOFTWARE QUALITY ASSURANCE AND
REVIEWS
• Software development Process  Different documents (SRS+ DDS)
• The system analysts & development team leaders who prepared the
document will check it repeatedly in order to detect any possible
error that might have entered.
• Others – such as peers, experts, and customer’s representatives–

reviewing the product and detecting the errors unnoticed by the
development team.
2
SOFTWARE QUALITY ASSURANCE AND
REVIEWS
As defined by IEEE , a review process is:
“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.”
• Reviews have special importance in the SQA process

• They provide early detection and prevent the passing of design
and analysis errors “downstream "to stages where error detection
and correction are much more costly.
3
REVIEW METHODOLOGIES
Several methodologies can be implemented when

reviewing documents.
• Formal design Reviews

• Peer Reviews (inspections and walkthroughs)
• Expert opinions
4
REVIEW OBJECTIVES- DIRECT
• 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.

Correction of these deviations is expected to contribute to improved
communication and coordination resulting from greater uniformity of methods
and documentation style
• To approve the relevant document/Product…. Approval allows the team to

continue to the next development phase. 5
REVIEW OBJECTIVES- INDIRECT
• 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 effectiveness and quality, among other product
features.
6
FORMAL DESIGN REVIEWS
• Formal design reviews, variously called …“formal technical reviews

(FTR)”
• Necessary for approval of the product.
• Formal reviews may be conducted at any development milestone

completion of an analysis or design document, whether that
document is a requirement specification or an installation plan.
7
Some common formal reviews
• DPR – Development Plan Review

• SRSR – Software Requirement Specification Review
• PDR – Preliminary Design Review
• DDR – Detailed Design Review
• DBDR – Data Base Design Review…etc
8
Formal design reviews will focus on

• The participants
• The prior preparation
• The DR session
• The recommended post DR activities
The participants in a DR
• All DRs are conducted by a review leader and a review team.
• The choice of appropriate participants is of special importance
because of their power approve or disapprove a product.
9
Review leader:
• Appointment of an appropriate review leader is a major factor affecting
the FR’s success
• Certain characteristics are to be looked for in a candidate for this position:

• Knowledge and experience in development of projects of the type
reviewed.
• A good relationship with the project leader and his team.
Candidates for review team leadership include
• The development department’s manager
• The software engineer
• The head of the software quality assurance unit 10
FORMAL DESIGN REVIEWS (DRS)
The review team:
• A review team of three to five members is expected to be an

efficient team
• Should be selected from among the senior members of the
project team
• Senior professionals assigned to other projects and departments
• Customer–user representatives
• Software development consultants.
11
Preparations for a DR:

The main tasks of the review leader in the preparation stage are:
• To appoint the team members
• To schedule the review sessions
• To distribute the document among the team members (hard copy,
electronic file, etc.).
Review team preparations:

• Review the document
• list their comments prior to the review session.
12
Development team preparations:
• Prepare a short presentation of the document.
• The presentation should focus on the main professional issues awaiting
approval
The DR session:
A typical DR session agenda includes:
• A short presentation of the design document.
• Comments made by members of the review team.
• Comments are 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.
13
FORMAL DESIGN REVIEWS (FRS)
These decisions can take three forms:
Full approval
• Enables immediate continuation to the next phase of the project.
Partial approval
• Approval of immediate continuation to the next phase for some parts of
the project, with major action items (corrections, changes and additions)
demanded for the remainder of the project.
• Continuation to the next phase of these remainder parts will be permitted
only after satisfactory completion of the action items.
Denial of approval
• Demands a repeat of the DR. This decision is applied in cases of multiple
major defects, particularly critical defects.
14
FORMAL DESIGN REVIEWS (DRS)
Post-review activities:
• The DR team or its representative is required to follow up performance of the
corrections and to examine the corrected sections.
The DR report
The report’s major sections contain:
• 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.
• For each action item, the anticipated completion date and project team
member responsible are listed.
• The name(s) of the review team member(s) assigned to follow up
performance of corrections.
15
THE FOLLOW-UP PROCESS
• The person appointed to follow up the corrections, in

many cases the review leader, is required to determine
whether each action item has been satisfactorily
accomplished .
• Follow-up should be fully documented to enable

clarification of the corrections in the future, if necessary.
16
17
18

SQA and Reviews 1

Uploaded by

Copyright:

Available Formats

SQA and Reviews 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SQA and Reviews 1

Uploaded by

Copyright:

Available Formats

SOFTWARE QUALITY

• Software development Process  Different documents (SRS+ DDS)

• Others – such as peers, experts, and customer’s representatives–

As defined by IEEE , a review process is:

“A process or meeting during which a work product, or set of work

• Reviews have special importance in the SQA process

Several methodologies can be implemented when

• Formal design Reviews

• To detect analysis and design errors as well as subjects where corrections,

• To identify new risks likely to affect completion of the project.

• To locate deviations from templates and style procedures and conventions.

• To approve the relevant document/Product…. Approval allows the team to

• To provide an informal meeting place for exchange of professional

• The corrective actions are expected to improve development

• Formal design reviews, variously called …“formal technical reviews

• Necessary for approval of the product.

• Formal reviews may be conducted at any development milestone

Some common formal reviews

• DPR – Development Plan Review

Formal design reviews will focus on

• Certain characteristics are to be looked for in a candidate for this position:

The review team:

• A review team of three to five members is expected to be an

Preparations for a DR:

Review team preparations:

• The person appointed to follow up the corrections, in

• Follow-up should be fully documented to enable

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.