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

...

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.

Requirements

4.1.1

The

project

shall

develop

a

Software

Configuration

Management

Plan

that

describes

the

functions,

responsibilities,

and

authority

for

the

implementation

of

software

configuration

management

for

the

project.

h2. {color:#003366}{*}

1.1

Notes{*}{color} The Software Configuration Management Plan may be a part of the project configuration management plan. The content is defined by the requirement in Chapter 5 \[of NPR 7150.2, NASA Software Engineering Requirements, Section

Notes

The Software Configuration Management Plan may be a part of the project configuration management plan. The content is defined by the requirement in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, Section 5.1.2

\

].

h2.

1.2

Applicability

Across

Classes

Class

G

is

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=1|esc=1|ensc=0|f=1|g=p|h=0} {div3}

Wiki Markup
{div3:id=tabs-2} h1. 2. Rationale {floatbox} "The discipline of CM (configuration management) is vital to the success of any software effort. CM is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life-cycle of the program for information that is shared by more than one individual or organization."

applicable
f1
gp
h0
asc1
ansc1
bnsc1
csc1
bsc1
esc1
cnsc1
dsc1
dnsc1
ensc0
Div
idtabs-2

2. Rationale

Floatbox

"The discipline of CM (configuration management) is vital to the success of any software effort. CM is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life-cycle of the program for information that is shared by more than one individual or organization." (NASA-GB-8719.13,

NASA

Software

Safety

Guidebook)

{sweref:276}{floatbox} "Software configuration management is practiced during all phases of the software life cycle, from initiation of development through software maintenance, and is responsible for ensuring that any changes during the development and maintenance processes are made in a controlled and complete manner... Configuration management contributes to software safety by ensuring that documentation and source code are updated only through a formal process."

sweref
276
276

"Software configuration management is practiced during all phases of the software life cycle, from initiation of development through software maintenance, and is responsible for ensuring that any changes during the development and maintenance processes are made in a controlled and complete manner... Configuration management contributes to software safety by ensuring that documentation and source code are updated only through a formal process." (NASA-STD-8719.13B,

NASA

Software

Safety

Standard)

{

sweref

:271}

271
271

NASA-GB-8719.13,

NASA

Software

Safety

Guidebook,

{

sweref

:

276
276

}

describes

the

software

configuration

management

(SCM)

plan

in

this

manner:

"All

software

products,

which

includes

far

more

than

just

code,

must

be

configuration

managed.

Old

files

in

a

software

build

are

a

notorious

problem,

as

are

lost

updates

and

other

problems

with

changed

files.

The

plan

specifies

what

will

be

under

configuration

management

(CM),

what

CM

system

will

be

used,

and

the

process

for

moving

an

item

into

or

out

of

the

CM

system."

Given

that

CM

occurs

throughout

the

project

life

cycle

and

is

critical

to

controlling

and

tracking

all

elements

of

the

project,

having

a

plan

in

place

ensures

that

the

team

is

informed

of

and

performs

all

necessary

and

required

configuration

management

tasks.

Development

of

the

SCM

plan

provides

the

opportunity

for

stakeholders

to

give

input

and

assist

with

the

documentation

and

tailoring

of

the

planned

configuration

management

activities

for

the

project.

  The SCM plan has both internal and external uses. Internally, it is used within the project to guide, monitor, and measure the overall CM process. It describes both the CM activities planned for future acquisition phases and the schedule for implementing those activities.  Externally, the SCM plan is used to communicate the CM process to the contractors involved in the program. It establishes consistent CM processes and working relationships. (NASA Systems Engineering Handbook{sweref:273}) {div3}
Wiki Markup
{div3:id=tabs-3}

h1. 3. Guidance

The SCM plan describes the software configuration management for the project, including functions, responsibilities, and implementation authority. This plan may be part of the software development plan (SDP)/software management plan (SMP) or it may be a standalone document. If the plan is a standalone document, part of its content needs to describe the SCM plan's relationship to other project plans, especially if configuration management activities are referenced or described in those plans.

{panel}Both providers and acquirers need to have a SCM plan. The contents of the provider plan are established in the contract.{panel}


The SCM plan primarily provides a formal method for managing change, but other activities are key to the overall process and are also appropriate to describe in the plan. See [SWE-103|SWE-103] in this Handbook for guidance on required contents, but consider the following topics as well when developing the SCM plan:

