JSC SOFTWARE ENGINEERING PROCEDURAL REQUIREMENTS · 2018-05-21 · Johnson Space EffectiveCenter...

Verify correct version before use at http://server-mpo.arc.nasa.gov/Services/CDMSDocs/Centers/JSC/Home.tml.

JSC Form JF2420B (Revised April 3, 2012) (MS Word August 28, 2006)

JPR No.: 7150.2A Johnson Space Center Effective Date: 01/23/2017 Procedural Requirements

Expiration Date: 01/23/2022

Verify that this is the correct version before use

Compliance is Mandatory

JSC SOFTWARE ENGINEERING

PROCEDURAL REQUIREMENTS

Responsible Office: Engineering Directorate

http://server-mpo.arc.nasa.gov/Services/CDMSDocs/Centers/JSC/Home.tml



JSC Software Engineering Requirements

JPR No. 7150.2A

Effective Date: 01/23/2017


Page Number 2 of 205

TABLE OF CONTENTS

PREFACE .................................................................................................................................................................................. 9

P.1 PURPOSE ...................................................................................................................................................................... 10 P.2 APPLICABILITY .............................................................................................................................................................. 11 P.3 AUTHORITY ................................................................................................................................................................... 12 P.4 APPLICABLE DOCUMENTS ............................................................................................................................................ 12 P.5 MEASUREMENT/VERIFICATION ................................................................................................................................... 13 P.6 CANCELLATION/RESCISSION ........................................................................................................................................ 13

CHAPTER 1: INTRODUCTION .................................................................................................................................................. 14

1.1. ROLES AND RESPONSIBILITIES............................................................................................................................................... 15 a. NASA Chief Engineer ..................................................................................................................................................... 15 b. NASA Chief, Safety and Mission Assurance (S&MA) ..................................................................................................... 15 c. JSC Center Director ....................................................................................................................................................... 15 d. JSC Safety and Mission Assurance (S&MA) .................................................................................................................. 15 e. Program and Project Managers ................................................................................................................................... 15

1.2. TECHNICAL AUTHORITY, TAILORING, WAIVERS, AND DEVIATIONS ............................................................................................... 17 1.3. OFF THE SHELF SOFTWARE .................................................................................................................................................. 18

CHAPTER 2: SOFTWARE MANAGEMENT REQUIREMENTS ...................................................................................................... 20

2.1 COMPLIANCE WITH LAWS, POLICIES, AND REQUIREMENTS ........................................................................................................ 20 2.1.1 Compliance Matrix ................................................................................................................................................... 21 2.1.2 Document Tailoring .................................................................................................................................................. 22

2.2 SOFTWARE LIFE-CYCLE PLANNING ........................................................................................................................................ 23 2.2.1 Software Plans ......................................................................................................................................................... 24 2.2.2 Tracking Results and Performance against Plans .................................................................................................... 25

2.3 SOFTWARE COST ESTIMATION ............................................................................................................................................. 26 2.3.1 Cost Estimate Methodology ..................................................................................................................................... 26 2.3.2 Cost Estimation ........................................................................................................................................................ 27

2.4 SOFTWARE SCHEDULES ....................................................................................................................................................... 28 2.4.1 Software Schedule .................................................................................................................................................... 28 2.4.2 Reviews and Issue Resolution ................................................................................................................................... 29 2.4.3 Software Life Cycle ................................................................................................................................................... 30

2.5 SOFTWARE PROJECT SPECIFIC TRAINING ................................................................................................................................ 31 2.5.1 Training .................................................................................................................................................................... 31

2.6 SOFTWARE CLASSIFICATION AND PLANNING ASSESSMENTS ........................................................................................................ 32 2.6.1 Software Classification ............................................................................................................................................. 32 2.6.2 Independent Software Classification ........................................................................................................................ 33 2.6.3 Software Safety Criticality ........................................................................................................................................ 34 2.6.4 Software Classification Evolution ............................................................................................................................. 35 2.6.5 Safety Critical Classification ..................................................................................................................................... 36

2.7 SOFTWARE ASSURANCE AND SOFTWARE IV&V ....................................................................................................................... 37 2.7.1 Software Assurance ................................................................................................................................................. 37 2.7.2 Software IV&V .......................................................................................................................................................... 38 2.7.3 Software IV&V Plan .................................................................................................................................................. 39

2.8 SAFETY-CRITICAL SOFTWARE ............................................................................................................................................... 40 2.8.1 Safety Standard .......................................................................................................................................................... 40 2.8.2 Computing System Safety Requirements ................................................................................................................. 41

2.9 AUTOMATIC GENERATION OF SOFTWARE SOURCE CODE ........................................................................................................... 44





JPR No. 7150.2A




2.9.1 Automatic Code Generation ..................................................................................................................................... 44 2.10 USE OF COMMERCIAL, GOVERNMENT, LEGACY, HERITAGE, AND MODIFIED OFF-THE-SHELF SOFTWARE ............................................ 45

2.10.1 COTS, GOTS, MOTS, Reused, or FOSS Software ........................................................................................................ 46 2.11 SOFTWARE VERIFICATION AND VALIDATION ............................................................................................................................ 48

2.11.1 Software Verification Plan ................................................................................................................................... 49 2.11.2 Software Validation Plan...................................................................................................................................... 50 2.11.3 Results of Verification ............................................................................................................................................... 51 2.11.4 Results of Validation ............................................................................................................................................ 52

2.12 SOFTWARE DEVELOPMENT PROCESSES .................................................................................................................................. 53 2.12.1 CMMI ................................................................................................................................................................... 54

2.13 SOFTWARE ACQUISITION .................................................................................................................................................... 56 2.13.1 Acquisition and Development .............................................................................................................................. 57 2.13.2 Acceptance Criteria .............................................................................................................................................. 58 2.13.3 Supplier Selection Procedure ............................................................................................................................... 59 2.13.4 Determining Processes, Activities, and Tasks ...................................................................................................... 60 2.13.5 Milestones ........................................................................................................................................................... 61 2.13.6 Documenting Acquisition Planning Decisions ...................................................................................................... 62

2.14 SOFTWARE CONTRACT REQUIREMENTS ................................................................................................................................. 63 2.14.1 Insight into Supplier Activities .............................................................................................................................. 64 2.14.2 Supplier Providing Information to NASA .............................................................................................................. 65 2.14.3 Access to Source Code ......................................................................................................................................... 66

2.15 SOFTWARE MONITORING ................................................................................................................................................... 67 2.15.1 Tracking Software Changes and Nonconformances ............................................................................................ 67 2.15.2 Joint NASA/Supplier Audits .................................................................................................................................. 68 2.15.3 Supplying the Software Schedule......................................................................................................................... 69 2.15.4 Supplying Traceability Data .............................................................................................................................. 70

2.16 SOFTWARE REUSE ............................................................................................................................................................. 71 2.16.1 Reusability Requirements .................................................................................................................................... 72 2.16.2 Reusability Contribution ...................................................................................................................................... 73

2.17 FREE AND OPEN SOURCE .................................................................................................................................................... 74 2.17.1 Free and Open Source .......................................................................................................................................... 75 2.17.2 Free and Open Source Notification ...................................................................................................................... 77

2.18 COMPUTING SYSTEM SAFETY AND SECURITY ........................................................................................................................... 78 2.18.1 Software Security Risks ........................................................................................................................................ 78 2.18.2 Software Security Risk Mitigations ...................................................................................................................... 79 2.18.3 Software Security Risk Evaluation ....................................................................................................................... 80 2.18.4 Software Security: Unauthorized Access ............................................................................................................. 81 2.18.5 Software Security: Vulnerability Assessment ....................................................................................................... 82 2.18.6 Software Security Verification and Validation ..................................................................................................... 83

CHAPTER 3: SOFTWARE ENGINEERING (LIFE-CYCLE) REQUIREMENTS .................................................................................... 84

3.1 SOFTWARE REQUIREMENTS ................................................................................................................................................. 84 3.1.1 Software Requirements Specification ...................................................................................................................... 85 3.1.2 Requirements Flow-Down ........................................................................................................................................ 86 3.1.3 Requirements Management ..................................................................................................................................... 87 3.1.4 Managing Inconsistencies ........................................................................................................................................ 88 3.1.5 Expectation Validation ............................................................................................................................................. 89

3.2 SOFTWARE ARCHITECTURE .................................................................................................................................................. 90 3.2.1 Software Architectural Design .................................................................................................................................. 91 3.2.2 Software Architectural Review ................................................................................................................................. 92

3.3 SOFTWARE DESIGN ............................................................................................................................................................ 93





JPR No. 7150.2A




3.3.1 Software Design ....................................................................................................................................................... 94 3.3.2 Detailed Design ........................................................................................................................................................ 95

3.4 SOFTWARE IMPLEMENTATION .............................................................................................................................................. 96 3.4.1 Design into Code ...................................................................................................................................................... 97 3.4.2 Coding Standards ..................................................................................................................................................... 98 3.4.3 Static Analysis Tools ................................................................................................................................................. 99 3.4.4 Unit Testing ............................................................................................................................................................ 100 3.4.5 Version Description Document ............................................................................................................................... 101 3.4.6 Validating and Accrediting Software Tools ............................................................................................................ 102

3.5 SOFTWARE TESTING ......................................................................................................................................................... 103 3.5.1 Software Plans, Procedures, and Reports .............................................................................................................. 104 3.5.2 Software Test Plan ................................................................................................................................................. 105 3.5.3 Verifying Requirements .......................................................................................................................................... 106 3.5.4 Documenting Test Results ...................................................................................................................................... 107 3.5.5 Documenting Defects ............................................................................................................................................. 108 3.5.6 Models, Simulations, and Analysis Tools ................................................................................................................ 109 3.5.7 Updating Test Plans and Procedures ..................................................................................................................... 110 3.5.8 Targeted Platform or High-Fidelity Simulation ....................................................................................................... 111

3.6 SOFTWARE OPERATIONS, MAINTENANCE, AND RETIREMENT ................................................................................................... 112 3.6.1 Planning for Operations, Maintenance, and Retirement ....................................................................................... 113

3.7 BIDIRECTIONAL TRACEABILITY ............................................................................................................................................ 115 3.7.1 Traceability between Software Requirement and Higher-Level Requirement ....................................................... 116 3.7.2 Traceability Between Software Requirements and Software Design ..................................................................... 117 3.7.3 Traceability Between Software Design and Software Code ................................................................................... 118 3.7.4 Traceability between Software Test Procedures and Software Requirements ...................................................... 119

CHAPTER 4: SUPPORTING SOFTWARE LIFE-CYCLE REQUIREMENTS ...................................................................................... 121

4.1 SOFTWARE CONFIGURATION MANAGEMENT ........................................................................................................................ 121 4.1.1 Software Configuration Management Plan ........................................................................................................... 122 4.1.2 Tracking and Evaluating Changes .......................................................................................................................... 123 4.1.3 Identifying Configuration Items .............................................................................................................................. 124 4.1.4 Authorizing Changes .............................................................................................................................................. 125 4.1.5 Maintaining Records .............................................................................................................................................. 126 4.1.6 Configuration Audits .............................................................................................................................................. 127 4.1.7 Implementing Procedures ...................................................................................................................................... 128

4.2 RISK MANAGEMENT......................................................................................................................................................... 129 4.2.1 Continuous Risk Management ............................................................................................................................... 130

4.3 SOFTWARE PEER REVIEWS/INSPECTIONS ............................................................................................................................. 131 4.3.1 Peer Reviews/Inspections of Software Requirements, Test Plan, and Code .......................................................... 132 4.3.3 Checklists, Criteria, Tracking, and Participants ...................................................................................................... 133 4.3.4 Basic Measurements .............................................................................................................................................. 134

4.4 SOFTWARE MEASUREMENT ............................................................................................................................................... 135 4.4.1 Measurements ....................................................................................................................................................... 136 4.4.2 Analyzing Data ....................................................................................................................................................... 137 4.4.3 Reporting Results ................................................................................................................................................... 138

CHAPTER 5: SOFTWARE DOCUMENTATION REQUIREMENTS ......................................................................................... 139

CHAPTER 6 RECORDS .................................................................................................................................................... 141

APPENDIX A. TERMS AND DEFINITIONS ........................................................................................................................... 142

APPENDIX B. ACRONYMS ................................................................................................................................................ 159





JPR No. 7150.2A




APPENDIX C. SOFTWARE CLASSIFICATIONS ..................................................................................................................... 162

APPENDIX D. HOW TO READ THESE PROCESS REQUIREMENTS ........................................................................................ 175

APPENDIX E. REQUIREMENTS MAPPING MATRIX ............................................................................................................ 177

APPENDIX F. HOW TO CREATE A COMPLIANCE MATRIX .................................................................................................. 195

APPENDIX G. DEVIATION/WAIVER PROCESS .................................................................................................................... 197

APPENDIX H. DEVIATION/WAIVER TECHNICAL AUTHORITY TABLE ................................................................................. 200

APPENDIX I. DEVIATIONS FROM NPR 7150.2....................................................................................................................... 201

APPENDIX J. PRE-APPROVED TAILORING FOR HEALTH AND HUMAN PERFORMANCE DIRECTORATE SPACE FLIGHT RESEARCH PROJECTS ............................................................................................................................................................................ 205





JPR No. 7150.2A




List of Tables TABLE 1-1 NUMBER OF JSWES PER SOFTWARE CLASS .............................................................................................................. 14 TABLE 2-1 CLASS APPLICABILITY FOR JSWE-125 ........................................................................................................................ 21 TABLE 2-2 CLASS APPLICABILITY FOR JSWE-121 ........................................................................................................................ 22 TABLE 2-3 CLASS APPLICABILITY FOR JSWE-013 ........................................................................................................................ 24 TABLE 2-4 CLASS APPLICABILITY FOR JSWE-024 ........................................................................................................................ 25 TABLE 2-5 CLASS APPLICABILITY FOR JSWE-151 ........................................................................................................................ 26 TABLE 2-6 CLASS APPLICABILITY FOR JSWE-015 ........................................................................................................................ 27 TABLE 2-7 CLASS APPLICABILITY FOR JSWE-016 ........................................................................................................................ 28 TABLE 2-8 CLASS APPLICABILITY FOR JSWE-018 ........................................................................................................................ 29 TABLE 2-9 CLASS APPLICABILITY FOR JSWE-019 ........................................................................................................................ 30 TABLE 2-10 CLASS APPLICABILITY FOR JSWE-017 ................................................................................................................... 31 TABLE 2-11 CLASS APPLICABILITY FOR JSWE-020 ................................................................................................................... 32 TABLE 2-12 CLASS APPLICABILITY FOR JSWE-132 ................................................................................................................... 33 TABLE 2-13 CLASS APPLICABILITY FOR JSWE-133 ................................................................................................................... 34 TABLE 2-14 CLASS APPLICABILITY FOR JSWE-021 ................................................................................................................... 35 TABLE 2-15 CLASS APPLICABILITY FOR JSWE-160 ................................................................................................................... 36 TABLE 2-16 CLASS APPLICABILITY FOR JSWE-022 ................................................................................................................... 37 TABLE 2-17 CLASS APPLICABILITY FOR JSWE-141 ................................................................................................................... 38 TABLE 2-18 CLASS APPLICABILITY FOR JSWE-131 ................................................................................................................... 39 TABLE 2-19 CLASS APPLICABILITY FOR JSWE-023 ................................................................................................................... 40 TABLE 2-20 CLASS APPLICABILITY FOR JSWE-134 ................................................................................................................... 42 TABLE 2-21 CLASS APPLICABILITY FOR JSWE-146 ................................................................................................................... 44 TABLE 2-22 CLASS APPLICABILITY FOR JSWE-027 ................................................................................................................... 47 TABLE 2-23 CLASS APPLICABILITY FOR JSWE-028 ................................................................................................................... 49 TABLE 2-24 CLASS APPLICABILITY FOR JSWE-029 ................................................................................................................... 50 TABLE 2-25 CLASS APPLICABILITY FOR JSWE-030 ................................................................................................................... 51 TABLE 2-26 CLASS APPLICABILITY FOR JSWE-031 ................................................................................................................... 52 TABLE 2-27 CLASS APPLICABILITY FOR JSWE-032 ................................................................................................................... 54 TABLE 2-28 CLASS APPLICABILITY FOR JSWE-033 ................................................................................................................... 57 TABLE 2-29 CLASS APPLICABILITY FOR JSWE-034 ................................................................................................................... 58 TABLE 2-30 CLASS APPLICABILITY FOR JSWE-035 ................................................................................................................... 59 TABLE 2-31 CLASS APPLICABILITY FOR JSWE-036 ................................................................................................................... 60 TABLE 2-32 CLASS APPLICABILITY FOR JSWE-037 ................................................................................................................... 61 TABLE 2-33 CLASS APPLICABILITY FOR JSWE-038 ................................................................................................................... 62 TABLE 2-34 CLASS APPLICABILITY FOR JSWE-039 ................................................................................................................... 64 TABLE 2-35 CLASS APPLICABILITY FOR JSWE-040 ................................................................................................................... 65 TABLE 2-36 CLASS APPLICABILITY FOR JSWE-042 ................................................................................................................... 66 TABLE 2-37 CLASS APPLICABILITY FOR JSWE-043 ................................................................................................................... 67 TABLE 2-38 CLASS APPLICABILITY FOR JSWE-045 ................................................................................................................... 68 TABLE 2-39 CLASS APPLICABILITY FOR JSWE-046 ................................................................................................................... 69 TABLE 2-40 CLASS APPLICABILITY FOR JSWE-047 ................................................................................................................... 70 TABLE 2-41 CLASS APPLICABILITY FOR JSWE-147 ................................................................................................................... 72 TABLE 2-42 CLASS APPLICABILITY FOR JSWE-148 ................................................................................................................... 73 TABLE 2-43 CLASS APPLICABILITY FOR JSWE-149 ................................................................................................................... 75 TABLE 2-44 CLASS APPLICABILITY FOR JSWE-041 ................................................................................................................... 77 TABLE 2-45 CLASS APPLICABILITY FOR JSWE-154 ................................................................................................................... 78 TABLE 2-46 CLASS APPLICABILITY FOR JSWE-155 ................................................................................................................... 79 TABLE 2-47 CLASS APPLICABILITY FOR JSWE-156 ................................................................................................................... 80 TABLE 2-48 CLASS APPLICABILITY FOR JSWE-157 ................................................................................................................... 81





JPR No. 7150.2A




TABLE 2-49 CLASS APPLICABILITY FOR JSWE-158 ................................................................................................................... 82 TABLE 2-50 CLASS APPLICABILITY FOR JSWE-159 ................................................................................................................... 83 TABLE 3-1 CLASS APPLICABILITY FOR JSWE-050 ........................................................................................................................ 85 TABLE 3-2 CLASS APPLICABILITY FOR JSWE-051 ........................................................................................................................ 86 TABLE 3-3 CLASS APPLICABILITY FOR JSWE-053 ........................................................................................................................ 87 TABLE 3-4 CLASS APPLICABILITY FOR JSWE-054 ........................................................................................................................ 88 TABLE 3-5 CLASS APPLICABILITY FOR JSWE-055 ........................................................................................................................ 89 TABLE 3-6 CLASS APPLICABILITY FOR JSWE-057 ........................................................................................................................ 91 TABLE 3-7 CLASS APPLICABILITY FOR JSWE-143 ........................................................................................................................ 92 TABLE 3-8 CLASS APPLICABILITY FOR JSWE-056 ........................................................................................................................ 94 TABLE 3-9 CLASS APPLICABILITY FOR JSWE-058 ........................................................................................................................ 95 TABLE 3-10 CLASS APPLICABILITY FOR JSWE-060 ................................................................................................................... 97 TABLE 3-11 CLASS APPLICABILITY FOR JSWE-061 ................................................................................................................... 98 TABLE 3-12 CLASS APPLICABILITY FOR JSWE-135 ................................................................................................................... 99 TABLE 3-13 CLASS APPLICABILITY FOR JSWE-062 ................................................................................................................. 100 TABLE 3-14 CLASS APPLICABILITY FOR JSWE-063 ................................................................................................................. 101 TABLE 3-15 CLASS APPLICABILITY FOR JSWE-136 ................................................................................................................. 102 TABLE 3-16 CLASS APPLICABILITY FOR JSWE-065 ................................................................................................................. 104 TABLE 3-17 CLASS APPLICABILITY FOR JSWE-066 ................................................................................................................. 105 TABLE 3-18 CLASS APPLICABILITY FOR JSWE-067 ................................................................................................................. 106 TABLE 3-19 CLASS APPLICABILITY FOR JSWE-068 ................................................................................................................. 107 TABLE 3-20 CLASS APPLICABILITY FOR JSWE-069 ................................................................................................................. 108 TABLE 3-21 CLASS APPLICABILITY FOR JSWE-070 ................................................................................................................. 109 TABLE 3-22 CLASS APPLICABILITY FOR JSWE-071 ................................................................................................................. 110 TABLE 3-23 CLASS APPLICABILITY FOR JSWE-073 ................................................................................................................. 111 TABLE 3-24 CLASS APPLICABILITY FOR JSWE-075 ................................................................................................................. 113 TABLE 3-25 CLASS APPLICABILITY FOR JSWE-077 ................................................................................................................. 114 TABLE 3-26 CLASS APPLICABILITY FOR JSWE-052 ................................................................................................................. 116 TABLE 3-27 CLASS APPLICABILITY FOR JSWE-059 ................................................................................................................. 117 TABLE 3-28 CLASS APPLICABILITY FOR JSWE-064 ................................................................................................................. 118 TABLE 3-29 CLASS APPLICABILITY FOR JSWE-072 ................................................................................................................. 119 TABLE 3-30 SUMMARY OF JSWE-052, 059, 064, AND 072 .................................................................................................... 120 TABLE 4-1 CLASS APPLICABILITY FOR JSWE-079 ...................................................................................................................... 122 TABLE 4-2 CLASS APPLICABILITY FOR JSWE-080 ...................................................................................................................... 123 TABLE 4-3 CLASS APPLICABILITY FOR JSWE-081 ...................................................................................................................... 124 TABLE 4-4 CLASS APPLICABILITY FOR JSWE-082 ...................................................................................................................... 125 TABLE 4-5 CLASS APPLICABILITY FOR JSWE-083 ...................................................................................................................... 126 TABLE 4-6 CLASS APPLICABILITY FOR JSWE-084 ...................................................................................................................... 127 TABLE 4-7 CLASS APPLICABILITY FOR JSWE-085 ...................................................................................................................... 128 TABLE 4-8 CLASS APPLICABILITY FOR JSWE-086 ...................................................................................................................... 130 TABLE 4-9 CLASS APPLICABILITY FOR JSWE-087 ...................................................................................................................... 132 TABLE 4-11 CLASS APPLICABILITY FOR JSWE-088 ................................................................................................................. 133 TABLE 4-12 CLASS APPLICABILITY FOR JSWE-089 ................................................................................................................. 134 TABLE 4-13 CLASS APPLICABILITY FOR JSWE-090 ................................................................................................................. 136 TABLE 4-14 CLASS APPLICABILITY FOR JSWE-093 ................................................................................................................. 137 TABLE 4-15 CLASS APPLICABILITY FOR JSWE-094 ................................................................................................................. 138 TABLE 5-1 CLASS APPLICABILITY FOR JSWE-153 ...................................................................................................................... 139





