1. Software Quality Assurance Plans
IEEE Standard for Software Quality Assurance Plans, (revision of 1998 version)
&
IEEE Guide for Software Quality Assurance Planning, (withdrawn)

2. Content Introduction to the IEEE 730-2002 Standard
Content of the Software Quality Assurance Plan (SQAP)
Guide to the Standard
IEEE (withdrawn)
Software Requirements Review according to 730.1
Implementation of SQAP
Evaluation of SQAP
Modification of SQAP
11/20/2018

3. Targeted Audiences The user
Needs the product to meet the requirements identified in the specification.
Cannot afford a ‘hands-off’ attitude
Cannont rely solely on a test to be executed at the end of the software development time period.
Needs to obtain a reasonable degree of confidence that the product is in the process of acquiring required attributes during software development.
The supplier (developer)
Needs an established standard against which to plan and to be measured
Needs a standard to ‘pass down’ to subcontractors.
The public
May be affected by the use of the product.
11/20/2018

4. Introduction
Scope
Applies to the development of a software quality assurance plan (SQAP).
Do not prohibit additional content in a SQAP.
Is consistent with IEEE/EIA standards.
Purpose
To provide uniform, minimum acceptable requirements for preparation and content of SQAPs.
Conformance to this standard
Can be claimed when all requirements (indicated by “shall”) are carried out as defined in this standard.
11/20/2018

5. Content of SQAP Purpose Reference document Management Documentation
Standards, practices, convention, and metrics
Software Reviews
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
11/20/2018

6. Content of SQAP Additional sections may be added as required
Some of the material may appear in other documents
Reference to these documents should be made in SQAP
E.g. a CM plan may be referenced in the SQAP
Approval of the Plan
SQAP shall be approved by the manager of each unit of the organization having responsibilities defined within this SQAP or their designated representatives.
11/20/2018

7. Content of SQAP Section 1: Purpose Purpose and scope
List of software items covered by the plan
Intended use of the software
Portion of lifecycle covered by the plan
Section 2: Reference document
List of documents referenced elsewhere in the SQAP
e.g. other standards (12207)
11/20/2018

8. Content of SQAP - Section 3: Management
Description of organization, tasks, roles and responsibilities
see IEEE Std
Organization
Organizational structure that influences and controls the quality of software
Organizational dependence or independence of SQA from developers.
Tasks – This section shall describe:
Portion of lifecycle covered by SQAP
Tasks to be performed
Entry and exit criteria for each task
Relationships between tasks and checkpoints, sequence of tasks
Responsibilities
Organizational elements responsible for each task
Quality assurance estimated resources
Provide the estimate of resources and the costs to be expended on quality assurance and quality control tasks.
11/20/2018

9. Content of SQAP -Section 4: Documentation
Identify the documentation governing:
The development, verification and validation, use, and maintenance of the software.
List which documents are to be reviewed or audited.
For each document listed, identify the reviews or audits to be conducted and the criteria by which adequacy is to be confirmed
Minimum Documentation Requirements
Software Requirements Description (SRD) (e.g. IEEE 830- SRS)
Software Design Description (SDD), IEEE 1016.
Verification and Validation Plan, e.g. IEEE 829, 1012.
Verification results report and Validation results Report
User documentation, IEEE 1063
Software Configuration Management Plan (SCMP), IEEE 828.
Other documents - may include the following:
Software Development Plan
Standards and Procedures Manual
Software safety plans (IEEE Std 1228)
11/20/2018
IEEE- Software Quality Assurance Plans

10. Content of SQAP - Section 5: Standards, practices, convention, and metrics
Identify the standards, practices, conventions, statistical techniques to be used, quality requirements, and metrics to be applied.
Product and process measures shall be included in the metrics used
State how conformance with these items is to be monitored and assured.
Minimum information required:
Documentation standards
Design standards
Coding standards
Commentary standards
Testing standards and practices
Selected software quality assurance product and process metrics
11/20/2018

11. Reviews in the Life Cycle
Hardware
Development
System
Design
Software
Development
Reviews
System
SRR
SDR
Integration
Software
Reqts
Analysis
Arch.
Design
Functional Baseline
Detailed
Design
SSR
Coding,
Unit
testing
ADR
Component
Integration
Testing
Allocated Baseline
DDR CI
Testing
TRR
Product Baseline
Adapted from US DoD Std 2167A
11/20/2018

