Chapter 9

FUNDAMENTALS OF SQA
PLANNING
Objectives
Upon completing this chapter, you will be able
to:
Define the benefits of SQA for projects specified
Modify SQAP checklists for organization-specific projects
Incorporate quality assurance with an overall organization
Set the standards and procedures for the specific project
implement the SQAP to develop quality end product
Develop an SQA plan that complies with the identified
goals.
BUILDING BLOCKS OF SOFTWARE
QUALITY ASSURANCE
IEEE Guideline for Software Quality Assurance Planning
[IEEE Std 730.1-1995] defines defines following building
blocks to develop software quality:
Purpose
Reference Documents
Management
Documentations
Standards, Practices, Conventions, and Metrics
Review, and Audits
Test
Problem Reporting and Corrective Actions
BUILDING BLOCKS OF SOFTWARE
QUALITY ASSURANCE (cont.)
Tools, techniques, and Methodologies
Code Control
Media Control
Supplier Control
Records Collection, Maintenance, and Retention
Training
Risk Management

PURPOSE
This section identifies the specific purpose
and scope of SQAP by:
developing the names of software items
covered by SQAP and the use of software.
It shall answer for the questions like how is
software to be used? How critical is this
software? Who does it apply to? Which
portion of the software life cycle applies to
each of software items? Etc.
REFERENCE DOCUMENTS
This section will provide the complete list
of document referenced to develop SQAP,
e.g. Military, industry specific or corporate
quality assurance standards and guidelines.

MANAGEMENT
This section with the major elements of the
organization that influences the quality of
software, list of tasks covered by this plan
and specification of organization
responsible for each task.
Therefore, IEEE has described this concept
to be incorporated in SQA planning-
Organization, Tasks and Responsibilities
Organization
This section of SQA plan will depict the
organizational structure by describing each
major elements of organization together
with the delegated responsibilities.
Project Manager
Management
Team
Architecture
Team
Development
Team
Assessment
Team
Common Organisational Structure
Role and Responsibilities
i) Project Manager:
Project manager is responsible for providing
requirements and directions, reporting bugs and issues
found by himself and the supervisory committee.
Project manager hosts status meeting time to time to
check the status of project. Project manager is also
responsible for grading presentation.
ii) Management Team:
Management team is responsible for planning the
effort, conducting the plan and adapting the plan to
changes in understanding of the requirements or the
design.
iii) Architecture Team:
Architecture team is responsible for the use case
modelers, and for achieving the system-wide qualities.
iv) Development Team:
Development team is the most popular team, which is
responsible for quality of individual components,
component development, testing and maintenance.
v) Assessment Team:
Assessment team is responsible for quality of end
product with respect to the requirement and customer
expectation.

Role and Responsibilities
Tasks
This section of the plan should identify the
planned major checkpoint to assure the
quality, the tasks to be performed with
special emphasis on software quality
assurance activities and the relationship
between the tasks and the planned
checkpoints.
Associated Tasks
i) Project manager:
the major task of project manager is to review
the weekly development and provide the
requirements.
ii) Management Team:
Management team is responsible for resonance
management and it sets the operational
priorities across the project life cycle.
iii) Architecture Team:
It is responsible to resolve the design issues.
Architecture team focuses on architecture properties,
architecture maintenance, multiple component issue
resolution, performance tuning and quality
improvements.
iv) Development Team:
This team decides how a design or implementation
issues local to a single component is resolved. It
focuses on critical design, implementation, test and
maintenance.
Associated Tasks
v) Assessment Test:
This team exposes any quality issues that affect
the customer's expectations to check whether or
not their expectations are captured in the
requirements.
Associated Tasks
DOCUMENTATIONS
This is an important section of quality assurance
plan as it identifies the the team, documentations
governing the development, verification and
validation, use and maintenance of software.
The main emphasis of this section is on how the
documents are to be checked for adequacy by
identifying the appropriate review or audits.
Minimum documents required to ensure that the
implementation of software satisfy requirements,
may be listed as follows:
Software Requirement Specification (SRS)
ii) Software Design Description (SDD)
iii) Software Verification and Validation Plan
(SVVP)
iv) Software Verification and Validation Report
(SVVR)
v) User Documentation (UD)
vi) Software Configuration Management Plan
(SCMP)
Other documentation such as Sw Dev Plan,
Standards and procedures, Sw Project
Management Plan and Sw Maintenance Manual

