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 Software Product Maturity at Life Cycle 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 shall be performed to assure that:
220.127.116.11 Those software life cycle processes employed for the project adhere to the applicable plans.
18.104.22.168 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.
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 related requirements in this handbook:
The content of various software plans are provided in Chapter 5 of NPR 7150.2.