* CM of deliverable and non-deliverable software development products including the following:
** Documentation (e.g., specifications, design documents, traceability matrices, presentations, project plans).
** Source code.
** Object code.
** Executables.
** Data.
** Development and test tools (operating systems, compilers, etc.).
** Development and test environments (both hardware and software).
** Testing software (e.g., test cases/scenarios, scripts (manual and automated), reports).
** Flow charts, {term:UML}or {term:OOD}products, input to automatic code generators.
** Interface control documents, message formats, data formats
** {term:COTS}software.
** Build procedures.
** Defect lists, change requests, problem reports/corrective actions.
** Metrics.
* CM of software assurance records.
* CM of safety-critical software requirements and software elements.
* CM of simulators, models, test suites, etc.
* Management of releases.
* CM of routine software configuration changes, such as mission-specific database changes.
* Assessment of changes for their impact on system safety.
* Metrics to be collected from the CM system, such as lines of code, complexity, estimated and actual time for various activities (development, testing, bug fixes, etc.), number of defects.
* Determinations that can be made from configuration metrics, such as defects per lines of code for a team, goodness of effort estimations, need for more time in unit testing, estimates for future updates/maintenance activities, etc.
* Processes for "handling classified information and sensitive but unclassified (SBU) information, including export controlled and proprietary information, as applicable." (NASA Configuration Management (CM) Standard {sweref:275})

When writing the SCM plan, consider the following tailoring suggestions from IEEE STD 828-2005 {sweref:216}:
* Reflect the current project environment by using terms familiar to the planned users and maintaining consistency with project development processes.
* When tailoring leads to the addition of SCM requirements for a particular project (beyond the minimum specified in a template, standard, etc.), conduct a cost-benefit analysis and obtain agreement from stakeholders.
* When tailoring leads to the removal of SCM requirements for a particular project (from the minimum set specified in a template, standard, etc.), include the rationale for the removal (project has limited scope, unusual environment, etc.) and obtain agreement from stakeholders.

The SCM plan may also be tailored by software classification. Goddard Space Flight Center (GSFC)'s Requirements for Minimum Contents of Software Documents{sweref:090}provides one suggestion for tailoring an SCM plan based on the required contents and the classification of the software being developed.

Development of the SCM plan, typically by engineering, begins during project formulation. Inputs to developing the project-level plan include the program CM plan, the IEEE Standard for Software Configuration Management Plans (IEEE STD 828-2005), and any Agency or Center-specific templates and guidance material.

Once the SCM plan is created, it is peer reviewed ([SWE-137|SWE-137]), coordinated with the project customer and other stakeholders, and reviewed at project milestone reviews, such as the System Requirements Review (SRR), Software Requirements Review (SwRR), Mission Definition Review (MDR), etc. (see [Topic 7.8 - Maturity of Life Cycle Products at Milestone Reviews|7.8 - Maturity of Life Cycle Products at Milestone Reviews]). The SCM plan needs to be reviewed by software assurance to ensure compliance with applicable standards, procedures, and to ensure the plan is being properly implemented.

