The document discusses software quality assurance (SQA), detailing its purpose, processes, and necessary documentation to ensure compliance with specified requirements and customer needs. It outlines the various roles, responsibilities, and procedures involved in maintaining software quality through planning, reviews, and audits at different stages of software development. Additionally, it emphasizes the importance of establishing clear quality targets and the integration of SQA activities within overall software project management.

1. Email : info@quontrasolutions.com
Call : 404-900-9988
Visit : www.quontrasolutions.com
1

2.  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.
2

3. 3

4.  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).
4

5. IEEE Standard for Software Quality
Assurance Plans
5

6.  Purpose
 Reference Documents
 Management
 Documentation
 Standards, practices, conventions, and
metrics
 Test
 Problem Reporting and corrective action
 Tools, techniques, and methodologies
 Media control
 Supplier control
 Records collection,
maintenance, and retention
 Training
 Risk management
 Glossary
 SQAP change procedure and
history
6

7.  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)
7

8.  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

9.  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]):
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
9

10.  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

11. • 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

12. SW-CMM
12

13.  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.
13

14.  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.
14

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

16.  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

17.  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

18.  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

19.  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

20. All text is taken from the 2004 Guide to the SWEBOK.
I formatted the text to highlight certain parts.
20

21.  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

22.  This means ensuring that the problem is clearly and adequately
stated and that the solution’s 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

23.  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.
 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

24.  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

25.  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

26. Thank you!!
26