2008-06-30

Software Quality Assurance Plans

IEEE Standard for Software Quality Assurance Plans, 730-2002 (revision of 1998 version) & IEEE Guide for Software Quality Assurance Planning, 730.1-1995 (withdrawn)

Content
1. Introduction to the IEEE 730-2002 Standard 2. Content of the Software Quality Assurance Plan (SQAP) 3. Guide to the Standard IEEE 730.1- 1995 (withdrawn) 4. Software Requirements Review according to 730.1 5. Implementation of SQAP 6. Evaluation of SQAP 7. Modification of SQAP

6/30/2008

IEEE- Software Quality Assurance Plans

2008-06-30

Targeted Audiences
1. The user Needs the product to meet the requirements identified in the specification. Cannot afford a hands-off attitude Cannot 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. 2. The supplier (developer) Needs an established standard against which to plan and to be measured Needs a standard to pass down to subcontractors. 3. The public May be affected by the use of the product.
6/30/2008 3

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 12207 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.

6/30/2008

IEEE- Software Quality Assurance Plans

2008-06-30

Content of SQAP
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
6/30/2008

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
5

Content of SQAP
1. Additional sections may be added as required 2. 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

3. 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.

6/30/2008

IEEE- Software Quality Assurance Plans

2008-06-30

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) Standards used to develop the plan e.g. Corporate quality manual.

6/30/2008

Section 3: Management
Description of organization, tasks, roles and responsibilities
1. See IEEE Std 1058 -1998 (Software Plan) Organization
Organizational structure that influences and controls the quality of software Organizational dependence or independence of SQA from developers. 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 Organizational elements responsible for each task Provide the estimate of resources and the costs to be expended on quality assurance and quality control tasks.
8

2.

Tasks

3. 4.

Responsibilities

Quality assurance estimated resources

6/30/2008

IEEE- Software Quality Assurance Plans

2008-06-30

Section 4: Documentation
Identify the documentation governing:
The development, verification and validation, use, and maintenance of the software. For each document listed, identify the reviews or audits to be conducted and the criteria by which adequacy is to be confirmed
Software Requirements Description (SRD) (e.g. IEEE 830- SRS), Software Design Description (SDD), IEEE 1016, Verification and Validation Plan, (SVVP) e.g. IEEE 829 (Test Doc), 1012, Verification results report and Validation results Report, User documentation, IEEE 1063, Software Configuration Management Plan (SCMP), IEEE 828.

List which documents are to be reviewed or audited.

Minimum Documentation Requirements

1. 2. 3. 4. 5. 6.

Other documents - may include the following:

1. Software Development Plan, 2. Standards and Procedures Manual, 3. Software safety plans (IEEE Std 1228).

6/30/2008

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:
a) b) c) d) e) f)
6/30/2008

Documentation standards Design standards Coding standards Commentary standards Testing standards and practices Selected software quality assurance product and process metrics
10

IEEE- Software Quality Assurance Plans

2008-06-30

Reviews in the Life Cycle

Hardware Development
System Design

Software Development
Software Reqts Analysis Arch. Design Detailed Design

Reviews

System Integration

SRR SDR
Functional Baseline

SSR ADR
Allocated Baseline

Coding, Unit testing Component Integration Testing

DDR TRR

CI Testing Product Baseline

Adapted from US DoD Std 2167A 6/30/2008

11

Reviews in the Life Cycle

What ?
System Requirements Review (SRR) System Design Review (SDR) Software Specification Review (SSR) Architecture Design Review (ADR) Detailed Design Review (DDR) Test Readiness Review (TRR)

When ?
After system requirements have been defined After allocations of functions between software and hardware is made After software requirements have been defined After software architecture has been determined and before detailed design is begun After detailed design is complete and before coding begins Before software configuration item (CI) testing begins

6/30/2008

12

IEEE- Software Quality Assurance Plans

2008-06-30

Section 6: Software Reviews

See IEEE 1028 1. Define Managerial and Technical reviews, walkthrough, inspection and audit 2. List the schedule of reviews and relationships to projects schedule 3. How reviews shall be accomplished 4. State what further actions shall be required and how they shall be implemented and verified 5. Minimum requirements:
1. 2. 3. 4.
6/30/2008

Software Requirements Review (SRR)* Architecture Design Review (ADR) Detailed Design Review (DDR) Verification and Validation Plan Review (SVVP)
13

Section 6: Software Reviews

5. Minimum requirements (cont)
5. Functional audits To verify that all requirements in the SRS have been met 6. Physical audits To verify that software and documentation are internally consistent and ready for delivery 7. In-Process audit To verify the consistency of design Code versus design Interface specifications Design implementation versus functional requirements Functional requirements versus test descriptions
6/30/2008 14

IEEE- Software Quality Assurance Plans

2008-06-30

Section 6: Software Reviews

5. Minimum requirements (cont)
8. Managerial reviews To assess the execution of all actions of SQAP 9. Software Configuration Management Plan (SCMP) 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)

6/30/2008

15

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.
6/30/2008 16

IEEE- Software Quality Assurance Plans

2008-06-30

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

6/30/2008

17

Section 11: Supplier control

