Page History
...
Responsible Office: Office of the Chief Engineer
Table of Contents
Preface
P.1 Purpose
P.2 Applicability
...
P.5 Measurement/Verification
P.6 Cancellation
Chapter 1. Introduction
1.1 Overview
1.2 Hierarchy of NASA Software-Related Engineering and Program/Project Documents
1.3 Document Structure
Chapter 2. Roles, Responsibilities, and Principles Related to Tailoring of the Requirements
2.1 Roles and Responsibilities
2.2 Principles Related to Tailoring of the Requirements
Chapter 3. Software Management Requirements
3.1 Software Life Cycle Planning
...
3.12 Software Bi-Directional Traceability
Chapter 4. Software Engineering (Life Cycle) Requirements
4.1 Software Requirements 4.2 Software Architecture
...
4.4 Software Implementation 4.5 Software Testing 4.6 Software Operations, Maintenance, and Retirement
Chapter 5. Supporting Software Life Cycle Requirements
5.1 Software Configuration Management 5.2 Software Risk Management 5.3 Software Peer Reviews/Inspections 5.4 Software Measurements
...
Chapter 6. Recommended Software Documentation Contents
6.1 Software Engineering Products
6.2 Software Engineering Product Content
List of Appendices
Appendix A. Definitions
Appendix B. Acronyms
...
Appendix D. Software Classifications
Appendix E. References
List of Figures
Figure 1. NASA Software Classification Structure
...
a. This NPR applies to NASA Headquarters (HQ) and NASA Centers, including Component Facilities and Technical and Service Support Centers. This language applies to the Jet Propulsion Laboratory (JPL) (a Federally Funded Research and Development Center (FFRDC)), other contractors, grant recipients, or parties to cooperative agreements and other agreements only to the extent specified or referenced in the appropriate contracts, grants, or agreements.
| Note |
|---|
Note: The above statement alone is not sufficient to stipulate requirements for the contractor, grant recipient, or agreement. This NPR provides requirements for NASA contracts, grant recipients, or agreements to the responsible NASA project managers, contracting officers, and the contracting officers representatives that are made mandatory through contract clauses, specifications, or statements of work (SOWs) in conformance with the NASA Federal Acquisition Regulation (FAR) Supplement or by stipulating in the contracts, grants, or agreements which of the NPR requirements apply. |
b. This NPR applies to the complete software development life cycle, including software planning, development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities. The requirements of this directive cover such software created, acquired, or maintained by NASA or for NASA to the extent specified or referenced in an appropriate contract, grant, or cooperative agreement. The applicability of these requirements to specific systems and subsystems within the Agency’s investment areas, programs, and projects is through the use of the NASA-wide definition of software classes, defined in Appendix D. Some projects may contain multiple software systems and software subsystems having different software classes. For this directive, software is defined in Appendix A, and includes software executing on processors embedded in programmable logic devices.
...
1.3.10 Appendix E contains software references for this directive.
Chapter 2. Roles, Responsibilities, and Principles Related to Tailoring of the Requirements
2.1 Roles and Responsibilities Associated with this Directive
...
2.1.1.2 The NASA OCE shall periodically benchmark each Center’s software engineering capability against requirements in this directive. [SWE-004]
| Note |
|---|
Note: Capability Maturity Model® Integration (CMMI®) for Development (CMMI®-DEV) appraisals are the preferred benchmarks for objectively measuring progress toward software engineering process improvement at NASA Centers. |
2.1.1.3 The NASA OCE shall periodically review the project requirements mapping matrices. [SWE-152]
...
2.1.5.2 Center Director, or designee, shall maintain, staff, and implement a plan to continually advance the Center’s in-house software engineering capability and monitor the software engineering capability of NASA’s contractors. [SWE-003]
| Note |
|---|
Note: The recommended practices and guidelines for the content of a Center Software Engineering Improvement Plan are defined in NASA-HDBK-2203, NASA Software Engineering Handbook. Each Center has a current Center Software Engineering Improvement Plan on file in the NASA Chief Engineer’s office. |
2.1.5.3 Center Director, or designee, shall establish, document, execute, and maintain software processes per the requirements in this directive. [SWE-005]
2.1.5.4 Center Director, or designee, shall comply with the requirements in this directive that are marked with an “X” in Appendix C. [SWE-140]
| Note |
|---|
Note: The responsibilities for approving changes in the requirements for a project is listed for each requirement in the requirement mapping matrix. When the requirement and software class are marked with an “X,” the projects will record the risk and rationale for any requirement that is not completely implemented by the project. The projects can document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix. Project relief from the applicable cybersecurity requirements, Section 3.11, Software Cybersecurity, has to include an agreement from the SAISO or Center CISO, as designated by the SAISO. The NASA Agency CIO, or Center CIO designee, has institutional authority on all Class F software projects. |
2.1.5.5 The Center Director, or designee, shall report on the status of the Center’s software engineering discipline, as applied to its projects, upon request by the OCE, OSMA, or OCHMO. [SWE-095]
...
2.1.5.12 The designated ETA(s) shall define the content requirements for software documents or records. [SWE-153].
| Note |
|---|
Note: The recommended practices and guidelines for the content of different types of software activities (whether stand-alone or condensed into one or more project level or software documents or electronic files) are defined in NASA-HDBK-2203. The Center defined content should address prescribed content, format, maintenance instructions, and submittal requirements for all software related records. The designated TA for software approves the required software content for projects within their scope of authority. Electronic submission of data deliverables is preferred. “Software records should be in accordance with NPR 7120.5, NPD 2810.1, NASA Information Security Policy, NPD 2800.1, and NPR 2810.1.” |
2.1.5.13 The Center Director, or designee, shall ensure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third party owners prior to providing the software for internal NASA software sharing or reuse. [SWE-215]
...
2.1.6.2 The Center SMA Director will assure the project completes thorough hazard analyses which include software.
| Note |
|---|
Note: The project manager is responsible for assuring Software Safety Hazard Analyses is performed on their project. The PM is responsible for the development of the project’s software hazard analyses and its independent review. Any differences in software safety’s independent software safety critical determinations will be worked through the ETA and the SMA TA. |
2.1.6.3 The Center SMA Director, will review the project’s IV&V ’Project Execution Plan (IPEP) to ensure it meets NASA IV&V criteria as defined in NASA-STD-8739.8.
...
2.1.8.1 The TA(s) or Institutional Authority(s) for requirements in this NPR will be defined per NPR 7120.5, Section 3.3.
| Note |
|---|
Note: Refer to Appendix C (column titled “Authority”) for requirements and their associated Technical or Institutional Authority. NASA HQ will designate the TA for SWE-032 and SWE-141. |
2.1.8.2 The technical and institutional authorities for requirements in this directive shall: [SWE-126]
a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by:
(1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.
(2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
(3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
(4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
(5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
(6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
(7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
(8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.
| Note |
|---|
Note: To effectively assess projects’ requirements mapping matrices, the designated Center Engineering Technical and Institutional Authorities for this NPR are recognized NASA software engineering experts or utilize recognized NASA software engineering experts in their decision processes. NASA-HDBK-2203 contains valuable information on each requirement, links to relevant NASA Lessons Learned, and guidance on tailoring. Center organizations or branches may also share frequently used tailoring and related common processes. |
b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).
| Note |
|---|
Note: The Requirements Mapping Matrix documents the requirements that the project plans to meet, “not applicable” requirements, and any tailoring approved by designated Authorities with associated justification. If a project wants to tailor a requirement marked as HQ TA, then the project is required to get NASA HQ approval (e.g., OCE, OSMA, OCIO, or OCHMO) on a tailored request or a software Requirements Mapping Matrix. |
2.2 Principles Related to Tailoring Requirements
...
2.2.5 The approval of the Authority designated in Appendix C is required for all tailoring of requirements designated as “X.” The implementation approach used to meet each requirement is typically determined by the appropriate software engineering management in conjunction with the project.
| Note |
|---|
Note: The request for relief from a requirement includes the rationale, a risk evaluation, and reference to all material that justifies supporting acceptance. The organization submitting the tailoring request informs the next higher level of involved management in a timely manner of the tailoring request. The dispositioning organization reviews the request with the other organizations that could be impacted or have a potential risk (i.e., to safety, quality, cybersecurity, health) with the proposed changes; and obtains the concurrence of those organizations. |
2.2.6 Requests for software requirements relief at either the Center or HQ TA level (i.e., partial or complete relief) may be submitted in the streamlined form of a Requirements Mapping Matrix. The required signatures from engineering, NASA CIO, and SMA authorities are to be obtained. A required signature from designated SAISO is required for relief of cybersecurity requirements. If the Requirements Mapping Matrix is completed and approved in accordance with NPR 7120.5’s direction on Authority and this directive, it meets the requirements for requesting tailoring.
...
2.2.8 If a system or subsystem development evolves to meet a higher or lower software classification as defined in Appendix D, then the project manager shall update their plan(s) and initiate modifications to any supplier contracts to fulfill the applicable requirements per the Requirements Mapping Matrix in Appendix C with approved tailoring. [SWE-021]
Chapter 3: Software Management Requirements
3.1 Software Life Cycle Planning
3.1.1 Software life cycle planning covers the software aspects of a project from inception through retirement. The software life cycle planning 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, decommissioning, and supporting activities and processes. The software effort is scoped, the development processes defined, measurements defined, and activities are documented in software planning documents.
3.1.2 The project manager shall assess options for software acquisition versus development. [SWE-033]
| Note |
|---|
Note: 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 a 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. e. Reuse an existing software product or service. f. Source code available external to NASA. See the NASA Software Engineering Handbook for additional detail. |
3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring. [SWE-013]
| Note |
|---|
Note: The recommended practices and guidelines for the content of different types of software planning activities (whether stand-alone or condensed into one or more project level or software documents or electronic files) are defined in NASA-HDBK-2203. The project should include, or reference in the software development plans, procedures for coordinating the software development and design, and the system or project development life cycle. |
3.1.4 The project manager shall track the actual results and performance of software activities against the software plans. [SWE-024]
...
3.1.6 The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables. [SWE-036]
| Note |
|---|
Note: A list of typical software engineering products or electronic data products used on a software project is contained in Chapter 6 of this directive. The software activities should include plans for software product verification and validation activities, software assurance, methods, environments, and criteria for the project. |
3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. [SWE-037]
...
3.1.10 The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format. [SWE-042]
| Note |
|---|
Note: The electronic access requirements for the source code, software products, and software process tracking information implies that NASA gets electronic copies of the items for use by NASA at NASA facilities. This requirement should include MOTS software, ground test software, simulations, ground analysis software, ground control software, science data processing software, hardware manufacturing software, and Class E and Class F software. |
3.1.11 The project manager shall comply with the requirements in this NPR that are marked with an “X” in Appendix C consistent with their software classification. [SWE-139]
...
3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. [SWE-125]
| Note |
|---|
Note: A project may have multiple software engineering requirements mapping matrices if needed for multiple software components on a given project. |
| Note |
|---|
Note: Project relief from an applicable “X” requirement can be granted only by the designated TAs, Engineering, and SMA, or, for security issues, the NASA CIO. The record of their approval of the tailored requirements in a Requirements Mapping Matrix will be indicated by the Authority signature or signatures in the Requirements Mapping Matrix. The projects will document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix. When the requirement and software class are marked with an “X,” the projects record the risk and rationale for any requirements that are entirely or partially relieved in the Requirements Mapping Matrix. The CIO has institutional authority on all Class F software projects. |
3.1.14 The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, OSS, or reused software component is acquired or used: [SWE-027]
...
f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components.
| Note |
|---|
Note: The project responsible for procuring off-the-shelf software is responsible for documenting, prior to procurement, a plan for verifying and validating the software to the same level that would be required for a developed software component. The project ensures that the COTS, GOTS, MOTS, reused, and auto-generated code software components and data meet the applicable requirements in this directive assigned to its software classification as shown in Appendix C. |
3.2 Software Cost Estimation
3.2.1 To better estimate the cost of development, the project manager shall establish, document, and maintain: [SWE-015]
...
f. Includes other direct costs.
| Note |
|---|
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. |
3.2.3 The project manager shall submit software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of major milestones. [SWE-174]
3.3 Software Schedules
3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions: [SWE-016]
...
3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested. [SWE-046]
3.4 Software Training
3.4.1 The project manager shall plan, track, and ensure project specific software training for project personnel. [SWE-017]
| Note |
|---|
Note: This includes any software assurance personnel assigned to the project. |
3.5 Software Classification Assessments
3.5.1 The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, and F software in Appendix D. [SWE-020]
| Note |
|---|
Note: The expected applicability of requirements in this directive to specific systems and subsystems containing software is determined through the use of the NASA-wide definitions for software classes in Appendix D in conjunction with the Requirements Mapping Matrix in Appendix C. These definitions are based on (1) usage of the software with or within a NASA system, (2) criticality of the system to NASA’s major programs and projects, (3) extent to which humans depend upon the system, (4) developmental and operational complexity, and (5) extent of the Agency’s investment. |
3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessments for the life of the project. [SWE-176]
3.6 Software Assurance and Software Independent Verification & Validation
3.6.1 The project manager shall plan and implement software assurance, software safety, and IV&V (if required) per NASA-STD-8739.8, Software Assurance and Software Safety Standard. [SWE-022]
| Note |
|---|
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. Software Assurance directions, requirements, and guidance can be found in the NASA-STD-8739.8. |
3.6.2 For projects reaching Key Decision Point A, the program manager shall ensure that software IV&V is performed on the following categories of projects: [SWE-141]
...
3.6.3 If software IV&V is required for a project, the project manager, in consultation with NASA IV&V, shall ensure an IPEP is developed, approved, maintained, and executed in accordance with IV&V requirements in NASA-STD-8739.8. [SWE-131]
| Note |
|---|
Note: The IV&V Advisory Board will review the scope of NASA IV&V activities on an annual basis as part of the budget planning process. |
3.6.4 If software IV&V is performed on a project, the project manager shall ensure that IV&V is provided access to development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively. [SWE-178]
| Note |
|---|
Note: The artifacts and products should be provided electronically in original format (i.e., non-pdf) and, where possible, direct read-only electronic access to project document repositories and data stores should be provided. Appropriate security products should be completed and transferred as part of the overall package. |
3.6.5 If software IV&V is performed on a project, the project manager shall provide responses to IV&V submitted issues and risks and track these issues and risks to closure. [SWE-179]
3.7 Safety-Critical Software
3.7.1 The project manager, in conjunction with the SMA organization, shall determine if each software component is considered to be safety-critical per the criteria defined in NASA-STD-8739.8. [SWE-205]
...
l. The software can place the system into a safe state.
| Note |
|---|
Note: These requirements apply to components that reside in a mission-critical or safety-critical system, and the components control, mitigate, or contribute to a hazard as well as software used to command hazardous operations/activities. |
3.7.4 If a project has safety-critical software, the project manager shall ensure that there is 100 percent code test coverage using the Modified Condition/Decision Coverage (MC/DC) criterion for all identified safety-critical software components. [SWE-219]
| Note |
|---|
Note: In MC/DC coverage, every condition in a decision is tested independently to reach full coverage. Each condition will be executed twice, once with the results true and once with the results of false, but with no difference in the truth values of all other conditions in the decision. In addition, it will be shown that each condition independently affects the decision. Any deviations from 100 percent should be reviewed and waived with rationale by the TAs approval. It is recommended that someone independent of the developer of the code under test design and perform this testing to ensure requirement interpretation or incorrect assumptions do not escape this testing. |
3.7.5 If a project has safety-critical software, the project manager shall ensure all identified safety-critical software components have a cyclomatic complexity value of 15 or lower. Any exceedance shall be reviewed and waived with rationale by the project manager or technical approval authority. [SWE-220]
| Note |
|---|
Note: Cyclomatic complexity is a metric used to measure the complexity of a software program. This metric measures independent paths through the source code. The point of the requirement is to minimize risk, minimize testing, and increase reliability associated with safety-critical software code components, thus reducing the chance of software failure during a hazardous event. The software developer should assess all software safety-critical components with a cyclomatic complexity score over 15 for testability, maintainability, and code quality. For more guidance on this requirement, see NASA-HDBK-2203. |
3.8 Automatic Generation of Software Source Code
3.8.1 The project manager shall define the approach to the automatic generation of software source code including: [SWE-146]
...
3.8.2 The project manager shall require the software developers and custom software suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. [SWE-206]
| Note |
|---|
Note: The term electronic access includes access to the data from NASA facilities. |
3.9 Software Development Processes and Practices
3.9.1 The CMMI® model is an industry-accepted model of software development practices. It is utilized to assess how well NASA projects are supported by software development organization(s) having the necessary skills, practices, and processes in place to produce reliable products within cost and schedule estimates. The CMMI® model provides NASA with a methodology to:
...
a. For Class A software: CMMI®-DEV Maturity Level 3 Rating or higher for software.
b. For Class B software (except Class B software on NASA Class D payloads, as defined in NPR 8705.4): CMMI®-DEV Maturity Level 2 Rating or higher for software.
| Note |
|---|
Note: Organizations need to complete an official CMMI® Institute defined appraisal against either the CMMI®-DEV model V1.3 or V2.0. Organizations are to maintain their rating and have their results posted on the CMMI® Institute Website, or provide an Appraisal Disclosure Statement so that NASA can assess the current maturity/capability rating. Software development organizations need to maintain their appraisal rating during the period they are responsible for the development and maintenance of the software. CMMI® ratings can cover a team, a group, a project, a division, or an entire organization. For Class B software, an exception can be exercised for those cases in which NASA wishes to purchase a product from the "best in class provider," but the best in class provider does not have the required CMMI® rating. For Class B software, instead of a CMMI® rating by a development organization, the project will conduct an evaluation, performed by a qualified evaluator selected by the Center ETA, against the CMMI®-DEV Maturity Level 2 practices, and mitigate any risk, if deficiencies are identified in the evaluation. If this approach is used, the development organization and project are responsible for correcting the deficiencies identified in the evaluation. When this exception is exercised, the OCE and Center ETA are notified of the proposition and provided the results of the evaluation. The project manager should seek guidance from the Office of Procurement (OP) for help in exercising the exception. |
3.10 Software Reuse
3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes. [SWE-147]
...
e. Any third-party code contained therein, and the record of the requisite license or permission received from the third party permitting the Government’s use and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
| Note |
|---|
Note: Currently, there are more than one Agency-wide software inventories and repositories, several options can be found in NASA-HDBK-2203. In order to obtain and reuse the internal software reuse candidates from these repositories, NASA civil servants may request a copy by requesting and completing a simple Acknowledgment of Receipt of the software form that identifies any restrictions on NASA’s right to use the software, including limiting its use to governmental purposes only. The Civil Servant Software Technical POC for the software product will keep a list of all contributors to the software. Any software shared will contain appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express, or implied and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors (see paragraph 2.1.5.17). |
f. Release notes.
3.10.3 In accordance with NPD 2091.1, Inventions Made by Government Employees, NASA Civil Servant employees who make an invention embodied by software will submit to NASA a disclosure of such invention. Likewise, such inventions made by NASA contractors will be reported to NASA, preferably through the NASA electronic New Technology Report (e-NTR) system, pursuant to the terms of their respective contract. Such disclosures are made through the NASA e-NTR system available at http://invention.nasa.gov/.
3.11 Software Cybersecurity
3.11.1 Software defects are a central and critical aspect of computer security vulnerabilities. Software defects with cybersecurity ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling.
| Note |
|---|
Note: Software security relies on high-quality code development and testing practices (clean code, modular structure, well-defined interfaces) – anything that reduces error rates and opportunities for misinterpretation or error; considers both the development and deployment/operational context for the software; has the ability to rapidly assess, triage, correct, and deploy security-related updates while the software is in deployment/operations. |
3.11.2 The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components. [SWE-156]
3.11.3 The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems. [SWE-154]
| Note |
|---|
Note: Project Protection Plans describe the program’s approach for planning and implementing the requirements for information, physical, personnel, industrial, and counterintelligence/counterterrorism security, and for security awareness/education requirements in accordance with NPR 1600.1, NASA Security Program Procedural Requirements, NPD 1600.2, the NASA Security Policy, NPD 2810.1, and NPR 2810.1. Include provisions in the plan to protect personnel, facilities, mission-essential infrastructure, and critical program information from potential threats and vulnerabilities that may be identified during the threat and vulnerability assessment process. |
3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard. [SWE-157]
3.11.5 The project manager shall test the software and record test results for the required software cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses analysis. [SWE-159]
| Note |
|---|
Note: Include assessments for security vulnerabilities during Peer Review/Inspections of software requirements and design. Utilize automated security static analysis as well as coding standard static analyses of software code to find potential security vulnerabilities. |
3.11.6 The project manager shall identify, record, and implement secure coding practices. [SWE-207]
3.11.7 The project manager shall verify that the software code meets the project’s secure coding standard by using the results from static analysis tool(s). [SWE-185]
| Note |
|---|
Note: If a static analysis tool will not work with the selected coding standard, other methods are acceptable, including manual inspection. |
3.11.8 The project manager shall identify software requirements for the collection, reporting, and storage of data relating to the detection of adversarial actions. [SWE-210]
| Note |
|---|
Note: Monitoring of key software observables (e.g., number of failed login attempts, performance changes, internal communication changes) is needed to detect adversarial actions that threaten mission success. When an adversarial action occurs, it should be reported. Raw event data should be further analyzed to determine whether an anomalous event represents an attack, and if so, the nature of the attack. |
3.12 Software Bi-Directional Traceability
3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: [SWE-052]
| Panel | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||
|
| Note |
|---|
Note: The project manager will maintain bi-directional traceability between the software requirements and software-related system hazards, including hazardous controls, hazardous mitigations, hazardous conditions, and hazardous events. |
Chapter 4: Software Engineering Life Cycle Requirements
...
4.1.2 The project manager shall establish, capture, record, approve, and maintain software requirements, including requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification. [SWE-050]
| Note |
|---|
Note: The software technical requirements definition process is used to transform the baselined stakeholder expectations into unique, quantitative, and measurable technical software requirements that can be used for defining a design solution for the software end products and related enabling products. This process also includes validation of the requirements to ensure that the requirements are well-formed (clear and unambiguous), complete (agrees with customer and stakeholder needs and expectations), consistent (conflict free), and individually verifiable and traceable to a higher level requirement. Recommended content for a software specification can be found in NASA-HDBK-2203. |
4.1.3 The project manager shall perform software requirements analysis based on flowed-down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design. [SWE-051]
...
4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture. [SWE-057]
| Note |
|---|
Note: A documented software architecture that describes: the software’s structure; identifies the software qualities (i.e., performance, modifiability, and security); identifies the known interfaces between the software components and the components external to the software (both software and hardware); identifies the interfaces between the software components and identifies the software components. Reference NASA’s Software Architecture Review Board (SARB) paper NTRS ID 20160005787, “Quality Attributes for Mission Flight Software: A Reference for Architects.” |
4.2.4 The project manager shall perform a software architecture review on the following categories of projects: [SWE-143]
...
4.4.3 The project manager shall select, define, and adhere to software coding methods, standards, and criteria. [SWE-061] 4.4.4 The project manager shall use static analysis tools to analyze the code during the development and testing phases to, at a minimum, detect defects, software security, code coverage, and software complexity. [SWE-135]
| Note |
|---|
Note: Although no maximum cyclomatic complexity score is required for non-safety critical software, all software projects should regularly collect and maintain complexity metrics and use them to manage risk, either when high-complexity code must be modified, or proactively to improve the overall quality and maintenance of the code base. For safety critical software, the analysis should take into account the requirements for cyclomatic complexity and code coverage as defined in 3.7.5 and 3.7.4 respectively. |
4.4.5 The project manager shall unit test the software code. [SWE-062]
| Note |
|---|
Note: For safety critical software, the unit testing should follow the requirement established in 3.7.4 of this document. |
4.4.6 The project manager shall assure that the unit test results are repeatable. [SWE-186]
...
4.4.8 The project manager shall validate and accredit the software tool(s) required to develop or maintain software. [SWE-136]
| Note |
|---|
Note: All software development tools contain some number of software defects. Validation and accreditation of the critical software development and maintenance tools ensure that the tools being used during the software development life cycle do not generate or insert errors in the software executable components. Software tool accreditation is the certification that a software tool is acceptable for use for a specific purpose. Accreditation is conferred by the organization best positioned to make the judgment that the software tool in question is acceptable. The likelihood that work products will function properly is enhanced, and the risk of error is reduced if the tools used in the development and maintenance processes have been validated and accredited themselves. |
4.5 Software Testing
4.5.1 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. Please note for Class A software there are additional software test requirements and software integration requirements as defined in NPR 8705.2.
...
4.5.3 The project manager shall test the software against its requirements. [SWE-066]
| Note |
|---|
Note: A best practice for Class A, B, and C software projects is to have formal software testing planned, conducted, witnessed, and approved by an independent organization outside of the development team. |
4.5.4 The project manager shall place software items under configuration management prior to testing. [SWE-187]
| Note |
|---|
Note: This includes the software components being tested and the software components being used to test the software, including components such as support software, models, simulations, ground support software, COTS, GOTS, MOTS, OSS, or reused software components. |
4.5.5 The project manager shall evaluate test results and record the evaluation. [SWE-068]
4.5.6 The project manager shall use validated and accredited software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment. [SWE-070]
| Note |
|---|
Note: Information regarding specific V&V techniques and the analysis of models and simulations can be found in NASA-STD-7009, Standard for Models and Simulations, NASA-HDBK-7009, Handbook for Models and Simulations, or discipline-specific recommended practice guides. |
4.5.7 The project manager shall update the software test and verification plan(s) and procedure(s) to be consistent with software requirements. [SWE-071]
4.5.8 The project manager shall validate the software system on the targeted platform or high-fidelity simulation. [SWE-073]
| Note |
|---|
Note: Typically, a high-fidelity simulation has the exact processor, processor performance, timing, memory size, and interfaces as the target system. |
4.5.9 The project manager shall ensure that the code coverage measurements for the software are selected, implemented, tracked, recorded, and reported. [SWE-189]
| Note |
|---|
Note: This requirement can be met by running unit, integration, and validation tests; measuring the code coverage; and achieving the code coverage by additional (requirement based) tests, inspection, or analysis. If the project does not get 100 percent structural coverage, it means one of four things and each requires action on the project manager’s part: |
4.5.10 The project manager shall verify code coverage is measured by analysis of the results of the execution of tests. [SWE-190]
| Note |
|---|
Note: If it can be justified that the required percentage cannot be achieved by test execution, the analysis, inspection, or review of design can be applied to the non-covered code. The goal of the complementary analysis is to assess that the non-covered code behavior is as expected. |
4.5.11 The project manager shall plan and conduct software regression testing to demonstrate that defects have not been introduced into previously integrated or tested software and have not produced a security vulnerability. [SWE-191]
...
4.5.13 The project manager shall develop acceptance tests for loaded or uplinked data, rules, and code that affects software and software system behavior. [SWE-193]
| Note |
|---|
Note: These acceptance tests should validate and verify the data, rules, and code for nominal and off-nominal scenarios. |
4.5.14 The project manager shall test embedded COTS, GOTS, MOTS, OSS, or reused software components to the same level required to accept a custom developed software component for its intended use. [SWE-211]
4.6 Software Operations, Maintenance, and Retirement
4.6.1 Planning for operations, maintenance, and retirement are typically 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.
...
5.1.4 The project manager shall identify the software configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project. [SWE-081]
| Note |
|---|
Note: The items to be controlled include tools, items, or settings used to develop the software, which could impact the software. Examples of such items include compiler/assembler versions, makefiles, batch files, and specific environment settings. |
5.1.5 The project manager shall establish and implement procedures to: [SWE-082]
a. Designate the levels of control through which each identified software configuration item is required to pass.
b. Identify the persons or groups with authority to authorize changes.
c. Identify the persons or groups to make changes at each level.
| Note |
|---|
Note: IEEE 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering describes configuration management processes to be established, how they are to be accomplished, who is responsible for doing specific activities, when they are to happen, and what specific resources are required. It addresses configuration management activities over a product’s life cycle. Configuration management in systems and software engineering is a specialty discipline within the larger discipline of configuration management. Configuration management is essential to systems engineering and software engineering. |
5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items. [SWE-083]
...
The project manager shall record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans. [SWE-086]
| Note |
|---|
Note: Project managers should be aware of any risks that remain after mitigations have been completed or after a risk has been accepted. |
5.3 Software Peer Reviews and Inspections
...
a. Software requirements.
b. Software plans, including cybersecurity.
c. Any design items that the project identified for software peer review or software inspections according to the software development plans.
d. Software code as defined in the software and or project plans.
e. Software test procedures.
| Note |
|---|
Note: Software peer reviews or software inspections are recommended best practices for all safety and mission-success related software components. Recommended best practices and guidelines for software formal inspections are contained in NASA-STD-8739.9, Software Formal Inspection Standard. |
5.3.3 The project manager shall, for each planned software peer review or software inspection: [SWE-088]
...
5.4.2 The project manager shall establish, record, maintain, report, and utilize software management and technical measurements. [SWE-090]
| Note |
|---|
Note: The NASA-HDBK-2203 contains a set of candidate management indicators that may be used on a software development project. The NASA Chief Engineer may identify and document additional Center measurement objectives, software measurements, collection procedures and guidelines, and analysis procedures for selected software projects and software development organizations. The software measurement process includes collecting software technical measurement data from the project’s software developer(s). |
5.4.3 The project manager shall analyze software measurement data collected using documented project-specified and Center/organizational analysis procedures. [SWE-093]
...
5.4.5 The project manager shall monitor measures to ensure the software will meet or exceed performance and functionality requirements, including satisfying constraints. [SWE-199]
| Note |
|---|
Note: The metrics could include planned and actual use of computer hardware resources (such as processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, and communications/network equipment capacity, bus traffic, partition allocation) over time. As part of the verification of the software detailed design, the developer will update the estimation of the technical resource metrics. As part of the verification of the coding, testing, and validation, the technical resource metrics will be updated with the measured values and will be compared to the margins. |
5.4.6 The project manager shall collect, track, and report software requirements volatility metrics. [SWE-200]
5.5 Software Non-conformance or Defect Management
5.5.1 The project manager shall track and maintain software non-conformances (including defects in tools and appropriate ground software). [SWE-201]
5.5.2 The project manager shall define and implement clear software severity levels for all software non-conformances (including tools, COTS, GOTS, MOTS, OSS, reused software components, and applicable ground systems). [SWE-202]
| Note |
|---|
Note: At a minimum, classes should include loss of life or loss of vehicle, mission success, visible to the user with operational workarounds, and an ‘other’ class that does not meet previous criteria. |
5.5.3 The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, and/or reused software components. [SWE-203]
| Note |
|---|
Note: This includes operating systems, run-time systems, device drivers, code generators, compilers, math libraries, and build and Configuration Management (CM) tools. It should be performed pre-flight, with mandatory code audits for critical defects. |
5.5.4 The project manager shall implement process assessments for all high-severity software non-conformances (closed loop process). [SWE-204]
Chapter 6: Recommended Software Records Content
6.1 Software Engineering Products
It is possible to prepare a plan, associated procedures, and reports, as well as numerous records, requests, descriptions, and specifications for each software development life cycle process. When deciding how to prepare any of these items, consider the users of the information first. Reviewing and understanding the requirements, needs, and background of users and stakeholders are essential to applying the recommendations for the content of software records defined in NASA-HDBK-2203. Specific content within these records may not apply to every project. Use of NASA Center and contractor formats in document deliverables is acceptable if the required content (as defined by the project) is addressed. Product records should be reviewed and updated as necessary. Typical software engineering products or electronic data include:
a. Software Development Plan/Software Management Plan.
b. Software Schedule.
c. Software Cost Estimate.
d. Software Configuration Management Plan.
e. Software Change Reports.
f. Software Test Plans.
g. Software Test Procedures.
h. Software Test Reports.
i. Software Version Description Reports.
j. Software Maintenance Plan.
k. Software Assurance Plan(s).
l. Software Safety Plan.
m. Software Requirements Specification.
n. Software Data Dictionary.
o. Software and Interface Design Description (Architectural Design).
p. Software Design Description.
q. Software User’s Manual.
r. Records of Continuous Risk Management for Software.
4 1
s. Software Measurement Analysis Results.
t. Record of Software Engineering Trade-off Criteria & Assessments (make/buy decision).
u. Software Acceptance Criteria and Conditions.
v. Software Status Reports.
w. Programmer’s/Developer’s Manual.
x. Software Reuse Report.
y. Software Model and Simulation Data and Documentation, including the Verification, Validation, and Credibility Plan for Software Model and Simulation.
...
