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 are to be complete, correct, workable, consistent, and verifiable.
Software plans include, but are not limited to:
- Software development or management plan.
- Software configuration management plan.
- Software test plans.
- Software maintenance plans.
- Software assurance plans.
- 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.8 - 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.8 - 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.
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to software plans, including responsibilities for producing 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: