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-036} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements

Div

id	tabs-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

does not include any notes for this requirement. h2.

, NASA Software Engineering Requirements, does not include any notes for this requirement.

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	*
g	p
h	0
ansc	1
asc	1
bnsc	1
csc	1
bsc	1
esc	1
cnsc	1
dnsc	p
dsc	1
ensc	0

Div

id	tabs-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=

Div

id	tabs-3

} h1.

3. Guidance

The

formulation

phase

in

the

life

cycle 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,

cycle (see 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 (CMMI®-Dev), Version 1.3 {sweref: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 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 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 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, NPR7123.1 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|SWE-005] | Software Processes | | [SWE-013|SWE-013] | Software Plans | | [SWE-016|SWE-016] | Software Schedule | | [SWE-019|SWE-019] | Software Life cycle | | [SWE-027|SWE-027] | Use of 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 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} h2. 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. ([http://www.nasa.gov/offices/oce/llis/imported_content/lesson_2218.html]) {div3} {tabclose}

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
157
. The CMMI-Dev describes the applicability of its processes areas for developing software work products.
[NPR 7123.1A
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
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
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
SWE-013	Software Plans
SWE-016	Software Schedule
SWE-019	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

id	tabs-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

id	tabs-5

5. Resources

refstable

toolstable

Div

id	tabs-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

Content

Space Tools

Versions Compared

Old Version 20

New Version Current

Key

1. Requirements

1.1

Notes

1.2

Applicability

Across

Classes

Class

2. Rationale

3.

Guidance

The

4. Small Projects

5. Resources

6. Lessons Learned

Content

Space Tools

Page History

Versions Compared

Old Version 20

New Version Current

Key

1. Requirements

1.1

Notes

1.2

Applicability

Across

Classes

Class

2. Rationale

3.

Guidance

The

4. Small Projects

5. Resources

6. Lessons Learned