1. Requirements

2.2.2 The project shall implement, maintain, and execute the software plan(s).

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement

1.2 Applicability Across Classes

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

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

At the project level, the Project Manager is responsible for executing the project plan.  For software, a software or development team lead may ensure plan execution and maintenance.

Plans are baselined 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.  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 shall be performed to assure that:

7.1.2.1 Those software life cycle processes employed for the project adhere to the applicable plans.

...

7.1.2.5 All management, engineering, and assurance processes are audited for compliance with 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 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.

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

The content of various software plans are provided in Chapter 5 of NPR 7150.2.

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

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.