1. Requirements

3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.

1.1 Notes

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 NASA-HDBK-2203. The project should include, or reference in the software development plans, procedures for coordinating the software development and design, and the system or project development life cycle.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Because software development is a complex technical process that requires a lot of steps, having a project plan is extremely helpful to visualize and follow each step of its development, according to a timeline for the team's work.

3. Guidance

Software plans describe the activities and processes that will be carried out and the products that will be produced to fulfill project requirements for the 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. The Software Development Plan (SDP) describes a developer’s plans for conducting a software development effort. The SDP provides the acquirer insight and a tool for monitoring the processes to be followed for software development. It also details the methods to be used and the approach to be followed for each activity, organization, and resource.

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. See also Topic 7.05 - Work Breakdown Structures That Include Software. 

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.

3.1 Plan Contents

Software plans include, but are not limited to:

1. Software development or management plan.
2. Software configuration management plan.
3. Software test plans.
4. Software maintenance plans.
5. Software assurance plans.
6. The software safety plan, if the project has 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. See also Topic 5.08 - SDP-SMP - Software Development - Management Plan

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 8.16 - SA Products also includes the recommended content for the 8.51 - Software Assurance Plan as well as additional references that may be used when developing each specific plan.

7.08 - Maturity of Life Cycle Products at Milestone Reviews guides the maturity of several project plans at various life cycle reviews. 

3.2 Plan Maintenance and Implementation

Once software plans have been baselined, consider the following guidelines for maintaining and implementing them.

While the Project Manager is responsible for executing the project plan, a software or development team lead may ensure the 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.08 - 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 - Plan Tracking) and software assurance processes. Per NASA-STD-8739.8, Software Assurance and Software Safety Standard ²⁷⁸ software assurance and software safety 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 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, and 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 on the completion of project objectives is evaluated to determine if changes to software plans are required. 

3.3 Reviews and Approval

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 promptly 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.

See also Topic 8.12 - Basics of Software Auditing. 

3.4 SA Plans

Software assurance plans should be based on the software assurance tasking identified in the Software Assurance Tasking Checklist Tool. See 8.15 - SA Tasking Checklist Tool

The purpose of the Software Assurance (SA) Tasking Checklist Tool is to streamline the Software Assurance and Software Safety Tasks (a.k.a. SA Tasking) that must be performed on a NASA project. The tool allows the user to tailor the SA Tasking based on the needs of the project via Software Classification, Safety Criticality, and required Milestones.

The SA Tasking Checklist Tool assists in the planning, execution, and monitoring of the Software Assurance (SA) tasks provided in NASA-STD-8739.8A Requirement SASS-01, mapped to the NPR-7150.2C Software Engineering Requirements. The tool is designed with a user-friendly front end which integrates the engineering, software assurance, and safety requirements across the development life cycle to create SA tasking checklists based on milestones to plan and ensure compliance. While the default project information addresses a “typical” development project with full compliance to SASS-01, the tool is flexible in terms of tailoring the requirements, as well as providing the ability to map the SWE requirements to various milestones for different development life cycles to address Center or project-specific attributes. The tool may also be used to capture status when SA activities are performed throughout the development life cycle. The resulting checklist of SA Tasking may be filtered. Monitoring of the resulting SA Tasking may be performed using the generated checklist in the tool. Another option for monitoring is to export the checklist(s) in common formats compatible with other tools including Excel, JIRA, and MS Project (i.e., Excel, CSV, and XML).

The SA Tasking Checklist Tool has a comprehensive Users Guide embedded in the tool to assist the user with tool features and functionality. It also provides instruction on how to use the tool to generate a project-specific SA Tasking Checklist.

See tab 7 for additional SA Tasking and guidance. 

3.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.6 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

Small 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.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Software Assurance and Safety Requirements Mapping Matrix  See 8.15 - SA Tasking Checklist Tool for guidance on Software Assurance and Safety Requirements Mapping Matrix 
• Software Assurance Plan (see topic 8.16 - 8.51 - Software Assurance Plan defined for software assurance, including safety, if required)
• Software Safety Plan (see Software Safety Plan tab located under topic 8.16 - 8.51 - Software Assurance Plan)

