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

...

Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


{div3:id=} h1.
Wiki Markup
Div
idtabs-1

1.

Requirements

2.5.5

The

project

shall

determine

which

software

processes,

activities,

and

tasks

are

required

for

the

project.

h2. {color:#003366}{*}

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2,

NASA

Software

Engineering

Requirements,

does

not

include

any

notes

for

this

requirement.

h2.

1.2

Applicability

Across

Classes

Class

F

is

labeled

with

"X

(not

OTS)."

This

means

that

this

requirement

does

not

apply

to

off-the-shelf

software

for

these

classes.

Class

D

and

not

Safety

Critical

and

Class

G

are

labeled

with

"P

(Center)."

This

means

that

an

approved

Center-defined

process

which

meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=p|esc=1|ensc=0|f=*|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Projects evaluate the environment


applicable
f*
gp
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnscp
dsc1
ensc0



Div
idtabs-2

2. Rationale

Projects evaluate the environment (e.g.,

organization,

funding,

size,

personnel)

in

which

they

plan

to

develop

software.

From

this

evaluation,

they

choose

an

appropriate

set

of

processes,

tasks

and

activities

to

develop

software

which

meets

their

needs.

The

Center

Process

Asset

Library

(PAL)

may

contain

processes

tailored

to

different

development

environments.

The

planning

down

to

the

activity

and

task

levels

will

assure

that

only

the

appropriate

processes

are

selected

from

the

ones

available

to

the

project.

A

further

evaluation

of

these

processes

will

determine

the

level

of

software

resources

that

the

project

team

needs

to

include

in

the

planning

documentation

and

funding

requests.

{div3} {div3:id=


} h1.
Div
idtabs-3

3.

Guidance

The

formulation

phase

in

the

life

cycle

(see

[SWE-019|

SWE-019

]

)

includes

the

selection

and

execution

of

planning

activities

that

are

necessary

for

the

successful

initiation

of

a

project.

During

this

phase

of

the

project

the

project

team

defines

customer

needs,

system

level

requirements,

make-versus-buy

strategies,

overall

project

and

software

management

plans,

a

work

breakdown

structure

(WBS),

software

safety

assessments,

and

primary

project

deliverables

and

work

products.

The

project

develops

planning

documents

to

account

for

the

above

and

for

use

in

managing

the

software

development

efforts.

The

core

set

of

software

plans

includes

a

Software

Development

or

Management

Plan

(see

[SWE-102|

SWE-102

]

),

Configuration

Management

Plan

(see

[

SWE-103

|SWE-103]

),

Test

Plan

(see

[SWE-104|

SWE-104

]

),

Maintenance

Plan

(see

[SWE-105|

SWE-105

]

),

and

Assurance

Plan

(see

[

SWE-106

|SWE-106]

).

The

planning

may

be

recorded

in

a

single

document

or

in

standalone

documents,

depending

on

project

size

and

requirements.

{


Panel
}

The

selections

of

the

processes

to

support

and

execute

the

above

planning

and

definition

activities

typically

are

based

on

an

analysis

of

the

desired

software

work

products

and

their

characteristics,

and

on

a

determination

of

which

activities

and

tasks

are

needed

to

produce

these

work

products.

The

selected

processes

must

meet

the

requirements

of

the

NPR

7150.2

that

are

applicable

to

the

project.

{panel}


Projects

may

find

it

helpful

to

review

the

following

sources

of

listed

processes

when

planning

their

project

implementation:

* \

  • [Agency
{sweref:266} and Center PALs that can be used to locate and select processes and activities that are applicable to software development activities. * The processes and best practices described in the Software Engineering Institute's (SEI) Capability Maturity Model Integration for Development
  • sweref
    266
    266
    and Center PALs that can be used to locate and select processes and activities that are applicable to software development activities.
  • The processes and best practices described in the Software Engineering Institute's (SEI) Capability Maturity Model Integration for Development (CMMI-Dev),
  • Version
  • 1.3
{sweref:157}. The
  • sweref
    157
    157
    . The CMMI-Dev
  • describes
  • the
  • applicability
  • of
  • its
  • processes
  • areas
  • for
  • developing
  • software
  • work
  • products.
* \
  • [NPR
  • 7123.1A
{sweref:041}, which establishes a core set of common
  • sweref
    041
    041
    , which establishes a core set of common Agency-level
  • technical
  • processes
  • and
  • requirements
  • needed
  • to
  • define,
  • develop,
  • realize,
  • and
  • integrate
  • the
  • quality
  • of
  • the
  • systems
  • products
  • created
  • and
  • acquired
  • for
  • NASA.
  • The
  • set
  • of
  • common
  • processes
  • in
  • the
  • NPR
  • may
  • be
  • supplemented
  • or
  • tailored
  • to
  • achieve
  • specific
  • project
  • requirements.
* \
  • [AS9100C
{sweref:372}, which provides a
  • sweref
    372
    372
    , which provides a process-based
  • quality
  • management
  • system
  • for
  • aerospace
  • applications.
  • "The
  • application
  • of
  • a
  • system
  • of
  • processes
  • within
  • an
  • organization...can
  • be
  • referred
  • to
  • as
  • the
  • 'process
  • approach'.
  • An
  • advantage
  • of
  • the
  • process
  • approach
  • is
  • the
  • ongoing
  • control
  • that
  • it
  • provides
  • over
  • the
  • linkage
  • between
  • the
  • individual
  • processes
  • within
  • the
  • system
  • of
  • processes,
  • as
  • well
  • as
  • over
  • their
  • combination
  • and
  • interaction."
{sweref:372} The processes that are selected
  • sweref
    372
    372

The processes that are selected and/or

tailored

to

be

applicable

to

the

project

will

be

accomplished

through

the

execution

of

the

activities

and

tasks

that

compose

the

process.

Specifically,

NPR

7123.1A,

NASA

Systems

Engineering

Processes

and

Requirements,

describes

an

activity

as

a

set

of

tasks

that

describe

the

technical

effort

needed

to

accomplish

a

process

and

to

help

generate

the

expected

outcomes.

Software

processes

are

generally

reviewed

during

the

software

development

life

cycle,

and

revised

and

modified

as

needed.

The

appropriate

planning

and

scheduling

of

these

tasks

and

activities

enable

the

successful

execution

of

the

planned

processes.

The

successful

placement

of

the

applicable

and

tailored

processes,

activities,

and

tasks

on

the

project

development

schedule

will

complete

the

determination

process.

Additional

guidance

related

to

Software

Process

Determination

may

be

found

in

the

following

related

requirements

in

this

Handbook:

| [


|SWE-005] | Software Processes | | [

Software Processes

SWE-013

|SWE-013] | Software Plans | | [

Software Plans

SWE-016

|SWE-016] | Software Schedule | | [

Software Schedule

SWE-019

|SWE-019] | Software Life Cycle | | [SWE-027|SWE-027] | Use of Commercial, Government, and Legacy Software (COTS, GOTS, MOTS) | | [SWE-032|SWE-032] | CMMI Levels | | [SWE-098|SWE-098] | Agency PAL | | [SWE-102|SWE-102] | Software Development/Management Plan | | [SWE-103|SWE-103] | Software Configuration Management Plan | | [SWE-104|SWE-104] | Software Test Plan | | [SWE-105|SWE-105] | Software Maintenance Plan | | [SWE-106|SWE-106] | Software Assurance Plan | | [SWE-130|SWE-130] | Develop A Software Safety Plan | {div3} {div3:id=tabs-4} h1. 4. Small Projects Small projects may want to use a standard set of processes that have been tailored for their development environment, and type of project. These processes may have been developed by people in the same organization that may have done similar developments. {div3} {div3:id=tabs-5} h1. 5. Resources {refstable} {toolstable} {div3} {div3:id=tabs-6} h1. 6. Lessons Learned A documented lesson from the NASA Lessons Learned database notes the following: *Flight Software Engineering Lessons. Lessons Learned 2218:* "The engineering of flight software is a major consideration in establishing JPL project total cost and schedule because every mission requires a significant amount of new software to implement new spacecraft functionality. Constraints to the development and testing of software concurrent to engineering the rest of the flight system has led to flight software errors, including the loss of some missions. The findings of several JPL studies and flight mishap investigations suggest a number of recommendations for mitigating software engineering risk."{sweref:572}\\ {div3}

Software Life Cycle

SWE-027

Use of Commercial, Government, and Legacy Software (COTS, GOTS, MOTS)

SWE-032

CMMI Levels

SWE-098

Agency PAL

SWE-102

Software Development/Management Plan

SWE-103

Software Configuration Management Plan

SWE-104

Software Test Plan

SWE-105

Software Maintenance Plan

SWE-106

Software Assurance Plan

SWE-130

Develop A Software Safety Plan



Div
idtabs-4

4. Small Projects

Small projects may want to use a standard set of processes that have been tailored for their development environment, and type of project. These processes may have been developed by people in the same organization that may have done similar developments.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

Flight Software Engineering Lessons. Lessons Learned 2218: "The engineering of flight software is a major consideration in establishing JPL project total cost and schedule because every mission requires a significant amount of new software to implement new spacecraft functionality. Constraints to the development and testing of software concurrent to engineering the rest of the flight system has led to flight software errors, including the loss of some missions. The findings of several JPL studies and flight mishap investigations suggest a number of recommendations for mitigating software engineering risk."

sweref
572
572