bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

Versions Compared

Old Version 12

changes.mady.by.user Haigh, Fred

Saved on

compared with

New Version Current

changes.mady.by.user Tim Crumbley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Excerpt Include
2D-Topic Page Message
2D-Topic Page Message
nopaneltrue

Show If
spacePermissionedit
Panel
borderColorred
titleVisible to editors only

Content updates needed on this page: 

  1. Update tabs as necessary
  2. Update References as necessary
  3. Update Lessons Learned as necessary
  4. Update space code in macros and links as needed - 11/19 - none
Expand


Set Data
hiddentrue
namereftab
4
Excerpt
hiddentrue

Addresses the history of the NASA software improvement efforts to provide a background for the development of this electronic handbook

Tabsetup
1. Purpose
1. Purpose
12. NASA Software Engineering Initiative
23. Conclusion
34. Resources
45. Lessons Learned
), as well as the increasing costs of software development, encouraged NASA to address the software engineering approaches used in the Agency. In 1976, the first NASA Software Engineering Workshop was held to address these issues. In the late 1980s, NASA followed up these efforts with the kickoff of a Software Management and Assurance Program (SMAP).


From these initial activities came the impetus for the NASA Software Engineering Initiative (NSEI) at the beginning of the new century. NSEI came into existence as one of the three basic components of NASA's Engineering Excellence Initiative (EEI). (Systems Engineering and Project Engineering are the other two main components.)

In 2004, the NASA Software Assurance Research Program (SARP) Software Research Infusion Initiative began. 

Div
idtabs-1

1. Purpose

NASA’s software engineering capability is a cornerstone of mission success. NPR 7150.2, NASA’s Software Engineering Requirements directive, has been central to standardizing practices and improving software reliability across the Agency.

Historical Context

  • 1960s–1970s: Early space missions revealed software reliability challenges, including Apollo 11 lunar landing alarms (1969).
  • 1976: NASA held its first Software Engineering Workshop to address software quality and reliability.
  • Late 1980s: Software Management and Assurance Program (SMAP) introduced to improve oversight.
  • 2000–2002: NASA Software Engineering Initiative (NSEI) launched under Engineering Excellence Initiative to integrate software engineering and assurance principles across Centers.

NPR 7150.2 – 20 Years of Evolution

NPR 7150.2 was first issued in 2004 to establish a unified set of software engineering requirements across NASA. Below are detailed revision summaries:

  • Initial Release (2004): Introduced baseline requirements for software engineering, focusing on consistency and compliance across Centers.
  • Revision A (2009): Incorporated lessons learned from early implementations and aligned with evolving mission-critical software needs.
  • Revision B (2013): Expanded coverage for software assurance and safety, reflecting increased emphasis on risk management and IV&V.
  • Revision C (2017): Integrated updates for cybersecurity, model-based engineering, and clarified tailoring guidance.
  • Revision D (2022): Strengthened alignment with NPR 7123.1 (Systems Engineering), added explicit requirements for software assurance and safety (NASA-STD-8739.8), and emphasized continuous improvement and metrics-driven maturity.

Key Changes Over Time

  • Early focus: Basic compliance and standardization.
  • Mid-phase: Added assurance, safety, and IV&V requirements.
  • Recent updates: Cybersecurity, advanced modeling, and continuous improvement.
  • Cultural shift: From compliance-driven to performance-driven, emphasizing metrics and maturity models.

Impact on Software Assurance and Engineering

NPR 7150.2 provides structured requirements for design, development, and verification (Software Engineering) and ensures compliance with safety standards and risk mitigation strategies (Software Assurance). Together, they create a dual framework for technical rigor and mission safety.

Lessons Learned

NASA’s experience underscores the importance of Independent Verification & Validation (IV&V), early defect detection, and continuous improvement to adapt to evolving technologies and mission needs.This topic addresses the purpose of the NASA software improvement efforts and provides an overview of the activities for software process improvement.  

1.1 Introduction

Software engineering is a core capability and a key enabling technology for NASA's missions and supporting infrastructure.

Panel
borderColorblue
titleNPR7150.2D
Set Data
nameQ1-083
 1.1.3 The Agency makes significant investments in software engineering to support the Agency’s investment areas: Space Flight, Aeronautics, Research and Technology, Information Technology (IT), and Institutional Infrastructure. NASA ensures that programs, projects, systems, and subsystems that use software follow a standard set of requirements. One of the goals of this directive is to bring the Agency’s engineering and software development and management communities together to optimize resources and talents across Center boundaries. For NASA to effectively communicate and work seamlessly across Centers, a common framework of generic requirements is needed.

Swerefn
refnum083

NASA's software development activities began with the earliest projects headed to space (Gemini, 1962

