1. Requirements

1.1 Notes

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

1.2 History

2. Rationale

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 engineering is defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, i.e., the application of engineering to software.  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 engineering, which is considered to be a core competency for the Agency. The Software Engineering Initiative Plan (SEIP) addresses this objective.

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 in monitoring progress.
• Improve NASA's software contractor community with respect to software engineering practices.

3. Guidance

This requirement primarily applies to the NASA Headquarters Office of the Chief Engineer (OCE). The requirement states that the leadership of the NASA Software Initiative resides with the NASA OCE.  The OCE has the responsibility to lead, maintain, and fund the Agency leadership and Agency-wide Software Initiative activities.  Centers have the responsibilities to lead, maintain, and fund the Center software improvement activities and Center or organizational software process activities, including the flow down of Agency policies and requirements into Center or organizational processes, requirements, and policies.  The final decision on the direction and selection of implementation approaches for the NASA Software Engineering Initiative is made by the NASA OCE.

The NASA Software Engineering Initiative (NSEI) began in 2002. The SEIP "defines a NASA-wide comprehensive approach for improving software engineering to a quantifiable maturity level commensurate with mission criticality in order to meet the software challenges of NASA."  NASA's plan employs common frameworks for software process improvement, which it does through the establishment and maintenance of engineering infrastructure. This approach includes the implementation of advanced practices, the establishment of integrated requirements set, and integrated training in advanced software engineering. The OCE assures the achievement of these activities by providing funding and coordination.

NSEI came into existence as one of the three basic components of the NASA Engineering Excellence Initiative (EEI). (Systems engineering and project engineering are the other two main components.)  In coordination with Center software engineering improvement activities, the Software Engineering Initiative Plan (SEIP)contains a NASA-wide comprehensive approach for improving software engineering to quantifiable maturity levels commensurate with mission criticality in order to meet the software challenges of NASA. As a part of the SEIP, the Office of the Chief Engineer (OCE) leads the Agency Software Working Group (SWG) to provide assistance and guidance to the OCE for implementing and assessing this software engineering initiative.  The OCE's Program Executive for Software oversees and approves Center Software Engineering Improvement Plans, Center Software Training Plans (see 5.10 - STP - Software Test Plan), reviews benchmark results of the Center's progress (see SWE-004), and oversees updates to these plans. 

Because the requirements in this NPR also incorporate elements of best practices, the OCE assesses the Centers' use of these practices through the compliance review of these requirements (see SWE-129). Because all NASA projects and activities have a finite length, the Centers and their software engineering organizations are expected to capture, maintain and support the software engineering improvement activities within their Center activities once the OCE Software Engineering Initiative concludes.

4. Small Projects

This requirement primarily applies to the Office of the Chief Engineer (OCE) at headquarters and to the performing Centers executing projects.  The size of the project is not relevant to this requirement.

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. Resulting mission-critical failure modes were not detected during 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.