12. Reviews in the Life Cycle
What ? When ?
System Requirements Review (SRR) After system requirements have been defined
System Design Review (SDR) After allocations of functions between software and hardware is made
Software Specification Review (SSR) After software requirements have been defined
Architecture Design Review (ADR) After software architecture has been determined and before detailed design is begun
Detailed Design Review (DDR) After detailed design is complete and before coding begins
Test Readiness Review (TRR) Before software configuration item (CI) testing begins
11/20/2018

13. Content of SQAP - Section 6: Software Reviews
See IEEE 1028
Define Managerial and Technical reviews, walkthrough, inspection and audit
List the schedule of reviews and relationships to project’s schedule
How reviews and audits shall be accomplished
State what further actions shall be required and how they shall be implemented and verified
Minimum requirements:
Software Requirements Review (SRR)*
Architecture Design Deview (ADR)
Detailed Design Review (DDR)
Verification and validation plan review
11/20/2018

14. Content of SQAP - Section 6: Software Reviews
Minimum requirements (cont)
Functional audits
To verify that all requirements in the SRS have been met
Physical audits
To verify that software and documentation are internally consistent and ready for delivery
In-Process audit
To verify the consistency of design
code versus design
Interface specifications
Design implementation versus functional requirements
Functional requirements versus test descriptions
11/20/2018

15. Content of SQAP - Section 6: Software Reviews
Minimum requirements (cont)
8. Managerial reviews
To assess the execution of all actions of SQAP
9. Software Configuration Management Plan Review
To evaluate the adequacy and completeness of CM methods defined in SCMP
10. Post-Implementation review
To assess development activities and provide recommendations for appropriate actions
Other
e.g. User Documentation Review (UDR)
11/20/2018

16. Content of SQAP Section 7: Test
Describe tests not covered in SVVP and methods to be used
Section 8: Problem reporting and corrective action
Describe practices and procedures for reporting, tracking, resolving problems in software items and development and maintenance process
State organisational responsibilities
Section 9: Tools, techniques, and methodologies
To support SQA processes
Describe their use, applicability, or circumstances under which it is to be used or not to be used, and limitations.
11/20/2018

17. Content of SQAP - Section 10: Media control
Identify the media for each intermediate and deliverable computer work product and documentation required to store, copy and restore.
Protect media from unauthorized access, damage, degradation during all phases of the software life cycle.
May be provided in SCMP
include reference
11/20/2018

18. Content of SQAP - Section 11: Supplier control
State provisions for assuring that software provided by suppliers meets established requirements
State method to assure that supplier receives adequate and complete requirements
Supplier prepares SQAP iaw this standard
State method to assure that suppliers comply to this standard
11/20/2018

19. Content of SQAP - Section 12: Records collection, maintenance, and retention
Identify SQA documentation to be retained
Identify methods and facilities to assemble, file, safeguard, and maintain this documentation
Designate retention period
11/20/2018

20. Content of SQAP Section 13: Training
Section 13: Training
Identify training activities to meet the needs of the SQAP
Section 14: Risk Management
Identify methods, procedures to identify, assess, monitor, and control areas of risk.
See IEEE 1540 Software Lifecycle Risk Management.
Section 15: Glossary
Terms unique to the SQAP
Section 16: SQAP change procedure and history
Procedure for modifying SQAP and maintaining a history of changes.
11/20/2018
IEEE- Software Quality Assurance Plans

21. IEEE Guide for Software Quality Assurance Planning - 730.1 (Withdrawn)
Guide presents the current consensus of those in the software development and maintenance community with expertise or experience in generating, implementing, evaluating, and modifying an SQAP.
Purpose
Identify approaches to good SQA practices in support of IEEE Std
The guide does not add new requirements to IEEE Std 730
Content
Detailed description of the content of SQA plan
Implementation of SQAP
Evaluation of the SQAP
Modification of an existing SQAP
Methods for proposing, reviewing and instituting modifications to an SQAP
11/20/2018

22. Software Requirements Review (SRR) According to IEEE 730.1
Background
SRD is one of the documents required by IEEE 730
SRD are subjected to reviews (SRR) as required by IEEE 730
IEEE indicates:
Organizational elements responsible for conducting SRR
e.g. customer, system engineering.
Items that will be assessed *
Purpose of SRR
To ensure the adequacy, technical feasibility, and completeness of the requirements stated in the SRD
To evaluate the SRD for the attributes required by IEEE 830
11/20/2018

