1. Software Principles at NASA

This topic contains the Guiding Principles that have been built over the years at NASA. These Principles are designed to help projects be successful by reducing the likelihood of defects.

1. The software design principles presented here represent a consensus view of best practices in the design of mission-critical Class A and B software at NASA. They were selected with participation from several Centers, representing the major disciplines in embedded real-time software: launch systems, manned systems, and robotic missions.
2. The design principles focus on features and characteristics that are typically found in high-quality embedded software applications. They should be familiar to the experienced embedded software professional. However, they include only those principles that were deemed common across all Centers and disciplines. In the course of development, many good ideas were not selected for inclusion because they were specific to a particular mission or application type. However, application-specific approaches and interpretations are included in the discussion section accompanying each principle to convey the kinds of variations that might be introduced.
3. It is important to understand what the design principles are, and what they are not. They are a distillation of decades of experience in the kind of embedded software that has enabled NASA’s most spectacular achievements. They can be used as a source of design criteria both in development and at review time. Training materials for new developers can draw upon them. Individual projects and organizations can use them as a reference in the development and implementation of local standards and processes.
4. The design principles are not requirements. They do not supersede design principles already in place at NASA Centers. There is no requirement to justify using a different set of design standards, nor are waivers for deviation from the principles required. The design principles here are not a complete statement about what makes for good embedded software design. Organizations and projects that choose to adopt them are encouraged to tailor and elaborate these principles to their specific situation.

1.1 Structure of the Software Principle Topics

Principle statements are deliberately brief to avoid including the detail that might not be universally applicable. Each principle has a short rationale that expresses why it was considered important enough to include in the Agency-wide set of design principles.

Following this is a section entitled “Examples and Discussion” that elaborates on the principle. Depending on the topic, this section may provide life cycle guidance, discussion of techniques commonly used to implement the principle, and implementation considerations.

When applicable entries from the NASA Lessons Learned ⁴³⁹  database are available, links to these entries are also included in the Examples and Discussion section. Lessons Learned often highlight a subtle aspect of a design principle or identify an opportunity to consider how the application of a principle might have helped avoid an incident. In a handful of cases, there are positive lessons learned that support adoption of the related principle.

Each principle was derived from one or more source materials. Where this material is not included in the Examples and Discussion section, it is included in a concluding section entitled “Inputs”. Inputs may be from works in progress furnished to the team, or from official standards. The Center responsible for the input material is identified by a subheading preceding that Center’s material.

Each principle has the same basic structure:

1. Principle and Rationale - a simple statement of the principle together with a short explanation of why the principle is important.
2. Examples - detailed description and discussion of the principle from an engineering perspective. Includes an analysis of the supporting data.
3. Inputs - Additional material usually from one or more Centers. Includes Center specific application of the principle.
4. Resources - List of resources referenced in one or more tabs on the page, with links to the actual reference.
5. Lessons Learned - descriptions and links to the appropriate Lessons Learned referenced on the page.

1.2 Support for NASA Software Safety Standard

• The NASA software design principles provide considerable support for the implementation of the NASA software safety requirements found in the NASA Procedural Requirement for software engineering (NPR 7150.2, SWE-134 - Safety-Critical Software Design Requirements ). It may be possible to demonstrate compliance for the design-related parts of the requirement through verified adherence to the design principles. See 9.02 Software Safety and Design Principles for a compliance matrix and discussion.

2. Resources

2.1 References

• (SWEREF-439)
  NASA Public Lessons Learned System
  The NASA Lessons Learned system. The system provides access to official, reviewed lessons learned from NASA programs and projects.
• (SWEREF-670)
  Space Flight System Design and Environmental Test
  ARC - APR 8070.1 This document defines engineering design and environmental test requirements and guidelines for Class C and D space flight systems.
• (SWEREF-671)
  JPL-D-17868 (REV.1), JPL GUIDELINE: DESIGN, VERIFICATION/VALIDATION AND OPERATIONS PRINCIPLES FOR FLIGHT SYSTEMS (16 FEB 2001)
  JPL: DocID 43913, Rev. 1
• (SWEREF-672)
  Rules for the Design, Development, Verification, and Operation of Flight Systems
  GSFC-STD-1000F, Approved: 02-08-2013 - With Administrative Changes , Expiration Date: 02-08-2018, Superseding GSFC-STD-1000E

2.2 Additional Guidance

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

2.3 Center Process Asset Libraries

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