STANDARDS, PRACTICES,
CONVENTIONS AND METRICS
This section will describe the standards,
practices, conventions and metrics to be
employed by all associated with the project
including management and vendors.
REVIEWS AND AUDITS
To determine the extent of program of the
software developed during the software
development life cycle and to evaluate the
technical adequacy of the work and its
conformance to software requirements, it is
necessary to review and audit the product
on a planned basis.
i) Software Requirement Review:
This review wil1 guarantee the technical feasibility,
adequacy, and completeness of the requirements as
outlined in SRS. It wil1 occur after the initial
submission of the SRS. Software development team is
responsible to perform such type of review.
ii) Preliminary Design Review:
This is also known as top-level design review. This
review is to evaluate the technical adequacy of the
preliminary design of the software as depicted in the
software architectural design description.
iii) Critical Design Review:
The critical design review (CDR) is held to determine
the acceptability of the detailed software design as
depicted in the detailed software design description in
satisfying the request in SRS.
iv) Software Verification and Validation Plan
Review:
this type of review is conducted to evaluate:
If the system meets its requirements and thus tries to
assess the correctness of the transition to the next
phase (Verification).
If the system meets the user's requirements
(Validation).
v) Functional Audits:
This audit is necessary to be performed prior to the
software delivery to end-users. Functional audit verifies
that all requests specified in SRS have been met. The
Tractability Document (TD) will be used to provide the
traceable matrix. This matrix may be used for verification
during the audits. .
vi) Physical Audits:
This audit is conducted to verify that the software and
its documentation are internally consistent and are
ready for delivery.
vii) In-Process Audits:
In-process audit verifies the consistency of the design
from the various aspects including code versus design
documentation, interface specifications, design
implementation versus functional requirements and
functional requirements versus test descriptions.
viii) Managerial Review:
Managerial reviews assess the execution of all actions
with items identified in software quality assurance
plans
ix) Software Configuration Management Plan
Review:
The adequacy and completeness of configuration
management methods defined in software configuration
management plan will be evaluated through software
configuration management plan review.
x) Post-Mortem Review:
On the successful completion of project, the
development team will submit it to supervising
committee to be reviewed. Now the committee has to
decide the approval of project. The project is
considered as complete, when supervisory committee
approves it.
TEST
Software test plan will be developed by quality
assurance team to outline the test activities, schedule
and resources required for testing and how the test will
be implemented.
The entire specific software tests and testing, which are
not addressed in SVVP, will be included in this section.
The testing process described in SQAP may be used to
address the preparation and review of documentation
associated with the testing process, including test plans,
test design and test case specification, etc.
PROBLEM REPORTING AND
CORRECTIVE ACTION
This section deals with the responsibility of
SQA team to provide the continuous feedback
concerning the problem status to management
and technical team, and describe the practices
and procedures to be followed for reporting,
tracking, and resolving problems identified.
The tasks performed during the problem reporting
and corrective action may be listed as follows:
.Identification of all development discrepancies and
submission to development team
Validation check for the items submitted to team.
Data base maintenance for all discrepancies found in
report.
Documentation of system and process related problems
identified by SQA on report.
Problem resolution by the end of working session.
Conducting meeting to handle any dispute among team
and relevant parties with manager as a mediator.
Documentation and maintenance database for any
problem resolved by the team members.
TOOLS, TECHNIQUES AND
METHODS
This section will describe the specific
software tolls, techniques and methodologies
to be used to support software quality
assurance activity.
Tools
Numerous tools have been proposed in literature for
this purpose. Few of them may be listed as follows:
Operating System Utilities - Simulators
Performance Monitor - Test Drivers
Structure Analyzer - Code Analyzer
Execution Analyzer - Test case Generator
Statistical Analysis Package - Rational Rose Enterprise
Static or Dynamic Test Tools