7.3 Metrics

•  # of software work product Non-Conformances identified by life cycle phase over time·
• # of Non-Conformances identified in plans (e.g., SMPs, SDPs, CM Plans, SA Plans, Safety Plans, Test Plans)

• Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational metric)

  •  # of projects tailoring each requirement (*organizational measure)
  •  % of requirements tailored per project (*organizational measure)
• # of safety-related non-conformances identified by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Step 1 Confirm that all appropriate plans are in place, and have expected content for the life cycle events, with proper tailoring for the classification of the software.

Software plans include, but are not limited to:

1. Software development or management plan.
2. Software configuration management plan.
3. Software test plans.
4. Software maintenance plans.
5. Software assurance plans.
6. The software safety plan, if the project has safety-critical software.
7. IT Security plans

When software assurance is confirming the appropriate software plans are in place, the following plans should be considered: SW Management/Development Plans, SW Configuration Management Plans, SW Risk Management Plan, SW V&V Plans, SW Operations/Maintenance Plan(s), SA Plans, SW Retirement Plan, and SW Safety Plan(s), if applicable. As mentioned earlier, these plans do not need to all be separate plans, but the applicable contents should be covered among the project’s plans. Recommended minimum contents for these plans can be found in NASA-HDBK-2203, under 7.18 - Documentation Guidance.

Some of these documents may not be available early in the life cycle. Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews will provide some guidance on when these documents should be available and baselined.

Step 2 Develop a Software Assurance Plan following the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety if required.

Software assurance plans should be based on the software assurance tasking identified in the Software Assurance Tasking Checklist Tool. See 8.15 - SA Tasking Checklist Tool

The purpose of the Software Assurance (SA) Tasking Checklist Tool is to streamline the Software Assurance and Software Safety Tasks (a.k.a. SA Tasking) that must be performed on a NASA project. The tool allows the user to tailor the SA Tasking based on the needs of the project via Software Classification, Safety Criticality, and required Milestones.

The SA Tasking Checklist Tool assists in the planning, execution, and monitoring of the Software Assurance (SA) tasks provided in NASA-STD-8739.8A Requirement SASS-01, mapped to the NPR-7150.2C Software Engineering Requirements. The tool is designed with a user-friendly front end which integrates the engineering, software assurance, and safety requirements across the development life cycle to create SA tasking checklists based on milestones to plan and ensure compliance. While the default project information addresses a “typical” development project with full compliance to SASS-01, the tool is flexible in terms of tailoring the requirements, as well as providing the ability to map the SWE requirements to various milestones for different development life cycles to address Center or project-specific attributes. The tool may also be used to capture status when SA activities are performed throughout the development life cycle. The resulting checklist of SA Tasking may be filtered. Monitoring of the resulting SA Tasking may be performed using the generated checklist in the tool. Another option for monitoring is to export the checklist(s) in common formats compatible with other tools including Excel, JIRA, and MS Project (i.e., Excel, CSV, and XML).

The SA Tasking Checklist Tool has a comprehensive Users Guide embedded in the tool to assist the user with tool features and functionality. It also provides instruction on how to use the tool to generate a project-specific SA Tasking Checklist.

For Software Assurance Plan content guidance see 8.51 - Software Assurance Plan.  The major part of the software assurance plan should be the software assurance and software safety requirements mapping matrix. An output from the 8.15 - SA Tasking Checklist Tool can be used for the software assurance and software safety requirements mapping matrix.

The software assurance plan can be a document or an electronic record. 

The SA plan should include a record for the Software Assurance and Software Safety Standard requirements tailoring based on the tailoring of the software assurance, software safety, and IV&V requirements using the following levels:

1. 1. The first level of tailoring is the Software Classification Decision, see NPR 7150.2.
   2. The second level of tailoring is the tailoring in the project’s Software Requirements Mapping Matrix, see NPR 7150.2.
   3. The third level of tailoring is the tailoring by the Software Assurance TA of the Software Assurance and Software Safety requirements that correspond to the project’s Software Requirements Mapping Matrix requirements.

