bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

SWE-013 - Software Plans

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:

SWE-102

Software Development/Management Plan

SWE-103

Software CM Plan

SWE-104

Software Test Plan

SWE-105

Software Maintenance Plan

SWE-106

Software Assurance Plan

SWE-138

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

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.