REG NASA-STD-8739 9-2013 SOFTWARE FORMAL INSPECTIONS STANDARD [Superseded NASA NASA-STD-2202 NASA NASA-STD-2202].pdf

《REG NASA-STD-8739 9-2013 SOFTWARE FORMAL INSPECTIONS STANDARD [Superseded NASA NASA-STD-2202 NASA NASA-STD-2202].pdf》由会员分享，可在线阅读，更多相关《REG NASA-STD-8739 9-2013 SOFTWARE FORMAL INSPECTIONS STANDARD [Superseded NASA NASA-STD-2202 NASA NASA-STD-2202].pdf（53页珍藏版）》请在麦多课文档分享上搜索。

1、 NASA TECHNICAL STANDARD NASA-STD-8739.9 National Aeronautics and Space Administration Approved: 06-17-2013 Washington, DC 20546-0001 Superseding NASA-STD-2202-93 SOFTWARE FORMAL INSPECTIONS STANDARD MEASUREMENT SYSTEM IDENTIFICATION: NOT MEASUREMENT SENSITIVE Provided by IHSNot for ResaleNo reprodu

2、ction or networking permitted without license from IHS-,-,-NASA-STD 8739.9 2 of 53 This page was intentionally left blank. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NASA-STD 8739.9 3 of 53 DOCUMENT HISTORY LOG Status Document Revision Approval

3、Date Description Baseline 04-xx-1993 Initial Release 03-29-2001 Revalidation Revision New document number. 06-17-2013 General Revision. Revisions made to address feedback received since the last revision, incorporate new research and best practices, and to align better with NPR 7150.2, NASA Software

4、 Engineering Requirements. Changes include: 1. Addressing projects concerns related to: Software Safety, COTS, and Software Acquisition, 2. Providing more guidance for tailoring inspections for different types of artifacts (e.g. project plans, auto-generated code), 3. Rewording best practices as rec

5、ommendations rather than requirements, and 4. Removing requirements addressed in other standards. (MW) Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-N

6、ASA-STD 8739.9 5 of 53 TABLE OF CONTENTS SECTION PAGE DOCUMENT HISTORY LOG . 3 FOREWORD . 4 TABLE OF CONTENTS . 5 LIST OF FIGURES 6 LIST OF TABLES 6 1. SCOPE . 7 1.1 PURPOSE 7 1.2 APPLICABILITY 7 1.3 REQUIREMENT RELIEF . 8 2. APPLICABLE DOCUMENTS . 8 2.1 GENERAL . 8 2.2 GOVERNMENT DOCUMENTS . 8 2.3

7、NON-GOVERNMENT DOCUMENTS 8 3. ACRONYMS AND DEFINITIONS . 8 3.1 ACRONYMS AND ABBREVIATIONS . 8 3.2 DEFINITIONS 9 4. SOFTWARE FORMAL INSPECTION PROCESS . 14 4.1 FORMAL INSPECTION DESCRIPTION . 15 4.2 CHARACTERISTICS . 15 4.3 COMPARISON TO OTHER REVIEW PRACTICES 15 4.4 PROCESS CONFORMANCE AND TAILORING

8、. 16 5. ROLES AND RESPONSIBILITIES 17 5.1 QUALIFICATIONS AND GENERAL RESPONSIBILITIES . 17 5.2 THE FORMAL INSPECTION TEAM 17 5.3 CANDIDATES FOR FORMAL INSPECTORS 21 6. PROCESS ELEMENTS . 22 6.1 INPUT AND OUTPUT . 22 6.2 ENTRY AND EXIT CRITERIA . 23 6.3 PROCESS STAGES . 23 6.4 FORMAL INSPECTION PROCE

9、DURE CUSTOMIZATION . 30 7. TYPES OF INSPECTIONS . 31 7.1 SOFTWARE PLAN INSPECTIONS 31 7.2 SYSTEM REQUIREMENTS INSPECTIONS (R0) 32 7.3 SOFTWARE REQUIREMENTS INSPECTIONS (R1) 33 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NASA-STD 8739.9 6 of 53 7.

10、4 ARCHITECTURAL DESIGN INSPECTION (I0) 35 7.5 DETAILED DESIGN INSPECTION (I1) . 36 7.6 SOURCE CODE INSPECTIONS (I2) . 37 7.7 TEST PLAN INSPECTION (IT1) 38 7.8 TEST PROCEDURE INSPECTION (IT2) 39 7.9 CONSIDERATIONS ON INSPECTIONS OF SOFTWARE THAT RUNS ON PROGRAMMABLE LOGIC DEVICES OPERATING SYSTEMS 40

