Book A.

Book B.
7150 Requirements Guidance

Book C.

References, & Terms

(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Error formatting macro: alias: java.lang.NullPointerException
SWE-014 - Execute Planning
Unknown macro: {div3}

1. Requirements

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

1.1 Notes">1.1 Notes

NPR 7150.2 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.





























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

Unknown macro: {div3}

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. 

Software plans also provide the structure and approach for a project.  This structure and approach is reviewed and agreed to by project stakeholders before the work begins and the project is held accountable for following those plans.

Unknown macro: {div3}

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 should be 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 Software Product Maturity at Lifecycle 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 the NASA Software Assurance Standard,

"Process assurance shall be performed to assure that: Those software life cycle processes employed for the project adhere to the applicable plans.

... 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 should 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 should be reviewed and approved before they are implemented. Plans and progress against those plans are typically reviewed at lifecycle 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.

Consult center Process Asset Libraries (PALs) for center-specific guidance and resources related to implementing, maintaining, and executing software plans, including guidance addressing project planning and project monitoring and control.

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


Software Processes


Software Plans


Corrective Action Plans


Commitment Agreement Changes

The content of various software plans are provided in Chapter 5 of NPR 7150.2, NASA Software Engineering Requirements

Unknown macro: {div3}

4. Small Projects

There is currently no guidance specific to small projects for this requirement.

Unknown macro: {div3}

5. Resources

  1. NASA Technical Standard, "NASA Software Assurance Standard", NASA-STD-8739.8, 2004.
  2. NASA Technical Standard, "NASA Systems Engineering Processes and Requirements w/ Change 1", NPR 7123.1A, 2009.
  3. NASA Procedural Requirements, "NASA Space Flight Program and Project Management Requirements", NPR 7120.5D [NM 7120-81], 2010.
  4. NASA Scientific and Technical Information (STI), NASA Center for AeroSpace Information, NASA Systems Engineering Handbook (6.1 Technical Planning), NASA/SP-2007-6105, Rev1, 2007.)
  5. Software Engineering Institute, "CMMI for Development, Version 1.3", CMU/SEI-2010-TR-033, 2010.
  6. Information System Division (ISD), GSFC, "Project Planning Process", 580-PC-004-03, 2007.
  7. Flight and Ground Software Division Software Engineering Process Group (SEPG), MSFC, "Software Development Process Description Document", EI32-OI-001, Revision R, 2010.

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.

Unknown macro: {div3}

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.

  • No labels