JPR No. 7150.2A




Change History Log

Revision Date Originator Description of Changes

Basic April 2012 Liz Strassner Initial Release

PCN001 August 2015 Pedro Martinez Added to Para 2.b: a Federally Funded Research and Development Center (FFRDC)

Appendix B Acronym list: FFRDC

Revision A Jan 2016 Pedro Martinez Incorporated updates from NPR 7150.2B





JPR No. 7150.2A




PREFACE

JSC Procedural Requirement (JPR) 7150.2A, JSC Software Engineering Procedural Requirements, supports the implementation of the JSC Policy Directive (JPD) 7150.1A, JSC Software Engineering Policy. Software engineering is a core capability and a key enabling technology for NASA’s missions and supporting infrastructure. The term “software” has many conflicting connotations. As it is used throughout this document, the following definition applies:

Software Computer programs, procedures, scripts, rules, and associated

operational data that provide instructions to and execute on a computing processing element.

The associated documentation and data pertaining to the development and operation of a computer system is also included as part of the software.

This includes COTS, GOTS, MOTS, reused software, embedded software, firmware, and open-source software components.

Note 1: For related software terms used in this JPR, see APPENDIX A Terms and Definitions.

Note 2: The parent document of this JPR, NPR 7150.2, NASA Software Engineering Requirements, identifies a traceable set of Software Engineering (SWE) requirements for the Agency as follows.

a. The requirement in a “shall” statement is followed by a successively numbered requirement identifier.

b. The requirements identifier is formatted as: [SWE-NNN].

c. Specific SWE requirements in NPR 7150.2 prescribed for flow-down and Center-level implementation are identified using the [SWE-NNN] convention in this JPR.

d. Requirements that have been flowed down for Center-level implementation and tracing are formatted in a similar manner. For identification of JSC-specific requirements in this JPR, a “J” is placed before the “SWE” abbreviation. Brackets used to set these items off as in: [JSWE-NNN]

e. If tailoring is appropriate for applying that requirement to a certain set of SW class/criticality items, the tailored statement appears in the applicability table accompanying

each JSWE. Interpret the table headings "When" and "Then” as:

When the project is working software that is this class and criticality,

Then the project shall implement or tailor this JSWE requirement as follows.

f. See APPENDIX D How to Read These Process Requirements for a detailed explanation of JSWE tailoring as used in this JPR.





JPR No. 7150.2A




P.1 PURPOSE

This JPR provides a minimal set of generic software engineering requirements for software acquisition, development, maintenance, retirement, operations, and management of commercial off-the-shelf (COTS) software, government off-the-shelf (GOTS) software, modified off-the-shelf (MOTS) software, reused software, embedded software, firmware, and Free and Open Source software (FOSS) components.

a. Tailoring: The software lead of each software project should impose the appropriate subset of these process requirements on the project and use the normal mechanisms for implementing project requirements and for performing verification and validation. The subset of process requirements to be imposed on each project varies according to the software classification (Class A through Class H) and according to the designation of the software as being safety critical or non-safety critical. Classes A through E describe engineering software and Classes F through H describe business (or information technology) software.

b. Rigor: For engineering software, the most process rigor is required for Class A and the least for Class E. For business software, the most process rigor is required for Class F and the least for Class H. The software classes do not take into account the size, complexity, or risk of the project as part of the classification assessment. The use of COTS software, GOTS software, MOTS software, reused software, and FOSS software can vary greatly and is typically implemented in a different manner from software that is developed “in-house”. In this document, Software Engineering (SWE) requirements from NPR 7150.2 are interpreted and addressed on a requirement-by-requirement basis (e.g., JSWE-013 is the JSC interpretation of NPR 7150.2’s SWE-013). SWEs which are either not implementable or may not make sense for all COTS software have been classified as “exempt” in this JPR. JSWE-027 contains the JSC-mandated approach for addressing these SWEs.

c. Traceability of Requirements: JPD 7150.1 and this JPR satisfy requirements SWE-005, SWE-140, and SWE-126 from NPR 7150.2, NASA Software Engineering Requirements, as illustrated below:





JPR No. 7150.2A




NPR

7150.2 B

SWE

Summary of SWE

Ad

dre

ssed

in

JP

D 7

15

0.1

Ad

dre

ssed

in

JP

R 7

15

0.2

Notes

005 SWE-005 requires that each center document its own software requirements.

√ √

140 SWE-140 specifically requires each center to comply with the requirements identified Appendix C of NPR 7150.2

√ √ This JPR does so, and it also provides rationale for each requirement.

126 SWE-126 requires that the Center level Technical Authority keep records of project compliance matrices, waivers, and deviations.

√ √ This JPR does so, and it also provides rationale for each requirement. The process for waivers and deviations is described in Appendix H

P.2 APPLICABILITY

a. This JPR is applicable to all JSC NASA organizations, Ellington Field, Sonny Carter Training Facility, and White Sands Test Facility, except for the following:

1) Office of Inspector General;

2) NASA Engineering and Safety Center (NESC) offices at JSC

b. This language applies to JPL, a Federally Funded Research and Development

Center (FFRDC), other contractors, grant recipients, or parties to agreements only to the extent specified or referenced in the appropriate contracts, grants, or agreements.

c. In this directive, all mandatory actions (i.e., requirements) are denoted by

statements containing the term "shall." The terms: "may" or "can" denote discretionary privilege or permission, "should" denotes a good practice and is recommended, but not required, "will" denotes expected outcome, and "are/is" denotes descriptive material.

d. In this directive, all document citations are assumed to be the latest version

unless otherwise noted.

e. Phased Implementation:

(1) This JPR is applicable to all software projects begun after September 27, 2004.





JPR No. 7150.2A




(2) The first exception to this JPR is for those legacy software projects begun before September 27, 2004, including any maintenance to products whose initial development started before September 27, 2004. To be specific, this JPR does not apply to a software development project producing Product X that began in June 2004 and was completed in June 2007, nor to a maintenance project for Product X that begins in June 2011.

(3) However, this JPR does apply to a software development project producing Product Y that began in December 2009 and was completed in December 2010. Though process changes naturally cannot be made to a closed project, any maintenance project for Product Y will adhere to this JPR.

(4) The second exception is for projects begun after September 27, 2004 but before November 19, 2009. Those projects may continue to use NPR 7150.2 (original) instead of this JPR.

(5) All other currently active projects need to comply with this JPR by January 1, 2013.

P.3 AUTHORITY

1 . NPR 7150.2, NASA Software Engineering Requirements, SWE-

003

2. JPD 7150.1, JSC Software Engineering Policy

P.4 APPLICABLE DOCUMENTS

1. NPD 7120.4, NASA Engineering and Program/Project Management Policy

2. NPD 2091.1, Inventions Made By Government Employees

3. NPR 2210.1 Release of NASA Software

4. NPR 7120.5, NASA Space Flight Program and Project Management Requirements

5. NPR 2190.1, NASA Export Control Program

6. NPR 2210.1, Release of NASA Software

7. NPR 2810.1, Security of Information Technology

8. NPR 2841.1, Identity, Credentials and Access Management

9. NPR 2800.2, Electronic and Information Technology Accessibility

10. NPR 9250.1, Property, Plant, and Equipment and Operating Materials and Supplies

11. NPR 8705.2, Human-Rating Requirements for Space Systems

12. NPR 8735.1, Procedures for Exchanging Parts, Materials, Software, and Safety





JPR No. 7150.2A




Problem Data Utilizing the Government-Industry Data Exchange Program (GIDEP) and

NASA Advisories

13. NPR 7120.8, NASA Research and Technology Program and Project Management

Requirements

14. NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program

and Project Management Requirements

15. NPR 7123.1, NASA Systems Engineering Processes and Requirements

16. JPR 1281.17, JSC Audits

17. NASA/SP-2007-6105, NASA Systems Engineering Handbook

18. NASA-STD-2202-93, Software Formal Inspections Standard

19. NASA-STD-8719.13, NASA Software Safety Standard

20. NASA-STD-8739.8, Software Assurance Standard

21. JSC-63722, Johnson Space Center (JSC) Engineering Technical Excellence and

Technical Authority Implementation Plan

P.5 MEASUREMENT/VERIFICATION

Audits, as prescribed in JPR 1281.17, JSC Audits, shall be used to verify conformance with requirements.

P.6 CANCELLATION/RESCISSION

Supersedes JPR 7150.2, dated May 14, 2012.

Original Signed By: Patrick S. Pilola for

Lauri N. Hansen Director, Engineering





JPR No. 7150.2A




CHAPTER 1: INTRODUCTION

This JPR imposes requirements on procedures, design considerations, activities, and tasks used to acquire, develop, assure, and maintain software created and acquired by or for projects at JSC. These requirements are dependent upon the class of the software project (A-H) and safety criticality. Refer to APPENDIX C Software Classifications, for definitions and examples for each class of software. Software class is based on the consequence of defects, not the probability; therefore, risk plays a minor role in determining the class of software. Each project will determine if adopting more than the minimal process requirements will mitigate the probability of risk outcomes. Table 1-1 below shows the impact of software class on the number of applicable software requirements:

TABLE 1-1 NUMBER OF JSWES PER SOFTWARE CLASS

Software Class

A B C D A B C D E F G H

Safety Critical Non-Safety Critical

95 95 93 89 93 93 88 52 18 87 69 10

Each process requirement is written in a consistent manner to identify the requirement, rationale, and applicability across software classes. Refer to APPENDIX D How to Read These Process Requirements, for an explanation of this format.

Refer to JPD 7150.1 for JSC responsibilities that are outside the scope of specific projects’ process requirements. This JPD also defines the responsibilities of projects to grant the JSC SEPG access to their process information.

This directive does not require a specific software life-cycle model; but where this JPR refers to phases and milestone reviews in the software life-cycle, it uses the standard NASA life-cycle models described in NPR 7120.5, NASA Space Flight Program and Project Management Requirement; NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements; and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements, as supported by milestone reviews described in NPR 7123.1, NASA Systems Engineering Processes and Requirements.





JPR No. 7150.2A




1.1. Roles and Responsibilities This section defines the roles and responsibilities of key officials in the software engineering management process. The role of the Center Director has specific SWE requirements and is documented in JPD 7150.1. The responsibilities of the center-specific roles are documented in NPR 7150.2 and are repeated here for completeness.

a. NASA Chief Engineer

The NASA CE’s responsibilities are defined in NPR 7150.2.

b. NASA Chief, Safety and Mission Assurance (S&MA)

The NASA Chief S&MA’s responsibilities are defined in NPR 7150.2.

c. JSC Center Director

The JSC Center Director’s responsibilities are defined in JPD 7150.1.

d. JSC Safety and Mission Assurance (S&MA)

The JSC S&MA responsibilities are defined in JPD 7150.1.

e. Program and Project Managers

The software management process requires the understanding and application of laws and additional NASA policy requirements that impact the development, release, and/or maintenance of software. The documents listed in this section are additional requirements that may have an effect on software development projects and are mentioned here for awareness and completeness: (1) The Program and Project Managers ensure that software invention requirements of NPD 2091.1 are implemented by the project. (2) The Program and Project Managers ensure that software technology transfer requirements of NPR 2190.1 are implemented by the project and coordinated with the Technology Transfer Office. The project ensures that there will be no access by foreign persons or export or transfer to foreign persons or destinations until an export control review is completed and access/release is approved in accordance with NPR 2190.1 and NPR 2210.1. (3) The Program and Project Managers ensure that software external release requirements of NPR 2210.1 are implemented by the project and coordinated with the Technology Transfer Office. (4) The Program and Project Managers ensure that the information security requirements of





JPR No. 7150.2A




NPR 2810.1 and NPR 2841.1 are implemented by the project. (5) The Program and Project Managers ensure that software is accessible to individuals with disabilities in accordance with NPR 2800.2. (6) The Program and Project Managers ensure that software acquisitions or developments that meet NASA's capitalization criteria be capitalized per NPR 9250.1. (7) The Program and Project Managers ensure the human-rated software specific requirements of NPR 8705.2 are fulfilled. (8) The Program and Project Managers ensure the implementation of NPR 8735.1 for software in Category 1 and 2 programs and projects (see NPR 7120.5, Space Flight Program and Project Management Requirements and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements) and for payloads with risk classification levels A-D (see NPR 8705.4, Risk Classification for NASA Payloads). (9) The Program and Project Managers ensure that IT strategy, investment, implementation, and operations decisions are integrated per NPR 2800.1. (10) The Program and Project Managers ensure that IT investments made at the project level align with the Agency Enterprise Architecture per NPR 2830.1. (11) The Program and Project Managers ensure compliance with intellectual property requirements and copyright laws. (12) When IV&V is required for a project as per Section 2.7 of this document, the project manager will ensure that IV&V is performed by the NASA IV&V Program, unless an alternate IV&V provider is agreed to by the CSMA.





JPR No. 7150.2A




1.2. Technical Authority, Tailoring, Waivers, and Deviations a. NPR 7150.2 lists the office that has technical authority for waivers and deviations for

each requirement. A table with JSC-specific technical authority information is available in APPENDIX H. As part of defining the flow down of waiver authority, NPR 7150.2 requires that each center name the technical authority that can approve the waivers and deviations to specific requirements that are allocated to “center director”. JSC-73622, Johnson Space Center (JSC) Engineering Technical Excellence and Technical Authority Implementation Plan, names the JSC Engineering Director as the position who has the technical authority to approve waivers and deviations. [SWE-122] In the table, this is notated as “JSC Engineering Technical Authority”.

b. Software requirements tailoring is the process used to seek relief from JPR

requirements consistent with program or project objectives, acceptable risk, and constraints. When a project will not or cannot meet a JSWE requirement in this document, the project requests a waiver or deviation. The forum for processing waivers and deviations to this JPR is the Engineering Directorate Configuration Control Board (EA CCB).For compliance with most NPRs, the process of tailoring requirements for a specific project results in the generation of deviations and waivers depending on the timing of the request. The following definitions apply:

Deviation A documented authorization releasing a program or project from

meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented.

Waiver

A documented authorization releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented.

c. Due to the nature of NPR 7150.2, there are no requirements related to when in a lifecycle these requirements are put under configuration control.

d. The process for requesting a deviation or waiver from JPR 7150.2 is in APPENDIX G.

e. The determination that a requirement is “not applicable” to a particular project at a specific point in time is not considered a waiver or a deviation and, therefore, does not require technical authority approval. Appropriate use of “not applicable” is described in APPENDIX F How to Create a Compliance Matrix.





JPR No. 7150.2A




f. Serving as Technical Authorities for requirements in this directive, Center Directors, or designees shall:

(1) Assess projects’ compliance matrices, tailoring, waivers, and deviations from requirements in this directive by: [SWE-126]

a. Checking the accuracy of the project’s classification of software components against the definitions in Appendix C.

b. Evaluating the project’s compliance matrix for commitments to meet applicable requirements in this directive, consistent with software classification.

c. Confirming that requirements marked “Not-Applicable” in the project’s compliance matrix are not relevant or not capable of being applied.

d. Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix E are reasonable and acceptable.

e. Coordinate with the Center S&MA organization that the compliance matrix implementation approach does not impact safety and mission assurance on the project.

f. Approving/disapproving requests for relief from requirements designated with “X” in Appendix E, which fall under this Technical Authority’s scope of responsibility.

g. Facilitating the processing of projects’ tailoring/compliance matrices, tailoring, waivers, or deviations from requirements in this directive, which fall under the responsibilities of a different Technical Authority (see column titled “Technical Authority” in Appendix H).

h. Ensuring that approved compliance matrices, including any waivers and deviations against this directive, are archived as part of retrievable project records.

(2) Indicate their approval by signature(s) in the compliance matrix itself, when the compliance matrix is used to waive/deviate from applicable “X” requirement(s). [SWE-145]

(3) Review any tailored requirements whenever changes in project software plans or technical scope are made. [SWE-150]

1.3. Off the Shelf Software Chapters 1 through 5 below include a software classification applicability table for each





JPR No. 7150.2A




requirement. There are subtle differences in the way the requirements apply based on whether the software is a “new development” or an “off the shelf” component being used. JSWE-027, in section 2.10, and the table in Appendix E provide explanation and notates the applicability per requirement.





JPR No. 7150.2A




CHAPTER 2: SOFTWARE MANAGEMENT REQUIREMENTS

The software management activities define and control the many software aspects of a project from beginning to end. This includes the interfaces to other organizations, determination of deliverables, estimates and tracking of schedule and cost, risk management, formal and informal reviews as well as other forms of verification and validation, and determination of the amount of supporting services. The planned management of these activities is captured in one or more software and/or system plans.

Software management includes all the planning activities across the project life cycle, software project management activities, verification, and validation, and contract requirements. The requirements in this section define the activities and the documentation required to manage software projects.

2.1 Compliance with Laws, Policies, and Requirements

a. This JPR is structured so that it can be imposed on software projects managed by civil servant organizations or by contractor organizations. Complying with this document means that a software project is complying with the approved JSC interpretation of NPR 7150.2.

b. The requirements in this document are labeled with JSWE requirements traceability numbers to distinguish them from the SWE numbers in NPR 7150.2. The JSWE requirements in this document are directly traceable to their NPR 7150.2 SWE parent requirements. If there are several JSWE requirements for each SWE requirement, the JSWE requirement number will include an alphabetic character.

c. This JPR document does not impose any additional technical requirements on software projects related to compliance with laws, policies, and requirements, but JPD 7150.1 (Section 1.4) does impose policy requirements.





JPR No. 7150.2A




2.1.1 Compliance Matrix

NPR 7150.2 [SWE-125] is the parent requirement.

2.1.1.1 Each project with software components shall establish and maintain a compliance matrix or multiple compliance matrices against requirements in this JPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. [JSWE-125]

Rationale: Without a compliance matrix, a project cannot be easily assessed as complying with this JPR.

TABLE 2-1 CLASS APPLICABILITY FOR JSWE-125

When Class

Then A B C D A B C D E F G H


X X X X X X X X X X X X Implement JSWE-125 as written.

Note: See APPENDIX F, How to Create a Compliance Matrix for instructions.





JPR No. 7150.2A




2.1.2 Document Tailoring


2.1.2.1 Where approved, the project shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and/or deployment of the affected software. [JSWE-121]

Rationale: Without the documented deviation of a requirement, project staff will perform the deviation in various ways with varying results.


When Class



X X X X X X X X X X X Implement JSWE-121 as written.





JPR No. 7150.2A




2.2 Software Life-Cycle Planning

Software life cycle planning covers the software aspects of a project from inception through retirement. The software life cycle planning cycle is an organizing process that considers the software as a whole and provides the planning activities required to ensure a coordinated, well- engineered process for defining and implementing project activities. These processes, plans, and activities are coordinated within the project. At project conception, software needs for the project are analyzed including: acquisition, supply, development, operation, maintenance, retirement, and supporting activities and processes. The software effort is scoped, and the processes, measurements, and activities are documented in the project’s software plan(s).

This JPR makes no recommendation for a specific software life-cycle model (i.e., it allows agile, incremental, spiral, etc., life-cycle models). However, expectations from the system project life- cycle models need to be adequately addressed in the software plan(s).





JPR No. 7150.2A




2.2.1 Software Plans


2.2.1.1 The project shall develop, maintain, and execute software plans that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring. [JSWE-013]

Rationale: Management of software development activities requires planning.


When Class




Note 1: The types and expected contents of the software plans are defined in Chapter 5.0. Typical plans are:

a. Software development or management plan

b. Software configuration management plan (except for Class D/E)

c. Software assurance plans (except for Class E/F/G)

d. Software test plans (except for Class E)

Note 2: Plans may be documented separately or together, based on the class of software and the size and complexity of the project. Plans may also be integrated into other project level plans.





JPR No. 7150.2A




2.2.2 Tracking Results and Performance against Plans


2.2.2.1 The project shall track the actual results and performance of software activities against the software plans. [JSWE-024]

a. Corrective actions are taken, recorded, and managed to closure.

b. Changes to commitments (e.g., software plans) that have been agreed to by the

affected groups and individuals.

Rationale: Basic project management discipline requires tracking actual performance against planned performance. This allows for early detection of problems and enables corrective action to be applied early in the project life cycle when it is most cost-effective.


When Class



X X X X X X X X X X Implement JSWE-024 as written.

Note: In the event of a decision to outsource, it is a best practice that both the acquirer (NASA) and the provider (contractor/subcontractor) be responsible for developing software cost estimates. For any class of software that has significant risk exposure, consider performing at least two cost estimates.





JPR No. 7150.2A




2.3 Software Cost Estimation

2.3.1 Cost Estimate Methodology


2.3.1.1 The project‘s software cost estimate(s) shall satisfy the following conditions:.

[JSWE-151].

a. Covers the entire software life cycle.

b. Is based on selected project attributes (e.g., assessment of the size, functionality,

complexity, criticality, reuse code, modified code, and risk of the software processes

and products).

c. Is based on the cost implications of the technology to be used and the required

maturation of that technology.

d. Incorporates risk and uncertainty.

e. Includes the cost for software assurance support.

f. Includes other direct costs

Rationale: Documented cost estimates allow projects to manage actual costs against budget numbers. Documenting these assumptions allows for re-planning when assumptions change. In addition, collecting cost attributes (size, functionality, complexity, etc.) across multiple projects enables the organization to refine and improve its ability to estimate costs for future projects.


When Class



X X X X X X X X Implement JSWE-151 as written.

Note 1: In the event of a decision to outsource, it is a best practice that both the acquirer (NASA) and the provider (contractor/subcontractor) be responsible for developing software cost estimates. For any class of software that has significant risk exposure, consider performing at least two cost estimates.

Note 2: Examples of cost estimation methodologies include expert opinion, analogy, use of a formalized methodology such as COCOMO or SEER-SEM, statistical sizing, etc.





JPR No. 7150.2A




2.3.2 Cost Estimation


2.3.2.1 The project shall establish and maintain one cost estimate and associated cost parameters for all software projects; two cost estimates are required for those projects that have an estimated project cost of $2 million or more. [JSWE-015]

Rationale: Multiple estimates are especially important due to the uncertainty that exists in the early part of the life cycle. Having two independent estimates will validate

the project’s approach by sparking discussions on the different assumptions that

were made with each estimate. Maintaining estimates throughout the life of the project will provide feedback to improve the models used in software cost estimation across the agency.


When Class



X X Implement JSWE-015 as written.

X X X X X X X The project shall establish and maintain one software cost estimate and associated cost parameter(s).





JPR No. 7150.2A




2.4 Software Schedules

2.4.1 Software Schedule


2.4.1.1 The project shall establish and maintain a software schedule that satisfies the following conditions [JSWE-016]

a. Coordinates with the overall project schedule.

b. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.

c. Reflects the critical path for the software development activities.

Rationale: Schedules are essentially documented agreements between project team members, stakeholders, etc. Milestones define deliverables and review activities, as well as allowing external stakeholders visibility into software products. Maintaining and following a current schedule enables the project to manage risks and resources effectively. Knowing the critical path for software development activities is essential to basic project management. This requirement assumes that the software project is part of a larger project with an overall schedule and that software is a subsystem in a larger system.


When Class




Note 1: The software schedule can be part of a larger project schedule and does not need to be a standalone schedule.

Note 2: The project should adhere to the guidance provided in NASA/SP-2010-3403,

NASA Scheduling Management Handbook.





JPR No. 7150.2A




2.4.2 Reviews and Issue Resolution


2.4.2.1 The project shall regularly hold reviews of software activities, status, and results with the project stakeholders and track issues to resolution. [JSWE-018]

Rationale: Projects should aim for establishing and maintaining good communications with customers and stakeholders to prevent gaps in expectation of scheduling, costs, requirements creep, etc. Depending on the complexity of the project, this may not be a formal status.


When Class




Note: Note: Different levels of formality of these reviews are required for

different Payload Risk Classes (A-D), per NPR 8705.4, Appendix C. Evidence of such meetings is satisfied by a simple e-mail with a brief summary of the meeting with a list of attendees.





JPR No. 7150.2A




2.4.3 Software Life Cycle


2.4.3.1 The project shall select and document a software life cycle or model. [JSWE-019]

Rationale: A software life cycle (or model) defines the processes, activities, milestones (reviews), and products generated during software development. The requirement is explicitly to select the software life cycle. Examples of software life-cycle models are waterfall, spiral, iterative, agile, etc. Selection of approved life-cycle models allows better control of project cost and resource estimates. Some life-cycle models are embedded in directorate-level work instructions.


When Class




Note: This JSWE does not apply to COTS software acquisition.





JPR No. 7150.2A




2.5 Software Project Specific Training

2.5.1 Training


2.5.1.1 The project shall plan, track, and ensure project-specific software training for project personnel. [JSWE-017]

Rationale: If developers on a project require training unique for that project, basic project management necessitates that the training is planned for, budgeted, and tracked as a project task.


When Class



X X X X X X X X X Implement JSWE-017 as written.

Note 1: This includes any software assurance personnel assigned to the project.

Note 2: The training schedule can be part of a larger project schedule and does not need to be a standalone schedule.





JPR No. 7150.2A




2.6 Software Classification and Planning Assessments

2.6.1 Software Classification

NPR 7150.2A [SWE-020] is the parent requirement.

2.6.1.1 The project shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, F, G, and H software in Appendix C. [JSWE-020]

Rationale: A project may have portions of software that are covered under different classifications. This approach is more cost effective than requiring all software within a project to be developed to the highest classification found within the project.


When Class




Note: Recommend utilizing JSC Form JF1704 to document the classification.





JPR No. 7150.2A




2.6.2 Independent Software Classification


2.6.2.1 The project’s software assurance organization shall perform an independent software classification assessment at project inception and update the assessment if the classification changes. [JSWE-132]

Rationale: An independent classification assessment by the software assurance organization provides a basis of comparison for the project’s internal assessment and supplies objectivity to the classification.


When Class




Note 1: The project and software assurance must reach agreement on the software classification determination of the software. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains.

Note 2: Recommend utilizing JSC Form JF1704 to document the classification.





JPR No. 7150.2A




2.6.3 Software Safety Criticality


2.6.3.1 The project, in conjunction with the Safety and Mission Assurance organization, shall determine the software safety criticality in accordance with NASA-STD- 8719.13. [JSWE-133]

Rationale: The safety criticality of the software is assessed to determine the impact of the software on the safety of the crew, employees, and the general public. The Safety and Mission Assurance organization provides the expertise to make the assessment.


When Class




Note: Recommend utilizing JSC Form JF1704 to document both the software safety criticality and software classification with the minimum appropriate signatures. The results (documented on the JF1704 or other mechanism) should be reflected in the project Initial Assessment of Criticality (IAC) in the description section. The IAC is approved by the Customer-designated safety authority.





JPR No. 7150.2A




2.6.4 Software Classification Evolution


2.6.4.1 If a system or subsystem evolves to a higher or lower software classification, as defined in APPENDIX C, or there is a change in the safety criticality of the software, then the project shall update its plan to fulfill the applicable requirements, per the Requirements Mapping Matrix in APPENDIX E and any approved tailoring. [JSWE-021]

Rationale: As a project evolves, its products may be identified to be used for more critical systems and thus pushing it into a higher software classification. The probability of defects existing within the product decreases as the classification is increased. To assure the quality of the product meets the expectations of its intended environment, software processes will be adjusted to meet the more critical classification.


When Class




Note: The timeframe to fulfill the evolved requirements should be completed prior to the next formal release of the product.





JPR No. 7150.2A




2.6.5 Safety Critical Classification


2.6.5.1 If a software component is determine to be safety critical software then software component classification shall be Software Class D or higher. [JSWE-160]

Rationale: There were no differences between Class E and Class D Safety-Critical requirements; therefore, this NPR is simplifying its structure by removing Class E Safety-Critical as a class.


When Class



X X X X Implement JSWE-160 as written.





JPR No. 7150.2A




2.7 Software Assurance and Software IV&V

2.7.1 Software Assurance


2.7.1.1 The project shall plan and implement software assurance per NASA-STD-8739.8. [JSWE-022]

Rationale: Planning the software assurance activities ensures that sufficient resources are put into the project plan to accomplish those activities. Following NASA-STD- 8739.8 ensures that the Software Assurance personnel know what is expected of them and allows them to commit to projects in a known, repeatable way.


When Class




Note: Software assurance activities occur throughout the life of the project. Some of the actual analyses and activities may be performed by engineering or the project. Safety and Mission Assurance organizations provide assurance that the products and processes are implemented according to the agreed-upon plan(s). Software Assurance is recommended on software activities and products, including solicitations, contract, and memorandums of agreements, software plans, requirements, design, implementation, verification, validation, certification, acceptance, maintenance, operations, and retirement activities.





JPR No. 7150.2A




2.7.2 Software IV&V NPR 7150.2 [SWE-141] is the parent requirement.

2.7.2.1 For projects following life cycles using Key Decision Point (KDPs), those

reaching KDP A after the effective date of this directive’s revision, the

program manager shall ensure that software IV&V is performed on the following categories of projects: [JSWE-141]

a. Category 1 projects as defined in NPR 7120.5.

b. Category 2 projects as defined in NPR 7120.5 that have Class A or Class B payload risk classification per NPR 8705.4.

c. Projects specifically selected by the NASA CSMA to have software IV&V.

Rationale: Without reusability requirements, some projects may focus on short term objectives without considering the long term benefits of having a reuse library where the project can lessen the cost of creating, testing, and releasing new software.


When Class




Note: The NASA IV&V Board of Advisors supports the NASA CSMA by recommending significant project needs for software IV&V beyond projects meeting the criteria in items a. and b. of JSWE-141. Waivers to the above requirement will be written by the project and responsible Center S&MA organization, adjudicated by the NASA IV&V Board of Advisors, with the final decision by the NASA CSMA. Additional projects, projects in other phases, or projects without a payload risk classification can be selected by the NASA CSMA to be required to have software IV&V. It is NASA policy to use the NASA IV&V Facility as the sole provider of IV&V services when software created by or for NASA is selected for IV&V by the NASA CSMA. IV&V support is funded and managed independent of the selected project.





JPR No. 7150.2A




2.7.3 Software IV&V Plan


2.7.3.1 If software IV&V is performed on a project, the project manager shall ensure that an IV&V Project Execution Plan (IPEP) is developed. [JSWE-131]

Rationale: The IPEP serves as the operational document for the IV&V efforts and communicates IV&V interactions, interfaces, roles and responsibilities, technical products, and reporting methods with the project.


When Class




Note: The scope of IV&V services is determined by the project and the IV&V provider, and is documented in the IPEP. The IPEP is developed by the IV&V provider and serves as the operational document that will be shared with the project receiving IV&V support. In accordance with the responsibilities defined in NPD 7120.4, section 5.J.(5), projects ensure that software providers allow access to software and associated artifacts to enable implementation of IV&V. A template and instructions for an IPEP may be found in the NASA IV&V Management System, accessible at http://www.nasa.gov/centers/ivv/ims/home/index.html





JPR No. 7150.2A




2.8 Safety-Critical Software

2.8.1 Safety Standard


2.8.1.1 When a project is determined to have safety-critical software, the project shall implement the safety requirements of NASA-STD-8719.13, Software Safety Standard. [JSWE-023]

Rationale: This Standard was developed by the NASA Office of Safety and Mission Assurance to provide the requirements for software safety across all NASA Centers, programs, and facilities. It describes the activities necessary to ensure that safety is designed into the software that is acquired or developed by NASA.


When Class




Note: Engineering and Software Assurance initially determine software safety criticality in the formulation phase per NASA-STD-8739.8, NASA Software Assurance Standard; the results are compared and any differences are resolved. As the software is developed or changed and the software components, software models, and software simulations are identified, the safety-critical software determination can be reassessed and applied at lower levels. Further scoping and tailoring of the safety effort is found in the NASA-STD-8719.13, Software Safety Standard and NASA-GB-8719.13, NASA Software Safety Guidebook.





JPR No. 7150.2A




2.8.2 Computing System Safety Requirements


2.8.2.1 The project shall ensure the following items are implemented in the requirements and design for safety-critical software: [JSWE-134]

No. Requirement

a. Safety-critical software is initialized, at first start and at restarts, to a known safe state.

N o t e : Aspects to consider when establishing a known safe state include state of the

hardware and software, operational phase, device capability, configuration, file allocation

tables, and boot code in memory. b. Safety-critical software safely transitions between all predefined known states.

c. Termination performed by software of safety-critical functions is performed to a known safe state.

d. Operator overrides of safety-critical software functions require at least two independent actions by an operator.

Note: Multiple independent actions by the operator help to reduce potential operator mistakes. e. Safety-critical software rejects commands received out of sequence, when execution of those commands out of sequence can cause a critical or catastrophic hazard.

f. Safety-critical software detects inadvertent memory modification and recovers to a known safe state.

Note: As an example, computing systems may implement error detection and correction, software- executable and data-load authentication, periodic memory scrub, and space partitioning to provide protection against inadvertent memory modification. Features of the processor and/or operating system can be utilized to protect against incorrect memory use.

g. Safety-critical software performs integrity checks on inputs and outputs to/from the software system.

Note: Software needs to accommodate both nominal inputs (within specifications) and off-nominal inputs from which recovery may be required.

h. Safety-critical software performs prerequisite checks prior to the execution of safety-critical software commands.

Note: The intent is to preclude the inappropriate sequencing of commands. Appropriateness is determined by the project and conditions designed into the safety-critical system. Safety- critical software commands are commands that can cause or contribute to a critical or catastrophic hazardous event or operation.

i. No single software event or action is allowed to initiate an identified critical or catastrophic hazard.





JPR No. 7150.2A




No. Requirement

j. Safety-critical software responds to an off-nominal condition within the time needed to prevent a critical or catastrophic hazardous event.

Note: The intent is to establish a safe state following detection of an off-nominal indication. The safety mitigation will complete between the time that the off-nominal condition is detected and the time the critical or catastrophic hazard would occur without the mitigation. The safe state either can be an alternate state from normal operations or can be accomplished by detecting and correcting the fault or failure within the timeframe necessary to prevent a critical or catastrophic hazard and continuing with normal operations.

k. Software provides error handling of safety-critical functions.

Note: Error handling is an implementation mechanism or design technique by which software faults and/or failures are detected, isolated, and recovered to allow for correct run-time program execution. The software error-handling features that support safety-critical functions may detect and respond to hardware and operational faults and/or failures.

l. Safety-critical software has the capability to place the system into a safe state.

Note: The design of the system will provide sufficient sensors and effectors, as well as self-checks within the software, in order to enable the software to detect and respond to system potential critical or catastrophic hazards.

m. Safety-critical elements (requirements, design elements, code components, and interfaces) are uniquely identified as safety-critical.

n. Incorporate requirements in the coding methods, standards, and/or criteria to identify safety- critical code and data clearly within source code comments.

Rationale: Generic technical requirements to control hazards. These requirements are applicable to components that reside in a safety-critical system, and control, mitigate, or contribute to a hazard as well as software used to command hazardous operations/activities.


When Class



X X Implement SWE-134.

X Implement JSWE-134 for Computer based control Systems (Flight Only)

X X Implement per Hazard Analysis for ground based C & all D

Note 1: These requirements are applicable to components that reside in a safety-critical system and the components control, mitigate or contribute to a hazard as well as software used to command hazardous operations/activities.





JPR No. 7150.2A




Note 2: Recommend utilizing JSC form JF1704 to document both the software safety criticality and software classification with the minimum appropriate signatures. The results (documented on the JF1704 or other mechanism) should be reflected in the project Initial Assessment of Criticality (IAC) in the description section. The IAC is approved by the Customer-designated safety authority.

Note 3: For ISS projects, compliance with SSP 50038, Computer-Based Control System Safety Requirements, is considered to meet JSWE-134





JPR No. 7150.2A




2.9 Automatic Generation of Software Source Code

2.9.1 Automatic Code Generation


2.9.1.1 The project shall define the approach to the automatic generation of software source code including. [JSWE-146]

a. Verification and validation of auto-generation tools.

b. Configuration management of the auto-generation tools and associate data.

c. Identification of the allowable scope for the use of auto-generated software.

d. Verification and validation of auto-generated source code.

e. Monitoring the actual use of auto-generated source code compared to the

planned use.

f. Policies and procedures for making manual changes to auto-generated source

code.

g. Configuration management of the input to the auto-generation tool, the output of

the auto-generation tool, and modifications made to the output of the auto-

generation tools.

Rationale: Without a formal approach to the management of auto-generated code, errors can arise even though the models and logic used to generate the code are correct.


When Class




Note: When using a compliance matrix, refer to these requirements as JSWE-146 and JSWE-146a to JSWE-146g.





JPR No. 7150.2A




2.10 Use of Commercial, Government, Legacy, Heritage, and Modified Off-the-Shelf Software

Projects utilizing COTS, GOTS, MOTS, and legacy/heritage software components need to take into consideration the importance of planning and managing the inclusion of those components into the project software. The off-the-shelf software discussed here applies only when the off-the-shelf software elements are to be included as part of a NASA system.

The following requirements do not apply to stand-alone desktop applications (e.g., word processing programs, spreadsheet programs, presentation programs). When software components use COTS applications (e.g., spreadsheet programs, database programs) within a NASA system/subsystem application, the software components typically are assessed and classified as part of the software subsystem in which they reside. Note that commercial, government, legacy, heritage, and MOTS software also have to meet the applicable requirements for each class of software.





JPR No. 7150.2A




2.10.1 COTS, GOTS, MOTS, Reused, or FOSS Software


2.10.1.1 When a COTS, GOTS, MOTS, reused, or FOSS software component is to be acquired or used, a COTS software plan shall be developed that addresses the following: [JSWE-027]

a. Acquisition (e.g., supplier selection, cost/schedule, usage rights, ownership rights, licensing rights, transfer rights)

b. Requirements (e.g., documentation, change management, traceability)

c. Acceptance (e.g., testing procedures, testing methods, testing tools, V&V)

d. Defects (e.g., documentation, tracking, corrective actions, periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components)

e. Operations, Maintenance, and Retirement (e.g., updates, future support)

f. Configuration Management

g. Software Design (e.g., architecture, detailed design, interface design)

h. Version Description

i. Project Management (e.g., corrective actions, NASA/supplier audits, plan implementation, peer review/inspections, measurements/metrics)

j. Source Information (e.g., source code, traceability data, FOSS notification, usage instructions, and other as-built documentation)

k. In-house modification approach

l. Equivalent Certification information; i.e. software that was developed in accordance with recognized commercial or government standards

m. Risk Management (e.g., untested code, loss of support, loss of product maintenance, or loss of the product itself)

Rationale: COTS, MOTS, and GOTS can be used advantageously when the correct precautions are implemented to prevent unwarranted software errors or misapplication.





JPR No. 7150.2A





When Class




Note1 If the COTS, GOTS, MOTS, reused, or FOSS software component is part of a larger development effort, the items required as part of the COTS software plan can be addressed within other project documents (such as software development plan, software configuration management plan, etc.)

Note2: The manner in which each item is addressed (from no action taken to rigorous compliance) is to be determined by the project based on risk, cost, and other factors as determined by the project.

Note 3: The application of JSWE-027 affects many other JPR requirements. The summary in Appendix E includes notes identifying which JSWE process requirements do not apply to COTS, which ones must be addressed, and which ones the project can implement at their discretion. The following notes are located in Appendix E to clarify the applicability of the matrixed requirements to COTS

X Note: The project is allowed flexibility (via JSWE-027) in addressing this requirement in the case of COTS software acquisition.

X1 Note: This requirement does not apply to COTS software acquisition.

X2 Note: This requirement is treated consistently whether the project involves software development or COTS software acquisition.





JPR No. 7150.2A




2.11 Software Verification and Validation

Ensuring that the software products meet their requirements and intended usage, and that the products are built correctly, is the purpose of verification and validation. Both software validation and software verification activities span the entire software life cycle and need to be planned. Formal and informal reviews, software peer reviews/inspections, testing, demonstration, and analyses can be used. Each project is generally free to choose the extent and combination of verification and validation methods and activities that best suit the project.





JPR No. 7150.2A




2.11.1 Software Verification Plan


2.11.1.1 The project shall plan software verification activities, methods, environments, and criteria for the project. [JSWE-028]

Rationale: Failure to plan the verification activities for the software may result in accepting software that does not meet requirements.


When Class



X X X X X X Implement JSWE-028 as written.

X X X X Implement JSWE-028 as written and additional requirements for safety-critical software:

a. Perform inspection to verify implementation of the safety-critical requirements in the code.

b. Perform analysis or testing to verify the effectiveness of hazard controls. (Analysis may be performed to support the case that hazard is effectively controlled.)

Note: When using a compliance matrix for safety critical software, refer to these requirements as JSWE-028, JSWE-028a, and JSWE-028b.





JPR No. 7150.2A




2.11.2 Software Validation Plan


2.11.2.1 The project shall plan the software validation activities, methods, environments, and criteria for the project. [JSWE-029]

Rationale: Failure to plan the validation activities for the software may result in accepting software that does not meet its intended use.


When Class








JPR No. 7150.2A




2.11.3 Results of Verification


2.11.3.1 The project shall record, address, and track to closure the results of software verification activities. [JSWE-030]

Rationale: Failure to record, address, and track the verification activities to closure may result in accepting software that does not meet requirements.


When Class








JPR No. 7150.2A




2.11.4 Results of Validation


2.11.4.1 The project shall record, address, and track to closure the results of software validation activities. [JSWE-031]

Rationale: Failure to record, address, and track the validation activities to closure may result in accepting software that does not fulfill its intended use.


When Class








JPR No. 7150.2A




2.12 Software Development Processes The use of the CMMI model is included to make sure NASA projects are supported by software development organization(s) having the necessary skills and processes in place to produce reliable products within cost and schedule estimates. The CMMI requirement, SWE-032, provides NASA with a methodology to:

a. Measure software development organizations against an industry-wide set of best practices that address software development and maintenance activities applied to products and services.

b. Measure and compare the maturity of an organization's product development and acquisition processes with industry state of the practice.

c. Measure and ensure compliance with the intent of the NPR 7150.2 process related requirements using an industry standard approach.

d. Assess internal and external software development organization’s processes. e. Identify potential risk areas within a given organization's software development processes.

The CMMI-DEV is an internationally used framework for process improvement in development organizations. It is an organized collection of best practices and proven processes that thousands of software organizations have both used and been appraised against for over the past two decades. CMMI defines practices that businesses have implemented on their way to success. Practices cover topics that include eliciting and managing requirements, decision making, measuring performance, planning work, handling risks, and more. Using these practices, NASA can improve NASA software projects' chances of mission success. CMMI ratings can cover a team, a work group, a project, a division, or an entire organization. When evaluating software suppliers, it's important to make sure that the specific organization doing the software work on the project has the cited rating (as some parts of a company may be rated while others are not).





JPR No. 7150.2A




2.12.1 CMMI


2.12.1.1 All projects producing software for flight or to support flight (e.g., ground support, ops, etc.) shall ensure software is acquired, developed, and maintained by an organization with a non-expired Capability Maturity Model Integration® for Development (CMMI-DEV) rating as measured by a Software Engineering Institute (SEI) authorized or certified lead appraiser as follows: [JSWE-032]

a. For Class A software: CMMI-DEV Maturity Level 3 Rating or higher for software, or CMMI-DEV Capability Level 3 Rating or higher in all CMMI-DEV Maturity Level 2 and Maturity Level 3 process areas for software..

b. For Class B software:

(except NASA Risk Level D payloads, as defined in NPR 8705.4)

CMMI-DEV Maturity Level 2 Rating or higher for software, or CMMI-DEV Capability Level 2 Rating or higher for software in the following process areas:

(1) Requirements Management

(2) Configuration Management

(3) Process and Product Quality Assurance

(4) Measurement and Analysis

(5) Project Planning

(6) Project Monitoring and Control

(7) Supplier Agreement Management (if applicable)


When Class



X X X X X Implement JSWE-032 as written.

Note 1: Organizations that have completed Standard CMMI® Appraisal Method for Process Improvement (SCAMPISM) Class A appraisals against the CMMI-DEV model are to maintain their rating and have their results posted on the CMMI Institute Web site so that NASA can assess the current maturity/capability rating. Software development organizations need to be reappraised and keep an active appraisal rating posted on the CMMI® Institute Website during the time that they are responsible for the development and maintenance of the software.





JPR No. 7150.2A




Note 2: For Class B software, in lieu of a CMMI® rating by a development organization, the project may conduct an evaluation, performed by a qualified evaluator selected by the JSC Engineering Technical Authority, of the seven process areas listed in JSWE-032 and mitigate any risk, if deficient. This exception is intended to be used in those cases in which NASA wishes to purchase a product from the “best of class provider”, but the best of class provider does not have the required CMMI® rating. When this exception is exercised, the JSC Engineering Technical Authority should be notified.

Note 3: For Class B software on NASA Class D Payloads and Class C software, it is highly

recommended that providers have a Certified CMMI® Lead Appraiser conduct periodic

informal evaluations (e.g., Appraisal Class Bs or Cs) against relevant process areas.

Note 4: By following this JPR, Class C software projects are already conforming with

CMMI® Level 2 process areas: Requirements Management, Configuration Management,

Process and Product Quality Assurance. Measurement and Analysis, Project Planning,

and Project Monitoring and Control (except for SP 1.3–SP 1.5: “Monitor Project Risks,” “Monitor Data Management,” and “Monitor Stakeholder Involvement”)





JPR No. 7150.2A




2.13 Software Acquisition

The requirements in this section are applicable for both NASA contracted software procurements (e.g., reuse of existing software, modification of existing software, contracted and subcontracted software, and/or development of new software) and in-house developments. Acquisition requirements are focused both inside the acquisition organization, to ensure the acquisition is conducted effectively, and outside the acquisition organization, as the organization conducts project monitoring and control of its suppliers. These acquisition requirements provide a foundation for acquisition process discipline and rigor that enables product and service development to be repeatedly executed with high levels of acquisition success. This section contains project software acquisition and contract requirements to ensure that the project has the data needed for the review of provided systems and/or services. The project is responsible for ensuring that these requirements apply when software activities are developed in-house, contracted directly, or subcontracted from a NASA prime contractor. These requirements are used in addition to, not in place of, the other requirements of this directive.





JPR No. 7150.2A




2.13.1 Acquisition and Development


2.13.1.1 The project shall assess options for software acquisition versus development. [JSWE-033]

Rationale: One of the most fundamental project decisions is whether to develop a product or purchase it. Assessment of the options enables estimation of cost and schedule, as well as management of resources and risk throughout the life of the project.


When Class




Note 1: The assessment can include risk, cost, and benefits criteria for each of the options listed below:

a. Acquire an off-the-shelf software product that satisfies the requirement.

b. Develop the software product or obtain the software service internally.

c. Develop the software product or obtain the software service through contract.

d. Enhance an existing software product or service.

Note 2: Risks are considered in software make/buy and acquisition decisions. The project needs to ensure that software products used in the design or support of human spaceflight components or systems include a level of rigor in risk mitigation as a software management requirement, regardless of software classification. The level of documentation needed for risk identification and tracking is defined by program and Directorate processes





JPR No. 7150.2A




2.13.2 Acceptance Criteria


2.13.2.1 The project shall define and document the acceptance criteria and conditions for the software. [JSWE-034]

Rationale: Essential to the project formulation stage of a project is formal agreement as to the criteria for completion of the project; i.e., the acceptance criteria and the environment the software is expected to operate within.


When Class




Note 1: The project is responsible for ensuring that this requirement applies when software activities are developed in-house, contracted directly, or subcontracted from a NASA prime contractor





JPR No. 7150.2A




2.13.3 Supplier Selection Procedure


2.13.3.1 The project shall establish a procedure for software supplier selection, including proposal evaluation criteria. [JSWE-035]

Rationale: Essential to the project formulation stage of a project that involves new contracts is the definition of the procedure for selecting a software supplier and the criteria for evaluating proposals.


When Class




Note 1 Refer to definition of “Perspective of the Supplier” for project/supplier clarification.

Note 2 The Federal Acquisition Regulation (FAR) policies and procedures require supplier selection and proposal evaluation criteria for large purchases.





JPR No. 7150.2A




2.13.4 Determining Processes, Activities, and Tasks


2.13.4.1 The project shall determine which software processes, software documents, electronic products, software activities, and tasks are required for the project, and software suppliers. [JSWE-036]

Rationale: Determination of software processes, activities, and tasks is essential to project planning and estimation.


When Class




Note 1: This JSWE does not apply to COTS software acquisition.

Note 2: The project is responsible for ensuring that this requirement applies when software activities are developed in-house, contracted directly, or subcontracted from a NASA prime contractor.





JPR No. 7150.2A




2.13.5 Milestones


2.13.5.1 The project shall define the milestones at which the software supplier(s) progress will be reviewed and work products audited as a part of the acquisition activities. [JSWE-037]

Rationale: Without progress measures, it is likely the supplier will deliver late and with a solution not meeting the expectations of the project. For small projects, a supplier’s progress may be reviewed monthly and the work products audited during acceptance. For larger projects, formal milestones are used (e.g., System Requirements Review (SRR), Preliminary Design Review (PDR), etc.).


When Class





Note 2: Refer to definition of “Perspective of the Supplier” for project/supplier clarification.





JPR No. 7150.2A




2.13.6 Documenting Acquisition Planning Decisions


2.13.6.1 The project shall document software acquisition planning decisions. [JSWE-038]

Rationale: Documentation of software acquisition planning decisions is essential to project management and is important when changes to initial project formulation assumptions require renegotiation of acquisition activities.


When Class









JPR No. 7150.2A




2.14 Software Contract Requirements

The requirements in this section are applicable for NASA-contracted software procurements (e.g., reuse of existing software, modification of existing software, contracted and subcontracted software, and/or development of new software). Acquisition requirements are focused both inside the acquisition organization to ensure the acquisition is conducted effectively and outside the acquisition organization as the organization conducts project monitoring and control of its suppliers. These acquisition requirements provide a foundation for acquisition process discipline and rigor that enables product and service development to be repeatedly executed with high levels of acquisition success. This section contains project software acquisition and contract requirements to ensure that NASA has the data needed for the review of project-provided systems and/or services. The project is responsible for ensuring that these requirements apply when software activities are subcontracted from a NASA prime contractor. These requirements are used in addition to, not in place of, the other requirements of this JPR.





JPR No. 7150.2A




2.14.1 Insight into Supplier Activities


2.14.1.1 The project shall require the software supplier(s) to provide insight into software development and test activities; at a minimum, the following activities are required: monitoring integration, review of the verification adequacy, review of trade study data and results, auditing the software development process, participation in software reviews, and systems and software technical interchange meetings. [JSWE-039]

Rationale: Insight into the development activities of software suppliers is essential to project management and oversight. This requirement lists the minimum set of activities that will provide the necessary management and technical insight and oversight during the software development process.


When Class




X X Implement JSWE-039 as written for safety- critical portions of the software only.

X X Implement JSWE-039 only for “adequacy of verification”.

Rationale: Of the activities listed, the highest benefit comes from ensuring the supplier’s verification coverage will sufficiently test all requirements.







JPR No. 7150.2A




2.14.2 Supplier Providing Information to NASA


2.14.2.1 The project shall require the software supplier(s) to provide NASA with all software products and software process-tracking information, in electronic format, including software development and management metrics. [JSWE-040]

Rationale: It is essential to specify the form and format of software supplier deliverables in the contract. Unexpected costs and delays are often incurred due to imprecise specifications in this area. Mismatches in data formats, use of uncommon (or proprietary) databases or management tools, can render software deliverables unusable. Licensing, training and maintenance of unfamiliar software build tools, discrepancy-tracking tools; configuration management tools, etc. can have a huge and unanticipated impact on project resources and schedules, both on the supplier side and the customer side of the contract.


When Class




X Implement JSWE-040 as written for safety- critical portions of the software only.







JPR No. 7150.2A




2.14.3 Access to Source Code


2.14.3.1 The project shall require the software supplier(s) to provide NASA with electronic access to the source code developed for the project, including MOTS software and non-flight software (e.g., ground test software, simulations, ground analysis software, ground control software, science data processing software, and hardware manufacturing software). [JSWE-042]

Rationale: The project needs to maintain the software after delivery.


When Class



X X X X X X X Implement JSWE-042 as written.








JPR No. 7150.2A




2.15 Software Monitoring

2.15.1 Tracking Software Changes and Nonconformances


2.15.1.1 The project shall require the software supplier(s) to track all software changes and non-conformances and provide the data for the project’s review. [JSWE-043]

Rationale: If software change requests and problems are not tracked and reported, there is no way to control scope creep on a project. Costs will increase and schedules will stretch out with no clear reason.


When Class











JPR No. 7150.2A




2.15.2 Joint NASA/Supplier Audits


2.15.2.1 The project shall participate in any joint NASA/supplier audits of the software development process and software configuration management process. [JSWE- 045]

Rationale: If an audit is performed without project participation, erroneous conclusions will be made, resulting in unnecessary corrective actions that require more effort to address than the original audit. Undiscovered process nonconformances could result in customer quality errors that will result in costly rework.


When Class











JPR No. 7150.2A




2.15.3 Supplying the Software Schedule


2.15.3.1 The project shall require the software supplier(s) to provide a software schedule for the project’s review and schedule updates as requested. [JSWE-046]

Rationale: Without a mutually-agreed-upon schedule, supplier capabilities cannot be balanced against customer expectations, resulting in costly delays in the integration of components due to miscommunications between the customer and supplier.


When Class






Note 3: The software schedule can be part of a larger project schedule and does not need to be a standalone schedule.





JPR No. 7150.2A




2.15.4 Supplying Traceability Data


2.15.4.1 The project shall require the software supplier(s) to provide the software traceability data in an agreed-upon electronic format for the project’s review. [JSWE-047]

Rationale: If traceability data is not available to map requirements throughout the implementation’s work products, it cannot be determine if requirements are implemented correctly until the final product is delivered.


When Class




X

Implement JSWE-047 as written for safety- critical portions of the software only.







JPR No. 7150.2A




2.16 Software Reuse

Software reuse entails capitalizing on existing software and systems to create new products. Successful reuse requires the integration of reuse-related activities into the life cycle to create reusable assets for current and future software and systems. Unless reuse is explicitly planned into life-cycle processes, an organization will not be able to repeatedly exploit reuse opportunities in multiple software projects or products. Systematic reuse is the practice of reuse according to a consistent, repeatable process. Practicing systematic reuse requires a focus on the use of engineering principles for all reuse assets involved in development. The major benefits that systematic reuse can deliver are as follows:

a) Increase software productivity. b) Shorten software development and maintenance time. c) Reduce duplication of effort. d) Move personnel, tools, and methods more easily among projects. e) Reduce software development and maintenance costs. f) Produce higher quality software products. g) Increase software and system dependability.





JPR No. 7150.2A




2.16.1 Reusability Requirements


2.16.1.1 The project shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including models used to generate the software. [JSWE-147]

Rationale: Without requirements for reusability, projects will miss opportunities to design reuse into their products early in the life cycle.


When Class




Note: Reusability requirements may be documented via “shoulds” in the SRS to use and create reuse libraries and patterns.





JPR No. 7150.2A




2.16.2 Reusability Contribution


2.16.1.2 The project shall evaluate its own software for potential reuse by other projects across the Agency and contribute reuse candidates to the Agency Software Catalog. [JSWE-148]

Rationale: Without a focus on reuse for outside projects, there will be duplication of effort across projects and a missing opportunity for adopting best of class solutions for common problems in software development.


When Class




Note 1: The Agency Software Catalog is maintained as a part of the NASA Technology Transfer Portal. Each software code listed in the catalog is evaluated for access requirements and restrictions per the software release process (see http://technology.nasa.gov/ and NPR 2210.1).

Note 2: The JSC SEPG will coordinate the contribution of reuse candidates from JSC to the Agency Catalog on an annual basis.





JPR No. 7150.2A




2.17 Free and Open Source

Free and Open Source Software (FOSS) is off-the-shelf software that is licensed to allow distribution, use, and redistribution of the software source code, including modifications. There are many different types of FOSS licenses, though any software license that has been approved by the Open Source Initiative (OSI) allows, at a minimum, use, modification and redistribution of the source code for any purpose. Most FOSS licenses allow the software to become closed source and do not require that the source code and any modifications be redistributed, while other FOSS licenses require that the source code and any modifications be made available to whomever the end product is distributed to. Many FOSS projects are supported by multiple commercial organizations directly, and because the software is available for modification, a particular software project can also be supported by new vendors or directly by NASA where appropriate. Leveraging FOSS in NASA software requires understanding of the architecture and implementation of the FOSS, its technical merit, and a legal review of its use related to licensing and intellectual property.





JPR No. 7150.2A




2.17.1 Free and Open Source


2.17.1.1 The project shall ensure that when a FOSS component is acquired or used, the following conditions are satisfied. [JSWE-149]

a. The requirements that are to be met by the software component are identified.

b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).

c. Proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed.

d. Future support for the software product is planned and adequate for project needs.

e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.

Rationale: (a) The requirements should be identified so that (1) the current OSS component can be accepted if it meets the requirements, (2) when the OSS component is updated, the update can be accepted if it still meets the requirements, and (3) if the OSS component is discontinued, a different component can be selected that meets the requirements. (b) The users must have sufficient documentation to use the software. (c) NASA must comply with licenses and must respect intellectual property rights. (d) Support plans must be adequate for the project needs. (e) OSS components should be tested just like any other component to ensure that they meet requirements and expectations.


When Class




X

Implement JSWE-149 as written for safety-critical portions of the software only.

Note 1: It is important to understand that under copyright law, OSS is a form of commercial software that needs to be treated with the same respect as any other commercial software.





JPR No. 7150.2A




For this reason, it is important to understand both the specifics of the DOAA license in question and how the project intends to use and redistribute any modified FOSS. It is the project's responsibility for both commercial and FOSS to verify that the Government receives sufficient rights in any source or executable code, libraries, or "building blocks" (COTS/GOTS/MOTS & FOSS) to meet the project's needs along with any anticipated further Government applications. This may include verifying that the license does not contain any undesired requirements or restrictions on redistribution, modification and release, etc. Seek guidance from your Center Office of Chief Counsel for help in making these determinations.

Note 2: Condition (e)’s reference to verifying at the same level is meant for the rigor of

verification of the feature in use, not features of the FOSS that are not being used by the product.





JPR No. 7150.2A




2.17.2 Free and Open Source Notification


2.17.2.1 The project shall require the software supplier(s) to notify the project, in the response to the solicitation, as to whether or not FOSS software will be included in code developed for the project. [JSWE-041]

Rationale: Failure to meet this requirement may allow the introduction of unauthorized and potentially harmful code into the system. Identifying up front gives the project manager the opportunity to evaluate its effects.


When Class





Note: Refer to definition of “Perspective of the Supplier” for project/supplier clarification.





JPR No. 7150.2A




2.18 Computing System Safety and Security

A central and critical aspect of the computer security problem is a software problem. Software defects with security ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling. Security requirements for the acquisition, development, integration, and modification of ground software systems are found in NPR 2810.1

2.18.1 Software Security Risks


2.18.1.1 The project shall ensure that security risks to software systems are identified and security risk mitigations are planned for these systems in the Project Protection Plan. [JSWE-154]

Rationale: Space flight software systems have unique security risks; software aspects of these risks should be mitigated.


When Class



X X X X X X X XX

Implement JSWE-154 as written.

X X

Implement JSWE-154 as written for software flown in space.

Note: The Project Protection Plan can be combined with the Risk Management Plan.





JPR No. 7150.2A




2.18.2 Software Security Risk Mitigations


2.18.2.1 The project shall implement the identified software security risk mitigations addressed in the Project Protection Plan. [JSWE-155]

Rationale: Planning risk mitigations is not sufficient; the risk mitigations must actually be implemented.


When Class




X X






JPR No. 7150.2A




2.18.3 Software Security Risk Evaluation


2.18.3.1 The project shall ensure and record that all systems are evaluated for security risks, including risks posed by the use of COTS, GOTS, MOTS, FOSS, and reused software. [JSWE-156]

Rationale: Space flight software has unique security risks; these risks should be evaluated.


When Class




X X






JPR No. 7150.2A




2.18.4 Software Security: Unauthorized Access


2.18.4.1 The project shall ensure that software systems with space communications capabilities are protected against un-authorized access. [JSWE-157]

Rationale: Space communication systems have unique security risks; these risks should be evaluated.


When Class




X X


Note: These risks should be addressed in the Project Protection Plan or the Risk Management Plan.





JPR No. 7150.2A




2.18.5 Software Security: Vulnerability Assessment


2.18.5.1 The project shall ensure that the space flight software systems are assessed for possible security vulnerabilities and weaknesses. [JSWE-158]

Rationale: Space flight software systems have unique security risks; software aspects of these risks should be mitigated.


When Class




X X Implement JSWE-158 as written for software flown in space.





JPR No. 7150.2A




2.18.6 Software Security Verification and Validation


2.18.6.1 The project manager shall verify and validate the required software security risk mitigations to ensure that security objectives identified in the Project Protection Plan for space flight software are satisfied in their implementation. [JSWE-159]

Rationale: Software systems have unique security risks; each risk mitigation should be examined to ensure that it successfully mitigates the risk as intended.


When Class




X X


Note Include assessments for security vulnerabilities during Peer Review/Inspections of software requirements and design and undergo automated security static analysis as well as coding standard static analyses of software code to find potential security vulnerabilities.





JPR No. 7150.2A




CHAPTER 3: SOFTWARE ENGINEERING (LIFE-CYCLE) REQUIREMENTS

Although this JPR does not impose a particular life-cycle model on each software project, this JPR does support a standard set of life-cycle phases. Use of the different phases of a life cycle allows the various products of a project to be gradually developed and matured from initial concepts through the fielding of the product and to its final retirement. Without recommending a life cycle, the requirements for each of these steps are provided below.

3.1 Software Requirements

Requirements provide the foundation for the entire life cycle as well as for the software product. Requirements also provide a basis for planning and estimating. Requirements are based on customer, user, and other stakeholder needs and design and development constraints. The development of requirements includes elicitation, analysis, documentation, verification, and validation. Ongoing customer validation of the requirements to ensure that the end products meet the customer’s needs is an important part of the life-cycle process. This can be accomplished via rapid prototyping and customer-involved reviews of iterative and final software requirements.





JPR No. 7150.2A




3.1.1 Software Requirements Specification


3.1.1.1 The project shall establish, capture, record, approve, and maintain the software requirements including the software quality requirements, as part of the technical specification.. [JSWE-050]

Rationale: Even for small projects, software requirements control scope creep and communicate the expected functionality of the software. For larger projects, the software requirements specification is the contract between the software development team and the rest of the organization. If the software requirements are not documented or controlled via customer approval, there is no definition of the software product, and the customer can say they expected features that were not in the delivered product (or that it had features they did not ask for).


When Class




Note 1: For some projects, the software requirements can be specified in narrative form, as part of a Concept of Operations document, or as user stories, rather than as a formal set of “shall” statements.

Note 2: Quality requirements mean reliability and maintainability, also some requirements dealing with the quality of the product (e.g., checksums).

Note 3: The content of the software requirement specifications are documented in Chapter 5.0.





JPR No. 7150.2A




3.1.2 Requirements Flow-Down


3.1.2.1 The project shall perform software requirements analysis based on flowed-down and derived requirements from the top-level systems engineering requirements and the hardware specifications and design. [JSWE-051]

Rationale: If the software requirements do not reflect the constraints of the overall system and hardware, significant rework will need to be done once the software is integrated with the hardware and surrounding system.


When Class








JPR No. 7150.2A




3.1.3 Requirements Management


3.1.3.1 The project shall collect and manage changes to the software requirements. [JSWE-053]

Rationale: If changes to the software requirements are not documented and agreed upon, there is no objective measure of functional completion of the project with the customer. This results in scope creep and cost overruns.


When Class








JPR No. 7150.2A




3.1.4 Managing Inconsistencies


3.1.4.1 The project shall identify, initiate corrective actions for, and track until closure inconsistencies among requirements, project plans, and software products. [JSWE-054]

Rationale: Failure to meet this requirement could result in products with errors even though inconsistencies were found by the team.


When Class








JPR No. 7150.2A




3.1.5 Expectation Validation


3.1.5.1 The project shall perform requirements validation to ensure that the software will perform as intended in the customer environment. [JSWE-055]

Rationale: If the customer does not review the software requirements, misinterpretation of the customer’s intent will result in rework once users begin working with the software product.


When Class




X






JPR No. 7150.2A




3.2 Software Architecture

Experience confirms that the quality and longevity of a software-reliant system is largely determined by its architecture. The software architecture underpins a system's software design and code; it represents the earliest design decisions, ones that are difficult and costly to change later. The transformation of the derived and allocated requirements into the software architecture results in the basis for all software development work. A software architecture:

a. Formalizes precise subsystem decompositions. b. Defines and formalizes the dependencies among software work products within the

integrated system. c. Serves as the basis for evaluating the impacts of proposed changes. d. Maintains rules for use by subsequent software engineers that ensure a consistent

software system as the work products evolve. e. Provides a stable structure for use by future groups through the documentation of the

architecture, its views and patterns, and its rules. f. Follows strategies created by the NASA Space Asset Protection Program to protect

mission architectures.





JPR No. 7150.2A




3.2.1 Software Architectural Design


3.2.1.1 The project shall develop and record the software architecture. [JSWE-057]

Rationale: If there is no architecture of the software components, the dependency among software components and external interfaces cannot be communicated. This results in rework caused by integration issues due to misunderstandings among the system engineers and software developers.


When Class




X

Transform the allocated and derived requirements into an informally documented software architectural design.

Rationale: An architecture does not need to be a formal document but simply a representation of the intended system.






JPR No. 7150.2A




3.2.2 Software Architectural Review


3.2.2.1 The project shall perform a software architecture review on the following categories of projects: [JSWE-143]

a. Category 1 Projects as defined in NPR 7120.5

b. Category 2 Projects as defined in NPR 7120.5 that have Class A or Class B

payload risk classification per NPR 8705.4.

Rationale: A review of the software architecture should identify issues that otherwise would be discovered later in the life cycle and incur substantial costs to correct on such large projects.


When Class




Note 1: NPR 7120.5 defines Category 1 projects to be those with a life cycle cost of greater than $1 billion, require significant radioactive material, or are associated with human space flight.

Note 2: NPR 7120.5 defines Category 2 projects to be those with a life cycle cost of greater than $250 million or whose importance to NASA is high.





JPR No. 7150.2A




3.3 Software Design

Software design is the process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements. The software architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. The software architectural design is concerned with creating a strong overall structure for software entities that fulfill allocated system- and software-level requirements. Typical views captured in an architectural design include the decomposition of the software subsystem into design entities, CSCI, definitions of external and internal interfaces, dependency relationships among entities and system resources, and finite-state machines. Detailed design further refines the design into lower-level entities that permit the implementation by coding in a programming language. Typical attributes that are documented for lower-level entities include: identifier, type, purpose, function, constraints, subordinates, dependencies, interface, resources, processing, and data. Rigorous specification languages, graphical representations, and related tools have been developed to support the evaluation of critical properties at the design level. Projects are encouraged to take advantage of these improved design techniques to prevent and eliminate errors as early in the life cycle as possible.





JPR No. 7150.2A




3.3.1 Software Design NPR 7150.2 [SWE-056] is the parent requirement.

3.3.1.1 The project shall establish and maintain the software design [JSWE-056]

Rationale: If the software design is not clearly communicated to the involved parties, developers may implement the requirements in a way that results in rework because the software either does not address project constraints or does not meet performance, security, or external interface requirements.


When Class




X

Implement JSWE-056 for safety critical portions of the software only.


Note 2: The content of the software design is documented in Chapter 5.0.





JPR No. 7150.2A




3.3.2 Detailed Design


3.3.2.1 The project shall develop, record, and maintain a design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested. [JSWE-058]

Rationale: For large or complex projects, the design provides the implementation planning of decomposed requirements so the team knows the approach that is being taken and maintenance staff can understand the functionality and original assumptions for each software unit. Without this, there will be misunderstandings and incorrect implementation of the high-level design, resulting in rework and missed schedule milestones.


When Class




X


Rationale: Safety-critical functionality will be able to be rigidly documented to provide assurance of its proper implementation.






JPR No. 7150.2A




3.4 Software Implementation

Software implementation consists of implementing the requirements and design into code, data, and documentation. Software implementation also consists of following coding methods and standards. Unit testing is also a part of software implementation (unit testing can also be conducted during the testing phase).





JPR No. 7150.2A




3.4.1 Design into Code


3.4.1.1 The project shall implement the software design into software code. [JSWE-060]

Rationale: While not precluding prototyping exploration, a design communicates the framework of functions, internal and external interfaces, and constraints, helping to identify issues prior to implementation of the code. Without this, there will be misunderstandings and incorrect implementation of the high-level design, resulting in rework and missed schedule milestones.


When Class









JPR No. 7150.2A




3.4.2 Coding Standards


3.4.2.1 The project shall select, adhere to, and verify software coding methods, standards, and/or criteria.

[JSWE-061]

Rationale: Adherence to and review of standards allow work product review to be a repeatable process. Without this, products of varying quality will either include defects or have inconsistent coding styles that will hamper maintenance of the software.

