1. Requirements

3.1.2 The project manager shall develop, maintain, and execute software plans that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring. 

1.1 Notes

The recommended practices and guidelines for the content of different types of software planning activities (whether stand-alone or condensed into one or more project level or software documents or electronic files) are defined in the NASA-HDBK-2203.

1.2 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Software plans describe the activities and processes that will be carried out and the products that will be produced to fulfill project requirements for software. These plans are created to guide the work and increase the expectations of meeting project objectives and goals. To fulfill this purpose, the plans need to be followed and kept up-to-date as project requirements change. 

3. Guidance

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.

Software plans include, but are not limited to:

1. Software development or management plan.
2. Software configuration management plan.
3. Software test plans.
4. Software maintenance plans.
5. Software assurance plans.
6. Software safety plan, if safety-critical software.

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 should “specify the standards and procedures for management, acquisition, engineering, and assurance activities.” ²⁷⁸   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 topic 7.18 - Documentation Guidance for recommended plans and content which support the activities that are required by NPR 7150.2.  Topic 7.18 - Documentation Guidance includes additional references which may be used when developing each specific plan. See NASA-STD-8739.8 ²⁷⁸  for more details on development of a software assurance plan and NASA-STD-8719.13 ²⁷¹  for details on development of a software safety plan.

Topic 7.08 - Maturity of Life-Cycle Products at Milestone Reviews provides guidance for the maturity of several project plans at various life-cycle reviews. 

Once software plans have been baselined, consider the following guidance for maintaining and implementing them.

While the Project Manager is responsible for executing the project plan, a software or development team lead may ensure execution and maintenance of software plans.

Baseline plans before they are implemented to ensure that only approved plans are executed by the project team. For Space Flight Projects the expected maturity (draft, preliminary, baselined, updated, and final) of plans at the various milestone reviews are provided in this Handbook's topic 7.08 - Maturity of Life-Cycle Products at Milestone Reviews matrix. Once software plans are approved and baselined, projects are expected to follow these plans. To ensure plans are followed, projects typically implement project monitoring and control (see SWE-024) and software assurance processes. Per NASA-STD-8739.8, Software Assurance Standard,  ²⁷⁸ process assurance are to be performed to assure that life-cycle processes adhere to applicable project plans and that management, engineering, and assurance processes are audited for compliance to applicable plans.

Requirements and processes typically change as the project progresses and new information is obtained, issues are found, or planned solutions are found to be unsuitable. When this happens, the baselined plans need to be updated to reflect the new information, new processes, new solutions, or other project changes. In other words, plans need to be maintained such that they are current with project activities, decisions, and other factors that affect the processes described in those plans.

Possible reasons for updating software plans include, but are not limited to:

• In response to the results of progress or status reviews.
• Changes in resource levels, availability (e.g., tools, facilities, personnel).
• Planned solutions are found to be unsuitable.
• Estimates are found to be inaccurate (e.g., cost, product size, effort).
• Changes in project scope.
• Requirements changes.
• Changes in timelines/schedules, especially for coordinated or linked activities.
• Missed milestones.
• In response to corrective actions.
• In response to new or revised risks.
• Budget changes.
• Regulatory changes.
• Changes in stakeholder commitments.

When one of these situations occurs, its impact to the completion of project objectives is evaluated to determine if changes to software plans are required.  Per the Project Planning chapter of Capability Maturity Model Integration (CMMI®) for Development, Version 1.3, ¹⁵⁷  "Criteria are established for determining what constitutes a significant deviation from the project plan. A basis for gauging issues and problems is necessary to determine when corrective action should be taken. Corrective actions can lead to replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities in the current plan. The project plan defines when (e.g., under what circumstances, with what frequency) the criteria will be applied and by whom."

Revised plans need to be reviewed and approved before they are implemented. Plans and progress against those plans are typically reviewed at life-cycle milestone reviews, but approval of revisions need not wait for a scheduled review. Those reviews occur in a timely manner to ensure continued progress toward project objectives and goals. Approved, revised software plans are distributed to affected stakeholders, such as the software development team, so they follow the most up-to-date plans. Periodic audits may be used to confirm team adherence to software plans.

NASA-specific software planning resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to maintaining and executing software plans and processes may be found in the following requirements in this Handbook:

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.