23. Software Requirements Review (SRR) According to IEEE 730.1
SQAP should specify how, during SRR, the quality of the following items will be assessed:
Traceability and completeness of the requirement from the next higher level specification
such as a system specification or user requirements specification.
Adequacy of rationale for any derived requirements.
Adequacy and completeness of algorithms and equations.
Correctness and suitability of logic descriptions that may be warranted.
11/20/2018

24. Software Requirements Review According to IEEE 730.1
Item to be assessed:
Compatibility of external (hardware and software) interfaces.
Adequacy of the description of and approach to the human-machine interface.
Consistency in the use of symbols and in the specification of all interfaces.
Availability of constants and tables for calculations.
Testability of the software requirements.
Adequacy and completeness of the verification and acceptance requirements.
Completeness and compatibility of interface specification and control documentation.
Freedom from unwarranted design detail.
11/20/2018

25. Software Requirements Review
Additional items to be considered for assessment of the SRR:
Trade-off and design studies that have applicability for decisions on:
Database design and/or real-time design issues.
Programming language characteristics and usage.
Resource allocation (e.g., storage, machine cycles, I/O channel personnel and hardware).
Operating system or executive design, or both.
Development versus COTS solution.
The general description of the size and operating characteristics of all support software
e.g., operational program, maintenance and diagnostic programs, compilers, etc.
A description of requirements for the operation of the software and identification of functional requirements such as functional simulation, performance, environmental recording and analysis, etc.
11/20/2018

26. Software Requirements Review
Results of Review
Documented in SRR report
Identifies deficiencies
Provides a plan and schedule for corrective action
Decision whether or not to proceed
SRD should be placed under Configuration Control
Baseline for software design effort
SQA uses the baseline to develop a Requirements Verification Traceability Matrix (RTVM)
To validate satisfaction of requirements in:
Design
Code
Test
11/20/2018

27. Implementation of SQAP
Describe the steps necessary for successfully implementing the SQAP
Acceptance of the SQAP by the software developers and others whose task responsibilities are defined in the SQAP.
Have concerned personnel participate to preparation and review
Acceptance of the SQAP by management.
To get commitment for budget and resources
Planning and scheduling of resources and tasks for implementation of the SQAP.
Resources: personnel, equipment, facilities, tools
Schedule coordinated with development team
Incorporated in SDP/SPMP
Distribution of the SQAP to implementors and interfacing personnel.
To help insure that intended recipients have a correct version of SQAP
Distribution list with sign-off sheet
Execution of the SQAP.
11/20/2018

28. Evaluation of SQAP Evaluation of Content
An assessment of how the SQAP complies with IEEE Std 730, internal development and quality assurance standards, and contractual documents.
Evaluating the content of the SQAP (initially and after all revisions).
Evaluation of the overall approach:
Are all mandatory requirements of IEEE Std 730 addressed in the SQAP ?
Are all contractual and company SQAP standards addressed in the SQAP ?
Does the SQAP specify compliance with any standards in addition to IEEE Std 730 ?
If so, does the SQAP meet the requirements of those standards?
Are all exceptions to mandatory requirements noted and adequately justified?
Is the content of the SQAP adequate to achieve its stated objectives?
Are the SQA requirements, as stated, enforceable, and measurable?
11/20/2018

29. Evaluation of SQAP Evaluation of Content
Evaluation of specific SQAP section (e.g. management, standards, etc)
SQAP evaluation checklist
11/20/2018

30. Evaluation of SQAP Evaluation of Use and Management of the SQAP.
Help assure that the project and its SQAP evolve together.
A management review of SQAP (e.g. IEEE 1028) is held at several points in the life cycle
e.g. Project milestones
Evaluation Process
SQAP evaluation may have the effect of causing SQAP modification or causing an implementation evaluation
11/20/2018

31. Modification of SQAP Purpose
Provide a method for modifying an existing SQAP
Reasons for modifying a SQAP
SQAP may contain deficiencies
Adjust to changes in the environment
New set of system requirements
Changes in management structure of the project
May make portions of the SQAP obsolete
New processes and technology
New SQA tools or techniques must be incorporated
Methodology
Identify alternative options
Recommend proposed change: e.g. a CCB review
Review proposes change: e.g. with CCB
Incorporate approved change
Release and promulgate change
11/20/2018

32. Annex A.- Summary of the SQAP and related standards
Note: has been updated in 2002.
11/20/2018

33. Summary Introduction to the IEEE 730 Standard
Content of the Software Quality Assurance Plan (SQAP)
Guide to the Standard
IEEE
Software Requirements Review according to 730.1
Implementation of SQAP
Evaluation of SQAP
Modification of SQAP
11/20/2018