Introduction to Software Quality
Assurance (SQA)
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
1
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
2
Software Quality Attributes
http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
3
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).
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
4
IEEE Std 730-2002 (Revision of
IEEE Std 730-1998)
IEEE Standard for Software
Quality Assurance Plans
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
5
Required SQAP Sections
•
•
•
•
•
Purpose
Reference Documents
Management
Documentation
Standards, practices,
conventions, and
metrics
• Test
• Problem Reporting
and corrective action
• Tools, techniques, and
methodologies
3/23/2016
• Media control
• Supplier control
• Records collection,
maintenance, and
retention
• Training
• Risk management
• Glossary
• SQAP change
procedure and history
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
6
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 1058™1998 [B13])
– e) Maintenance plan (see IEEE Std 1219™-1998 [B15])
– f) Software safety plans (see IEEE Std 1228™-1994 [B16])
– g) Software integration plan
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
7
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]):
•
•
•
•
•
•
3/23/2016
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 Alexander Reyes.
reyes@uta.edu
8
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
•
•
•
•
–
–
–
–
3/23/2016
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
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
9
Software Capability Maturity Model
SW-CMM
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
10
SW-CMM Key Practices for
Software Quality Assurance
• A SQA plan is prepared for the SW project ATADP.
• The SQA group’s activities are performed IAW the SQA
plan.
• The SQA group participates in the preparation & review of
the project’s 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 customer’s SQA personnel, as
appropriate.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
11
RUP Steps for SQA
All the following text is from
Rational Unified Process
7.0.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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"
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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:
–
–
–
–
–
–
–
–
3/23/2016
Documentation Plan
Measurement Plan
Risk Management Plan
Problem Resolution Plan
Configuration Management Plan
Software Development Plan
Test Plan
Subcontractor Management Plan
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.Compiled by Arthur Alexander Reyes.
3/23/2016
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
18
• This means ensuring that the
problem is clearly and
adequately stated and that the
solution’s requirements are
properly defined and expressed.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
21
• The SQA plan defines the means
that will be used to ensure that
software developed for a specific
product satisfies the user’s
requirements and is of the
highest quality possible within
project constraints.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
22
• In order to do so, it must first
ensure that the quality target is
clearly defined and understood.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
23
• It must consider management,
development, and maintenance
plans for the software.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
24
• Refer to standard (IEEE730-98)
for details.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
26
• The SQA plan should be
consistent with the software
configuration management plan
(refer to the Software
Configuration Management KA).
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
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-theshelf software (COTS) installation,
and service after delivery of the
software.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
30
• It can also contain acceptance
criteria as well as reporting and
management activities which are
critical to software quality.
3/23/2016
Compiled by Arthur Alexander Reyes.
reyes@uta.edu
31