1. Requirements

2.1.2.2 The NASA Chief, SMA shall lead and maintain a NASA Software Assurance and Software Safety Initiative to advance software assurance and software safety practices.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

2. Rationale

To ensure that the processes, procedures, and products used to produce and sustain NASA software conform to all requirements and standards specified to govern those processes, procedures, and products.

3. Guidance

Software engineering is a core capability and a key enabling technology for NASA's missions and supporting infrastructure.  The objective of the NASA Software Initiative is to support NASA programs and projects to accomplish their planned goals (e.g., mission success, safety, schedule, and budget) while satisfying their specified software requirements. 

Software Assurance is defined as the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in an intended manner.

The objective of NASA Software Assurance and Software Safety ³⁵²  is to ensure that the processes, procedures, and products used to produce and sustain NASA software conforms to all requirements and standards specified to govern those processes, procedures, and products. 

See also Topic Review - 7.01 - History and Overview of the Software Process Improvement (SPI) Effort for additional details on the SPI Initiative. 

3.1 NASA Software Initiative

A key goal in the 2018 NASA Strategic Plan ¹¹⁷  indicates that the Agency must maintain and sustain its diverse workforce with the right balance of skills and talents. The associated objective is to establish and maintain a workforce that possesses state-of-the-art technical competencies. One of these is software assurance, which is considered to be a core competency for the Agency. 

Some of the key motivations for the NASA Software Initiative activities are to do the following:

• Reduce the risk of software failures and increase mission safety.
  • Improvement processes based on best practices in industry and government.
  • Risk management improved on NASA software projects.
• Utilize more predictable software cost estimates and delivery schedules.
  • Data shows projects working within Capability Maturity Model Integration (CMMI) software framework and its best practices have increased accuracy in cost estimates and smaller growth in resources over the life cycle.
• Educate NASA personnel, so that NASA is a smarter buyer during the acquisition of software.
  • Educating the NASA workforce on best practices in Software Engineering.
• Find and remove more software defects earlier in the life cycle.
• Reduce duplication of efforts between projects.
• Increase NASA's ability to meet the challenges of evolving software technology.
• Improve software development planning across the Agency.
  • There is a growing consensus among practitioners and software managers that working to a defined process has substantial benefits.
  • Vast improvement in planning of software projects and monitoring progress.
• Improve NASA's software contractor community with respect to software engineering practices.

See also SWE-032 - CMMI Levels for Class A and B Software.

See also Review - SWE-002 - Software Engineering Initiative for the requirement on the Software Engineering Initiative.

3.2 NASA Software Activity Motivations

Some of the key motivations for the NASA Software activities are to do the following:

1. Provide risk-based performance requirements that provide flexibility for the project Software Assurance and Software Safety activities.
2. Improve the risk, issue, and finding reporting from the NASA Software Assurance and Software Safety organizations.
3. Add value for Software Assurance and Software Safety activities and demonstrate the importance of the NASA Software Assurance activities.
4. Provide standard tools and services for Software Assurances activities on projects.
5. Provide measurable Software Assurance process improvement.
6. Improve the use of data and metrics on all NASA Software Assurance activities.
7. Focus on Software Assurance activities on known software issues, including targeting Software Assurance and Software Safety research activities.
8. Develop more efficient and automated methods for Software Assurance activities.
9. Establish a Software Assurance services and tool sharing capability.
10. Improve Software Assurance training and training requirements in the Safety and Mission Assurance Technical Excellence Program and across the agency.

See also SWE-086 - Continuous Risk Management

3.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

Software assurance applies to all projects.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

NASA based the need for software engineering improvement on a general recognition of the mixed state of its software development procedures and a string of visible failures in the space exploration program that was traced back to software errors. The NASA Lessons Learned database contains the following lessons learned related to the Mars exploration activities that illustrate the need for the NSEI:

• Probable Scenario for Mars Polar Lander Mission Loss (1998). Lesson Number 0938 ⁵²⁹:  NASA lost the Mars Polar Lander (MPL) mission in 1998 because not all hardware operational characteristics were captured in the software requirements, and because software test procedures did not take into account retest needs after software changes following a test failure. The MPL flight software did not take into account certain known hardware characteristics. The resulting mission-critical failure modes were not detected during the testing of the spacecraft. It was known that the touchdown sensors generated false momentary signals at leg deployment. This transient behavior was not properly accounted for in the software design. It is believed that these momentary signals were recorded as valid touchdown events, resulting in the engines shutting down at an altitude of 40 meters. The resultant free fall to the surface of Mars is viewed as the probable cause of the December 1999 MPL mission loss.

• Deficiencies in Mission Critical Software Development for Mars Climate Orbiter (1999). Lesson Number 0740 ⁵²¹:  The Mars Climate Orbiter (MCO) had deficiencies in its mission-critical software development. Upon arrival at Mars in September 1999, the MCO began a scheduled 16-minute Mars orbit insertion (MOI) maneuver to achieve orbit. Approximately 49 seconds before the anticipated occultation by Mars, communication was lost and never reestablished. The root cause of the mission loss was an error in the "Sm_forces" program output files. The JPL MCO review board determined that the files containing the magnitudes of the small impulses applied to the spacecraft had been delivered by the Spacecraft Operations Team to the Spacecraft Navigation Team in English units (pounds-force seconds) instead of the specified metric units (Newton-seconds). The erroneous engineering units provided by these files to the navigation software were not discovered in the walkthroughs of requirements, design, code, and testing. The Software Management and Development Plan (SMDP) was not followed in the walkthroughs of the "Sm_forces" software, and the overall training in the software walkthrough process was not adequate. Specifically, required persons were not always in attendance, the Software Interface Specification (SIS) was not used, minutes were not taken, and action items were not published.

6.2 Other Lessons Learned

• No other Lessons Learned have currently been identified for this requirement.