bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Alias
aliasSWE-106

...

Tabsetup
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
1. The Requirement
{div3:id=} h1.
Wiki Markup
Div
idtabs-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}
Wiki Markup
{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 that these products and projects comply with requirements in

applicable
f1
g1
h0
asc1
ansc1
bnsc1
csc1
bsc1
esc1
cnsc1
dsc1
dnsc0
ensc0

Div
idtabs-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
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
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

SAPs

include

and

address

the

same

key

tasks

and

assurance

activities.

{div3}
Wiki Markup
{div3:id=

} h1.
Div
idtabs-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 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}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
  • sweref
    278
    278
    ].

 NASA-STD-8719.13B,

Software

Safety

Standard,

{

sweref

:

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}

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

|7.8 - Maturity of Life Cycle Products at Milestone Reviews]

and

at

[

appropriate

life

cycle

reviews

|7.9 - 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: !SWE-106_NEWFlow_Chart.png|border=0! 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 related 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}

Wiki Markup
{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}
Wiki Markup
{div3:id=tabs-5}

h1. 5. Resources

{refstable}

{toolstable}


{div3}
Wiki Markup
{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}

for developing and documenting a SAP:

Image Added

Any changes to the baselined SAP (typically baselined at

Term
PDR
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 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
idtabs-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
idtabs-5

5. Resources

refstable
toolstable
Div
idtabs-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
    Term
    QA
    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
    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
    Term
    ISS
    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