Professional Documents
Culture Documents
Ieee STD 730 Sqa Plans
Ieee STD 730 Sqa Plans
Ieee STD 730 Sqa Plans
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
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
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
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
6/30/2008
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.
6/30/2008
Documentation standards Design standards Coding standards Commentary standards Testing standards and practices Selected software quality assurance product and process metrics
10
2008-06-30
Software Development
Software Reqts Analysis Arch. Design Detailed Design
Reviews
System Integration
SRR SDR
Functional Baseline
SSR ADR
Allocated Baseline
DDR TRR
11
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
2008-06-30
Software Requirements Review (SRR)* Architecture Design Review (ADR) Detailed Design Review (DDR) Verification and Validation Plan Review (SVVP)
13
2008-06-30
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
2008-06-30
6/30/2008
17
6/30/2008
18
2008-06-30
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
10
2008-06-30
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
11
2008-06-30
6/30/2008
23
12
2008-06-30
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
6/30/2008
26
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.
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.
5.
6/30/2008
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.
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
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
6/30/2008
32
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
17