Tabsetup

	1. The Requirement
	1. The Requirement
1	2. Rationale
2	3. Guidance
3	4. Small Projects
4	5. Resources
5	6. Lessons Learned

Wiki Markup

{alias:SWE-106} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1.Requirement

Div

id	tabs-1

1.Requirement

5.1.5.1

The

Software

Assurance

Plan(s)

shall

be

developed

and

documented

per

NASA-STD-8739.8,

Software

Assurance

Standard.

\

[SWE-106

\] h2.

]

1.2 Notes

NPR

7150.2,

NASA

Software

Engineering

Requirements,

does

not

include

any

notes

for

this

requirement.

h2.

1.3 Applicability

Across

Classes

{applicable:asc=1\|ansc=1\|bsc=1\|bnsc=1\|csc=1\|cnsc=1\|dsc=1\|dnsc=0\|esc=1\|ensc=0\|f=1\|g=1\|h=0} {div3}{div3:id=tabs-2} h1. 2. Rationale Software assurance activities ensure that the project team implements software engineering products and processes according to the plans established by the project and comply with requirements in

applicable

f	1
g	1
h	0
ansc	1
asc	1
bnsc	1
csc	1
bsc	1
esc	1
cnsc	1
dnsc	0
dsc	1
ensc	0

Div

id	tabs-2

2. Rationale

Software assurance activities ensure that the project team implements software engineering products and processes according to the plans established by the project and that these products and projects comply with requirements in NASA-STD-8739.8.

NASA-STD-8739.8

{

sweref

:278}captures the assurance requirements in a single place for more uniform application across projects where software is developed or acquired for NASA. The Software Assurance Plan (SAP) represents an agreement between the project, the software developers, and the software assurance personnel. It describes the activities, roles, and responsibilities of software assurance on the project. As with any task, a plan helps ensure that the team performs all necessary and required tasks. Development of the plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned activities for the project. Specific to software assurance,

	278
	278

captures the assurance requirements in a single place for more uniform application across projects where software is developed or acquired for NASA.

The Software Assurance Plan (SAP) represents an agreement between the project, the software developers, and the software assurance personnel. It describes the activities, roles, and responsibilities of software assurance on the project. As with any task, a plan helps ensure that the team performs all necessary and required tasks. Development of the plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned activities for the project.

Specific to software assurance, NASA-STD-8739.8

{

sweref

:278}provides requirements that the team can use as the basis for development of a project's Software Assurance Plan. Using this previously

	278
	278

provides requirements that the team can use as the basis for development of a project's SAP. Using this previously thought-out,

defined

set

of

requirements

gives

plan

development

teams

a

common

starting

point

for

their

activities

and

ensures

that

all software assurance plans include and address the same key tasks and assurance activities. {div3}{div3:id=tabs-3} h1. 3. Guidance ?{floatbox:width=full} NPR 7150.2, section

all SAPs include and address the same key tasks and assurance activities.

Div

id	tabs-3

3. Guidance

Floatbox

width	full

NPR 7150.2, section 5.1.5,

states

that:

"The

Software

Assurance

Plan

details

the

procedures,

reviews,

and

audits

required

to

accomplish

software

assurance.

The

project

office

should

coordinate

with

the

Office

of

Safety

and

Mission

Assurance

for

help

in

scoping

and

adapting

the

effort

appropriately,

and

to

designate

the

individual

responsible

for

software

assurance

on

the

project."

    {floatbox} For projects that involve contracted work, both the acquirer and the provider (subcontractor), need Software Assurance Plans, and those plans must work together to accomplish the required level of software assurance. The preliminary acquirer plan is developed at the same time that the Request for Proposal (RFP) or Memorandum of Agreement/Memorandum of Understanding (MOA/MOU) is created. Both acquirer and provider plans are to be completed by the time the contract is awarded, though an update of the provider plan is expected at the Software Requirements Review (SwRR). As with many project plans, the SAP may be a separate document or may be combined with another project plan such as the Software Development Plan (SDP). However, the independent software assurance organization of the acquirer Safety and Mission Assurance (SMA) Office needs to have sign-off authority on the content no matter into what document the SAP contents may be incorporated. The SAP is a joint agreement between acquirer SMA and the project/facility for software assurance activities. While NASA-STD-8739.8 {sweref:278}contains requirements for software assurance in general, it also contains minimum content requirements for the SAP. The following requirements, identified by