11、 7.10 CONSIDERATIONS FOR ACQUISITION PROJECTS . 41 7.11 OTHER QUALITY CONSIDERATIONS 42 8. PROCESS EVALUATION 42 8.1 PRODUCT AND PROCESS MEASURES 43 8.2 EVALUATION ANALYSES . 44 8.3 PROCESS IMPROVEMENT 45 APPENDIX A: REFERENCES . 46 A.1 PURPOSE . 46 A.2 REFERENCE DOCUMENTS 46 A.3 FURTHER GUIDANCE .

12、47 APPENDIX B: INSPECTION TYPE AND PARTICIPANTS MATRIX . 48 APPENDIX C: FORMAL INSPECTION COMPLIANCE MATRIX . 50 LIST OF FIGURES FIGURE PAGE Figure 1: Inspection Process 24 LIST OF TABLES TABLE PAGE Table 1: Data Collected at Inspection Points . 43 Provided by IHSNot for ResaleNo reproduction or net

13、working permitted without license from IHS-,-,-NASA-STD 8739.9 7 of 53 SOFTWARE FORMAL INSPECTIONS STANDARD 1. SCOPE 1.1 Purpose The purpose of this Standard is to define the requirements for a software inspection process aimed at detecting and eliminating defects as early as possible in the softwar

14、e life cycle. This process can be used for any documented product, however, this Standard focuses on its use for software productsi.e., software code, plans, manuals, etc. The process provides for the collection and analysis of inspection data to improve the inspection process as well as the quality

15、 of the software. This Standard provides a core set of requirements that are applicable whenever formal inspections are required. NASA-GB-A302, Software Formal Inspections Guidebook, provides additional information on approaches for implementing a software formal inspection process. The implementati

16、on and approach to meeting these requirements will vary to reflect the system to which they are applied. 1.2 Applicability This standard will be used to insure NASA maintains the rigor and benefits of software formal inspections, when Software Formal Inspections are to be performed on software as sp

17、ecified by agreement or project direction,. This Standard is applicable to formal inspections of software products during the development life cycle of software developed, maintained, or acquired by or for NASA, including the incorporation of open source, auto-generated code and test procedures, Com

18、mercial Off-The-Shelf (COTS), Government Off-The-Shelf (GOTS), or Modified Off-The-Shelf (MOTS) into NASA systems. Legacy and reuse software products are also covered with a focus on how they fit into the systems under current development. Projects need to choose which software products they will pe

19、rform software formal inspection on, which will receive other kinds of peer reviews, and which will receive no peer review. These decisions should be documented in the program/project/facility software development or management plan. This Standard is approved for use by NASA Headquarters and NASA Ce

20、nters, including Component Facilities and Technical and Service Support Centers, and may be cited in contract, program, and other Agency documents as a technical requirement. This Standard may also apply to the Jet Propulsion Laboratory or to other contractors, grant recipients, or parties to agreem

21、ents only to the extent specified or referenced in their contracts, grants, or agreements. Requirementsi.e., mandatory actionsare denoted by statements containing the term “shall,“ are identified by “(Requirement),” and are numbered SFI-#. The terms: “may“ or “can“ denote discretionary privilege or

22、permission, “should“ denotes a good practice and is recommended, but not required, “will“ denotes expected outcome, and “are/is“ denotes descriptive material. The project manager is usually called out as the responsible party for ensuring formal inspections are performed on their projects, and for t

23、he quality of the formal inspections. Project managers are not expected to personally perform nor run the actual Software Formal Inspections. It is recognized that these requirements and activities may either be delegated by the project Provided by IHSNot for ResaleNo reproduction or networking perm

24、itted without license from IHS-,-,-NASA-STD 8739.9 8 of 53 manager to a software lead, Software Formal Inspection chief moderator, software assurance lead within the project; or it could be the responsibility of a division or Center Software Engineering Process Group, Software Assurance, or other re

25、sponsible party assigned this role. The project manager is used within this standard as the one responsible for using Software Formal Inspections (SFIs) on a project and thus is responsible for supporting the principles of SFIs for their projects and the monitoring and improvement of SFI to achieve

26、reduced software risks. 1.3 Requirement Relief Once invoked, relief from requirements in this Standard for application to a specific program or project shall be formally documented as part of program or project requirements and approved by the Technical Authority SFI- 001. This will be in accordance

27、 with procedures in NPR 8715.3, paragraph 1.13 and NASA-STD 8709.20, Management of Safety and Mission Assurance Technical Authority. 2. APPLICABLE DOCUMENTS 2.1 General The documents listed in this section contain provisions that constitute requirements of this Standard as cited in the text. The lat

28、est issuances of cited documents apply unless specific versions are designated. The applicable documents are accessible via the NASA Standards and Technical Assistance Resource Tool at http:/standards.nasa.gov or may be obtained directly from the Standards Developing Organizations or other document

