Software Quality Assurance

What is Software Quality Assurance?

SQA is a set of activities that

Defines and assesses the adequacy of software processes to ...
Provide evidence for a justified statement of confidence that ...
The software processes will produce software products that ...
Conform to their established requirements.

SQA Is Not

Testing
Reviewing or Auditing
Reactive
A gate or ꞌꞌpoliceꞌꞌ
Done only at the end of development
An organizational unit (though some units may be named ꞌꞌSQAꞌꞌ)

Why SQA?

Fewer defects in the
- Processes used to develop software.
- Business rules and requirements.
- Software products.
Defects are found much earlier in lifecycle
- Thereby costing far less in money and time address.
Reduction and elimination of waste.
Generate confidence throughout the project that activities will go well.

Beneficiaries

Who benefits when an organization adopts IEEE 730?

Quality managers who are looking for guidance and streamlined implementation for SQA.
Project managers who do not want poor quality to damage their schedule, budget, and ability to deliver customer acceptable software.
Product managers who want to deliver software that fully satisfies their customer’s requirements.
Senior managers who want their company’s quality to be a competitive advantage, and those having customers who require a demonstration of a commitment to quality.
Customers and end users who want quality software with few or no bugs.

What is IEEE 730?

Gives guidance and establishes requirements for Software Quality Assurance in a software project.
The very first published software engineering standard – 1979.
Gives the details for the Software Quality Assurance tasks outlined in the IEEE 12207 Standard for Software Life Cycle Processes.
IEEE 730-2014 greatly expands on the previous version of 2002; more like a whole new standard than a revision.

Why IEEE 730?

Easy to use, very informative
- Easy to follow, like a handbook
- Gathers all the current SQA information in one place
- Provides a clear checklist of what to do to organize the production of quality software
Fulfills important quality purposes for an organization
- Demonstrating conformance to the official standard for SQA
- As a reference for developing an effective and consistent SQA process specifically pertinent to the organization
- Obtaining information and guidance for specific questions

Relation to IEEE 12207

7.2.3 Software Quality Assurance Process

Purpose

Software Quality Assurance Process provides assurance that work products and processes comply with predefined provisions and plans.

Outcomes

As a result of successful implementation of SQA Process:

strategy for conducting quality assurance is developed;
evidence of software quality assurance is produced and maintained;
problems and/or non-conformances with requirements are identified and recorded; and
adherence of products, processes and activities to applicable standards, procedures and requirements is verified.

Key Concepts of IEEE 730

Management Responsibility
SQA = Product Assurance + Process Assurance
Software Product Risk
- Software Integrity Levels
- Assurance Cases
Non-conformance
- Corrective and Preventive Actions
- Root Cause Analysis

Management Responsibility

Management support for SQA

Management is familiar with and understands SQA purposes, concepts, practices, and needs.
Management shall provide the SQA organization with an appropriate level of skilled resources (people and equipment, knowledge, methods, facilities, tools) as requested by the SQA organization in order to accomplish their project responsibilities.
Management shall receive and act upon information provided by SQA organization throughout course of a project.

Product Assurance

An important aspect of software quality assurance is establishment of confidence in quality of software products produced
- These products include not only software and related documentation but also plans associated with development, operation, support, maintenance, and retirement of software
- A product may also be a software service
Product assurance activities provides evidence that software services, products, and related documentation comply with contract and any non-conformances are identified and addressed.

Process Assurance

Process Assurance activity makes certain that lifecycle model processes used to develop, install, operate, and maintain software are adequate, efficient and effective.
Process Assurance provides evidence that the processes that create software products comply with the contract and any non-conformances are identified and recorded.

Software Product Risk

A fundamental principle of this standard is making sure that SQA Plan is commensurate with inherent product risk.
Product risks may include safety, security, and liability, and other defined risks.
Two techniques for addressing product risks are software integrity levels and assurance cases.

Software Integrity Levels

A software integrity level scheme is a set of discrete values used to define level of rigor (applied by Software Development and SQA) to b applied to portions of system – often from lowest to highest – as determined by some critical project attribute, such as consequences associated with system failures.

Software Integrity Level Schemes

Integrity Level	Description
4	An error in a function or system feature that causes: - catastrophic consequences to the system with reasonable, probable, or occasional likelihood of occurrence of an operating state that contributes to the error; or - critical consequences with reasonable or probable likelihood of occurrence of an operating state that contributes to the error.
3	An error in a function or system feature that causes: - catastrophic consequences with occasional or infrequent likelihood of occurrence of an operating state that contributes to the error; or - critical consequences with probable or occasional likelihood of occurrence of an operating state that contributes to the error; or - marginal consequences with reasonable or probable likelihood of occurrence of an operating state that contributes to the error.
2	An error in a function or system feature that causes: - critical consequences with infrequent likelihood of occurrence of an operating state that contributes to the error; or - marginal consequences with probable or occasional likelihood of occurrence of an operating state that contributes to the error; or - negligible consequences with reasonable or probable likelihood of occurrence of an operating state that contributes to the error.
1	An error in a function or system feature that causes: - critical consequences with infrequent likelihood of occurrence of an operating state that contributes to the error; or - critical consequences operating state that contributes to the error; or - marginal, sequences with probable, occasional or infrequent occurrence of an operating state that contributes to the error; or - negligible consequences with probable, occasional, or infrequent likelihood of occurrence of an operating state that contributes to the error.

Assurance Cases

A documented body of evidence that provides a convincing and valid level of confidence that a specified set of critical claims about a software system's properties are adequately justified for a given application in a given context.
Presents a claim that is supported by arguments and evidence that a software system is acceptably safe, secure, reliable, in a given context.

Assurance Cases (cont.)

Assurance Case Part	Explanation
Claim	A claim made about some aspect of a software system
Arguments	Specific arguments supporting the claim: - Argument #1 ... - Argument #n
Evidence	Factual evidence (including reviews, records, and test results) that support each of the arguments. - Evidence #1 ... - Evidence #n

Additional details on assurance cases can be found in ISO/IEC 15026 - Systems and software engineering — Systems and software assurance.

Non-conformance

A non-conformance is a general term used to indicate that actual results do not match expected results.
Typically raised by SQA as a result of performing an activity defined in SQA Plan
- Product Assessments such as reviews and inspections and testing
- Process Assessments such as audits
Corrective and Preventive Actions
Root Cause Analysis