{note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to CM. {note}

Additional guidance related to CM and topics that have to be addressed in the SCM plan may be found in the following related requirements in this Handbook:
| [SWE-080|SWE-080] | Track and Evaluate Changes |
| [SWE-081|SWE-081] | Identify Software Configuration Management Items |
| [SWE-082|SWE-082] | Authorizing Changes |
| [SWE-083|SWE-083] | Status Accounting |
| [SWE-084|SWE-084] | Configuration Audits |
| [SWE-085|SWE-085] | Release Management |
| [SWE-103|SWE-103] | Software Configuration Management Plan |
\\
\\
{div3}
Wiki Markup
{div3:id=tabs-4}

h1. 4. Small Projects

CM activities are based on risk, so projects designated small by size of the team or budget need to ensure that their {term:SCM}plans consider all the required content noted in [SWE-103|SWE-103], but only include those processes and the associated structure commensurate with project risk. This might mean planning to use simpler tools or fewer personnel (filling multiple roles) to carry out the SCM processes.  It could also mean planning to use a single tool for multiple purposes to reduce tool management and overhead. Note that waivers may be necessary if any required content is left out of the SCM plan.

Small projects may not require the formality of a separate SCM plan; instead SCM planning may be documented as a section of the project's Software Management Plan. Alternatively, one master SCM plan may document CM for multiple small projects.
{div3}
Wiki Markup
{div3:id=tabs-5}

h1. 5. Resources

{refstable}

{Toolstable}


{div3}
Wiki Markup
{div3:id=tabs-6} h1. 6. Lessons Learned The NASA Lessons Learned database contains the following lessons learned related to the importance of configuration management: * *Software Design for Maintainability (Software maintainability). Lesson Number 0838:* "Configuration management of software is probably the single most important management and maintainability concept utilized in software development. Utilization of coding standards, documentation standards, release standards, common languages and other methods will provide for good configuration management. A plan should be developed very early in the development cycle for managing the configuration of the software under development, and that plan should be followed rigorously. If configuration management breaks down, the code under development is doomed to be extremely troublesome when released for operations." {sweref:526} * *Computer Software/Configuration Control/Verification and Validation (V&V) (Auto-generated code). Lesson Number 1023:* "The use of the ... autocode generator for ISS software can lead to serious problems if the generated code and ... \[tool\] itself are not subjected to effective configuration control or the products are not subjected to unit-level V&V. These problems can be exacerbated if the code generated ... is modified by hand." {sweref:533} * *Take CM Measures to Control the Renaming and Reuse of Old Command Files (2002) (File naming). Lesson Number 1481:* "The ... Team renamed a ... file ... prepared for a previous mission for use on a current mission without changing the file creation time recorded in the file header. This error caused the new file to be repeatedly recognized as an 'old' file, and required operations personnel for several months to manually specify the correct file. Implement {term:CM}measures to assure adequate oversight when renaming old command sequence resources for reuse." {sweref:556} {div3}

 

The SCM plan has both internal and external uses. Internally, it is used within the project to guide, monitor, and measure the overall CM process. It describes both the CM activities planned for future acquisition phases and the schedule for implementing those activities.  Externally, the SCM plan is used to communicate the CM process to the contractors involved in the program. It establishes consistent CM processes and working relationships. (NASA Systems Engineering Handbook

sweref
273
273
)

Div
idtabs-3

3. Guidance

The SCM plan describes the software configuration management for the project, including functions, responsibilities, and implementation authority. This plan may be part of the software development plan (SDP)/software management plan (SMP) or it may be a standalone document. If the plan is a standalone document, part of its content needs to describe the SCM plan's relationship to other project plans, especially if configuration management activities are referenced or described in those plans.

Panel

Both providers and acquirers need to have a SCM plan. The contents of the provider plan are established in the contract.

The SCM plan primarily provides a formal method for managing change, but other activities are key to the overall process and are also appropriate to describe in the plan. See SWE-103 in this Handbook for guidance on required contents, but consider the following topics as well when developing the SCM plan:

  • CM of deliverable and non-deliverable software development products including the following:
    • Documentation (e.g., specifications, design documents, traceability matrices, presentations, project plans).
    • Source code.
    • Object code.
    • Executables.
    • Data.
    • Development and test tools (operating systems, compilers, etc.).
    • Development and test environments (both hardware and software).
    • Testing software (e.g., test cases/scenarios, scripts (manual and automated), reports).
    • Flow charts,
      Term
      UML
      UML
      or
      Term
      OOD
      OOD
      products, input to automatic code generators.
    • Interface control documents, message formats, data formats
    • Term
      COTS
      COTS
      software.
    • Build procedures.
    • Defect lists, change requests, problem reports/corrective actions.
    • Metrics.
  • CM of software assurance records.
  • CM of safety-critical software requirements and software elements.
  • CM of simulators, models, test suites, etc.
  • Management of releases.
  • CM of routine software configuration changes, such as mission-specific database changes.
  • Assessment of changes for their impact on system safety.
  • Metrics to be collected from the CM system, such as lines of code, complexity, estimated and actual time for various activities (development, testing, bug fixes, etc.), number of defects.
  • Determinations that can be made from configuration metrics, such as defects per lines of code for a team, goodness of effort estimations, need for more time in unit testing, estimates for future updates/maintenance activities, etc.
  • Processes for "handling classified information and sensitive but unclassified (SBU) information, including export controlled and proprietary information, as applicable." (NASA Configuration Management (CM) Standard
    sweref
    275
    275
    )

When writing the SCM plan, consider the following tailoring suggestions from IEEE STD 828-2005 

sweref
216
216
:

  • Reflect the current project environment by using terms familiar to the planned users and maintaining consistency with project development processes.
  • When tailoring leads to the addition of SCM requirements for a particular project (beyond the minimum specified in a template, standard, etc.), conduct a cost-benefit analysis and obtain agreement from stakeholders.
  • When tailoring leads to the removal of SCM requirements for a particular project (from the minimum set specified in a template, standard, etc.), include the rationale for the removal (project has limited scope, unusual environment, etc.) and obtain agreement from stakeholders.

The SCM plan may also be tailored by software classification. Goddard Space Flight Center (GSFC)'s Requirements for Minimum Contents of Software Documents

sweref
090
090
provides one suggestion for tailoring an SCM plan based on the required contents and the classification of the software being developed.

Development of the SCM plan, typically by engineering, begins during project formulation. Inputs to developing the project-level plan include the program CM plan, the IEEE Standard for Software Configuration Management Plans (IEEE STD 828-2005), and any Agency or Center-specific templates and guidance material.

Once the SCM plan is created, it is peer reviewed (SWE-137), coordinated with the project customer and other stakeholders, and reviewed at project milestone reviews, such as the System Requirements Review (SRR), Software Requirements Review (SwRR), Mission Definition Review (MDR), etc. (see Topic 7.8 - Maturity of Life Cycle Products at Milestone Reviews). The SCM plan needs to be reviewed by software assurance to ensure compliance with applicable standards, procedures, and to ensure the plan is being properly implemented.

Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to CM.

Additional guidance related to CM and topics that have to be addressed in the SCM plan may be found in the following related requirements in this Handbook:

SWE-080

Track and Evaluate Changes

SWE-081

Identify Software Configuration Management Items

SWE-082

Authorizing Changes

SWE-083

Status Accounting

SWE-084

Configuration Audits

SWE-085

Release Management

SWE-103

Software Configuration Management Plan



Div
idtabs-4

4. Small Projects

CM activities are based on risk, so projects designated small by size of the team or budget need to ensure that their

Term
SCM
SCM
plans consider all the required content noted in SWE-103, but only include those processes and the associated structure commensurate with project risk. This might mean planning to use simpler tools or fewer personnel (filling multiple roles) to carry out the SCM processes.  It could also mean planning to use a single tool for multiple purposes to reduce tool management and overhead. Note that waivers may be necessary if any required content is left out of the SCM plan.

Small projects may not require the formality of a separate SCM plan; instead SCM planning may be documented as a section of the project's Software Management Plan. Alternatively, one master SCM plan may document CM for multiple small projects.

Div
idtabs-5

5. Resources

refstable
Toolstable
Div
idtabs-6

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to the importance of configuration management:

  • Software Design for Maintainability (Software maintainability). Lesson Number 0838: "Configuration management of software is probably the single most important management and maintainability concept utilized in software development. Utilization of coding standards, documentation standards, release standards, common languages and other methods will provide for good configuration management. A plan should be developed very early in the development cycle for managing the configuration of the software under development, and that plan should be followed rigorously. If configuration management breaks down, the code under development is doomed to be extremely troublesome when released for operations."
    sweref
    526
    526
  • Computer Software/Configuration Control/Verification and Validation (V&V) (Auto-generated code). Lesson Number 1023: "The use of the ... autocode generator for ISS software can lead to serious problems if the generated code and ... [tool] itself are not subjected to effective configuration control or the products are not subjected to unit-level V&V. These problems can be exacerbated if the code generated ... is modified by hand."
    sweref
    533
    533
  • Take CM Measures to Control the Renaming and Reuse of Old Command Files (2002) (File naming). Lesson Number 1481: "The ... Team renamed a ... file ... prepared for a previous mission for use on a current mission without changing the file creation time recorded in the file header. This error caused the new file to be repeatedly recognized as an 'old' file, and required operations personnel for several months to manually specify the correct file. Implement
    Term
    CM
    CM
    measures to assure adequate oversight when renaming old command sequence resources for reuse."
    sweref
    556
    556