Planning the software assurance on any project requires an understanding of the project’s function, needs, and risk posture as well as Software Class and criticality.   Software Assurance and Software Safety needs to work with the software development team to assure that the software development processes are planned well and are based on the project and software criteria, as appropriate. Software Assurance also needs to assure any acquisition process is adequate and complete and that criteria are set up to eventually assure the delivery of needed software products and reports.  Once these criteria are established, software assurance can create their plans and assure the appropriate SA needs are provided, any needed training on the project development processes and functionality, needed tools, and access to project data, products, and activities.

Office of Safety and Mission Assurance is responsible for creating, maintaining, and assuring the proper execution of the basic SA requirements; however, at the Centers and on Projects and Programs, various personnel can perform varying aspects of SA. Based on SMA resources and Project needs and resources, a combination of Project, Project independent SMA personnel, DCMA, support contractors, NASA, and contractor personnel all may serve in some capacity to meet the total SA requirements. All planned SA activities and a listing of the parties responsible for performing these activities need to be documented and follow the organizational structure and governing documents for each Program/Project. The SA personnel has the responsibility to identify SA issues and risks for the Projects they support and to elevate those that remain unresolved through the SMA reporting chain. The responsible SMA organization assures the personnel performing SA are trained per requirements to perform SA and provides them with a reporting chain independent from the organization whose products and processes they are assuring (an independent reporting chain). SA is performed by both the Acquirer (NASA) and the Provider (NASA and/or contractor).

Many different groups may perform the varying aspects of SA (e.g., systems engineering might perform the software safety analyses, software engineering might collect and trend defects). An entity/organization independent from the development organization has to either perform the SA activities or assure that those activities are performed by the development organization correctly and to the extent consistent with the software classification and safety criticality of the software and that records of those activities are created, analyzed, and maintained.  Many software assurance and software safety activities may be tailored and performed within the Project structure, but a group independent from the Project assures those activities and the results.

Often, one or more software assurance personnel from an SMA organization may be assigned to work with a project throughout its life cycle. While these SAs are a part of the Project and participate in day-to-day activities, performing most or all of the SA functions and attending Project meetings and reviews, they maintain a separate reporting chain through their SMA organization. This activity is an oversight role, the SAs are closely tied in with the Project and provide input daily. At other times, the independent SMA organization may provide only insight into the Project, assuring the SA activities are performed by the Project personnel and participating primarily in audits and at formal review intervals. In either case, there has to be a close working association and joint reporting to both the Project and the SMA organization.

Step 3 Assess plans for risks, issues, completeness, and compliance with NPR 7150.2 requirements, NASA-STD-8739.8, contract, and Center requirements.

When software assurance is confirming the appropriate software plans are in place, the following plans should be considered: SW Management/Development Plans, SW Configuration Management Plans, SW Risk Management Plan, SW V&V Plans, SW Operations/Maintenance Plan(s), SA Plans, SW Retirement Plan, and SW Safety Plan(s), if applicable. As mentioned earlier, these plans do not need to all be separate plans, but the applicable contents should be covered among the project’s plans. Recommended minimum contents for these plans can be found in NASA-HDBK-2203, under 7.18 - Documentation Guidance.

Some of these documents may not be available early in the life cycle. Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews will provide some guidance on when these documents should be available and baselined.

In addition to assessing that these documents have their expected contents, they should be evaluated to verify that they:

• satisfy their requirements, per the appropriate software classification (i.e., NPR 7150.2, Center, Project, any contractual requirements, and Project planning requirements, as applicable)
• are consistent among SW plans, including risk management, configuration management, and problem/discrepancy reporting and resolution,
• cover the appropriate topics, and include all life cycle phases,
• are complete and usable,
• are consistent with systems plans, planned communications, deliverables, and schedules, 
• have identified critical paths and dependencies,
• identify risks associated with proposed plans,
• have determined initial safety criticality, potential security risks, coordination with IV&V, as needed
• have complete coverage, with no omissions or inadequacies. 

Software assurance will identify any risks or issues found during their assessment of the plans and report them to software management. Issues and risks found should be tracked to closure.

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: