1. Requirements
2.2.1.1 The project shall develop software plan(s).
1.1 Notes
Note: The requirement for the content of each software plan (whether stand-alone or condensed into one or more project level or software documents) is defined in Chapter 5 [section 5.1 of NPR 7150.2, NASA Software Engineering Requirements].
. These include, but are not limited to:
a. Software development or management plan.
b. Software configuration management plan.
c. Software test plans.
d. Software maintenance plans.
e. Software assurance plans.
Note: Software engineering and the software assurance disciplines are integrally related and yet each has its own responsibilities. Jointly they are responsible for providing project management with the optimal solution for software to meet the engineering, safety, quality, and reliability needs of the project. This necessitates a close working relationship to assure the appropriate levels of effort for both. See NASA-STD-8739.8 [Software Assurance Standard]. 278 for more details on development of a software assurance plan.
1.2 Applicability Across Classes
Classes D non-safety critical, E non-safety critical, and G are labeled with "P (Center)." This means that an approved Center-defined process that meets a non-empty subset of the full requirement can be used to achieve this requirement.
Class |
A_SC |
A_NSC |
B_SC |
B_NSC |
C_SC |
C_NSC |
D_SC |
D_NSC |
E_SC |
E_NSC |
F |
G |
H |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Applicable? |
|
|
|
|
|
|
|
P(C) |
|
P(C) |
|
P(C) |
|
Key: A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... |
- Applicable |
- Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures
2. Rationale
As with any activity that involves multiple tasks and functions, software development requires thought before implementation. The team documents and reviews those thoughts and plans before implementation to allow for consideration of all the tasks, methods, environments, tools, and related criteria needed to complete the work. Planning helps the team efficiently produce what is needed and expected as well as provides a means for communications and partnering with customers and stakeholders on the implementation of the project. Planning also allows a current project to improve based on lessons learned from previous projects, including using more appropriate or efficient techniques and avoiding previously experienced difficulties.
Having plans also allows the team to review, improve, and verify software activities before implementation to ensure the outcome will meet the expectations and goals of the project. Planning also helps to ensure the project is cost-efficient and timely.
3. Guidance
Software plans are to be complete, correct, workable, consistent, and verifiable.
Per NASA-STD-8739.8, product assurance is performed to assure that "All of the required plans (e.g., configuration management, risk management, provider's assurance plan, software management plan) are documented, adhere to applicable standards and procedures, are mutually consistent, and are being executed." 278 For this reason, it is important to follow documented standards, policies, and requirements for format and content of software plans.
When developing software plans for a project, consider using templates for the content of each required plan to ensure consistent content and application across projects. Keep in mind that tailoring may be necessary for a particular project, especially given different safety and software classifications that may apply.
Plans "specify the standards and procedures for management, acquisition, engineering, and assurance activities." 278 This includes documenting the work products, tasks, resources, commitments, schedules, and risks for the project, as well as describing strategies for development or acquisition, data management, risk management, stakeholder management, and measurement and analysis. See the related requirements list at the end of this guidance section for plans and content required by NPR 7150.2, NASA Software Engineering Requirements. Guidance for those requirements includes additional references which may be used when developing each specific plan.
Per the NASA Systems Engineering Handbook, 273 many software plans are drafted during Phase A, Concept and Technology Development, including risk management plans, configuration management plans, safety and mission assurance plans, software development or management plans, and verification and validation plans.
Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews provides guidance for the maturity of plans at various life cycle reviews.
See SWE-014 for guidance on maintaining and implementing software plans once they are baselined.
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to software plans, including responsibilities for producing software plans.
Additional guidance related to software plans may be found in the following related requirement in this Handbook:
Software Development/Management Plan | |
Software CM Plan | |
Software Test Plan | |
Software Maintenance Plan | |
Software Assurance Plan | |
Software Safety Plan |
4. Small Projects
Projects with limited budgets or personnel may consider combining several plans into a single plan, devoting sections of the larger plan to specific planning topics.
5. Resources
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-157) CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-271) NASA STD 8719.13 (Rev C ) , Document Date: 2013-05-07
- (SWEREF-273) NASA SP-2016-6105 Rev2,
- (SWEREF-278) NASA-STD-8739.8B, NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A"
- (SWEREF-695) The NASA GSFC Lessons Learned system. Lessons submitted to this repository by NASA/GSFC software projects personnel are reviewed by a Software Engineering Division review board. These Lessons are only available to NASA personnel.
5.1 Tools
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.