For projects that involve contracted work, both the acquirer and the provider (subcontractor) need SAPs, and those plans must work together to accomplish the required level of software assurance. The preliminary acquirer plan is developed at the same time that the Request for Proposal (RFP) or Memorandum of Agreement/Memorandum of Understanding (MOA/MOU) is created. Both acquirer and provider plans are to be completed by the time the contract is awarded, though an update of the provider plan is expected at the Software Requirements Review (SwRR).

As with many project plans, the SAP may be a separate document or may be combined with another project plan such as the Software Development Plan (SDP). However, the independent software assurance organization of the acquirer Safety and Mission Assurance (SMA) Office needs to have sign-off authority on the content no matter into what document the SAP contents may be incorporated. The SAP is a joint agreement between acquirer SMA and the project/facility for software assurance activities.

While NASA-STD-8739.8

sweref

	278
	278

contains requirements for software assurance in general, it also contains minimum content requirements for the SAP. The following requirements, identified by NASA-STD-8739.8

paragraph

numbers,

apply

specifically

to

the

development

and

documentation

of

a

SAP.

These

requirements,

shown

here

without

their

associated

project

life-cycle

phase,

provide

a

high-level

content

overview

of

both

the

acquirer

and

provider

SAPs.

When

carrying

out

these

requirements,

consult

NASA-STD-8739.8

{sweref:278}to determine the specific

sweref

	278
	278

to determine the specific life-cycle

phase

in

which

they

are

to

be

completed.

*

Acquirer

SAP:

* *

5.1.2.8

-

Prepare

a

preliminary

acquirer

program/project

software

assurance

plan

documenting

the

planned

level

of

software

assurance

effort

and

activities

required

and

the

necessary

resources

using

the

template

provided

in

Appendix

B

\

[of

NASA-STD-8739.8

{sweref:278}\]. *

sweref
278
278
].
5.3.1.1

-

Verify

that

the

provider's

software

assurance

plan

meets

contractual

requirements.

*

5.3.1.2

-

Verify

that

the

acquirer's

software

assurance

plan

and

the

provider's

software

assurance

plan

are

consistent,

compatible,

and

are

baselined.

*

Provider

SAP:

* *

6.3.1

-

Each

software

provider

shall

establish

and

maintain

a

software

assurance

plan

that

addresses

all

software

development

and

maintenance

activities.

NOTE:

For

smaller

projects,

this

plan

may

be

incorporated

in

another

project-planning

document

or

may

be

a

separate

document.

Larger

projects

may

have

a

separate

plan

or

more

than

one

software

assurance

plan.

*

6.3.2

-

The

software

assurance

plan

shall:

*

6.3.2.1

-

Conform

to

IEEE

730-2002,

IEEE

Standard

for

Software

Quality

Assurance

Plans

{sweref:218}. *

sweref
218
218
.
6.3.2.2

-

In

addition,

address

how

the

provider

will

implement

the

requirements

of

Sections

6.0

and

7.0

of

this

Standard

\

[NASA-STD-8739.8

{

sweref

:278}\].  NASA

278
278
].

NASA-STD-8719.13B,

Software

Safety

Standard,

{

sweref

:271}also includes two requirements that address content to consider for the SAP: *

	271
	271

also includes two requirements that address content to consider for the SAP:

6.2.2.1

-

The

?\

[safety

\

]

analysis

methodology

\

[for

software

design

\

]

shall

be

recorded

in

an

appropriate

