Introduction to Software Quality

Assurance (SQA)

02/24/15

Compiled by Arthur

Software Quality
(IEEE Standard Glossary)
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.
02/24/15

Compiled by Arthur

Software Quality Attributes

http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html

02/24/15

Compiled by Arthur

SQA (via IEEE)

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).
02/24/15

Compiled by Arthur

IEEE Std 730-2002 (Revision of

IEEE Std 730-1998)
IEEE Standard for Software
Quality Assurance Plans

02/24/15

Compiled by Arthur

Required SQAP Sections

Purpose
Reference Documents
Management
Documentation
Standards, practices,
conventions, and
metrics
Test
Problem Reporting
and corrective action
Tools, techniques, and
methodologies
02/24/15

Media control
Supplier control
Records collection,
maintenance, and
retention
Training
Risk management
Glossary
SQAP change
procedure and history

Compiled by Arthur

4.4 Documentation (section 4 of

the SQAP)

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

a) Development process plan

b) Software development standards description
c) Software engineering methods/procedures/tools description
d) Software project management plan (see IEEE Std 10581998 [B13])
e) Maintenance plan (see IEEE Std 1219-1998 [B15])
f) Software safety plans (see IEEE Std 1228-1994 [B16])
g) Software integration plan

02/24/15

Compiled by Arthur

4.5 Standards, practices, conventions, and

metrics (section 5 of the SQAP)
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.2-1988 [B7]):

02/24/15

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

Compiled by Arthur

4.6 Software reviews (section 6

of the SQAP)

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
4.6.2.7 In-process audits

a) Code versus design documentation

b) Interface specifications (hardware and software)
c) Design implementations versus functional requirements
d) 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

02/24/15

Compiled by Arthur

Software Capability Maturity Model

SW-CMM

02/24/15

Compiled by Arthur

10

SW-CMM Key Practices for

Software Quality Assurance
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.
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.

02/24/15

Compiled by Arthur

11

RUP Steps for SQA

All the following text is from
Rational Unified Process
7.0.
02/24/15

Compiled by Arthur

12

Ensure Quality Objectives are

Defined for the Project
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"

02/24/15

Compiled by Arthur

13

Define Quality Assurance

Roles and Responsibilities
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.

02/24/15

Compiled by Arthur

14

Coordinate With Developers of

Referenced Plans
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

02/24/15

Compiled by Arthur

15

Define Quality Assurance Tasks

and Schedule
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.

02/24/15

Compiled by Arthur

16

What SWEBOK Says about SQA

All text is taken from the
2004 Guide to the SWEBOK.
I formatted the text to highlight
certain parts.
02/24/15

Compiled by Arthur

17

 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.
02/24/15

Compiled by Arthur

18

 This means ensuring that the

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

02/24/15

Compiled by Arthur

19

 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.
02/24/15

Compiled by Arthur

20

 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.
02/24/15

Compiled by Arthur

21

 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.

02/24/15

Compiled by Arthur

22

 In order to do so, it must first

ensure that the quality target is
clearly defined and understood.

02/24/15

Compiled by Arthur

23

 It must consider management,

development, and maintenance
plans for the software.

02/24/15

Compiled by Arthur

24

 Refer to standard (IEEE730-98)

for details.

02/24/15

Compiled by Arthur

25

 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.

02/24/15

Compiled by Arthur

26

 The SQA plan should be

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

02/24/15

Compiled by Arthur

27

 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.

02/24/15

Compiled by Arthur

28

 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.
02/24/15

Compiled by Arthur

29

 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.
02/24/15

Compiled by Arthur

30

 It can also contain acceptance

criteria as well as reporting and
management activities which are
critical to software quality.

02/24/15

Compiled by Arthur

31