29、distributors. NASA Directives are available at: http:/nodis3.gsfc.nasa.gov/ 2.2 Government Documents National Aeronautics and Space Administration NPR 7150.2 NASA Software Engineering Requirements NPR 8715.3 NASA General Safety Program Requirements NASA-STD 8709.20 Management of Safety and Mission A

30、ssurance Technical Authority NASA-STD 8719.13 NASA Software Safety Standard 2.3 Non-Government Documents None. 3. ACRONYMS AND DEFINITIONS 3.1 Acronyms and Abbreviations ASIC Application-Specific Integrated Circuit CMMI Capability Maturity Model Integration COTS Commercial Off-The-Shelf DR Discrepan

31、cy Report Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NASA-STD 8739.9 9 of 53 FPGA Field Programmable Gate Array FMEA Failure Mode and Effects Analysis FTA Failure Tree Analysis HDL Hardware Description Language IEEE Institute of Electrical and E

32、lectronics Engineers IV for example, input to, or output from, an assembler, compiler, linkage editor, or an executive routine. (see IEEE Std 610.12-1990) Off-the-shelf software (OTS): Software not developed in-house or by a contractor for the specific project now underway. The software is general p

33、urpose or developed for a different purpose from the current project. (see NASA-STD 8709.22) Includes COTS, GOTS, and MOTS software. OTS software may also be legacy, heritage, and re-use software. Peer Review: 1 A review of a software work product, following defined procedures, by peers of the produ

34、cers of the product for the purpose of identifying defects and improvements. 2 Independent evaluation by internal or external subject matter experts who do not have a vested interest in the work product under review. Peer reviews can be planned, focused reviews conducted on selected work products by

35、 the producers peers to identify defects and issues prior to that work product moving into a milestone review or approval cycle. (see NASA-STD 8709.22) Performance: A measure of how well a system or item functions in the expected environments. (see NASA-STD 8709.22) Provided by IHSNot for ResaleNo r

36、eproduction or networking permitted without license from IHS-,-,-NASA-STD 8739.9 12 of 53 Phase: The period of time during the life cycle of a project in which a related set of software engineering activities is performed. Phases may overlap. Provider: The entities or individuals that design, develo

37、p, implement, test, operate, and maintain the software products. A provider may be a contractor, a university, a separate organization within NASA, or within the same organization as the acquirer. (see NASA-STD 8709.22) Reader: An inspection participant who describes the product being inspected to t

38、he other inspectors during the inspection meeting. (see Wiegers 2008) Recorder: An inspection participant who documents the defects and issues brought up during the inspection meeting. (see Wiegers 2008) Release ID: Identification code associated with a products version level. Reliability: The proba

39、bility that a system of hardware, software, and human elements will function as intended over a specified period of time under specified environmental conditions. (see NASA-STD 8709.22) Requirement: A precise statement of need intended to convey understanding about a condition or capability that mus

40、t be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system components. Severity: A degree or category of magnitude for the ult

41、imate impact or effect of executing a given software fault, regardless of probability. Software: Computer programs, procedures, scripts, rules, and associated documentation and data pertaining to the development and operation of a NASA component or computer system. Software includes programs and dat

42、a. This also includes COTS, GOTS, MOTS, reused software, auto generated code, embedded software, firmware, the software which runs on programmable logic devices (PLDs) operating systems, and open source software components. (see NASA-STD 8709.22) Software Assurance: The planned and systematic set of

43、 activities that ensure that software life-cycle process and products conform to requirements, standards, and procedures. For NASA this includes the disciplines of software quality (functions of software quality engineering, software quality assurance, and software quality control), software safety,

44、 software reliability, software verification and validation, and Independent Verification otherwise a waiver/deviation may be required. Test Plan: A document prescribing the approach to be taken for intended testing activities. The plan typically identifies the items to be tested, the testing to be

45、performed, test schedules, personnel requirements, reporting requirements, evaluation criteria, the level of acceptable risk, and any risk requiring contingency planning. Test Procedure: The detailed instructions for the setup, operation, and evaluation of results for a given test. A set of associat

46、ed procedures is often combined to form a test procedure document. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NASA-STD 8739.9 14 of 53 Traceability: 1 The degree to which a relationship can be established between two or more products of the deve

47、lopment process, especially products having a predecessor successor or master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software component match. (see IEEE Std 610.12-1990) 2 The characteristic of a system that allows identificat

48、ion and control of relationships between requirements, software components, data, and documentation at different levels in the system hierarchy. Validation: Confirmation that the product, as provided (or as it will be provided), fulfills its intended use. In other words, validation ensures that “you built the right thing.“ (see SEI-CMMI) Verification: Confirmation that work products properly reflect the requirements specified for them. In other words, verification ensures that “you built it right.“ (see SEI-CMMI) Walkthrough: A static analysis technique in which a designer or pr