Email : info@quontrasolutions.

com
Call

: 404-900-9988

Visit

: www.quontrasolutions.com
1

The degree to which a system, component, or

process meets specified requirements.

The degree to which a system, component or

process meets customer or user needs or
expectations.

A planned and systematic pattern of all actions

necessary to provide adequate confidence that an
item or product conforms to established technical
requirements.

A set of activities designed to evaluate the

process by which products are developed or
manufactured. Contrast with: quality control (1).

IEEE Standard for Software

Quality Assurance Plans

Purpose

Media control

Reference Documents

Supplier control

Management

Documentation

Records collection,
maintenance, and
retention

Standards, practices, conventions,

and metrics

Training

Risk management

Glossary

SQAP change procedure

and history

Test
Problem Reporting and corrective
action
Tools, techniques, and
methodologies

4.4.2.1 Software requirements description (SRD)

4.4.2.2 Software design description (SDD)

4.4.2.3 Verification and validation plans

4.4.2.4 Verification results report and validation

results report

4.4.2.5 User documentation

4.4.2.6 Software configuration management plan

(SCMP)

4.4.3 Other documentation

Development process plan
Software development standards description
Software engineering methods/procedures/tools

description
Software project management plan (see IEEE
Std 1058-1998 [B13])
Maintenance plan (see IEEE Std 1219-1998
[B15])
Software safety plans (see IEEE Std 1228-1994
[B16])
Software integration plan
8

4.5.1 Purpose

4.5.2 Content
The subjects covered shall include the basic technical, design,

and programming activities involved, such as documentation,

variable and module naming, programming, inspection, and
testing. As a minimum, the following information shall be
provided (see IEEE Std 982.1-1988 [B6] and IEEE Std 982.21988 [B7]):
a) Documentation standards
b) Design standards
c) Coding standards
d) Commentary standards
e) Testing standards and practices
f) Selected software quality assurance product and process
metrics

4.6.1 Purpose

4.6.2 Minimum requirements

4.6.2.1 Software specifications review (SSR)
4.6.2.2 Architecture design review (ADR)
4.6.2.3 Detailed design review (DDR)
4.6.2.4 Verification and validation plan review
4.6.2.5 Functional audit
4.6.2.6 Physical audit

10

 4.6.2.7 In-process audits

1. Code versus design documentation
2. Interface specifications (hardware and software)
3. Design implementations versus functional
requirements
4. Functional requirements versus test descriptions
4.6.2.8 Managerial reviews
4.6.2.9 Software configuration management plan

review (SCMPR)
4.6.2.10 Post-implementation review
4.6.3 Other reviews and audits
11

SW-CMM

12

A SQA plan is prepared for the SW project ATADP.

The SQA groups activities are performed IAW the

SQA plan.

The SQA group participates in the preparation &

review of the projects SW dev plan, standards, &
procedures.

The SQA group reviews the SWE activities to

verify compliance.
13

The SQA group audits designated SW work

products to verify compliance.

The SQA group periodically reports the results of

its activities to the SWE group.

Deviations identified in the SW activities & SW

work products are documented & handled ATADP.

The SQA group conducts periodic reviews of its

activities & findings with the customers SQA
personnel, as appropriate.
14

All the following text is from

Rational Unified Process 7.0.

15

The Project Manager may not necessarily define the quality

goals for the project, but ensures that these definitions are
created and agreed by the customer, and captured ultimately
in the Software Requirements Specification. The developing
organization may also have a standard set of quality goals, in
a quality policy statement, which can form the basis for these
definitions.

Where possible, these objectives should be described in

measurable terms. For example:
"Zero known severity 1 defects" (...and include a definition
of a severity 1 defect)
"Maximum 3 second response time"
"User can pick up software and begin entering account
information within 1 hour"
16

The next step is to define the organization, roles and

responsibilities that will participate in these tasks.

This should include the reporting channel for the results

of Quality Assurance reviews.

In many situations, the Quality Assurance task should

submit its reports directly to the Project Review Authority.

The Rational Unified Process recommends that the

Software Engineering Process Authority (SEPA) should
have responsibility for the process aspects of quality, and
perform process reviews and audits, as well as ensuring
the proper planning and conduct of the review events
described in the Review and Audit section of the Quality
Assurance Plan.
17

The Quality Assurance Plan also references a number of other

plans describing project standards and how various supporting
process (e.g. configuration management) to be handled.

This information is used to help determine the types of Quality

Assurance reviews that will be done, and their frequency.

The referenced plans would normally include the following:

Documentation Plan
Measurement Plan
Risk Management Plan
Problem Resolution Plan
Configuration Management Plan
Software Development Plan
Test Plan
Subcontractor Management Plan
18

Identify the tasks of Quality Assurance. Typically these reviews

would include:
Audit/review of project plans to ensure they follow the
defined delivery process for the project.
Audit/review of project to ensure the work performed is
following the project plans.
Approval of deviations from the standard organizational
project processes.
Process improvement assessments

The Project Review Authority and Project Manager together

determine the schedule for Quality Assurance reviews and
audits, and the schedule is captured in the project and
iteration plan, which may then be referenced from the Quality
Assurance Plan.

The contract may also allow the customer to request audits.

19

All text is taken from the

2004 Guide to the SWEBOK.
I formatted the text to highlight certain
parts.

20

SQA processes provide assurance that the

software products and
processes

in the project life cycle

conform to their specified requirements

by planning, enacting, and performing a set of activities to

provide adequate
confidence

that quality is
being built into

the software.
21

This means ensuring that the problem is clearly and

adequately stated and that the solutions requirements
are properly defined and expressed.

SQA seeks to maintain the quality throughout the

development and maintenance of the product by the
execution of a variety of activities at each stage which
can result in early identification of problems, an almost
inevitable feature of any complex activity.

The role of SQA with respect to process is to ensure

that planned processes are appropriate and later
implemented according to plan, and that relevant
measurement processes are provided to the
appropriate organization.

22

The SQA plan defines the means that will be used to

ensure that software developed for a specific product
satisfies the users requirements and is of the highest
quality possible within project constraints.

In order to do so, it must first ensure that the quality

target is clearly defined and understood.

It must consider management, development, and

maintenance plans for the software.

Refer to standard (IEEE730-98) for details.

23

The specific quality activities and tasks are laid out,

with their costs and resource requirements, their overall
management objectives, and their schedule in relation
to those objectives in the software engineering
management, development, or maintenance plans.

The SQA plan should be consistent with the software

configuration management plan (refer to the Software
Configuration Management KA).

The SQA plan identifies documents, standards,

practices, and conventions governing the project and
how they will be checked and monitored to ensure
adequacy and compliance.
24

The SQA plan also identifies measures, statistical techniques,

procedures for problem reporting and corrective action,
resources such as tools, techniques, and methodologies,
security for physical media, training, and SQA reporting and
documentation.

Moreover, the SQA plan addresses the software quality

assurance activities of any other type of activity described in
the software plans, such as procurement of supplier software
to the project or commercial off-the-shelf software (COTS)
installation, and service after delivery of the software.

It can also contain acceptance criteria as well as reporting and

management activities which are critical to software quality.

25

Thank you!!

26