document

(e.g.,

software

safety

plan

or

software

assurance

plan).

*

6.3.2.1

-

The

?\

[safety

\

]

analysis

methodology

\

[for

software

implementation,

e.g.,

code

\

]

shall

be

recorded

in

an

appropriate

document

(e.g.,

software

safety

plan

or

software

assurance

plan).

Before

writing

a

SAP,

it

is

recommended

that

the

team

review

the

following

material

as

preparation:

*

Software

assurance

lessons

learned

from

similar

projects.

*

Existing

software

assurance

processes,

standards,

procedures,

etc.

*

Software

assurance

deliverables

(records,

reports,

etc.)

for

similar

projects.

Using

an

existing

template

will

ensure

consistency

of

plans

across

projects,

as

well

as

ensure

all

key

information

is

included

in

the

SAP.

If

a

project

or

Center

SAP

template

or

"best-in-class"

example

does

not

exist,

NASA-STD-8739.8

{sweref:278}contains a basic outline in its Appendix B. Templates are included in the Resources section of this guidance, including one from Goddard Space Flight Center (GSFC) based on IEEE 730-2002 noted in

sweref

	278
	278

contains a basic outline in its Appendix B. Templates are included in the Resources section of this guidance, including one from Goddard Space Flight Center (GSFC) based on IEEE 730-2002 noted in NASA-STD-8739.8

