NPR 7150.2C¶
M4OPT is designed to support both space-based observatories and ground-based telescopes. Both ground and flight software for NASA payloads are subject to software engineering requirements set forth in the NASA Procedural Requirements (NPR) document NPR 7150.2C.
The software classification determines which of NPR 7150.2C’s requirements are in force. M4OPT is classified as Class C software, suitable for non-safety-critical applications on Class D NASA payloads.
M4OPT is fully compliant with all requirements for Class C software. One of the requirements is that there must be a requirements matrix, which is satisfied by the table below. In almost all cases, compliance is a matter of mapping the very dense language of NPR 7150 onto everyday best practices of open-source scientific Python software development.
NPR Section # |
NPR Requirements Text |
Complies how? |
---|---|---|
Software Life Cycle Planning |
||
3.1.2 |
The project manager shall assess options for software acquisition versus development. |
Reuse of third-party open source dependencies |
3.1.3 |
The project manager 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. |
This manual |
3.1.4 |
|
|
3.1.5 |
The project manager shall define and document the acceptance criteria for the software. |
GitHub Actions workflow must pass |
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. |
This manual |
3.1.7 |
The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. |
|
3.1.8 |
|
In weekly team meetings |
3.1.9 |
The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information and nonconformances, in electronic format, including software development and management metrics. |
GitHub issues and pull requests |
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. |
|
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. |
This table |
3.1.12 |
Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software. |
No requirements tailored |
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. |
This table |
3.1.14 |
|
Proposed new dependencies are reviewed in GitHub pull requests |
Software Cost Estimation |
||
3.2.1 |
|
Line count and COCOMO II cost model available upon request |
3.2.2 |
|
Factors provided as COCOMO II input parameters |
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. |
Reported quarterly to Astrophysics Line of Business at NASA Goddard Space Flight Center |
Software Schedules |
||
3.3.1 |
|
|
3.3.2 |
The project manager shall regularly hold reviews of software schedule activities, metrics, status, and results with the project stakeholders and track issues to resolution. |
GitHub issues and weekly team meetings |
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. |
|
Software Training |
||
3.4.1 |
The project manager shall plan, track, and ensure project specific software training for project personnel. |
No training required |
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. |
M4OPT is Class C software because it has stakeholders that are Class D payloads |
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. |
This page |
Software Assurance and Software IV&V |
||
3.6.1 |
The project manager shall plan and implement software assurance per NASA-STD-8739.8. |
See Testing |
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. |
Not safety critical. M4OPT should not be used to directly command a spacecraft. User is responsible for validating output and transforming to safe command sequences. |
3.7.2 |
If a project has safety-critical software, the project manager shall implement the safety-critical software requirements contained in NASA-STD-8739.8. |
Not applicable: not safety critical |
3.7.3 |
|
Not applicable: not safety critical |
Automatic Generation of Software Source Code |
||
3.8.1 |
|
Not applicable: no auto-generated code |
3.8.2 |
The project manager shall require the software developers and suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. |
Not applicable: no auto-generated code |
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 United States Government purposes. |
Reusability by US Government is implicit in making the software open source |
3.10.2 |
|
TO DO |
Software Cybersecurity |
||
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. |
Considered in review of new dependencies in GitHub pull requests. GitHub Dependabot alerts are enabled. |
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. |
Considered in reviews of all GitHub pull requests |
3.11.4 |
The project manager shall implement protections for software systems with communications capabilities against unauthorized access. |
Considered in reviews of all GitHub pull requests |
3.11.5 |
The project manager shall ensure that space flight software systems are assessed for possible cybersecurity vulnerabilities and weaknesses. |
Not applicable: not flight software |
3.11.6 |
The project manager shall address identified cybersecurity vulnerabilities and weaknesses. |
|
3.11.7 |
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. |
In unit test suite |
3.11.8 |
The project manager shall identify, record, and implement secure coding practices. |
See, for example, Top 10 Python security best practices |
3.11.9 |
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). |
|
Software Bi-Directional Traceability |
||
3.12.1 |
The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: (See Table in 3.12.1) |
All requirements are defined by the Example Scenarios, verified by CI pipeline |
Software 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. |
See 3.12.1 |
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. |
See 3.12.1 |
4.1.4 |
The project manager shall include software related safety constraints, controls, mitigations and assumptions between the hardware, operator, and software in the software requirements documentation. |
Not safety critical software |
4.1.5 |
The project manager shall track and manage changes to the software requirements. |
The Example Scenarios are in the GitHub repository |
4.1.6 |
The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products. |
|
4.1.7 |
The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. |
In test suite |
Software Architecture |
||
4.2.3 |
The project manager shall transform the requirements for the software into a recorded software architecture. |
Architecture is to be documented in this manual |
4.2.4 |
|
Not applicable |
Software Design |
||
4.3.2 |
The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested. |
Design is to be documented in this manual |
Software Implementation |
||
4.4.2 |
The project manager shall implement the software design into software code. |
In the GitHub repository |
4.4.3 |
The project manager shall select and adhere to software coding methods, standards, and criteria. |
|
4.4.4 |
The project manager shall use static analysis tools to analyze the code during the development and testing phases to detect defects, software security, and coding errors. |
|
4.4.5 |
The project manager shall unit test the software code. |
See Testing |
4.4.6 |
The project manager shall assure that the unit test results are repeatable. |
|
4.4.7 |
The project manager shall provide a software version description for each software release. |
See Changes |
4.4.8 |
The project manager shall validate and accredit the software tool(s) required to develop or maintain software. |
Reusing toolchain from the Astropy affiliated package template |
Software Testing |
||
4.5.2 |
|
See Testing |
4.5.3 |
The project manager shall test the software against its requirements. |
See Testing and Example Scenarios |
4.5.4 |
The project manager shall place software items under configuration management prior to testing. |
|
4.5.5 |
The project manager shall evaluate test results and record the evaluation. |
Reported in GitHub Actions |
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. |
Not applicable: not flight software |
4.5.7 |
The project manager shall update the software test plan(s) and the software test procedure(s) to be consistent with software requirements. |
See Testing and Example Scenarios |
4.5.8 |
The project manager shall validate the software system on the targeted platform or high-fidelity simulation. |
On GitHub-hosted runners with as many operating systems and Python versions as feasible |
4.5.9 |
The project manager shall ensure that the code coverage measurements for the software are selected, implemented, tracked, recorded, and reported. |
|
4.5.10 |
The project manager shall verify code coverage is measured by analysis of the results of the execution of tests. |
|
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. |
As part of unit test suite |
4.5.12 |
The project manager shall verify through test the software requirements that trace to a hazardous event, cause, or mitigation technique. |
As part of unit test suite |
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. |
Dependencies are evaluated based on code quality, test coverage, release cycle, etc. |
Software Operations, Maintenance, and Retirement |
||
4.6.2 |
The project manager shall plan and implement software operations, maintenance, and retirement activities. |
Defects logged and bug fix releases done as needed |
4.6.3 |
The project manager 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. |
This manual, and see also Changes |
4.6.4 |
The project manager shall complete, prior to delivery, verification that all software requirements identified for this delivery have been met, that all approved changes have been implemented and that all defects designated for resolution prior to delivery have been resolved. |
|
4.6.5 |
The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase. |
Defects logged and bug fix releases done as needed |
4.6.6 |
The project manager shall identify the records and software tools to be archived, the location of the archive, and procedures for access to the products for software retirement or disposal. |
Software artifacts are tagged as GitHub releases and packages are uploaded to PyPI |
Software Configuration Management |
||
5.1.2 |
The project manager shall develop a software configuration management plan that describes the functions, responsibilities, and authority for the implementation of software configuration management for the project. |
Everything is in the GitHub repository |
5.1.3 |
The project manager shall track and evaluate changes to software products. |
Git commit log |
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. |
Everything is in the GitHub repository |
5.1.5 |
|
See Contributing |
5.1.6 |
The project manager shall prepare and maintain records of the configuration status of software configuration items. |
Everything is in the GitHub repository |
5.1.7 |
The project manager 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. |
The GitHub repository is the source of truth |
5.1.8 |
The project manager shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products. |
Software artifacts are tagged as GitHub releases and packages are uploaded to PyPI |
5.1.9 |
The project manager shall participate in any joint NASA/developer audits. |
Whenever requested |
Software Risk Management |
||
5.2.1 |
The project manager shall record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans. |
TO DO |
Software Peer Reviews/Inspections |
||
5.3.2 |
|
|
5.3.3 |
|
GitHub issue and pull request templates |
5.3.4 |
The project manager shall, for each planned software peer review or software inspection, record necessary measurements. |
Coverage analysis, benchmarks, etc. collected by GitHub Actions pipeline |
Software Measurements |
||
5.4.2 |
The project manager shall establish, record, maintain, report, and utilize software management and technical measurements. |
|
5.4.3 |
The project manager shall analyze software measurement data collected using documented project-specified and Center/organizational analysis procedures. |
Reported quarterly to Astrophysics Line of Business at NASA Goddard Space Flight Center |
5.4.4 |
The project manager 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, the Center Technical Authorities, and Headquarters SMA. |
As requested |
5.4.5 |
The project manager shall monitor measures to ensure the software will meet or exceed performance and functionality requirements, including satisfying constraints. |
In test suite |
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). |
|
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). |
Labels in GitHub Issues |
5.5.3 |
The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, or reused software components. |