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 Introduction to the IEEE 730-2002 Standard Content of the Software Quality Assurance Plan (SQAP) Guide to the Standard IEEE 730.1- 1995 (withdrawn) Software Requirements Review according to 730.1 Implementation of SQAP Evaluation of SQAP Modification of SQAP 11/20/2018

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

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. 11/20/2018

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

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

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

Content of SQAP - Section 3: Management Description of organization, tasks, roles and responsibilities see IEEE Std 1058 -1998 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

Content of SQAP -Section 4: Documentation 2018-11-20 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

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

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

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

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

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

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

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

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

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

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

Content of SQAP Section 13: Training 2018-11-20 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

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 730- 1998. 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

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 11/20/2018

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

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

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

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

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

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

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

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

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

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

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