{sweref:278}requirements, which includes suggested content for each section of the SAP. Other content elements to consider include: * Software assurance organization and management structure and responsibilities. * Software assurance planning activities. * Software classification and safety criticality. * Software assurance implementation activities covering all five assurance disciplines: ** Software Quality (includes software quality assurance, software quality engineering, and software quality control). ** Software Safety. ** Software Reliability. ** Software Verification and Validation. ** Independent Verification and Validation. * Standards and processes to be used, including those used for: ** Software assurance implementation activities, such as reviews, audits, etc. ** Problem reporting and tracking. ** Risk management. ** Software assurance metrics, e.g., planned versus actual reviews, audits, assessments; open versus closed issues; number of identified risks. ** Record creation, review, and maintenance. * Training for software assurance personnel. * Resources, including tools, personnel, and facilities. * Identification of products and processes to be reviewed or audited. * Identification of deliverables (records) to be created and maintained. * Schedule. Ensure that the SAP is [reviewed prior to implementation|https://nasa7150.onconfluence.com/display/7150/7.4+-+Maturity+of+Lifecyle+Products+at+Milestone+Reviews] and at [appropriate life cycle reviews|https://nasa7150.onconfluence.com/display/7150/7.3+-+Entrance+and+Exit+Criteria] by personnel with sufficient software assurance knowledge to identify omissions, inadequacies, and other issues. Include stakeholders affected by the plan in the reviews for awareness of planned activities and so that their suggestions can be addressed within the bounds of the project's required level of software assurance. Any identified issues need to be corrected before plan implementation or before carrying out affected software assurance activities in the next life-cycle phase. The following diagram excerpted from the Glenn Research Center SQA Process for Software Assurance, SEGP-SQA-PRC-1{sweref:382}, shows a basic flow of activities for developing and documenting a SAP: !swassurance1.png! Any changes to the baselined SAP (typically baselined at {term:PDR}) need to be made via the appropriate formal change request process (internal to the project for the acquirer SAP or via NASA's formal change request process for the provider SAP) and be accompanied by a risk analysis to ensure the project's level of software assurance is not compromised.  The acquirer software assurance personnel are responsible for ensuring the provider software assurance personnel are meeting the contents of the provider SAP. The acquirer SAP describes how this will be done (based on software size, software class, safety criticality, and other factors that may be specific to a project).  Guidance related to software assurance and to be considered for inclusion in the SAP may be found in the following topics and requirements in this Handbook: | [SWE-013|SWE-013] | Software Plans | | [SWE-020|SWE-020] | Software Classification | | ?[SWE-022|SWE-022] | Software Assurance | | [SWE-132|SWE-132] | Independent Software Classification Assessment | | [SWE-133|SWE-133] | Software Safety Determination | \\ {div3}{div3:id=tabs-4} h1. 4. Small Projects According to NASA-STD-8739.8 {sweref:278}, smaller projects have the choice of incorporating their SAP in another project-planning document or using a separate document.{div3}{div3:id=tabs-5} h1. 5. Resources {refstable} {toolstable} {div3}{div3:id=tabs-6} h1. 6. Lessons Learned There must be a software assurance plan.  "Most Project Managers feel they have too many plans, and the suggestion of another one for Software Quality Assurance might be the proverbial straw that breaks the camel's back\! But the success of any undertaking is to know what one is trying to achieve and how one expects to accomplish it, hence, the necessity of a plan for SQA. The plan will specify the goals, what is to be performed, standards against which the development work is to be measured, all relevant procedures, and the organizational structure of the Quality Assurance within the project. At NASA a software assurance plan is required." (Lesson 4 of 12, SoftwareTech News{sweref:433}). The NASA Lesson Learned database contains the following lessons learned related to software assurance planning: * *Quality Assurance Access to Critical Areas, Management (Quality Assurance Access). Lesson Number 0332:* "If program or engineering management exercises the authority to deny {term:QA}access to critical areas, QA oversite will be severely \[compromised\]."  \[Note that, while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.\] {sweref:503} * *Quality Assurance Expertise in Special Technical Areas (e.g., optics) (Quality Assurance Expertise). Lesson Number 0331:* "If quality assurance personnel responsible for oversight of the quality of highly technical state-of-the-art development do not have a degree of expertise in that technical area, the likelihood of discovering QA problems decreases significantly." \[Note that, while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.\] {sweref:502} * *International Space Station (ISS) Program/Computer Hardware-Software/Software (Schedules). Lesson Number 1062:* "The {term:ISS}software development schedule is almost impossibly tight. If something else does not cause a further delay in ISS deployment, software development may very well do so. The decision this year to add integrated testing of some modules ... is a very positive step for safety. However, there is no room in the schedule for required changes that may be discovered during this testing." {sweref:536} {div3} {tabclose}

sweref

	278
	278

requirements, which includes suggested content for each section of the SAP.

Other content elements to consider include:

Software assurance organization and management structure and responsibilities.
Software assurance planning activities.
Software classification and safety criticality.
Software assurance implementation activities covering all five assurance disciplines:
- Software Quality (includes software quality assurance, software quality engineering, and software quality control).
- Software Safety.
- Software Reliability.
- Software Verification and Validation.
- Independent Verification and Validation.
Standards and processes to be used, including those used for:
- Software assurance implementation activities, such as reviews, audits, etc.
- Problem reporting and tracking.
- Risk management.
- Software assurance metrics, e.g., planned versus actual reviews, audits, assessments; open versus closed issues; number of identified risks.
- Record creation, review, and maintenance.
Training for software assurance personnel.
Resources, including tools, personnel, and facilities.
Identification of products and processes to be reviewed or audited.
Identification of deliverables (records) to be created and maintained.
Schedule.

Ensure that the SAP is reviewed prior to implementation (see Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews) and at appropriate life cycle reviews (see Topic 7.09 - Entrance and Exit Criteria) by personnel with sufficient software assurance knowledge to identify omissions, inadequacies, and other issues. Include stakeholders affected by the plan in the reviews for awareness of planned activities and so that their suggestions can be addressed within the bounds of the project's required level of software assurance. Any identified issues need to be corrected before plan implementation or before carrying out affected software assurance activities in the next life-cycle phase.

The following diagram excerpted from the Glenn Research Center SQA Process for Software Assurance, SEGP-SQA-PRC-1

sweref

	382
	382

, shows a basic flow of activities for developing and documenting a SAP:

Image Added

Any changes to the baselined SAP (typically baselined at PDR (Preliminary Design Review)) need to be made via the appropriate formal change request process (internal to the project for the acquirer SAP or via NASA's formal change request process for the provider SAP) and be accompanied by a risk analysis to ensure the project's level of software assurance is not compromised.

The acquirer software assurance personnel are responsible for ensuring the provider software assurance personnel are meeting the contents of the provider SAP. The acquirer SAP describes how this will be done (based on software size, software class, safety criticality, and other factors that may be specific to a project).

Guidance related to software assurance and to be considered for inclusion in the SAP may be found in the following related requirements in this Handbook:

SWE-013	Software Plans
SWE-020	Software Classification
SWE-022	Software Assurance
SWE-132	Independent Software Classification Assessment
SWE-133	Software Safety Determination

Div

id	tabs-4

4. Small Projects

According to NASA-STD-8739.8

sweref

	278
	278

, smaller projects have the choice of incorporating their SAP in another project-planning document or using a separate document.

Div

id	tabs-5

5. Resources

refstable

toolstable

Div

id	tabs-6

6. Lessons Learned

There must be a software assurance plan. "Most Project Managers feel they have too many plans, and the suggestion of another one for Software Quality Assurance might be the proverbial straw that breaks the camel's back! But the success of any undertaking is to know what one is trying to achieve and how one expects to accomplish it, hence, the necessity of a plan for SQA. The plan will specify the goals, what is to be performed, standards against which the development work is to be measured, all relevant procedures, and the organizational structure of the Quality Assurance within the project. At NASA a software assurance plan is required." (Lesson 4 of 12, SoftwareTech News

sweref

	433
	433

).

The NASA Lesson Learned database contains the following lessons learned related to software assurance planning:

Quality Assurance Access to Critical Areas, Management (Quality Assurance Access). Lesson Number 0332: "If program or engineering management exercises the authority to deny QA (Quality Assurance) access to critical areas, QA oversite will be severely [compromised]." [Note that, while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.]
sweref
503
503
Quality Assurance Expertise in Special Technical Areas (e.g., optics) (Quality Assurance Expertise). Lesson Number 0331: "If quality assurance personnel responsible for oversight of the quality of highly technical state-of-the-art development do not have a degree of expertise in that technical area, the likelihood of discovering QA problems decreases significantly." [Note that, while this lesson does not specifically call out software, the lesson remains relevant regarding assurance personnel access to information and areas required to perform software assurance activities.]
sweref
502
502
International Space Station (ISS) Program/Computer Hardware-Software/Software (Schedules). Lesson Number 1062: "The ISS software development schedule is almost impossibly tight. If something else does not cause a further delay in ISS deployment, software development may very well do so. The decision this year to add integrated testing of some modules ... is a very positive step for safety. However, there is no room in the schedule for required changes that may be discovered during this testing."
sweref
536
536

Content

Space Tools

Versions Compared

Old Version 46

New Version Current

Key

1.Requirement

1.2

Notes

NPR

1.3

Applicability

Across

Classes

applicable
f 1
g 1
h 0
ansc 1
asc 1
bnsc 1
csc 1
bsc 1
esc 1
cnsc 1
dnsc 0
dsc 1
ensc 0

2. Rationale

3. Guidance

4. Small Projects

5. Resources

6. Lessons Learned

Content

Space Tools

Page History

Versions Compared

Old Version 46

New Version Current

Key

1.Requirement

1.2

Notes

NPR

1.3

Applicability

Across

Classes

applicablef1g1h0ansc1asc1bnsc1csc1bsc1esc1cnsc1dnsc0dsc1ensc0

2. Rationale

3. Guidance

4. Small Projects

5. Resources

6. Lessons Learned

applicable
f 1
g 1
h 0
ansc 1
asc 1
bnsc 1
csc 1
bsc 1
esc 1
cnsc 1
dnsc 0
dsc 1
ensc 0