bannerc
SWE-013 - Software Plans

1. Requirements

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

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 and procedures for coordinating the software development and the design and the system or project development life cycle.

1.2 History

SWE-013 - Last used in rev NPR 7150.2D

RevSWE Statement
A

2.2.1.1 The project shall develop software plan(s).

Difference between A and B

Expanded scope of SW Plans to  align to software lifecycle, compliance with NPR requirements, after approval and tailoring of the requirements.


B

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. 


Difference between B and C

No change

C

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

Difference between C and DAdded security plans to what needed to be included
D

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.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable


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

3. Guidance

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:

  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 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 8.16 - Documentation Guidance also includes the recommended content for the 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. 

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) and software assurance processes. Per NASA-STD-8739.8, Software Assurance and Software Safety Standard 278 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 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 on 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, 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.

 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:

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.

5. Resources

5.1 References

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

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

SWE-013 - Software Plans
3.1.3 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.

7.1 Tasking for Software Assurance

  1. Confirm that all plans are in place, and have expected content for the life-cycle events, with proper tailoring for the classification of the software.
  2. Develop a Software Assurance Plan following the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety.

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 - Software Assurance Plan defined for software assurance, including safety, if required)
  • Software Safety Plan (see Software Safety Plan tab located under topic 8.16 - Software Assurance Plan)

Objective Evidence

  • A project plan for the development, management, and assurance of the software activities. 
  • A completed software engineering (NPR 7150.2) requirements mapping matrix and a software assurance (NASA-STD-8739.8) requirements mapping matrix.  An output from the 8.15 - SA Tasking Checklist Tool can be used as objective evidence for the software assurance and software safety requirements mapping matrix. 

Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

  •  # of software work product Non-Conformances identified by life-cycle phase over time·
  • Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational metric)
  • # of Non-Conformances identified in plans (e.g., SMPs, SDPs, CM Plans, SA Plans, Safety Plans, Test Plans)
  •  # 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

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 safety-critical software.

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.

For Software Assurance Plan content guidance see Software Assurance PlanThe 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. 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 of 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 for 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, and 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.



  • No labels