The "and/or" in the text of the requirement statement is meant for flexibility in tailoring the requirement to the needs of the project. In appropriate settings (e.g., less "critical") a subset of this list (the "or" in "and/or") would be sufficient and compliant. For human-rated applications, the project would want to cover each of the items (methods, standards, criteria) in the statement (the "and" in "and/or"; e.g., the use of Klockwork tool as part of the "method," MISRA C "standards," avoidance of the project's restricted language constructs "criteria," etc).


When Class




X







JPR No. 7150.2A




3.4.3 Static Analysis Tools


3.4.3.1 The project shall verify the software code by using the results from static analysis tool(s. [JSWE-135]

Rationale: Static analysis tools allow work product review to be a repeatable process. Without this, products of varying quality will either include defects or have inconsistent coding styles that will hamper maintenance of the software.


When Class




X


Rationale: Safety-critical functionality will be able to be assessed in a repeatable manner to provide assurance of its proper implementation.

Note: The project determines what constitutes static analysis.





JPR No. 7150.2A




3.4.4 Unit Testing


3.4.4.1 The project shall unit test the software code per the plans for software testing. [JSWE-062]

Rationale: Requirement verification of integrated components will need to be redone if the individual components do not execute as expected. The unit test plan specifies what functionality to ensure coverage of the unit testing.


When Class









JPR No. 7150.2A




3.4.5 Version Description Document


3.4.5.1 The project shall provide a Version Description Document (VDD) for each software release. [JSWE-063]

Rationale: Without a VDD, there is no way to know the capabilities and issues of the delivered executable product.


When Class





Note 2: The content of the VDD is documented in Chapter 5.0.





JPR No. 7150.2A




3.4.6 Validating and Accrediting Software Tools


3.4.6.1 The project shall validate and accredit software tool(s) required to develop or maintain software when software development tools are used to develop or maintain Class A, Class B, Class C, or safety-critical software. [JSWE-136]

Rationale: A project will validate its software development tools (compilers, debuggers, code generators, test tools, etc.) prior to code construction; otherwise, software tool-induced defects caught in testing will cause a work stoppage awaiting either an update or release of a new software development tool. There could be software tool-induced defects that are not caught in testing but impact the execution of the software product during operations. Without accreditation, a project may apply a tool for a purpose for which it is not acceptable.


When Class




X



Note 2: Class F/G is included with this JSWE to conform with the NPR. No Class F/G project should come across this issue since it is the responsibility of the Class A/B/C project to accredit the Class F/G tool it is using, not the Class F/G project.





JPR No. 7150.2A




3.5 Software Testing

The purpose of testing is to verify the software functionality and remove defects. Testing verifies the code against the requirements and the design to ensure that the requirements are implemented. Testing also identifies problems and defects that are corrected and tracked to closure before product delivery. Testing also validates that the software operates appropriately in the intended environment.





JPR No. 7150.2A




3.5.1 Software Plans, Procedures, and Reports


3.5.1.1 The project shall establish and maintain the following: [JSWE-065]

a. Software test plan(s)

b. Software test procedure(s)

c. Software test report(s)

Rationale: Failure to establish these plans may result in accepting software that does not fulfill its intended use.


When Class




Note: The content of each of the software test plan, software test procedures, and software test report is documented in Chapter 5.0.





JPR No. 7150.2A




3.5.2 Software Test Plan


3.5.2.1 The project shall perform software testing. [SWE-066]

Rationale: Failure to test the software may result in accepting software that does not fulfill its intended use.


When Class








JPR No. 7150.2A




3.5.3 Verifying Requirements


3.5.3.1 The project shall verify the requirement to the implementation of each software requirement. [JSWE-067]

Rationale: Failure to establish these plans may result in accepting software that does not fulfill its intended use.


When Class








JPR No. 7150.2A




3.5.4 Documenting Test Results


3.5.4.1 The project shall evaluate test results and record the evaluation. [JSWE-068]



When Class




Note: The content of the software test report is documented in Chapter 5.0.





JPR No. 7150.2A




3.5.5 Documenting Defects


3.5.5.1 The project shall document defects identified during testing and track to closure. [JSWE-069]



When Class




Note: No formal process is required; an action item spreadsheet will suffice.





JPR No. 7150.2A




3.5.6 Models, Simulations, and Analysis Tools


3.4.6.1 The project shall use validated and accredited software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment. [JSWE-070]

Rationale: Failure to use validated, and accredited software models, simulations, and analysis tools could result in inadequate qualification of flight software or flight equipment.


When Class




Note: Information regarding specific verification and validation techniques and the analysis of models and simulations can be found in NASA-STD-7009 and NASA-HDBK-7009.

Note 2: The term “qualification” is more suited for flight equipment. “Certification” is the

term most suited to Flight Software





JPR No. 7150.2A




3.5.7 Updating Test Plans and Procedures


3.5.7.1 The project shall update software test plan(s) and software test procedure(s) to be consistent with software requirements. [JSWE-071]

Rationale: Failure to keep work products synchronized with requirement updates will cause defects in the final product or defeat the purpose of controlling scope creep.


When Class








JPR No. 7150.2A




3.5.8 Targeted Platform or High-Fidelity Simulation


3.5.8.1 The project shall validate the software system on the targeted platform or high-fidelity simulation. [JSWE-073]

Rationale: Failure to validate on the targeted platform or high-fidelity simulation may result in accepting software unfit for its intended use.


When Class




X


Note: Typically, a high-fidelity simulation has the exact processor, processor performance, timing, memory size, and interfaces as the flight unit.





JPR No. 7150.2A




3.6 Software Operations, Maintenance, and Retirement

Planning for operations, maintenance, and retirement will be considered throughout the software life cycle. Operational concepts and scenarios are derived from customer requirements and validated in the operational or simulated environment. Software maintenance activities sustain the software product after the product is delivered to the customer until retirement.





JPR No. 7150.2A




3.6.1 Planning for Operations, Maintenance, and Retirement


3.6.1.1 The project shall plan for operations, maintenance, and retirement activities. [JSWE-075]

Rationale: Without a plan for post-development phases, knowledge gained during the development phase may be lost that would be beneficial to future support staff.


When Class



X X X X X Implement JSWE-075.

X X


Rationale: Errors could be introduced in software components that are safety-critical if the maintenance resources are not provided or communicated.





JPR No. 7150.2A




3.6.2 Delivering Software Products


3.6.2.1 The project shall complete and deliver the software product to the customer with appropriate records, including as-built records, to support the operations and maintenance phase of the software’s life cycle. [JSWE-077]

Rationale: Without documentation that specifies how to use the software product, seek support, and report problems, the development organization will spend excessive time walking customers through the product usage and support process.


When Class




Note: The term “Appropriate” refers to the classification of the project.





JPR No. 7150.2A




3.7 Bidirectional Traceability

Traceability of requirements throughout the project’s work products ensures that all functionality is implemented and tested as well as providing a mechanism to determine the impacts of requirements changes throughout the life of the software. Requirements should be traced from system requirements to software requirements through the design, implementation, and testing of work products. Traceability of software requirements to test cases is most critical since this provides proof of verification of the requirements.





JPR No. 7150.2A




3.7.1 Traceability between Software Requirement and Higher-Level Requirement


3.7.1.1 The project shall perform, record, and maintain bidirectional traceability between the software requirement and the higher-level requirement. [JSWE-052]

Rationale: If software requirements do not reflect the purpose of a higher-level requirement, then the result is either unnecessary functionality or missing functionality that will be discovered late in testing, resulting in potentially costly rework. Even though orphan or derived requirements may end up not having parents, tracing will help identify those requirements.


When Class




X


Rationale: Safety-critical functionality that is able to be easily traced throughout the work products provides assurance of its proper implementation.

Note: It is understood that 100% bidirectional traceability cannot be achieved due to derived/orphaned requirements. It is the intent of the requirement to provide traceability to the fullest extent possible.





JPR No. 7150.2A




3.7.2 Traceability Between Software Requirements and Software Design


3.7.2.1 The project shall perform, record, and maintain bidirectional traceability between the: [JSWE-059]

a. Software requirements and the software architecture.

b. Software architecture and the software design.

c. Software requirements and the software design.

Rationale: Traceability between the requirements, architecture, and design provides an efficient mechanism for staff unfamiliar with the software to track the impacts of changes to the requirements or the design. Without this traceability, development staff will need to walk through the design multiple times to prove all requirements are implemented.


When Class




X




Note 2: Guidance on Architecture and Design Trace: Each software requirement, each architectural element, and each design element should have a unique identifier to facilitate this traceability. The project should maintain three traceability matrices to meet this SWE: (1) a table showing the relationships between requirements and architectural elements, (2) a table showing the relationships between architectural elements and design elements, and (3) a table showing the relationships between requirement and design elements. These are separate from the traceability matrices describe in JSWE-052, JSWE-064, JSWE-072 and separate from the compliance matrix described in Appendix F.





JPR No. 7150.2A




3.7.3 Traceability Between Software Design and Software Code


3.7.3.1 The project shall perform, record, and maintain bidirectional traceability between the software design and the software code. [JSWE-064]

Rationale: For complex projects, functionality is easier to monitor if the source code is traced to the requirements via the design. This identifies scope creep as well as aids in compliance with requirements.


When Class




X X




Note 2: Tracing design to code may be limited to the CSCI or CSC level. The design should already be tied to CSCIs.





JPR No. 7150.2A




3.7.4 Traceability between Software Test Procedures and Software Requirements


3.7.4.1 The project shall perform, record, and maintain bidirectional traceability between the Software Test Procedures to the software requirements. [JSWE-072]

Rationale: Failure to maintain bidirectional traceability may result in failure to test requirements completely.


When Class




X

Establish and maintain traceability from the Software Test Procedures to the software requirements. [JSWE-072]





JPR No. 7150.2A




A summary of the bi-directional traceability process requirements and their applicability to the various classes of software is shown below.

TABLE 3-30 SUMMARY OF JSWE-052, 059, 064, AND 072

When Requirement

Then Perform Trace



JSWE-052 – Trace between Software Requirements and System Requirements

X X X X X X X X X

JSWE-059 – Trace between Software Requirements and Software Design

X X X X X X X X X

JSWE-064 – Trace between Software Design and Software Code

X X X X X X X X X

JSWE-072 – Trace between Software Requirements and Software Test Procedures

X X X X X X X X X





JPR No. 7150.2A




CHAPTER 4: SUPPORTING SOFTWARE LIFE-CYCLE REQUIREMENTS

Support processes are not limited to a single software life-cycle phase, such as requirements, design, implementation, or test. Support processes typically occur throughout the software life cycle. For example, typical configuration management baselines (e.g., requirements, code; products) happen across the life cycle. Support processes are software management and engineering processes that typically support the entire software life cycle (e.g., configuration management).

4.1 Software Configuration Management

Software configuration management is the process of applying configuration management throughout the software life cycle to ensure the completeness and correctness of software configuration items. Software configuration management applies technical and administrative direction and surveillance to identify and document the functional and physical characteristics of software configuration items, to control changes to those characteristics, to record and report change processing and implementation status, and to verify compliance with specified requirements. Software configuration management establishes and maintains the integrity of the products of a software project throughout the software life cycle. A project (or higher level) configuration management plan can encompass the processes necessary for the software configuration management. Use of standard Center or organizational software configuration management processes and procedures is encouraged where applicable.





JPR No. 7150.2A




4.1.1 Software Configuration Management Plan


4.1.1.1 The project shall develop a software configuration management plan that describes the functions, responsibilities, and authority for the implementation of software configuration management for the project. [JSWE-079]

Rationale: Configuration management allows a project to ensure that the content of the delivery is known, correct, and documented. Without an SCM plan, the project cannot ensure software changes are made in a controlled manner.


When Class




X


Note: The content of the SCMP is documented in Chapter 5.1.





JPR No. 7150.2A




4.1.2 Tracking and Evaluating Changes


4.1.2.1 The project shall track and evaluate changes to software products electronically (i.e., online, not paper hardcopy). [JSWE-080]

Rationale: Without the ability to track and evaluate changes, there is no way to identify and record the resolution to a software defect or the implementation of a modification in a software item.


When Class




X

No formal process is required; an action item spreadsheet will suffice.

Note: The project should use a software change request system or a software problem-tracking system. Very small projects can use a table or spreadsheet.





JPR No. 7150.2A




4.1.3 Identifying Configuration Items


4.1.3.1 The project shall identify the configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project. [JSWE-081]

Rationale: Configuration items will be identified in order to implement configuration management effectively. Failure to identify configuration items could result in the inability to make changes in a controlled manner.


When Class




Note: All versions are controlled for software being developed but dependencies on FOSS/COTS implies specific versions.





JPR No. 7150.2A




4.1.4 Authorizing Changes


4.1.4.1 The project shall establish and implement procedures to:

[JSWE-082]

a. Designate the levels of control through which each identified configuration item is required to

pass.

b. Identify the persons or groups with authority to authorize changes

c. Identify the persons or groups with authority to make changes at each level.

Rationale: Without the proper controls and authorization, the project cannot ensure software changes are made in a controlled manner.


When Class




X


Rationale: Errors could be introduced in software components that are safety-critical if the maintenance resources are not provided or communicated.





JPR No. 7150.2A




4.1.5 Maintaining Records


4.1.5.1 The project shall establish and maintain records of the configuration status of software configuration items. [JSWE-083]

Rationale: Without records, the project cannot ensure the configuration items are controlled and that correct versions are maintained.


When Class








JPR No. 7150.2A




4.1.6 Configuration Audits


4.1.6.1 The project shall perform software configuration audits to determine the correct version of the software configuration items and verify that they conform to the records that define them.. [JSWE-084]

Rationale: Audits are required to ensure the integrity of the artifacts. Without configuration audits, the project cannot ensure software changes are made in a controlled manner.


When Class




X






JPR No. 7150.2A




4.1.7 Implementing Procedures


4.1.7.1 The project shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products. [JSWE-085]

Rationale: Mishandling of deliverable software products is a common source of delivery defects and should be a repeatable process that is easily documented.


When Class








JPR No. 7150.2A




4.2 Risk Management

Identification and management of risks provide a basis for systematically examining changing situations over time to uncover and correct circumstances that impact the ability of the project to meet its objectives.





JPR No. 7150.2A




4.2.1 Continuous Risk Management


4.2.1.1 The project shall identify, analyze, plan, track, control, communicate, and document software risks in accordance with NPR 8000.4 and the project’s risk management plan. [JSWE-086]

Rationale: Failure to exercise proper risk management could result in danger to the public, workers, or environment. It may also result in program/project failures and large financial losses.


When Class




X


X X Address known risks.

Note: A project should assess the risk that any untested code poses to the system or subsystem.





JPR No. 7150.2A




4.3 Software Peer Reviews/Inspections

Software peer reviews and inspections are the in-process technical examination of work products by peers to find and eliminate defects early in the life cycle. Software peer reviews/inspections are performed following defined procedures covering the preparation for the review, conducting the review itself, documenting results, reporting the results, and certifying the completion criteria. When planning the composition of a software peer review/inspection team, consider including software testing, system testing, software assurance, software safety, and software Independent Verification and Validation (IV&V) personnel (where IV&V is levied).





JPR No. 7150.2A




4.3.1 Peer Reviews/Inspections of Software Requirements, Test Plan, and Code


4.3.1.1 The project shall perform and report the results of software peer reviews or software inspections for: [JSWE-087]

a. Software requirements

b. Software test plan

c. Any design items that the project identified for software peer review/inspections according to the software development plans.

d. Software code as defined in the software and/or project plans.

e. Software test procedures.

Rationale: Peer reviews are a mechanism for early detection of problems with software products. Failure to report peer review results deprives management of early insight into software product quality.


When Class




X



Note 2: The content of Software peer review/inspection report is documented in Chapter 5.0.

Note 3: Guidelines for software code peer reviews/inspections are contained in NASA-STD-2202-93, NASA Software Formal Inspection Standard.

Note 4: For Class G software projects that do not have test procedures, the approach to testing should be peer reviewed.





JPR No. 7150.2A




4.3.3 Checklists, Criteria, Tracking, and Participants


4.3.3.1 The project shall, for each planned software peer review/inspection,: [JSWE-088]

a. Use a checklist or formal reading technique (e.g., perspective based reading) to evaluate the work products.

b. Use established readiness and completion criteria.

c. Track actions identified in the reviews until they are resolved.

d. Identify required participants.

Rationale: Peer reviews are a mechanism for early detection of problems with software products. Failure to perform properly conducted peer reviews or track defects introduces the risk that problems will go undetected until late in the life cycle when they are more expensive to correct.


When Class




X








JPR No. 7150.2A




4.3.4 Basic Measurements


4.3.4.1 The project shall, for each planned software peer review/inspection, record basic measurements. [JSWE-089]

Rationale: Peer reviews are a mechanism for early detection of problems with software products. Failure to report peer review results deprives management of early insight into software product quality.


When Class




X Implement JSWE-089 as written for safety-critical

portions of the software only.


Note 2: Refer to the JSC SEPG Process Asset Library (PAL)for a minimum list of measurements to be recorded. Specific measurements will be defined and agreed upon by the project and stakeholders.






JPR No. 7150.2A




4.4 Software Measurement

Software measurement programs at multiple levels are established to meet measurement objectives. The requirements below are designed to establish measurement programs at the project and the Mission Directorate levels to assist in managing projects, assuring quality, and improving software engineering practices. Project-level and Mission Directorate/Mission Support Office-level (product line) measurement programs are designed to meet the following high-level goals:

a. To improve future planning and cost estimation.

b. To provide realistic data for progress tracking.

c. To provide indicators of software quality.

d. To provide baseline information for future process improvement activities.

Additional measures can be defined by either the projects or the Mission Directorate/Mission Support Office, based on any additional high-level goals they may have.





JPR No. 7150.2A




4.4.1 Measurements


4.4.1.1 The project shall establish, record, maintain, report, and utilize software management and technical measurements. [JSWE-090]

Rationale: Management and technical measurements provide a measure of relative project performance. Failure to establish and document specific measurements will result in failure to collect critical performance data or the expenditure of resources to collect unneeded data.


When Class




X



Note 2: Suggested software management and technical measurements are:

Software progress meets schedule.

Design implements software functionality.

Defects are documented, prioritized, tracked, trended, and addressed.

Software requirements are mature.

Software characteristics have been determined.

The results of software product milestones (e.g., inspection and test, reviews) are recorded for management insight. (from CMMI-DEV, PMC, GP 2.10)

The results of software assurance activities (e.g., contractor/subcontractor surveys, audits) are recorded for management insight. (from CMMI-DEV, PPQA, GP 2.10)





JPR No. 7150.2A




4.4.2 Analyzing Data


4.4.2.1 The project shall analyze software measurement data collected using documented project-specified and/or Center/organizational analysis procedures. [JSWE-093]

Rationale: Failure to analyze measurement data properly may result in making management and development decisions on the basis of flawed data.


When Class




X X


X X

Analyze software measurement data collected. Rationale: For Class C and G projects, the repeatability of metrics analysis methods is not required, though suggested.






JPR No. 7150.2A




4.4.3 Reporting Results


4.4.3.1 The project shall provide access to the software measurement data, measurement analyses and software development status as requested to the sponsoring Mission Directorate, the NASA Chief Engineer, Center and Headquarters S&MA, and Center repositories.. [JSWE-094]

Rationale: Failure to provide access to measurement data may result in making uninformed management and development decisions. Each Center needs a complete view of its

projects’ product and process measures to make informed decisions.


When Class




X







JPR No. 7150.2A




CHAPTER 5: SOFTWARE DOCUMENTATION REQUIREMENTS

This section lists the required work products for software projects. NPR 7150.2 [SWE-153] is the parent requirement.

5.1 The designated Engineering Technical Authority(s) shall define the content requirements for software documents or records [JSWE-153]

Rationale: Without templates conforming to a standard, projects will spend unnecessary resources trying to adhere to those standards.


When Class




The required content based on class is reflected in the work product templates found in the JSC SEPG Process Asset Library (PAL). These work product templates are stored in the JSC SEPG PAL and the PALs of the directorates. Use these resources to simplify the process of creating work products. The JSC SEPG PAL may be found from the JSC SEPG Web site https://oasis.jsc.nasa.gov/teams/jscsepg/. The PAL in listed on the left navigation.

The software engineering products or electronic data needed for software development are listed below. Typical names for those data products (or equivalent) are:

Software Plans

a. Software Development Plan/Software Management Plan. b. Software Schedule. c. Software Cost Estimate. d. Software Configuration Management Plan. e. Software Test Plans. f. Software Maintenance Plan. g. Software Assurance Plan(s). h. Project Protection Plan i. Software Safety Plan, if safety-critical software.

Software Requirements and Product Data


https://oasis.jsc.nasa.gov/teams/jscsepg/




JPR No. 7150.2A




a. Software Requirements Specification. b. Software and Interface Design Description (Architectural Design). c. Software Design Description. d. Record of Software Engineering Trade-off Criteria & Assessments (make/buy decision). e. Software Data Dictionary. f. Software Test Procedures. g. Software User's Manual. h. Software Version Description Reports. i. Software Acceptance Criteria and Conditions. j. Programmer's/Developer's Manual.

Software Reports

a. Software Measurement Analysis Results. b. Software Change Reports. c. Software Test Reports. d. Records of Continuous Risk Management for Software. e. Software Status Reports. f. Software Reuse Report.





JPR No. 7150.2A




CHAPTER 6 RECORDS

Records Description Originator Custodian Retention Schedule

Software Project Documentation meeting requirements for Permanent Retention

Project Team

Project Manager or Records Custodian as designated by the Project Manager

AFS#8000, 8/101: Permanent. Cut off records at close of Program/Project or in 3-year blocks for longer term Programs/Projects. Transfer to National Archives 7 years after cutoff.

Software Project Documentation meeting requirements for Temporary Retention

Project Team

Project Manager or Records Custodian as designated by the Project Manager

AFS#8000, 8/103: Temporary. Cut off records at close of Program/Project or in 5-year blocks. Destroy/Delete between 0 and 30 years after cutoff as designated by the Project Manager.





JPR No. 7150.2A




APPENDIX A. TERMS AND DEFINITIONS

The following terms appear in this document:

TERM DEFINITION

Acceptance Testing Tests to determine that a part, component, subsystem, or system is capable of meeting performance requirements over the environmental and operating ranges prescribed in the specification documents.

Accredit The official acceptance of a software tool, model, or simulation (including associated data) to use for a specific purpose.

Accreditation Endorsement or formal assurance that a tool, model, simulation, etc. meets certain standards (characteristics) and is approved for use. Usually follows a qualification process.

Accreditation Certification

A formal declaration by the Accreditation Authority that a system is approved to operate in a particular manner using a prescribed set of safeguards.

Analysis The post-processing or interpretation of the individual values, arrays, files of data, or execution information. It is a careful study of something to learn about its parts, what they do, and how they are related to each other

Application Application software (an application) is a set of computer programs designed to permit the user to perform a group of coordinated functions, tasks, or activities. Application software cannot run on own but is dependent on system software to execute.

Audit Formal review to assess compliance with hardware or software requirements, specifications, baselines, safety standards, procedures, instructions, source code, and contractual and licensing requirements.

Baseline A specification or product that has been reviewed formally and agreed upon that thereafter serves as the basis for further development and that can be changed only through formal change control procedures.





JPR No. 7150.2A




TERM DEFINITION

Bidirectional Traceability The ability to trace both forward and backward (i.e., from requirements to end products and from end product back to requirements). This traceability is required to ensure that all requirements are addressed, and that only what is required is developed.

Association among two or more logical entities that is discernible in either direction (to and from an entity). (ISO/IEC/IEEE 24765 Systems and software engineering-Vocabulary)

Certification Legal recognition by the certification authority that a product, service, organization or person complies with the applicable requirements. Such certification comprises the activity of checking the product, service, organization or person and the formal recognition of compliance with the applicable requirements by issue of a certificate, license, approval, or other document as required by national law or procedures.

In particular, certification of a product involves:

a. the process of assuring the design of a product to ensure that it complies with a set of standards applicable to that type of product so as to demonstrate an acceptable level of safety;

b. the process of assessing an individual product to ensure that it conforms with the certified type design;

c. the issue of any certificate required by national laws to declare that compliance or conformity has been found with applicable standards in accordance with items (a) or (b) above.

Change Request A form completed by users describing changes or additions to the requirements of a project.

Commercial Off-The- Shelf (COTS) Software

Operating systems, libraries, applications, and other software purchased from a commercial vendor. Not customized for a particular project. Access to source code and documentation are often limited.





JPR No. 7150.2A




TERM DEFINITION

Complex Electronics Programmable and designable complex integrated circuits. “Programmable” logic devices can be designed by the user and range from simple chips to complex devices. Some types of these devices are:

Complex Programmable Logic Devices (CPLD)

Field Programmable Gate Arrays (FPGA)

Application Specific Integrated Circuit (ASIC)

System-on-Chip (SoC)

In-field or reconfigurable SoC

FPGA microprocessor/systems

Reconfigurable computing

Complex electronics may include use of software as part of their design. Corporations developing complex electronics may have corporate best practices that do not use software development processes in the development of the complex electronics. These best practices recognize the different development methodologies used in developing complex electronics as compared to software.

Component See Computer Software Component (CSC).

Computer Functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations

Computer Software Component (CSC)

A constituent element of a system or subsystem. Consists of one or more Computer Software Units (CSU). Components can be classes, libraries, a well-defined subset of functionality, etc. CSCs can be separate processes, threads, etc.

Computer Software Configuration Item (CSCI)

A configuration item for computer software. Consists of one or more Computer Software Components (CSC) and is equivalent to a system or subsystem.

An aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process

Computer Software Unit (CSU)

A unit is the smallest part of software such as a group of functions, procedures, subroutines, etc., in procedural programming and methods in object-oriented programming. This is usually implemented as a single source code file and its associated header file.





JPR No. 7150.2A




TERM DEFINITION

Computer System A system containing one or more computers and associated software. (Source: ISO/IEC/IEEE 24765 Systems and software engineering-Vocabulary)

Configuration Item An aggregation of hardware, software, or both that is established and baselined, with any modifications tracked and managed. [Based on IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology] Examples include requirements document, Use Case, or unit of code.

Configuration Management (CM)

The electronic and/or procedural means of tracking software through a defined directory structure or CM tool and promotion process in the development and operational environments.

Contract A mutually binding legal relationship obligating the seller to furnish the supplies or services (including construction) and the buyer to pay for them. In addition to bilateral instruments, contracts include, but are not limited to, awards and notices of awards; job orders or task letters initiated under basic ordering agreements; letter contracts; orders, such as purchase orders, under which the contract becomes effective by written acceptance or performance; and bilateral contract modifications.

Contracted Software Software created for a project by a contractor or subcontractor. Process requirements and safety analyses may be included. This is custom-made but not in-house software.

Control System A system that controls the physical output of a larger system, (e.g., electrical, mechanical, thermal, or hydraulic). A control system takes inputs (e.g., sensor data), and provides a responding output that effects a physical response (e.g., valve or pump operation). Examples: Climate control, GNC, Command and control.





JPR No. 7150.2A




TERM DEFINITION

Catastrophic Hazard Any condition which may cause a disabling or fatal personnel injury, or cause loss of one of the following: the Orbiter, ISS or major ground facility. Loss of ISS: Loss of the ISS is to be limited to those conditions resulting from failures or damages to elements in the critical path of the ISS that render the ISS unusable for further operations, even with contingency repair or replacement of hardware, or which render the ISS in a condition which prevents further rendezvous and docking operations with ISS launch elements. (From SSP 50038 Revision B)

Configuration Audits Provide an independent evaluation of a software product's configuration items to confirm that all components in the as-built version map to their specifications. Specifically, this audit is held to verify that the software and its documentation are internally consistent.

Critical Hazard Any condition which may cause a non-disabling personnel injury, severe occupational illness; loss of a ISS element, on-orbit life sustaining function or emergency system; or involves damage to the Orbiter or a major ground facility. For safety failure tolerance considerations, critical hazards include loss of ISS elements that are not in the critical path for station survival or damage to an element in the critical path which can be restored through contingency repair. (From SSP 50038 Revision B)

Critical to Success In a lean, Class D environment, processes that are not critical to the success of a project do not need to be specified or measured. In this context, “critical to success” is defined as a process that the final acceptance by the customer is dependent upon.

Customer Any individual, organization, or other entity to which a program or project provides a product(s) and/or service(s).

Data Information for computer processing (e.g., numbers, text, images, and sounds in a form that is suitable for storage in or processing by a computer).

Dependability Dependability is the trustworthiness of a computing system that allows reliance to be justifiably placed on the service it delivers. Dependability includes reliability, availability, safety, and security.





JPR No. 7150.2A




TERM DEFINITION

Derived Requirement A derived requirement is one that was not explicitly stated by a stakeholder but has been found to be necessary as part of the requirements analysis process. Derived requirements are inferred during the design process and normally result from some trade-off study as part of the functional and physical design processes.

Deviation A documented authorization releasing a program or project from meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented.

Embedded Computer System

Software that is part of a larger system and performs some of the requirements of that system. (Source: ISO/IEC 24765 Systems and software engineering- Vocabulary)

Establish and Maintain Formulation, documentation, use/deployment, and current maintenance of the object (usually a document, requirement, process, or policy) by the responsible project, organization, or individual.

Facility Software In the context of determining software classes, facility software is defined as software upon which the laboratory is dependent for operations.

Failure Inability of a system, subsystem, component, or part to perform its required function within specified limits.

Firmware A term used to describe a subset of software. The combination of a hardware device and computer instructions and data that reside as read-only software on that device.

Notes: (1) This term is sometimes used to refer only to the hardware device or only to the computer instructions or data, but these meanings are deprecated. (2) The confusion surrounding this term has led some to suggest that it be avoided altogether. (3)For the purposes of JPR 7150, JSC does not consider logic design that defines logic gate configurations in a programmable logic device (including FPGA intellectual property) and does not execute in a computer-processing element. However, software residing within the CPU on an FPGA is still considered software (From IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology)

The documentation of these programs and data are also considered part of the software or firmware.





JPR No. 7150.2A




TERM DEFINITION

FOSS Computer software that can be classified as both free software and open-source software.

Glueware Software created to connect the off-the-shelf software/reused software with the rest of the system. It may take the form of "adapters" that modify interfaces or add missing functionality, "firewalls" that isolate the off-the-shelf software, or "wrappers" that check inputs and outputs to the off-the-shelf software and may modify to prevent failures.

Government Off-The- Shelf (GOTS) Software

This refers to government-created software, usually from another project. The software was not created by the current developers (see software reuse). Usually, source code is included and all documentation, including test and analysis results, is available. That is, the government is responsible for the GOTS software to be incorporated into another system.

Highly Specialized Information Technology

Highly Specialized IT is a part of, internal to, or embedded in a mission platform. The platform's function is enabled by IT but not driven by IT itself (e.g., computer hardware and software to automate internal functions of a spacecraft or spacecraft support system such as spacecraft control and status, sensor signal and data processing, and operational tasking.) Highly Specialized IT acquisitions may include full development to modification of existing systems where information technology is not an issue. Real time is often critical — and few opportunities exist to use

Commercial Off The Shelf or Government Off The Shelf beyond microprocessors and operating systems because these systems are largely unprecedented or largely unique applications. Certain IT considered Mission Critical because the loss of which would cause the stoppage of mission operations supporting real—time

on—orbit mission operations is identified as "Highly Specialized"

by the Directorate Associate Administrator. Highly Specialized IT is largely custom, as opposed to COTS or commodity IT systems or applications, and includes coding/applications that are integral parts of the research or science requirements, e.g., Shuttle Avionics Upgrade. Common engineering IT tools such as Product Life cycle Management (PLM) systems, Computer-Aided Design systems, and collaborative engineering systems and environments are not Highly Specialized IT. Representative examples of Highly Specialized IT include: Avionics software, real-time control systems, onboard processors, Deep Space Network, spacecraft instrumentation software, wind tunnel control system, human physiology monitoring systems, ground support environment, experiment simulators, Mission Control Center, and Launch cameras. (Source: NPR2800.1, Managing Inf. Technology)





JPR No. 7150.2A




TERM DEFINITION

Implementation The process used to deliver the products and capabilities specified in the approved program/project plan.

Independent Verification and Validation (IV&V)

Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization. (Source: ISO/IEC 24765 systems and software engineering vocabulary)

IV&V, as a part of Software Assurance, plays a role in the overall NASA software risk mitigation strategy applied throughout the life cycle to improve the safety and quality of software systems.

Interface Control Document (ICD)

An agreement between two or more organizations describing the interfaces between and/or among vehicles, facilities, systems, applications, software, and/or data.

Information Technology Any equipment or interconnected system(s) or subsystem(s) of equipment that is used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the Agency (reference FAR 2.101). (Source: NPR2800.1, Managing Information Technology)

Insight An element of Government surveillance that monitors contractor

compliance using Government-identified metrics and contracted milestones. Insight is a continuum that can range from low intensity such as reviewing quarterly reports to high intensity such as performing surveys and reviews. (Source: NPR 7123.1B)

Legacy and Heritage Software products (architecture, source code, requirements) written specifically for one project and then, without prior planning during its initial development, found to be useful on other projects. See software reuse.

Life Cycle Refers to all phases of a project: design, development, verification, production, deployment, operation, maintenance, support, decommission.

Life Cycle (COTS) If a project simply acquires a COTS product, the life cycle is generally (1) create requirements, (2) choose COTS product, (3) acquire and install COTS product, and (4) test COTS product.

Loss of Mission Failure to achieve major mission objectives





JPR No. 7150.2A




TERM DEFINITION

Major Engineering/Research Facility

Used in this document to show research, development, test, or simulation facilities representing a significant NASA investment (facilities with a Current Replace Value (CRV) equal to or greater than 50 million dollars) which contains software that supports programs and projects managed under NPR 7120.5, NPR 7120.7, or NPR 7120.8 and that have a Mission Dependency Index value equal to or greater than 70

Metric A measurement taken over a period of time that communicates vital information about a process or activity. A metric should drive appropriate action.

Mission In the context of determining software classes, mission is defined as the primary mission of the flight; not the specific software’s goal. For example, a software failure may result in the loss of an ISS experiment’s goal, but the ISS mission is not affected.

Mission Critical Item or function that should retain its operational capability to assure no mission failure (i.e., for mission success - meeting all mission objectives and requirements for performance and safety). (Source: NPR 8715.3).

Mission Success Meeting all mission objectives and requirements for performance and safety.

Model A description or representation of a system, entity, phenomena, or process. (Source: NASA-STD-7009) Only for the purpose of this document, the term "model" refers to only those models that are implemented in software.





JPR No. 7150.2A




TERM DEFINITION

Modified Off-The-Shelf (MOTS) Software

When COTS, or legacy and heritage software is reused, or heritage software is changed, the product is considered “modified”. The changes can include all or part of the software products and may involve additions, deletions, and specific alterations. An argument can be made that any alterations to the code and/or design of an off-the-shelf software component constitutes “modification”, but the common usage allows for some percentage of change before the off-the-shelf software is declared to be MOTS software. This may include the changes to the application shell and/or glueware to add or protect against certain features and not to the off-the-shelf software system code directly. Changes to source code are typically considered modifications. See off-the-shelf software.

Off-The-Shelf Software Software not developed in-house or by a contractor for the specific project now underway. The software is general purpose or developed for a different purpose from the current project. Used in practice as umbrella for COTS, GOTS, and MOTS

Open-Source Software Software where its human-readable source code is made broadly available without cost under an OSS license, which provides conditions on use, reuse, modification/improvement, and redistribution; and often where the software development, management, and planning is done publicly, or easily observable by an individual or organization not previously connected with its open source project.

Operability As applied to a system, subsystem, component, or device, is the

capability of performing its specified function(s), including the capability of performing its related support function(s).

Operational Software Software that has been accepted and deployed, has been delivered to its customer, or is deployed in its intended environment.

Organization Refers to the personnel and line management structure. It usually

refers to a discipline(s) organization (company, contract, section, branch, or division level) but not in all cases (i.e., facility, payload customers, etc.).

Orphan Requirement An orphan requirement is one that does not trace to a parent requirement. An orphan requirement is usually a derived requirement as part of the requirements analysis process.





JPR No. 7150.2A




TERM DEFINITION

Perspective of the Supplier

In Section 2.0, many of the JSWEs begin with “The project requires the software supplier(s) to …” A JSWE is from the perspective of the organization filling out the compliance matrix, even when that organization is a supplier to a higher organization. A common scenario is for contractors to implement a product for NASA using NASA processes. In this case, there is no supplier, and these JSWEs do not apply.

Primary Mission Objectives

Outcomes expected to be accomplished, which are closely associated with the reason the mission was proposed, funded, developed, and operated (e.g., objectives related to top-level requirements or their flow down).

Process Asset Library A collection of process asset holdings that may be used by an organization or project. (Source: CMMI® for Systems Engineering/Software Engineering/Integrated Product and Process Development Supplier Sourcing).

Program A strategic investment by a Mission Directorate or Mission Support Office that has a defined architecture and/or technical approach, requirements, funding level, and a management structure that initiates and directs one or more projects. A program defines a strategic direction that the Agency has identified as critical.

Project (1) A specific investment having defined goals, objectives, requirements, life-cycle cost, a beginning, and an end. A project yields new or revised products or services that directly address NASA’s strategic needs. They may be performed wholly in-house; by government, industry, or academia partnerships; or through contracts with private industry.

(2) A unit of work performed in programs, projects, and activities.

Project Plan / Project Management Plan

The document that establishes the baseline for implementation, signed by the responsible program manager, Center Director, project manager, and the MDAA, if required. Reference NPR 7120.5

Prototype System or software created for a proof of concept.





JPR No. 7150.2A




TERM DEFINITION

Qualification A test or assessment conducted by the developer executed on target (or equivalent) hardware. The objectives of the software qualification test or assessment are to obtain confirmation that the design will meet performance and operational requirements, to determine the adequacy of any corrective action indicated by previous testing, and to determine the maturity and operational readiness.

Quality Assurance A planned and systematic set of actions necessary to provide confidence that the products or services conform to documented requirements.

Regression Testing The selective retesting of a system that has been modified to ensure that any defects have been fixed and that no other previously working functions have failed or ceased to work as expected as a result of the changes.

Risk The combination of (1) the probability (qualitative or quantitative), which includes the associated uncertainty, that the space system will experience an undesired event (or sequences of events), such as internal system or component failure or an external event, and (2) the magnitude of the consequences (personnel, public, mission impacts) and associated uncertainties given that the undesired event(s) occur(s).

Risk Assessment An evaluation of a risk item that determines (1) what can go wrong, (2) how likely is it to occur, and (3) what the consequences are.

Risk Management An organized, systematic decision-making process that efficiently identifies, analyzes, plans (for the handling of risks), tracks, controls, communicates, and documents risk to increase the likelihood of achieving program/project goals. (Source: NPR 8715.3)

Safety-Critical Term describing any condition, event, operation, process, equipment, or system that could cause or lead to severe injury, major damage, or mission failure if performed or built improperly or allowed to remain uncorrected.





JPR No. 7150.2A




TERM DEFINITION

Safety-Critical Software Software is safety-critical if it meets at least one of the criteria listed in Appendix C.

Scripts A sequence of automated computer commands embedded in a program that tells the program to execute a specific procedure (e.g., files with monitoring, logic, or commands used by software to automate a process or procedure).

Simulation The imitation of the characteristics of a system, entity, phenomena, or process using a computational model. (Source: NASA-STD-7009) Only for the purpose of this document, the term "simulation" refers to only those simulations that are implemented in software.

Software Computer programs, procedures, scripts, rules, and associated documentation and data pertaining to the development and operation of a computer system. This definition applies to software developed by NASA, software developed for NASA, commercial-off-the-shelf (COTS) software, Government-off-the-shelf (GOTS) software, modified-off-the-shelf (MOTS) software, reused software, auto-generated code, embedded software, the software executed on processors embedded in Programmable Logic Devices (see NASA-HDBK-4008), and open-source software components.

Software Architecture The software architecture of a program or computing system is the structure or structures of the system which comprise software components, the properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.





JPR No. 7150.2A




TERM DEFINITION

Software Assurance The planned and systematic set of activities that ensure that software life-cycle processes and products conform to requirements, standards, and procedures. [IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology] For NASA, this includes the disciplines of Software Quality (functions of Software Quality Engineering, Software Quality Assurance, Software Quality Control), Software Safety, Software Reliability, Software Verification and Validation, and IV&V.

Software Development Life Cycle

All activities required to analyze, define, develop, test, and deliver a software product. The development life cycle ends when the software becomes operational and is accepted formally for use by the customer and/or operations. Once operational, any changes/upgrades are to be treated as reduced-scale software development life cycles, and the main activities (analyze, define, develop, test, and deliver) should apply during these maintenance activities.

Software Engineering The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software (that is, the application of engineering to software). (Source: IEEE 24765, Systems and software engineering-Vocabulary, paragraph 3.2760)

Software Hazard A hazard caused by incorrect software control of hazardous hardware. The software might be functioning correctly (according to its requirements) or in a failure mode.





JPR No. 7150.2A




TERM DEFINITION

Software Hazard Analysis

Identification and verification of adequate software controls and inhibits and the identification, analysis, and elimination of discrepancies relating to safety-critical command and control functions.

Software Item Source code, object code, control code, control data, or a collection of these items.

Software Peer Review and Inspection

A visual examination of a software product to detect and identify software anomalies, including errors and deviations from standards and specifications. (Source: IEEE 1028, IEEE Standard for Software Reviews and Audits). Refer to NASA-STD-8739.9 for guidelines for software peer reviews or inspections.

Software Reuse A software product developed for one use but having other uses or one developed specifically to be usable on multiple projects or in multiple roles on one project. Examples include, but are not limited to, COTS products, acquirer-furnished software products, software products in reuse libraries, and pre-existing developer software products. Each use may include all or part of the software product and may involve its modification. This term can be applied to any software product (such as requirements and architectures), not just to software code itself. Often, this is software previously written by an in-house development team and used on a different project. GOTS software would come under this category if the product is supplied from one Government project to another Government project.

Software Safety-Critical Software operations that, if not performed, performed out of sequence, or performed incorrectly, could directly or indirectly cause or allow a hazardous condition to exist.

Software 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.” (Source: IEEE 1012, IEEE

Standard for Software Verification and Validation)

Software Verification Confirmation that work products properly reflect the requirements specified for them. In other words, verification ensures that “you

built it right.” (Source: IEEE 1012, IEEE Standard for Software

Verification and Validation)

Source Code A set of programming language instructions that are translated into machine instructions (interpreted or compiled) before it can be run.





JPR No. 7150.2A




TERM DEFINITION

Sponsor Responsible for justifying the need, defining the requirements, ensuring the development, and completing the certification of the software.

Stakeholder An individual or organization having an interest (or stake) in the outcome or deliverable of a program or project.

Static Analysis The process of evaluating a system or component based on its form, structure, content, or documentation (definition from source document: ISO/IEC 24765:2008 Systems and software engineering vocabulary).

Status Accounting The process of creating and organizing the knowledge base necessary for the performance of configuration management. In addition to facilitating CM, the purpose of status accounting is to provide a highly reliable source of configuration information to support all program/project activities including program management, systems engineering, manufacturing, software development and maintenance, logistic support, modification, and maintenance.

Subsystem A secondary or subordinate system within a larger system. (Source: ISO/IEC 24765, Systems and software engineering-Vocabulary)

Success Criteria That portion of the top-level requirements that define what will be achieved to successfully satisfy the strategic plan objectives addressed by the program, project, or technology demonstration.

Supplier See “Perspective of the Supplier”

Surveillance The continual monitoring and verification of the status of an entity and analysis of records to ensure that specified requirements are being met. Note: Surveillance can be performed in an insight, oversight, or combined mode as determined by NASA using a risk-based decision process.

System The combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose. (Source: NPR 7123.1)





JPR No. 7150.2A




TERM DEFINITION

Tailoring The process used to adjust or seek relief from a prescribed requirement to accommodate the needs of a specific task or activity (e.g., program or project). The tailoring process results in the generation of deviations and waivers depending on the timing of the request..

Test Case Defines a specific test objective and the steps necessary to achieve that objective.

Test Plan Defines the testing process and which test procedures will be used.

Test Procedure Consists of a set of test cases that will be used to achieve a high- level test objective.

Traceability Ability to trace the history, application, or location of an entity by means of recorded identifications. [ISO 8402, 3.16] For example, requirements traceability as applied to software safety involves identifying safety-critical requirements/functions and then tracing them through design, test, acceptance, changes and upgrades, and through retirement.

Uncertainty (1) The estimated amount or percentage by which an observed or calculated value may differ from the true value. (2) A broad and general term used to describe an imperfect state of knowledge or a variability resulting from a variety of factors including, but not limited to, lack of knowledge, applicability of information, physical variation, randomness or stochastic behavior, indeterminacy, judgment, and approximation. (Source: NPR 8000.4)

Unit Test (1) Testing of individual routines and modules by the developer or an independent tester (ISO/IEC/IEEE 24765 Systems and software engineering--Vocabulary) (2) A test of individual programs or modules in order to ensure that there are no analysis or programming errors (ISO/IEC 2382-20 Information technology--Vocabulary--Part 20: System development, 20.05.05) (3) Test of individual hardware or software units or groups of related units. (ISO/IEC/IEEE 24765 Systems and software engineering--Vocabulary)

Waiver A documented authorization releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented.

Wrapper See glueware definition.





JPR No. 7150.2A




APPENDIX B. ACRONYMS

The following acronyms are used in this document:

ACRONYM FULL TERM

CM Configuration Management

CMMI Capability Maturity Model Integrated

COTS Commercial Off-The-Shelf

CSC Computer Software Component

CSCI Computer Software Configuration Item

CSMA Chief, Safety and Mission Assurance

CSU Computer Software Unit

FAR Federal Acquisition Regulation

FFRDC Federally Funded Research and Development Center

FOSS Free and Open Source Software

GOTS Government Off-The-Shelf

ICD Interface Control Document

ID Identifier

ISS International Space Station

IV&V Independent Verification and Validation

JPD JSC Policy Directive

JPR JSC Procedural Requirement

JSC Johnson Space Center

JSWE JSC Software Engineering

LC Life Cycle

MCR Mission Concept Review





JPR No. 7150.2A




ACRONYM FULL TERM

MDAA Mission Directorate Associate Administrator

MOTS Modified Off-The-Shelf

NASA National Aeronautics and Space Administration

NESC NASA Engineering and Safety Center

NPR NASA Procedural Requirement

Ops Operations

OSMA Office of Safety and Mission Assurance

OSS Open Source Software

OTS Off-The-Shelf

PDR Preliminary Design Review

PRACA Problem Reporting and Corrective Action

S&MA Safety and Mission Assurance

SCM Software Configuration Management

SCMP Software Configuration Management Plan

SEI Software Engineering Institute

SEPG Software Engineering Process Group

Sim Simulation

SRR System Requirements Review

SRS Software Requirements Specification

SSP Space Shuttle Program

STD Standard

SWE Software Engineering

V&V Verification and Validation

VDD Version Description Document





JPR No. 7150.2A




ACRONYM FULL TERM

SWE Software Engineering

V&V Verification and Validation

VDD Version Description Document

WBS Work Breakdown Structure





JPR No. 7150.2A




APPENDIX C. SOFTWARE CLASSIFICATIONS

Note 1: any software used to support engineering development efforts are classified as A-E. Classifications F-H are reserved for Business/IT infrastructure software.

Note 2: Any data needed by the software has the same classification as the software.





JPR No. 7150.2A




Class A: Human Rated Space Software Systems a. Definition: 1. Human Space Flight Software Systems1: Ground and flight software systems developed and/or operated by or for NASA needed to perform a primary mission objective of human space flight and directly interact with human space flight systems. Limited to software required to perform "vehicle, crew, or primary mission function," as defined by software that is:

a) Required to operate the vehicle or space asset (e.g., spacesuit, rover, or outpost), including commanding of the vehicle or asset,

b) Required to sustain a safe, habitable2 environment for the crew, c) Required to achieve the primary mission objectives, or d) Required to directly prepare resources (e.g., data, fuel, power) that are consumed by the above

functions.

1 Includes software involving launch, on-orbit, in space, surface operations, and entry, descent, and landing. 2 Current standards that address habitability and environmental health, including atmospheric composition and pressure, air, and water quality and monitoring, acceleration, acoustics, vibration, radiation, thermal environment, combined environmental effects, and human factors, are documented in NASA-STD-3001, Vol. 2 - NASA Space Flight Human System Standard: Human Factors, Habitability, and Environmental Health. b. Examples: Examples of Class A software (human-rated space flight) include, but are not limited to, the mission phases listed below. 1. During Launch: Abort modes and selection; separation control; range safety; crew interface (display and controls); crew escape; critical systems monitoring and control; guidance, navigation, and control; and communication and tracking. 2. On Orbit/In Space: Extra vehicular activity (EVA); control of electrical power; payload control (including suppression of hazardous satellite and device commands); critical systems monitoring and control; guidance, navigation, and control; life support systems; crew escape; rendezvous and docking; failure detection; isolation and recovery; communication and tracking; and mission operations. 3. On Ground: Pre-launch and launch operations; Mission Control Center (and Launch Control Center) front-end processors; spacecraft commanding; vehicle processing operations; re-entry operations; flight dynamics simulators used for ascent abort calls; and launch and flight controller stations for manned spaceflight. 4. Entry, Descent, and Landing (EDL): Command and control; aero-surface control; power; thermal; fault protection; and communication and tracking.





JPR No. 7150.2A




5. Surface Operations: Planet/lunar surface EVA and communication and tracking. c. Exclusions: Class A does not include:

1. Software that happens to fly in space but is superfluous to mission objectives (e.g., software contained in an iPod carried on board by an astronaut for personal use);

2. Software that exclusively supports aeronautics, research and technology, and science conducted

without space flight applications; or

3. Systems (e.g., simulators, emulators, stimulators, facilities) used to test Class A systems containing software in a development environment.





JPR No. 7150.2A




Class B: Non-Human Space Rated Software Systems or Large Scale Aeronautics Vehicles a. Definitions: 1. Space Systems involve flight and ground software that should perform reliably to accomplish primary mission objectives or major function(s) in non-human space rated systems. Included is software involving launch, on orbit, in space, surface operations, entry, descent, and landing. These systems are limited to software that is:

a) Required to operate the vehicle or space asset (e.g., orbiter, lander, probe, flyby spacecraft, rover, launch vehicle, or primary instrument) such as commanding of the vehicle or asset,

b) Required to achieve the primary mission objectives, or c) Required to directly prepare resources (data, fuel, power) that are consumed by the above

functions. 2. Airborne Vehicles include large scale1 aeronautic vehicles unique to NASA in which the software:

a) Is integral to the control of an airborne vehicle, b) Monitors and controls the cabin environment, or c) Monitors and controls the vehicle’s emergency systems.

This definition includes software for vehicles classified as “test,” “experimental,” or “demonstration” that meets the above definition for Class B software. Also included are systems in a test or demonstration where the software’s known and scheduled intended use is to be part of a Class A or B software system. 1 Large-scale (life-cycle cost exceeding $250M) fully integrated technology development system – see NPR 7120.8, section 5.1.1.1. b. Examples: Examples of Class B software include, but are not limited to: 1. Space, Launch, Ground, EDL, and Surface Systems: Propulsion systems; power systems; guidance navigation and control; fault protection; thermal systems; command and control ground systems; planetary/lunar surface operations; hazard prevention; primary instruments; science sequencing engine; simulations that create operational EDL parameters; subsystems that could cause the loss of science return from multiple instruments; flight dynamics and related data; and launch and flight controller stations for non-human space flight. 2. Aeronautics Vehicles (Large Scale NASA Unique): Guidance, navigation, and control; flight management systems; autopilot; propulsion systems; power systems; emergency systems (e.g., fire suppression systems, emergency egress systems, emergency oxygen supply systems, traffic/ground collision avoidance system); and cabin pressure and temperature control.





JPR No. 7150.2A




c. Exclusions: Class B does not include

1. Software that exclusively supports non-primary instruments on non-human space rated systems (e.g., low cost non-primary university supplied instruments), or

2. Systems (e.g., simulators emulators, stimulators, facilities) used in testing Class B systems

containing software in a development environment.





JPR No. 7150.2A




Class C: Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility Software a. Definition: 1. Space Systems include the following types of software:

a) Flight or ground software necessary for the science return from a single (non-primary) instrument, b) Flight or ground software used to analyze or process mission data, c) Other software for which a defect could adversely impact attainment of some secondary mission

objectives or cause operational problems, d) Software used for the testing of space assets, e) Software used to verify system requirements of space assets by analysis, or f) Software for space flight operations that are not covered by Class A or B software.

2. Airborne Vehicles include systems for non-large scale aeronautic vehicles in which the software:

a) Is integral to the control of an airborne vehicle, b) Monitors and controls the cabin environment, or c) Monitors and controls the vehicle’s emergency system.

Also included are systems on an airborne vehicle (including large scale vehicles) that acquire, store, or transmit the official record copy of flight or test data. 3. Major Engineering/Research Facility is systems that operate a major facility for research, development, test, or evaluation (e.g., facility controls and monitoring, systems that operate facility-owned instruments, apparatus, and data acquisition equipment). b. Examples: Examples of Class C software include, but are not limited to: 1. Space Systems: Software that supports prelaunch integration and test; mission data processing and analysis; analysis software used in trend analysis and calibration of flight engineering parameters; primary/major science data collection storage and distribution systems (e.g., Distributed Active Archive Centers); simulators, emulators, stimulators, or facilities used to test Class A, B, or C software in a development; integration and test environments (development environment, including environments used from unit testing through validation testing); software used to verify system-level requirements associated with Class A, B, or C software by analysis (e.g., guidance, navigation, and control system performance verification by analysis); simulators used for mission training; software employed by network operations and control (which is redundant with systems used at tracking complexes); command and control of non-primary instruments; and ground mission support software used for secondary mission objectives, real-time analysis, and planning (e.g., monitoring, consumables analysis, mission planning).





JPR No. 7150.2A




2. Aeronautics Vehicles: Guidance, navigation, and control; flight management systems; autopilot; propulsion systems; power systems; emergency systems (e.g., fire suppression systems, emergency egress systems, emergency oxygen supply systems, traffic/ground collision avoidance system); cabin pressure and temperature control; in-flight telescope control software; aviation data integration systems; and automated flight planning systems and primary/major science data collection storage and distribution systems (e.g., Distributed Active Archive Centers). 3. Major Engineering/Research Facility: Major Center facilities; data acquisition and control systems for wind tunnels, vacuum chambers, and rocket engine test stands; ground-based software used to operate a major facility telescope; and major aeronautic applications facilities (e.g., air traffic management systems; high fidelity motion based simulators). JSC Specific Examples of Class C Software are:

Air Quality Monitor (AQM)

CR (Centrifuge Rotor)

EUROPA (External Use of Robotics for Payload Automation)

EXPRESS Racks #1-8

Facilities: Arc Jet, Thermal Vacuum Chambers, Trainers, V&V facilities

HHR #1 (Habitat Holding Rack)

Human Research Facility (HRF)

ISS Portable Oxygen Monitor (IPOM)

OZ Payloads

Probe instrument package

Station Detailed Test Objectives (SDTOs)

Total Organic Carbon Analyzer (TOCA)

c. Exclusions: Systems unique to a research, development, test, or evaluation activity in a major engineering/research facility or airborne vehicle in which the system is not part of the facility or vehicle and does not impact the operation of the facility or vehicle.





JPR No. 7150.2A




Class D: Basic Science/Engineering Design and Research and Technology Software a. Definitions: 1. Basic Science/Engineering Design includes:

a) Ground software that performs secondary science data analysis, b) Ground software tools that support engineering development, c) Ground software used in testing other Class D software systems, d) Ground software tools that support mission planning or formulation, e) Ground software that operates a research, development, test, or evaluation laboratory (i.e., not a

major engineering/research facility), or f) Ground software that provides decision support for non-mission critical situations.

2. Airborne Vehicle Systems include:

a) Software whose anomalous behavior would cause or contribute to a failure of system function resulting in a minor failure condition for the airborne vehicle (e.g., the Software Considerations in Airborne System and Equipment Certification, DO-178B, “Class D”),

b) Software whose anomalous behavior would cause or contribute to a failure of system function with no effect on airborne vehicle operational capability or pilot workload (e.g., the Software Considerations in Airborne System and Equipment Certification, DO-178B, “Class E”), or

c) Ground software tools that perform research associated with airborne vehicles or systems. 3. Major Engineering/Research Facility related software includes research software that executes in a major engineering/research facility but is independent of the operation of the facility. b. Examples: Examples of Class D software include, but are not limited to: 1. Basic Science and Engineering Design: Engineering design and modeling tools (e.g., computer-aided design and computer-aided manufacturing (CAD/CAM), thermal/structural analysis tools); project assurance databases (e.g., problem reporting, analysis, and corrective action system, requirements management databases); propulsion integrated design tools; integrated build management systems; inventory management tools; probabilistic engineering analysis tools; test stand data analysis tools; test stand engineering support tools; experimental flight displays evaluated in a flight simulator; and tools used to develop design reference missions to support early mission planning. 2. Airborne Vehicles: Software tools for designing advanced human-automation systems; experimental synthetic-vision display; and cloud-aerosol light detection and ranging installed on an aeronautics vehicle. JSC Specific Examples of Class D Software are:





JPR No. 7150.2A




CMS Ground Software Quest Suite Professional

Customized SharePoint applications for Science and Engineering(e.g., Mission Medical Repository)

Data analysis tools and databases (PRACA)

Payloads deployed on ISS

RIAC 217 Plus (Failure Mode and Effects Analysis)

SAPHIRE

Test Stand software c. Exclusions: Class D does not include:

1. Spaceflight software (Note: that if the software flies in space it needs to be classified as A-C, even if the software is for research or to vet a design concept.).

2. Software that can impact primary or secondary mission objectives or cause loss of data that is

generated by space systems,

3. Software that operates a major engineering/research facility,

4. Software that operates an airborne vehicle, or





JPR No. 7150.2A




Class E: Design Concept and Research and Technology Software a. Definition: 1. Software developed to explore a design concept or hypothesis but not used to make decisions for an operational Class A, B, or C system or to-be-built Class A, B, or C system, or 2. Software used to perform minor desktop analyses of science or experimental data. Class E software cannot be safety-critical software. If the software is classified as safety-critical software, then it has to be classified as Class D or higher. b. Examples: Examples of Class E software include, but are not limited to, parametric models to estimate performance or other attributes of design concepts; software to explore correlations between data sets; line of code counters; file format converters; and document template builders. JSC Specific Examples of Class E Software are:

Acoustical sound level meter

Certified Reliability Engineer (CRE) Electronic Exam

Digital microscope

Educational outreach for engineering – Mobile apps (like iMorpheus)

Games

MATLAB models

Non-business web sites

Personal devices used by the crew, i.e.; iPods, DVD players, CD players, etc.

Pro/Engineer Compilers

Prototype robots, vehicles

Prototype tools

Reliability Alliance Center (RAC) Computer Aided Reliability Training

SigmaPlot

SIMULINK models c. Exclusions: Class E does not include:

1. Space flight systems (i.e., software that meets the space flight portions of Class A, B, or C Software Classifications),

2. Software developed by or for NASA to directly support an operational system (e.g., human-rated

space system, robotics spacecraft, space instrument, airborne vehicle, major engineering/research facility, mission support facility, and primary/major science data collection storage and distribution systems),

3. Software developed by or for NASA to be flight qualified to support an operational system,

4. Software that directly affects primary or secondary mission objectives,





JPR No. 7150.2A




5. Software that can adversely affect the integrity of engineering/scientific artifacts,

6. Software used in technical decisions concerning operational systems,

7. Software that has an impact on operational vehicles, or

8. Software that is safety critical.





JPR No. 7150.2A




Business and Information Technology Infrastructure Software Class F: General Purpose Computing, Business and IT Software (Multi-Center or Multi- Program and Project) a. Definition: General purpose computing Business and IT software used in support of the Agency, multiple Centers, or multiple programs and projects, as described for the General Purpose Infrastructure To-Be Component of the NASA Enterprise Architecture, Volume 5 (To-Be Architecture), and for the following portfolios: voice, wide-area network, local-area network, video, data Centers, application services, messaging and collaboration, and public Web. A defect in Class F software is likely to affect the productivity of multiple users across several geographic locations and may possibly affect mission objectives or system safety. Mission objectives can be cost, schedule, or technical objectives for any work that the Agency performs. b. Examples: Examples of Class F software include, but are not limited to, agency-wide enterprise applications (e.g., WebTADS, SAP, eTravel, ePayroll, Business Warehouse), including mobile applications; agency-wide educational outreach software; software in support of the NASA-wide area network; and the NASA Web portal. Class G: General Purpose Computing, Business and IT Software (Single Center or Project) a. Definition: General purpose computing, business and IT software used in support of a single Center or project, as described for locally deployed portions of the General Purpose Infrastructure To-Be Component of the NASA Enterprise Architecture, Volume 5 (To-Be Architecture) and for the following portfolios: voice, local-area network, video, data Centers, application services, messaging and collaboration, and public Web. A defect in Class G software is likely to affect the productivity of multiple users in a single geographic location or workgroup but is unlikely to affect mission objectives or system safety. b. Examples: Examples of Class G software include, but are not limited to software for Center custom applications such as Headquarters' Corrective Action Tracking System; Headquarters' User Request Systems; content management system mobile applications; and Center or project educational outreach software.





JPR No. 7150.2A




Class H: General Purpose Desktop Software a. Definition: General purpose desktop software as described for the General Purpose Infrastructure To-Be Component (Desktop Hardware and Software Portfolio) of the NASA Enterprise Architecture, Volume 5 (NASA To-Be Architecture). A defect in Class H software may affect the productivity of a single user or small group of users but generally will not affect mission objectives or system safety, but a defect in desktop IT security-related software, e.g., anti-virus software, may lead to loss of functionality and productivity across multiple users and systems. b. Examples: Examples of Class H software include, but are not limited to, desktop applications such as word processing applications, spreadsheet applications, and presentation applications.





JPR No. 7150.2A




APPENDIX D. HOW TO READ THESE PROCESS REQUIREMENTS

Refer to Appendix Figure 1 Sample Requirement Formatting on the next page for mapping of the following points.

a. Each JSWE process requirement has a consistent format of the requirement, parent reference, rationale, and applicability to different classes of software.

An example for JSWE-015 below shows:, 2.3.2.1 as the subheading number and [JSWE-015] as the requirement ID. Any additional notes are placed after the Class Applicability table for each JSWE.

b. The JSWE statement may be applied in varying levels of stringency to particular classes of software at different levels of criticality. In some cases, the JSWE applies across the board. In other cases, a JSWE is tailored for each set of the classes where an “X” appears under the criticality row:

c. When Class (“X” is marked), Then statement of how JSWE requirement is to be applied to SW identified in that row. For this software class/criticality, what appears in the applicability table serves as the full requirement for that category of SW to follow.

d. The When-Then table identifies only software Classes A-E as potentially being safety critical. If an F-H class is determined to be safety-critical, the Directorate’s SEPG will determine the additional software process requirements required and present the recommendation to the JSC SEPG for approval.

d. This approach was taken because the “Then” statement for a particular set software class/criticality in the table (where “X” is marked) provides the exactly tailored requirement to follow so that unnecessarily a burdensome requirement (i.e., the entire requirement and all its parts) is not levied where it is not needed and in a manner that adds no value but does add unnecessary cost and overhead to a project implementing the particular requirement.





JPR No. 7150.2A




APPENDIX_FIGURE 1 SAMPLE REQUIREMENT FORMATTING





JPR No. 7150.2A




APPENDIX E. REQUIREMENTS MAPPING MATRIX

This matrix is a consolidation of the matrices found throughout the document. Those JSWEs without a number are not the responsibility of the project but are included to provide complete traceability from this JPR and other documents. To enhance readability for notes as follows:

X Note: indicates the project is allowed flexibility (via JSWE-027) in addressing this requirement in the case of COTS software acquisition

X1 Note: indicates the requirement does not apply to COTS software acquisition

X2 Note: indicates the requirement is treated consistently whether the project involves software development or COTS software acquisition





JPR No. 7150.2A




APPENDIX_TABLE E-1 CONSOLIDATION OF JSWE MATRICES IN THIS JPR

Section of JPR

Requirement Descriptor

J

SW

E #

When Class

Then



P.2 Applicability

Effective Date - X X X X X X X X X X X X NPR SWE-001 met with this document

N/A Agency software initiative

- X X X X X X X X X X X X NPR SWE-002. Refer to NPR 7150.2

N/A Center plan - X X X X X X X X X X X X NPR SWE-003. Refer to JPD 7150.1

N/A Benchmark - X X X X X X X X X X X X NPR SWE-004. Refer to NPR 7150.2

N/A Software processes - X X X X X X X X X X X X NPR SWE-005. Refer to JPD 7150.1

N/A

List of agency's programs & projects containing software

-

X

X

X

X

X

X

X

X

X

X

X

X

NPR SWE-006. Refer to JPD 7150.1

Software Life- Cycle Planning

Software Plans 13 X X X X X X X X X X X Implement JSWE-013 as written.


Cost Estimation

15


X X

X X X X

The project shall establish and maintain one software cost estimate and associated cost parameter(s).


Software Schedule 16 X X X X X X X X



Training 17 X X X X X X X



Reviews and Issue Resolution

18 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 Implement JSWE-018 as written.





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Software Life Cycle 19 X1 X1 X1 X1 X1 X1 X1 X1 X1 X1 Implement JSWE-019 as written.


Software Classification

20 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X Implement JSWE-020 as written.


Software Classification Evolution

21

X2

X2

X2

X2

X2

X2

X2

X2 X2 X2

X2

X



Software Assurance 22 X2 X2 X2 X2 X2 X2 X2 X2 Implement JSWE-022 as written.


Safety Standard 23 X2 X2 X2 X2 Implement JSWE-023 as written.


Tracking Results and Performance Against Plans

24 X X X X


COTS, GOTS,

MOTS, and Legacy/ Heritage Software

COTS, GOTS, MOTS, Reused, or FOSS Software

27

X2

X2

X2

X2

X2

X2

X2

X2

X2






JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Software Verification and Validation

Software Verification Plan

28


X X X X

Implement JSWE-028 as written and additional requirements for safety-critical software:

a. Perform inspection to verify implementation of the safety-critical requirements in the code.

b. Perform testing to verify the effectiveness of hazard controls.

c. Analysis may be performed to support the case that hazard is effectively controlled.


Software Validation Plan

29 X X X X X X X X X X



Results of Verification




Results of Validation



Project Formulation Requirements

CMMI

32

X1

X1

X1

X1



Acquisition Versus Development

33

X

X

X

X

X

X

X

X

X

X






JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Acceptance Criteria

34

X

X

X

X

X

X

X

X

X

X



Supplier Selection Procedure

35 X X X X

X X X X



Determining Processes, Activities, and Tasks

36

X

X

X

X

X

X

X

X

X1

X1



Milestones

37

X

X

X

X

X

X

X

X

X1

X1



Documenting Acquisition Planning Decisions

38

X

X

X

X

X

X

X

X

X1

X1


Software Contract Requirements

Insight Into Supplier Activities

39

X X X X X1 Implement JSWE-039 as written.

X X


X X

Implement JSWE-039 except for “monitoring integration”.


Supplier Providing Information to NASA 40

X X X X X X X1 X1 Implement JSWE-040 as written.

X






JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Free and Open Source Software Notification

41

X X X

X X X

X Implement JSWE-041 as written.

X



Access to Source Code

42

X X X X X X X1 Implement JSWE-042 as written.

X



Tracking Software Changes and Nonconformances

43

X X X

X X X X1 X1 Implement JSWE-043 as written.

X



Joint NASA/Supplier Audits

45

.


X



Supplying the Software Schedule

46

X

X

X

X

X

X

X

X

X1



Supplying Traceability Data

47

X1 X1 X1 X1 X1 X1 X1 Implement JSWE-047 as written.

X1 Implement JSWE-047 as written for safety- critical portions of the software only.





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Software Requirements

Software Requirements Specification 50 X X X X X X X X X X X



Requirements Flow- Down

51 X X X X X X X


Bidirectional Traceability

Between Software Requirement and Higher-Level Requirement

52

X X X

X X X


X



Requirements Management

53 X X X X X X X X X X X Implement JSWE-053 as written.


Managing Inconsistencies

54

X X X X X X X X


X

Implement JSWE-054 as written for safety-

critical portions of the software only.


Expectation Validation

55

X X X X X X


X

Implement JSWE-055 as written for safety-

critical portions of the software only.

Software Design

Software Design 56 X1 X1 X1 X1 X1 X1 X1 X1 X1 Implement JSWE-056 as written.





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Software Design

Software Architectural Design

57

X X X X X X1 X1 Implement JSWE-057 as written.

X X


X

Transform the allocated and derived requirements into an informally documented software architectural design.

Software Design

Detailed Design

58

X1 X1 X1 X1 X1 X1 Implement JSWE-058 as written.

X1 X1 Implement JSWE-058 as written for safety- critical portions of the software only.


Between Software Requirements and Software Design

59

X1 X1 X1 X1 X1 X1 X1 X1 Implement JSWE-059 as written.


Software Implementation

Design Into Code 60 X1 X1 X1 X1 X1 X1 X1 X1 X1 X1 Implement JSWE-060 as written.


Coding Standards

61




Unit Testing 62 X1 X1 X1 X1 X1 X1 X1 X1 X1 X1 Implement JSWE-062 as written.


Version Description Document

63 X X X X X X X X

X1 X1 Implement JSWE-063 as written.


Between Software Design and Software Code

64

X1 X1 X1 X1 X1 Implement JSWE-064 as written.

X1 X1 Implement JSWE-064 as written for safety- critical portions of the software only.

Software Testing

Software Plans, Procedures, and Reports

65






JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Software Testing

Software Test Plan 66 X X X X X X X X


Software Testing

Verifying Requirements

67 X X X X X X X X X


Software Testing

Documenting Test Results

68 X X X X X X X X


Software Testing

Documenting Defects

69 X X X X X X X X


Software Testing

Models, Simulations, and Analysis Tools

70 X2 X2 X2 X2 X2 X2 X2 X2 Implement JSWE-070 as written.

Software Testing

Updating Test Plans and Procedures

71 X X X X X X X



Between Software Test Procedures and Software Requirements

72

X X X X X X X


X

Establish and maintain traceability from the Software Test Procedures to the software requirements.

Software Testing

Targeted Platform or High-Fidelity Simulation

73

X2 X2 X2 X2 X2 X2

X2 X2


X2

Implement JSWE-073 as written for safety- critical portions of the software only..





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Software Operations, Maintenance, and Retirement

Planning for Operations,

Maintenance, and Retirement

75

X X X X X Implement JSWE-075.

X

X


X X X

The project shall plan software operations, maintenance, and retirement for projects that are expected to be multi use, or with an operational life of 3 months or more

Software Operations, Maintenance, and Retirement

Delivering Software Products


Software Configuration Management

Software Configuration Management Plan

79

X

X

X

X

X

X

X

X


X Implement JSWE-079 as written as written for safety-critical portions of the software only..


Tracking and Evaluating Changes

80


X No formal process is required; an action item spreadsheet will suffice.





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Identifying Configuration Items

81

X

X

X

X

X

X

X

X

X

X



Authorizing Changes

82




Maintaining Records

83

X

X

X

X

X

X

X

X

X



Configuration Audits

84

X X




Implementing Procedures

85

X X X X X X X X X X X


Risk Management

Continuous Risk Management

86



X X Address known risks.





JPR No. 7150.2A




Section of JPR


JS

WE

# When Class

Then




Software Peer Reviews / Inspections

Peer Reviews/Inspections of Software Requirements, Test Plan, and Code

87

X1

Perform and report on software peer reviews/inspections for the plans identified:

a. Software requirements

b. Software test process

c. Any design items that the project identified for software peer reviews/inspections according to the software development plans.

d. Software code as defined in the software and/or project plans.



Checklists, Criteria, Tracking, and Participants

88




Basic Measurements

89


X2 Implement JSWE-089 as written for safety- critical portions of the software only





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Software Measurement

Measurement Objectives

90



Software Measurement Specific Measures -

X

X

X

X

X

X

X

X

X

X

X

X



Data Collection and Storage

-

X

X

X

X

X

X

X

X

X

X

X

X



Analyzing Data

93

X2

X2

X2

X2 X1


X2

X2


X2 X1 Analyze software measurement data collected.





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Reporting Results 94

X2 X2 X2 X2 X2 X1 X1 Implement JSWE-094 as written.

X2


N/A

Software measurement system

- X X X X X X X

X

X X X X NPR SWE-095. JPD 7150.1

N/A

Objectives & procedures

-

X

X

X

X

X

X

X

X

X

X

X

X NPR SWE-096. Refer to NPR 7150.2

N/A

Agency process asset library

X

X

X

X

X

X

X

X

X

X

X

X

NPR SWE-098. Refer to NPR 7150.2

N/A Identify applicable practices

X X X X X X X X X X X X


N/A Software engineering training

- X X X X X X X X X X X X NPR SWE-100. Refer to JPD 7150.1

N/A Software training plan

- X X X X X X X X X X X X NPR SWE-101. Refer to JPD 7150.1





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



Tailoring of Requirements

Document approved alternate requirements

121

X2

X2

X2

X2

X2

X2

X2

X2

X2

X2

X


1.2 Technical Authority, Tailoring, Waivers, and Deviations

Center level Engineering Technical Authority approval

-

X

X

X

X

X

X

X

X

X

X

X

X


Compliance With Laws, Policies, and Requirements

Compliance Matrix

125 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X


1.2 Technical Authority, Tailoring, Waivers, and Deviations

Considerations for waivers

-

X X X X X X X X X X X X


Addressed in JPR Chapter 1.2

N/A Review of "P(Center)"

- X X X X X X X X X X X X NPR SWE-127. Refer to NPR 7150.2

P.1 Purpose Compliance records X X X X X X X X X X X X NPR SWE-128 met with this document.

N/A Check compliance - X X X X X X X X X X X X NPR SWE-129. Refer to JPD 7150.1


IV&V Plan 131 X X X X X X X X

Implement JSWE-131 as written


Independent Software Classification

132 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X






JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Software Safety Criticality



Computing System Safety Requirements

134

X2 X2 Implement JSWE-134 as written

X2 Implement JSWE-134 for Computer based control Systems (Flight Only)

X2 X2 Implement per Hazard Analysis for ground based C & all D


Static Analysis Tools

135




Validating and Accrediting Software Tools

136

X1 X1 X1 X1 X1 X1 X1 X1 X1 Implement JSWE-136 as written.

X1 Implement JSWE-136 as written for safety-critical portions of the software only.





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then



N/A

“Shall" statements in this JPR

-

X

X

X

X

X

X

X

X

X

X

X

X

NPR SWE-139. Refer to NPR 7150.2

Section 1.0 Purpose

Meeting "P(Center)"

-

X

X

X

X

X

X

X

X

X

X

X

X

NPR SWE-140 met with this document.

Software Life Cycle

IV&V Required 141

X2 X2 X2 X2 X2 X2 X2 X2 X2 NPR SWE-141. Program Manager Requirement

N/A

Center Cost Repository

-

X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 X


Software Architecture

Review 143 X X X X Implement JSWE-143 as written.

N/A

NASA PAL -

X

X

X

X

X

X

X

X

X

X

X

X


N/A

Approve waivers -

X

X

X

X

X

X

X

X

X

X

X

X


Code Generation

Auto-generated Code

146 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2 Implement JSWE-146 as written.

Software Reuse Reusability Requirements

147 X X X X X X X X Implement JSWE-147 as written.

Software Reuse Reusability Contribution

148 X X X X X X X X X X Implement JSWE-148 as written.

Free and Open Source

Conditions for use

149


X2 Implement JSWE-149 as written for safety-critical portions of the software only.

N/A

Review waivers -

X X X X X X X X X X X X NPR SWE-150. Refer to JPD 7150.1





JPR No. 7150.2A




Section of JPR


J

SW

E #

When Class

Then




Cost Estimate 151 X2 X2 X2 X2 X2 X2 X2 X2 Implement JSWE-151 as written.

N/A

Review Compliance Matrices

-

X X X X X X X X X X X X NPR SWE-152. Refer to NPR 7150.2

Software Documentation

Define Content Requirements

153

X X X X X X X X X X X X Implement JSWE-153 as written –see Chapter 5

Software Security

Identify Risk Mitigations

154


X2 X2 Implement JSWE-154 as written for software

flown in space.

Software Security

Implement Risk Mitigations

155


X2 X2 Implement JSWE-155 as written for software flown in space.

Software Security

Security Evaluation

156



Software Security

Access

157



Software Security

Vulnerability Assessment

158



Software Security

Validate Risk Mitigations

159




Class D for Safety Critical

160 X2 X2 X2 X2 Implement JSWE-160 as written.





JPR No. 7150.2A




APPENDIX F. HOW TO CREATE A COMPLIANCE MATRIX

F.1 General

F.1.1 Templates

a. Excel Spreadsheet templates for compliance matrices are available in the JSC Software Engineering Process Group (SEPG) Process Asset Library (PAL). Organizations may develop their own templates with standard references to organizational processes. Current NPR Compliance templates may be used since the JPR JSWEs match directly with the NPR SWEs.

b. Each Project will fill out a compliance matrix that includes columns for each classification of software that the project is developing or acquiring. If the Project hires a contractor or contractor team to develop the software, the project will have a suite of mapping matrices, as each organizational entity in the project that is developing or acquiring software will maintain a mapping matrix.

F.1.2 Mapping Compliance

a. The project will replace each “X” in the matrix with a specific reference to how the project intends to comply with the requirement. This reference can be a specific step in a documented work process. It can be a reference to use of a standard template. It can be a reference to a section of a project-controlled document such as the Project Plan, the Software Development Plan, or the Software Assurance Plan.

b. If the requirement will not be met by the project, the reference will be to an approved waiver, an approved deviation, or “not applicable (N/A)”.

F.2 Use of Not Applicable

There are two situations that legitimately call for the use of “not applicable” in filling out a compliance matrix. The Project will make the first assessment of applicability of requirements. Safety and Software Assurance personnel will also be involved in the assessment. It is recommended that the mapping matrix be reviewed at project milestones to enhance discussions on the particular use of Not Applicable. Disputes in the use of Not Applicable follow the JSC Independent Technical Authority processes.

F.2.3 Situation 1:

The requirement does not apply because the project definition and/or life cycle does not involve the specific requirement. A project that provides maintenance to existing software would not necessarily have a “software development plan” but would have a “software maintenance plan”. In this case, requirements related to a “software development plan” would be marked N/A. A project that has determined that they will not purchase any commercial off- the-shelf software (COTS) and documented that in one of their controlled plans would mark the





JPR No. 7150.2A




requirement for a COTS plan (JSWE-027) N/A. Explanation of why the N/A is valid needs to be attached to the compliance matrix. Several requirements include notes that state “this JSWE does not apply to ….” Use N/A in the matrix for these if the requirement does not apply at all to your project, otherwise only address compliance to the part that applies. F.2.4 Situation 2:

The requirement does not apply to this specific organization within the project because it is being handled by another part of the project. A large project with a prime contract and many subcontracts will frequently run into this type of not applicable in their suite of mapping matrices. Perhaps only one of the subcontracts or the prime contractors is handling the development and implementation of testing. The others could mark the test plan and related testing requirements as N/A. Explanation of why the N/A is valid needs to be attached to the compliance matrix.





JPR No. 7150.2A




APPENDIX G. DEVIATION/WAIVER PROCESS

G.1 Determine Project Specific Deviation/Waiver or Center-Wide Blanket

Deviation/Waiver.

G.1.1 Need for Deviation/Waiver

a. Individual projects may request a project-specific deviation or waiver from JPR 7150.2

based on project-specific circumstances and risks. Alternately, projects may take proposals for center-wide blanket deviations and waivers to their directorate level Software Engineering Process Group (SEPG). (Not all directorate level SEPGs use SEPG in their title.) The directorate level SEPG may request a center-wide blanket waiver or may join with other directorate level SEPGs and have the center’s JSC SEPG request the center- wide blanket waiver.

b. The project or SEPG determines that it needs a waiver or deviation from complying fully or partially with one or more JSWE requirements for one or more classes of software.

c. A Center-wide deviation applies to projects that have not yet baselined their project plan. A Center-wide waiver applies to on-going projects.

G.1.2 Determination of Technical Authority

The project or SEPG reviews APPENDIX H to determine who holds the waiver authority for each of the requirements that the project is requesting a waiver for.

a. Headquarters Chief Engineer

b. Headquarters Chief Engineer and Headquarters Chief Safety & Mission Assurance

c. JSC Engineering Technical Authority

d. JSC Engineering Technical Authority and JSC Safety & Mission Assurance Technical Authority

e. JSC Health & Medical Technical Authority (concurrence)

Note: Even in the cases, where the Safety & Mission Assurance technical authorities are not required for approval they may either concur with the Engineering Technical Authority or challenge the waiver approval to the next higher decision authority if the project includes safety critical software.





JPR No. 7150.2A




G.2 Description of Waiver Request

For each requirement that the project or SEPG is requesting a waiver for:

a. Provide a description of the requested waiver or deviation

b. Provide a risk assessment of not fully complying with the requirement

c. Provide a risk mitigation plan or an explanation as to why one is not needed

d. Program (if applicable)

e. Project name (if applicable)

f. Name and contact information for the POC requesting the waiver or deviation

g. Identification of requirement(s) that are included in the deviation/waiver request

h. Scope of software affected by the deviation/waiver request

i. Duration of deviation/waiver (in years or project milestone)

j. Justification for the deviation/waiver

k. Identification of mandatory signatures and any additional signatures

G.3 Request Deviation or Waiver from JSC

G.3.1 Project Management Plan (PMP) Method

JSC has a practice of using the Project Management Plan (PMP) as a formal method of defining what requirements apply to the project as follows.

a. If a project requests a waiver from a specific requirement (or a set of specific requirements) and the project's decision authority has the authority to approve the waiver, the documentation specified in G.2 Description of Waiver Request is attached as an appendix to the PMP before signature approval.

b. Otherwise, the same information is submitted as a separate request for waiver from the requirement(s) to the appropriate approval authority.

c. Updates to the approved PMP that include new requests for relief from requirements can be handled the same way, but they are now called waivers instead of deviations.

d. When a project requests a deviation or waiver and the approval authority for the PMP does not hold the required authority (see APPENDIX H), the project may use the alternate Technical Authority Method to process the request. The project may select the Technical Authority Method to process all requests for waiver or deviation.





JPR No. 7150.2A




G.3.2 Technical Authority Method a. The JSC Engineering Technical Authority forum for processing JPD 7150.1, JPR 7150.2,

and NPR 7150.2 deviations and waivers is the Engineering Directorate Configuration Control Board (EA CCB). Deviations and waivers related to the Software Safety Standard or the Software Assurance Standard require HQ OSMA approval and will meet NASA-STD- 8709.20, Management of Safety and Mission Assurance (S&MA) Technical Authority (SMA TA) Requirements.

b. Deviations and waivers that require HQ Office of Chief Engineer or HQ OSMA approval or concurrence will first be approved by the JSC Engineering Technical Authority and the JSC Safety & Mission Assurance Technical Authority.

c. Deviations or waivers that require JSC S&MA Technical Authority or JSC Health & Medical Technical Authority approval or concurrence, will be processed through the appropriate S&MA or Health & Medical technical authorities before coming to the EA CCB for final approval.

d. All center-wide deviations and waivers require approval from HQ OCE and HQ Office of Safety and Mission Assurance.

e. The Project representative or SEPG Lead that is requesting the deviation or waiver follows the process to get on an agenda for the EA CCB. They present their deviation or waiver with the associated risk analysis and justification to the EA CCB for approval or concurrence to take the deviation or waiver to HQ for approval where required by APPENDIX H.

f. The EA CCB will record and post approved deviations and waivers.





JPR No. 7150.2A




APPENDIX H. DEVIATION/WAIVER TECHNICAL AUTHORITY TABLE

As stated in Section 1.1, deviations and waivers require the concurrence of and approval of technical authorities. The Technical Authority for Class F software JSWEs is the HQ CIO. The Technical Authority for Class G/H software JSWEs is the Center CIO. The Technical Authorities for Classes A-E are listed in Table H-1.

APPENDIX_TABLE H-1 Technical Authorities for Classes A-E

Section of JPR

Requirement

Descriptor

JS

WE

#

Technical

Concurrence

Technical Authority

Project Formulation Requirements CMMI 32 Note 1 & 2 HQ Chief Engineer and

HQ OSMA

Software IV&V Plan IV&V 131 Note 1 & 2 JSC Engr Technical Authority & JSC S&MA Director

Software Life-Cycle Planning

Software Safety Criticality 133 Note 1 & 2 Project S&MA & JSC

S&MA Director

Software Life-Cycle Planning

Computing System Safety Requirements

134

Note 1 & 2 JSC Engr Technical Authority & JSC S&MA Director

Software IV&V Review 141 Note 1 & 2 HQ Chief Engineer & HQ Chief S&MA

- - All

Other JSWEs

Note 1 & 2 JSC Engr Technical Authority

Note 1 If the requirement to be waived involves safety-critical software or the waiver is elevated to HQ, the JSC Director of S&MA will concur.

Note 2: If the requirement to be waived involves software with health or medical implications the JSC Director of Space Life Sciences will concur.





JPR No. 7150.2A




APPENDIX I. DEVIATIONS FROM NPR 7150.2 This JPR deviates from the NPR in the following cases.

JSWE NPR Shall JPR Shall Class Differences

Rationale

15 The project manager shall establish and maintain two cost estimates and associated cost parameters for all software Class A and B projects that have an estimated project cost of $2 million or more or one software cost estimate and associated cost parameter(s) for other software projects

The project shall establish and maintain one cost estimate and associated cost parameters for all software projects; two cost estimates are required for those projects that have an estimated project cost of $2 million or more

All

The JPR addresses class-specific requirements via class applicability tables.

28 The project manager shall plan software verification activities, methods, environments, and criteria for the project

The project shall plan software verification activities, methods, environments, and criteria for the project

…

a. Perform inspection to verify implementation of the safety-critical requirements in the code. b. Perform analysis or testing to verify the effectiveness of hazard controls

Added requirements for Safety Critical Software

JSC has added verification activities specific to safety critical software to ensure these are clearly communicated to the projects.





JPR No. 7150.2A





Rationale

39 The project manager shall require the software supplier(s) to provide insight into software development and test activities; at a minimum, the following activities are required: monitoring integration, review of the verification adequacy, review of trade study data and results, auditing the software development process, participation in software reviews, and systems and software technical interchange meetings

The project shall require the software supplier(s) to provide insight into software development and test activities; at a minimum, the following activities are required: review of the verification adequacy.

Tailored for C, D Removed for G

Of the activities listed, the highest benefit comes from

ensuring the supplier’s

verification coverage will sufficiently test all requirements Removed based on JSC CIO feedback.

41 The project manager shall require the software supplier(s) to notify the project, in the response to the solicitation, as to whether or not open source software will be included in code developed for the project.

Removed for G

Removed based on JSC CIO feedback.

42 The project manager shall require the software supplier(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format, including MOTS software and non-flight software.

Removed for G


45 The project manager shall participate in any joint NASA/supplier audits of the software development process and software configuration management process.

Removed for G






JPR No. 7150.2A





Rationale

46 The project manager shall require the software supplier(s) to provide a software schedule for the project's review and schedule updates as requested.

Removed for G


47 The project manager shall require the software supplier(s) to make electronically available the software traceability data for the project's review.

Removed for G


57 The project shall develop and record the software architecture.

The project shall develop and record the software architecture.

Add D All software projects should have a documented architecture to ensure stakeholders have a high level understanding of how the solution fits within its environment. This can be as simple as a diagram included in the project plan or user training.

64 The project manager shall perform, record, establish and maintain bidirectional traceability between the software design and the software code.

Removed for C, G

This waiver is for Class C, & G projects that are less than $500K in cost and where risks have been assessed as low (only green and yellow risks). JSC uses a risk-based approach to ensure trace is appropriate to the level of risk. The JPR team found that full implementation would make these small scale/low complexity projects more cost and resource intensive than the value it brings would warrant. In this case, the JPR team believes that these small projects can dispense with the bidirectional traceability requirement without risking their ability to deliver a valuable asset to the agency.

67 The project manager shall verify the requirement to the implementation of each software requirement.

The project shall verify the requirement to the implementation of each software requirement.

Add D





JPR No. 7150.2A





Rationale

69 The project manager shall record defects identified during testing and track to closure.

Removed for G


72 The project manager shall perform, record, establish and maintain bidirectional traceability between the Software Test Procedures to the software requirements.

The project shall establish and maintain traceability from the Software Test Procedures to the software requirements.

Tailored for G

JSC will use this waiver for Class G projects that are less than $500K in cost and where risks have been assessed as low (only green and yellow risks). JSC uses a risk-based approach for class F projects to ensure trace is appropriate to the level of risk. In this case, the JPR team believes that these small projects can rely on unidirectional traceability without risking their ability to deliver a valuable asset to the agency.

75 The project manager shall plan for operations, maintenance, and retirement activities.

The project shall plan software operations, maintenance, and retirement for projects that are expected to be multi use, or with an operational life of 3 months or more.

Tailored for C, D, G

The JPR team found that software operations, maintenance, and retirement plans for one time use, small duration projects are rarely if ever used. Therefore, development of such plans for those cases is not an effective use of resources.

82 The project manager shall establish and implement procedures to: Designate levels of

control …

Removed for Class H

We believe this is just a mistake with the NPR where Classes D/E were exempt but not H.

93 The project manager shall analyze software measurement data collected using documented procedures, project-specified and/or Center/organizational analysis procedures

The project shall analyze software measurement data collected.

Tailored for C, G

For Class C and G projects, the repeatability of metrics analysis methods is not required, though suggested.

160 If a software component is determine to be safety critical software then software component classification shall be Software Class D or higher

If a software component is determine to be safety critical software then software component classification shall be Software Class D or higher

Removed Non-Safety Critical Classes

The NPR applied this to all classes but it is only applicable to safety critical classes.





JPR No. 7150.2A




APPENDIX J. PRE-APPROVED TAILORING FOR HEALTH AND HUMAN PERFORMANCE DIRECTORATE SPACE FLIGHT RESEARCH PROJECTS

The JSC Health and Human Performance Directorate often develops software for space flight research projects that are intended to prove a concept or for technology maturation through space flight experience. For projects of this kind the project manager shall ensure that a software classification and safety criticality assessment is performed and approved by the appropriate technical authorities, or their designees. Once classified, the following JPR 7150.2 requirement tailoring is pre-approved for projects of this type:

1. Software that is Class C AND Non-Safety Critical:

a. The following JSWE’s are waived: JSWE-017, JSWE-131, JSWE-035, JSWE-042, JSWE-045, JSWE-

047, JSWE-0147, JSWE-051, JSWE-052, JSWE-054, JSWE-058, JSWE-059, JSWE-0135, JSWE-064,

JSWE-0136, JSWE-070, JSWE-084, JSWE-086, JSWE-087, JSWE-088, JSWE-089, JSWE-090, JSWE-

093, and JSWE-094.

b. The following JSWE’s are waived if NASA S&MA determines that there are no software security

concerns: JSWE-154, JSWE-155, JSWE-156, JSWE-157, JSWE-158, and JSWE-159.

c. Once the software has been validated through in-flight assessments, the software can be

transitioned to operational use by complying with JSWE-042.

2. Software that is Any Class Other Than C, OR Safety Critical:

a. No tailoring is pre-approved. The project may request customized process tailoring from the

relevant technical authority.


JSC SOFTWARE ENGINEERING PROCEDURAL REQUIREMENTS · 2018-05-21 · Johnson Space EffectiveCenter...

Documents

Transcript of JSC SOFTWARE ENGINEERING PROCEDURAL REQUIREMENTS · 2018-05-21 · Johnson Space EffectiveCenter...