Swerefn
refnum408
). Usually, the software activities were project-specific and were created with a particular project in mind. Often, the spacecraft design dictated the size and shape of the computer. New software development was required because software adaptation and reuse were essentially non-existent, because of unique platforms, individual programming styles, and the relative non-existence of other software.

The early occurrence and recognition of software issues (software faults caused computer restarts during the Apollo 11 lunar landing in 1969

Swerefn
refnum409
Swerefn
refnum204
 This initiative encourages the uptake of new research results within real NASA missions. A key success feature is realized when a NASA Center adds the research product resulting from an initiative to its list of recommended practices. Also in 2004, the Office of the Chief Engineer (OCE) conducted the first annual software inventory and issued the initial version of NPR 7150.2. The Office of Safety and Mission Assurance (OSMA) completed the updates to NASA-STD-8719.13, Software Safety Standard,
Swerefn
refnum271
  and NASA-STD-8739.8, Software Assurance Standard. 
Swerefn
refnum278
 )

Note

NPR 7150.2

Swerefn
refnum083
is written in the "shall" statement format with supplemental information in the form of accompanying notes and appendices. While these were included to help explain the meaning of each requirement, it was recognized that additional detail on the scope and the applicability of each SWE would increase the speed of cultural change and adoption of these software requirements. This Handbook, NASA-HDBK-2203, was established in wiki format to help achieve the above goals. 

See SWE-139 - Shall Statements in this handbook for the requirement. 

During the development of the NPR 7150.2, there was an intentional effort to minimize the size of the document by keeping it focused on the requirements. However, the 7150 teams had developed a large amount of additional guidance material for the NPR, which they decided could be more effectively utilized in a NASA Handbook rather than in the NPR itself. Therefore, after the OCE released NPR 7150.2A, the effort to develop this electronic Handbook in wiki format was initiated.         


Div
idtabs-2

2. NASA Software Engineering Initiative

NASA Software Engineering Initiative

Overview

Software engineering is a core capability and a key enabling technology necessary for the support of NASA's Enterprises. Surveys and assessments identified and documented many software challenges within the Agency. Additionally, continuing exponential growth in the scope, complexity, and importance of software within NASA systems challenged the Agency's ability to manage it effectively. As a result, the NASA Headquarters OCE formed the NASA Software Engineering Initiative 

Swerefn
refnum205
 in 2002. In coordination with Center software engineering improvement activities, the OCE defined a NASA-wide comprehensive approach for improving software engineering to for NASA’s missions and supporting infrastructure. Over time, surveys and assessments revealed significant challenges in software development across the Agency, including increasing complexity, cost, and risk. To address these issues, NASA Headquarters’ Office of the Chief Engineer (OCE) launched the NASA Software Engineering Initiative (NSEI) in 2002. This initiative established a NASA-wide, comprehensive approach to improve software engineering processes and achieve quantifiable maturity levels commensurate with mission criticality to meet the software challenges of NASA.

What is

it

the Initiative?

A coordinated, Agency-wide effort to:

  • Standardize and improve
    • NASA-wide comprehensive approach for improving
  • software engineering processes
    • and technology
  • .
  • Infuse advanced tools and technologies.
  • Elevate software assurance practices alongside engineering.

Why

are we doing it

Was It Created?

To meet

the challenges facing NASA in software engineering (schedule, cost, meet project commitments, and ensuring the use of best practices).
  • What are the elements of OCE’s approach?
    • The integration of sound software engineering principles and standards.
    • Enhancing software engineers' knowledge and skills.
    • The use of the Software Engineering Institute's Capability Maturity Model as a benchmark for assessments.
    • Software engineering tool infusion.
    • Software metrics.

    • NASA’s software challenges:

    • Increasing schedule and cost pressures.
    • Growing complexity of mission-critical software.
    • Need for consistent application of best practices across Centers.

    Key Elements of NASA’s Approach

    • Integration of principles: Combine sound software engineering and software assurance standards.
    • Workforce development: Enhance knowledge and skills of engineers and assurance personnel.
    • Benchmarking: Use the Integrated Capability Maturity Model for assessments.
    • Tool infusion: Deploy modern software engineering tools.
    • Metrics: Collect and analyze software metrics to drive improvement.

    Who Deploys It

    Who is deploying it

    ?

    • OCE in collaboration with
      • each Center and the
    • :
      • NASA Engineering and Safety Center (NESC
      • ).NASA Software Working Group.
    • Center projects, organizations, and working groups.

    The following key principles guide NASA's software improvement activities:

    • Reduce the risk of software failure - Increase mission safety.
    • Improve how defects are found and remove the defects early in the development cycle.
    • Improve processes based on best practices in Industry and Government.
    • Provide more predictable software cost estimates and delivery schedules.
    • Create smarter buyers for contracted out software projects.
    • Educate the NASA workforce on best practices in Software Engineering.
    • Reduce duplication of efforts between projects in the area of software.
    • Increase NASA’s ability to meet the challenges of evolving software technology.
    This initiative covers software process improvement, as well as items related to software research: software safety, reliability, and quality; attraction and retention of software engineers, and improvement of NASA's software engineering knowledge and skills. It applies to both
      • )
      • Office of Safety and Mission Assurance (OSMA)
      • NASA IV&V Facility
      • Center software working groups and projects

    Guiding Principles

    • Develop efficient, automated methods.
    • Improve risk, issue, and defect reporting.
    • Reduce software failure risk and increase mission safety.
    • Detect and remove defects early in the lifecycle.
    • Apply industry and government best practices.
    • Provide predictable cost and schedule estimates.
    • Educate NASA workforce on software engineering excellence.
    • Reduce duplication of effort across projects.
    • Adapt to evolving software technologies.

    Scope

    The initiative addresses:

    • Process improvement for mission-critical and non-mission-critical software
    .
    • .
    • Software safety and quality.
    • Workforce development and retention.
    • Knowledge sharing through a Software Community of Practice.

    What It Provides

    The initiative provides:

    • Technical support for
      • NASA
    • project issues and special studies.
      • Serves as
    • Agency
      • &
    • and NESC subject matter
      • experts for the software technical discipline
    • expertise.
      • Recommends, reviews, and maintains software
    • Recommendations and maintenance of requirements, policies,
      • processes, standards, best practices, and handbooks. Maintains NASA internal
    • and standards.
    • Internal and external assessments
      • (CMMI)
    • of software development organizations.
      • Maintains and supports reporting
    • Reporting on the state of the software discipline.
      • Coordinates
    • Coordination of external
      • NASA
    • interfaces for software engineering.
    • Maintains a list of top software engineering discipline topics and or challenges.
    • Collects and analyses project software engineering metrics and proactively identify discipline issues & concerns that require additional investigation (identification of trends).
    • Supports/lobbies for continued funding of Center Software Improvement Programs.
    • Promote/integrate continuous improvement of software processes.
      • Maintains a software Community of Practice site and knowledge management for the software community
    • Collection and analysis of software metrics to identify trends.
    • Continuous improvement of software processes.
    • Knowledge management and community engagement.


    Review - SWE-002 - Software Engineering Initiative is the NPR 7150.2 requirement for the Software Engineering Initiative. 

    Review - SWE-005 - Software Processes is the NPR 7150.2 requirement for the Software Processes. Addresses Centers establishing an SEPG and a Process Asset Library. 

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

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


    Div
    idtabs-3

    3. Conclusion

    Ensuring the quality, safetyreliability, and reliability safety of NASA software is of paramount importance in essential to achieving mission success for the across all Agency 's programs and projects. The NASA Software Process Improvement Initiative brings together an integrated spectrum of software engineering professionals, researchers, trained practitioners, improved processes, ratings and appraisal systems, accredited tools, and numerous engineering productivity tools to promote software improvement and overall excellence serves as a cornerstone for this effort by uniting a diverse ecosystem of expertise—software engineers, assurance specialists, researchers, and practitioners—with proven processes, maturity models, and advanced tools. Through integrated standards, accredited methodologies, and productivity-enhancing technologies, the initiative drives continuous improvement, reduces risk, and promotes engineering excellence. Ultimately, this collaborative approach strengthens NASA’s ability to deliver robust, mission-critical software that meets the highest standards of performance and safety.

    Div
    idtabs-4

    4. Resources

    4.1 References

    refstable-topic

    Show If
    groupconfluence-users
    Panel
    Visible to editors only
    titleColorred
    titleInstructions for Editors
    Expand

    Enter the necessary modifications to be made in the table below:

    SWEREFs to be addedSWEREFS to be deleted


    SWEREFs called out in text: 083, 204, 205, 271, 278, 408, 409, 518

    SWEREFs NOT called out in text but listed as germane: 038, 040, 157, 170, 255, 257, 290, 389

    Related Links Pages

    Children Display


    4.2 Tools


    Include Page
    Tools Table Statement
    Tools Table Statement

    4.3 Additional Guidance

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

    Related Links

    Include Page
    7.01 - Related SWEs
    7.01 - Related SWEs

    Include Page
    7.01 - Related SM
    7.01 - Related SM

    4.4 Center Process Asset Libraries

    Excerpt Include
    SITE:SPAN
    SITE:SPAN
    nopaneltrue

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

    SPAN Links

    Include Page
    SITE:SPAN Center Libraries
    SITE:SPAN Center Libraries



    Show If
    labelactivity

    4.5 Related Activities

    This Topic is related to the following Life Cycle Activities:

    Related Links


    Include Page
    7.01 - Related Activities
    7.01 - Related Activities
    Div
    idtabs-5

    5. Lessons Learned

    5.1 NASA Lessons Learned

    A documented lesson from the

    NASA Lessons Learned

    database notes the following: Independent Verification and Validation of Embedded Software, Lesson Number 0723
    Swerefn
    refnum518
    :     Besides the recognition of the need for extensive project retesting (see the Introduction section for computer restarts
    Swerefn
    refnum409
    ), this lesson learned indicates the need for independent verification of performance results because of recognition of earlier problems, e.g., failure to perform IV&V for software projects could result in software system weaknesses, performance of unintentional functions, and failure of the system and the mission. Anything less than a methodical, systematic rigorous treatment of IV&V could cause loss of mission, life, and valuable resources.   

    : SWEHB & Software Engineering Initiative

    From the SWEHB History & SPI Effort (Topic 7.01)

    • Defects found early drive improvement
      Evaluations of research-infused tools—like orthogonal-defect classification and code static-analysis tools—revealed defects that traditional testing missed. These insights led to adoption of new techniques across Centers

    • Assessment ensures maturity growth
      Tracking SCAMPI/CMMI appraisals from FY07–FY10 showed growth in organizational maturity at major Centers, reinforcing the value of structured improvement

    • Wiki lifecycle enables ongoing enhancement
      Shifting NPR 7150.2 guidance to a living wiki (SWEHB) allowed continual content updates based on real project experiences, improving adoption and cultural change

    From 25 Years of GSFC Software Engineering Laboratory (SEL)

    • Data-informed process evolution
      SEL’s work showed the importance of collecting project data and analytics to guide software process improvements, avoiding reliance on anecdote

    • Need for institutional support
      SEL’s impact declined due to shifting NASA priorities and resource constraints. Lesson: sustaining improvement requires active Agency-level sponsorship

    From NASA Lessons Learned Information System (LLIS)

    • Lessons need closed-loop integration
      Audits revealed that merely storing lessons isn’t effective. JPL demonstrated success by incorporating lessons learned compliance assessments at each project milestone

    • Proactive infusion accelerates uptake
      JPL’s strategy to embed lessons into procedures and training institutionalized learning, rather than relying on individual awareness

    These lessons highlight key strategies for software excellence:

    • Leverage practical tools and metrics to uncover and fix defects early.
    • Pair Agency-wide leadership with sustained funding to drive lasting process improvement.
    • Use living handbooks (like SWEHB) for continuous refinement of guidance.
    • Integrate lessons learned systematically into procedures, training, and project milestones.

    Would you like me to include a table summarizing each lesson with its source and impact for easy reference in your newsletter or presentation?

    Here are key NASA lessons learned associated with the SWEHB Handbook and the NASA Software Engineering Initiative:

    ✅ Lessons from SWEHB & SPI Effort

    • Early Defect Detection Improves Quality
      Research-infused tools (e.g., orthogonal defect classification, static analysis) uncovered defects missed by traditional testing, leading to adoption of advanced techniques across Centers.
      Impact: Reduced mission risk and improved software reliability.

    • Continuous Improvement via Wiki Handbook
      Moving NPR 7150.2 guidance into a living wiki (SWEHB) enabled ongoing updates based on real project feedback, accelerating cultural adoption of best practices.

    • Maturity Assessments Drive Progress
      SCAMPI/CMMI appraisals showed measurable growth in Center process maturity, validating structured improvement approaches.

    ✅ Lessons from NASA Software Engineering Laboratory (SEL)

    • Data-Driven Process Evolution
      SEL demonstrated that collecting and analyzing project data is critical for guiding effective process improvements—avoiding reliance on anecdotal fixes.

    • Institutional Support is Essential
      SEL’s decline due to shifting priorities and budget cuts underscores that sustained improvement requires strong Agency-level sponsorship.

    ✅ Lessons from NASA LLIS (Lessons Learned Information System)

    • Closed-Loop Integration is Key
      Simply storing lessons isn’t enough. JPL improved uptake by embedding lessons into procedures and training, ensuring they influence projects at the right time.

    • Milestone-Based Compliance Works
      JPL’s practice of assessing lessons learned applicability at major reviews helped prevent mission risks (e.g., thruster plume impingement on MER).

    5.2 Other Lessons Learned

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

    ...

    Page Editor: Tim Crumbley
    NASA Official: Tim Crumbley
    Accessibility
    NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer
    NASA Privacy Statement
    ______________________________________________________________________________