What does the software quality process for NASA's SLS look like? What are the relevant standards that they have to comply to? Do they have to show that they are CMMI compliant, for example? I'm interested in avionics in particular, but basically everything that is going to space. What kind of tools and software are they employing to reach their goal?

I am aware of this fantastic piece over at fastcompany, but it describes the space shuttle era. There does not seem to be current information available.

  • $\begingroup$ Before I gave up on it, nasawatch.com used to regularly post alarming articles about SLS software quality. You could check there. $\endgroup$ Commented Nov 28, 2017 at 16:03
  • $\begingroup$ @OrganicMarble Why did you give up on nasawatch? Quickly skimming through their site, it sounds alarming indeed. Can they be taken serious? $\endgroup$
    – mike
    Commented Nov 28, 2017 at 16:09
  • $\begingroup$ I got tired of the site owner insulting people (including me) in comments, and banning other folks who insulted people in comments. Plus, it's been pretty boring to read since shuttle ended. You will have to make your own judgment on its credibility. $\endgroup$ Commented Nov 28, 2017 at 16:16
  • 1
    $\begingroup$ A coworker of mine thinks it's the NASA Procedural Requirements 7102.7 and 7120.8. Moreover, they also use CMMI standards (which level, no idea). $\endgroup$
    – ChrisR
    Commented Nov 29, 2017 at 11:01
  • 1
    $\begingroup$ I have submitted a FOIA request for this, in the meantime, you can find some info on the Software Components here (on page 19) $\endgroup$
    – Mark Omo
    Commented Sep 17, 2018 at 17:50

2 Answers 2


I have retrieved via FOIA request the "Space Launch System Program (SLSP), Flight Software Application, Software Assurance Plan (SAP)". It is the core document describing the software development processes for the Flight computer (the bit responsible for on-pad prelaunch, launch, and ascent of the SLS vehicle) and the Green Run Application Software (software for ground testing of the control hardware) as well as 13 other utilities.

Space Launch System Program (SLSP), Flight Software Application, Software Assurance Plan (SAP)

It outlines everything from the software standards, practices, and conventions for the software development effort, to information on the Software Development Facility (SDF).

The Flight Software for the SLS is defined as Class A software which means that it is developed to meet the highest standards and undergoes extensive review and verification.

Applicable Standards (Pg. 12-13, section 2.0) :

  • SLS-PLAN-180 Space Launch System (SLS) Program Risk and Opportunity Management Plan
  • SLS-RQMT-014 Space Launch System (SLS) Safety and Mission Assurance (SMA) Requirement Document
  • NASA-STD-8739.8 NASA Software Assurance Standard
  • NPR 7150.2B NASA Software Engineering Requirements
  • IEEE 730-2002 [PDF] IEEE Standard for Software Quality Assurance Plans
  • NASA-STD-8719.13 Software Safety Standard
  • And a large number of NASA documents that are not available on the internet like requirements administrative standards, processes, and procedures, etc...

Tools used in the software assurance processes (Pg. 37, section 9.1):

Tools used in the software assurance processes

You can find the full pdf here

  • 1
    $\begingroup$ Is there a way I can provide a post-submission bounty on this answer? This is VERY insightful! $\endgroup$
    – ChrisR
    Commented Oct 24, 2018 at 5:39
  • 1
    $\begingroup$ @ChrisR Thanks! You can see here: stackoverflow.blog/2010/06/19/improvements-to-bounty-system $\endgroup$
    – Mark Omo
    Commented Oct 24, 2018 at 5:41
  • 1
    $\begingroup$ Thanks! It seems like I can only award it in 23 hours. Standby for bounty ;-) $\endgroup$
    – ChrisR
    Commented Oct 24, 2018 at 5:43

A good starting point is NASA Software Engineering Requirements NPR 7150.2B

3.6 Software Assurance and Software IV&V 3.6.1 The project manager shall plan and implement software assurance per NASA-STD-8739.8. [SWE-022] Note: Software assurance activities occur throughout the life of the project. Some of the actual analyses and activities may be performed by engineering or the project. 3.6.2 For projects reaching Key Decision Point (KDP) A after the effective date of this directive's revision, the program manager shall ensure that software IV&V is performed on the following categories of projects: [SWE-141]

a. Category 1 projects as defined in NPR 7120.5.

b. Category 2 projects as defined in NPR 7120.5 that have Class A or Class B payload risk classification per NPR NPR 7150.2B -- Chapter3

c. Projects specifically selected by the NASA CSMA to have software IV&V.


3.6.3 If software IV&V is performed on a project, the project manager shall ensure that an IV&V Project Execution Plan (IPEP) is developed. [SWE-131] Note: The scope of IV&V services is determined by the project and the IV&V provider, and is documented in the IPEP. The IPEP is developed by the IV&V provider and serves as the operational document that will be shared with the project receiving IV&V support. In accordance with the responsibilities defined in NPD 7120.4, section 5.J.(5), projects ensure that software providers allow access to software and associated artifacts to enable implementation of IV&V. A template and instructions for an IPEP may be found in the NASA IV&V Management System, accessible at http://www.nasa.gov/centers/ivv/ims/home/index.html

3.7.1 When a project is determined to have safety-critical software, the project manager shall implement the requirements of NASA-STD-8719.13. [SWE-023]

SLS would fall in class A (human-rated).

More on the flight control system for SLS:

The fundamental design paradigms that shaped the development of the architecture are as follows:
1. Rely on simple, proven, flight-tested algorithms and processes. Based on a heritage of more than fifty years of successful NASA flight controls development for large boosters, the use of classical PID control, multi-station rate gyro blending, linear optimal bending filters, and gain scheduling is retained.
2. Enhance algorithm capability when warranted with compact and verifiable methods. The use of optimal reconfigurable linear control allocation has been employed to maximize control authority and enhance fault tolerance, and a novel mechanization of classical load relief has been applied. In addition, robustness enhancement is obtained through the use of a simple model reference adaptive control scheme.
3. Maximize robustness to failures. As a program requirement, tolerance of at least one engine failure at any point in the flight regime with negligible impact to flight control performance is supported by the architecture. Robustness to sensor failures and severe off-nominal conditions has been demonstrated through rigorous simulation analysis.
4. Seamlessly integrate with the SLS program to facilitate flight certification. In support of concise communication of the design margin from the flight controls element, new metrics, such as the flight control Technical Performance Metric (TPM), are used to facilitate straightforward assessment of the design’s merit and the vehicle capability at the system engineering level.

This presentation gives a high-level overview of the development process.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.