1. Requirements

2.1.1.1 The NASA OCE shall lead and maintain a NASA Software Engineering Initiative to advance software engineering practices. 

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. 

3. Guidance

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.   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. 

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 concerning software engineering practices.

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

3.1 Applicability

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.

See also:

• SWE-003 - Center Improvement Plans for the NPR 7150.2 requirement on Center Improvement Plans.
• SWE-005 - Software Processes, addresses Centers establishing an SEPG and a Process Asset Library.
• SWE-095 - Report Engineering Discipline Status requires reporting on the status of the Center’s software engineering discipline, as applied to its projects, upon request by the OCE, OSMA, or OCHMO.
• SWE-208 - Advancing Software Assurance and Software Safety Practices, requires that the NASA Chief, SMA shall lead and maintain a NASA Software Assurance and Software Safety Initiative to advance software assurance and software safety practices.

3.2 Engineering Infrastructure and SWG

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. See also SWE-100 - Software Training Funding, SWE-222 - Software Assurance Training. 

In coordination with Center software engineering improvement activities, a NASA-wide comprehensive approach for improving software engineering to quantifiable maturity levels commensurate with mission criticality to meet the software challenges of NASA. The Office of the Chief Engineer (OCE) leads the Agency Software Working Group (SWG) to provide assistance and guidance to the OCE in implementing and assessing this software engineering initiative.  The NESC Technical Fellow for Software oversees and approves the software engineering improvement plans, works with the NASA Centers to coordinate the organizational software improvement activities, reviews benchmark results of the Center's progress (see SWE-004 - OCE Benchmarking, SWE-209 - Benchmarking Software Assurance and Software Safety Capabilities), and oversees updates to these plans. 

3.3 Compliance Reviews

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 - OCE NPR Appraisals, SWE-221 - OSMA NPR Appraisals). 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.

3.4 Additional Guidance

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

3.5 Center Process Asset Libraries

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

4. Small Projects

This requirement primarily applies to the Office of the Chief Engineer (OCE) at headquarters and 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. 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.