Techniques
One of the technical and managerial procedures
used to evaluate and improve requirements is
SQA technique, such as listed below:
Review of the use of standards
Software Inspection
Requirements Tracing
Requirements and Design Verification
Reliability Measurement and Assessments

CODE CONTROL
It is a way to protect or ensure the validity
of completed code. Methods and facilities
used to maintain, store, secure and
document controlled version of the
identified software during all phases of
software life cycle, will be discussed in this
section.
MEDIA CONTROL
In this section, methods and facilities will be used
to identify the media for each product and
documentation required to store the media and to
protect these media from unauthorized access or
damage during the development life cycle.
This activity will assure the software storage and
retrieval process, accessibility of software to those
with the need of access, and controls environment
so that the physical media on which the software
is stored do not degrade.
SUPPLIER CONTROL
This section will assure that the developed
software meets the established requirements
by assuring that the developer receives the
adequate and complete requirements.

RECORDS COLLECTION,
MAINTENANCE AND
RETENTION

All the projects artifacts will be stored in
configuration management system.
A copy of each deliverable will be given to the
project manager upon completion of the project.
This section deals with retaining, assembling,
safeguarding, and maintaining the documentation.

TRAINING
This section deals with team training
session carried out whenever necessary to
familiarize the team members to new tools
or techniques.
The technical manager may prepare this
training.
Clients may also be trained after delivering
the software upon the client's request.
RISK MANAGEMENT
This section will deal with ensuring that any potential
risks are identified and discussed fully in team meeting.
Risk Notification Procedure will record the risk that
arises throughout the duration of the project.
Risk management is responsible for identifying the
level of risk associated with the possible failure of each
required task or the unavailability of each resource and
will quantify the magnitude of each identified risk.
SQAP Assurance
Building SQAP is the major plan development
activity in software quality assurance, it is more
important to assure the developed plan to ensure
its completeness, testability, and usability.
SQAP assurance is not an advantage, but a
necessary activity to implement the plan
successfully to develop the quality end software.
Use meta-checklist to verify and ensure the quality
of SQAP.
Meta-checklist Examples
Purpose
Intended use of the software covered by SQAP has been defined:
Scope of SQAP has been identified:
Basic Objective of writing SQAP has been specified:
Software items covered by SQAP has been abbreviated:
Software life cycle development model used has been described:
The reasons for choosing supporting documents that form basis
of SQAP has been presented:

Reference Documents
All the documents that form the basis of SQAP has been
listed:
These documents has been originated outside the project:
The use of most current official version of document has
been ensured :
All the standards, procedures and guidelines has been listed:
Deviations from identified standards, procedures and
guidelines as been listed:
Software deliverables requiring additional or rigorous
practices, procedures or guidelines has been identified:

Management
i) Organization
An appropriate organizational structure has been presented:
Each major elements of organization together with the
delegated responsibilities has described:
The relationship among SQA organizational elements and
software development elements has been delineated and
explained:
A process to resolve all the conflicts has been followed:

ii) Tasks
Major checkpoints to assure the quality has been identified:
Tasks to be performed with special emphasis on software
quality assurance activities has been listed:
The relationship between the tasks and planned checkpoints
has been established and shown:
A workflow diagram has been designed for SQA activities:
iii) Responsibilities
All the specific organizational elements responsible
for each tasks has been listed:
Responsibilities of individuals have been identified
if two organizational elements are sharing the
responsibilities for task.

Documentation
All the documents governing the development, verification and
validation, use and maintenance of software has been identified:
An appropriate way to check for adequacy of documents has been
emphasized:
Minimum documents required to ensure the implementation has
been identified:
All required test documentation has been noted:
Standards, Practices, Conventions and
Metrics
All standards, practices, conventions and metrics to be
planned has been identified:
The way to monitor and assure the compliance with these
items has been depicted:
The phases of life cycle to which they apply has been
listed:
SUMMARY
Software quality assurance is more about the
customer.
Creating a product that has gone through proper
software testing is crucial to guaranteeing
customer satisfaction.
Quality planning involves deciding on a suitable
development process and setting target values for
internal attributes.
Quantitative targets are set for the internal quality
attributes identified in the quality model.
Below is the meta-checklist prepared to
verify and ensure the quality of SQAP.