1. State provisions for assuring that software provided by suppliers meets established requirements 2. State method to assure that supplier receives adequate and complete requirements 3. Supplier prepares SQAP i.a.w. this standard 4. State method to assure that suppliers comply to this standard

6/30/2008

18

IEEE- Software Quality Assurance Plans

2008-06-30

Section 12: Records collection, maintenance, and retention

1. Identify SQA documentation to be retained, 2. Identify methods and facilities to assemble, file, safeguard, and maintain this documentation, 3. Designate retention period.

6/30/2008

19

Content of SQAP
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.
6/30/2008 20

IEEE- Software Quality Assurance Plans

10

2008-06-30

IEEE Guide for Software Quality Assurance Planning - 730.1 (Withdrawn)

Guide presents the 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 730- 1998. The guide does not add new requirements to IEEE Std 730 Content 1. Detailed description of the content of SQA plan 2. Implementation of SQAP 3. Evaluation of the SQAP 4. Modification of an existing SQAP Methods for proposing, reviewing and instituting modifications to an SQAP
6/30/2008 21

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 730.1 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.
22

6/30/2008

IEEE- Software Quality Assurance Plans

11

2008-06-30

Software Requirements Review (SRR)

According to IEEE 730.1 SQAP should specify how, during SRR, the quality of the following items will be assessed:
1. Traceability and completeness of the requirement from the next higher level specification such as a system specification or user requirements specification. 2. Adequacy of rationale for any derived requirements. 3. Adequacy and completeness of algorithms and equations. 4. Correctness and suitability of logic descriptions that may be warranted.

6/30/2008

23

Software Requirements Review

According to IEEE 730.1 Item to be assessed (cont):
5. Compatibility of external (hardware and software) interfaces. 6. Adequacy of the description of and approach to the humanmachine interface. 7. Consistency in the use of symbols and in the specification of all interfaces. 8. Availability of constants and tables for calculations. 9. Testability of the software requirements. 10. Adequacy and completeness of the verification and acceptance requirements. 11. Completeness and compatibility of interface specification and control documentation. 12. Freedom from unwarranted design detail.
6/30/2008 24

IEEE- Software Quality Assurance Plans

12

2008-06-30

Software Requirements Review

Additional items to be considered for assessment of the SRR: 1. Trade-off and design studies that have applicability for decisions on:
1. Database design and/or real-time design issues. 2. Programming language characteristics and usage. 3. Resource allocation (e.g., storage, machine cycles, I/O channel personnel and hardware). 4. Operating system or executive design, or both. 5. Development versus COTS solution.

2. The general description of the size and operating characteristics of all support software
e.g., operational program, maintenance and diagnostic programs, compilers, etc.

3. 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.
6/30/2008 25

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

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

6/30/2008

26

IEEE- Software Quality Assurance Plans

13

2008-06-30

Implementation of SQAP
Describe the steps necessary for successfully implementing the SQAP
1. 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 To get commitment for budget and resources

2. 3.

Acceptance of the SQAP by management.

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

4.

Distribution of the SQAP to implementers and interfacing personnel.

To help insure that intended recipients have a correct version of SQAP Distribution list with sign-off sheet
27

5.
6/30/2008

Execution of the SQAP.

Evaluation of SQAP
Evaluation of Content
1. 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).

2.

Evaluation of the overall approach:

1. Are all mandatory requirements of IEEE Std 730 addressed in the SQAP ? 2. Are all contractual and company SQAP standards addressed in the SQAP ? 3. 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? 4. Are all exceptions to mandatory requirements noted and adequately justified? 5. Is the content of the SQAP adequate to achieve its stated objectives? 6. Are the SQA requirements, as stated, enforceable, and measurable?
6/30/2008 28

IEEE- Software Quality Assurance Plans

14

2008-06-30

Evaluation of SQAP
Evaluation of Content
Evaluation of specific SQAP section (e.g. management, standards, etc)
SQAP evaluation checklist

6/30/2008

29

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 SQAP evaluation may have the effect of causing SQAP modification or causing an implementation evaluation

Evaluation Process

6/30/2008

30

IEEE- Software Quality Assurance Plans

15

2008-06-30

Modification of SQAP
Purpose Provide a method for modifying an existing SQAP
Reasons for modifying a SQAP
1. SQAP may contain deficiencies 2. Adjust to changes in the environment New set of system requirements 3. Changes in management structure of the project May make portions of the SQAP obsolete 4. New processes and technology New SQA tools or techniques must be incorporated

Methodology
1. 2. 3. 4. 5. 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
31

6/30/2008

Annex A.- Summary of the SQAP and related standards

Note: 730-1989 has been updated in 2002.

6/30/2008

32

IEEE- Software Quality Assurance Plans

16

2008-06-30

Summary
1. Introduction to the IEEE 730 Standard 2. Content of the Software Quality Assurance Plan (SQAP) 3. Guide to the Standard IEEE 730.1- 1995 4. Software Requirements Review according to 730.1 5. Implementation of SQAP 6. Evaluation of SQAP 7. Modification of SQAP

6/30/2008

33

IEEE- Software Quality Assurance Plans

17