This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
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.
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
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.
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.
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:
- 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.” 278 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 278 for more details on development of a software assurance plan and NASA-STD-8719.13 271 for details on development of a software safety plan.
Topic 7.8 - The 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 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, 278 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, 157 "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.
- CMMI Development Team (2010). "CMMI for Development, Version 1.3: Improving processes for developing better products and services,"CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.
Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.
VersionOne is an all-in-one enterprise agile solution for software organizations scaling agile. From discovery to delivery, Version One uniquely scales to any number of organizational levels and supports methodologies such as Scaled Agile Framework, Enterprise Scrum, Kanban, DAD, LeSS, or a Hybrid approach.
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.