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

Wiki Markup

Tabsetup

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

Div

id	tabs-1

1. Requirements

5.1.2.1

The

Software

Configuration

Management

Plan

shall

contain:

[SWE-103]

a.

The

project

organization(s).

b.

Responsibilities

of

the

software

configuration

management

organization.

c.

References

to

the

software

configuration

management

policies

and

directives

that

apply

to

the

project.

d.

All

functions

and

tasks

required

to

manage

the

configuration

of

the

software,

including

configuration

identification,

configuration

control,

status

accounting,

and

configuration

configuration audits

and

reviews.

e.

Schedule

information,

which

establishes

the

sequence

and

coordination

for

the

identified

activities

and

for

all

events

affecting

the

plan's

implementation.

f.

Resource

information,

which

identifies

the

software

tools,

techniques,

and

equipment

necessary

for

the

implementation

of

the

activities.

g.

Plan

maintenance

information,

which

identifies

the

activities

and

responsibilities

necessary

to

ensure

continued

planning

during

the

life

cycle

of

the

project.

h.

Release

management

and

delivery.

h2. 1.1       Notes NPR 7150.2 does not include any notes for this requirement. h2. 1.2       Applicability Across Classes * Class B, Class B Safety Critical and Classes C through E Safety Critical are labeled,

1.1 Notes

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

1.2 Applicability Across Classes

Class B, Class B Safety Critical, and Classes C through E Safety Critical are labeled, "P (Center)

+

SO."

.

This

means

that

this

requirement

applies

to

the

safety-critical

aspects

of

the

software

and

that

an

approved

Center-defined

process

which

that meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

*

Class

C

not

Not Safety

Critical,

Class

D

not

Not Safety

Critical,

and

Class

G

are

labeled

with

"P (Center)."

. 

This

means

that

an

approved

Center-defined

process

which

that meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

{applicable:asc=1\|ansc=1\|bsc=*\|bnsc=*\|csc=*\|cnsc=p\|dsc=*\|dnsc=p\|esc=*\|ensc=0|f=1\|g=p|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Configuration Management is the "process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the system life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items." ([NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126], NASA-BG-8719.13).^1^ This work can only be properly accomplished if there exists a plan addressing all of these activities which has been reviewed by an appropriate set of stakeholders and tailored for a specific project's needs. {div3} {div3:id=tabs-3} h1. 3. Guidance The software configuration management (SCM) plan may be tailored by software classification.  Goddard Space Flight Center (GSFC)'s [Requirements for Minimum Contents of Software Documents|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.0.2.doc]^6^ provides one suggestion for tailoring a SCM plan based on the required contents and the classification of the software being developed. When creating a SCM plan, using a template ensures consistent plans for all projects at a Center.  Consider the following guidance, listed by the required elements shown in the NPR 7150.2A text for this SWE above, to ensure that all the required content is properly addressed and tailored for the project: *{+}Project organization(s)+* Consider the following when writing the project organization section of the SCM:\* Describe where SCM fits into the technical and managerial reporting chain of the project * Identify by role project personnel responsible for managing the SCM activities for the project * Identify by role those persons on the project who will carry out SCM activities for the project *{+}Responsibilities{+}* The responsibilities of the software configuration management organization should address: * Responsibilities for each role participating in SCM activities, including team personnel, Leads, Change Control Board (CCB), quality assurance, managers, and any other roles relevant for the project * Responsibilities for carrying out each of the SCM functions defined in the SCM plan * Responsibilities of each CCB established for the project, including references to their charters or other governing documents (purpose, objectives, scope of authority, duration of existence) and the hierarchy among the CCBs; charts or diagrams may be helpful here * CCB participants either by project name and role or individual names * CCB meeting schedules, if not captured elsewhere * Responsibilities for releasing software, if not captured elsewhere * Provider roles and integration of provider SCM into overall project SCM * Responsibilities for maintaining SCM tools *{+}References to SCM policies and directives{+}* This section of the SCM plan should list any specific SCM policies and directives that apply to or impact SCM for the project.  Those policies and directives may be named in a reference section of the plan, so referring to that section may be appropriate.  However, the impact of those policies and directives on SCM for the project should be described here. Consider: * Existing CCB procedures * Existing status accounting procedures * Existing configuration identification procedures * Existing audit procedures \\ *{+}All functions and tasks required to manage the configuration of the software{+}* This section of the plan should describe configuration identification, configuration control, status accounting, and configuration audits and reviews.  [See related guidance for each of these topics in this handbook.|#Check1] This section of the SCM plan should describe how each of these SCM functions will be performed.  Consider using a separate subsection for each of the 4 functions.  As appropriate for the project, the following highlights should be included, but should not be considered the only items to document: * List of configuration items (or reference to where it can be found or how it can be obtained) * Naming convention for configuration items * Activities to define, track, store, and retrieve configuration items * Process for capturing a configuration item in the SCM system * How to request a change (how to enter a CR and get it into the review & approval process) * Levels of control for changes (CCBs) * Activities for verifying and implementing an approved change * Schedule, purpose, responsible party for status accounting forms and reports, including metrics * Access to status accounting data * List, description, and purpose of planned SCM audits and reviews If the project uses data management in addition to SCM, those activities should be described in this section of the SCM plan, including: * Receiving data * Cataloging data * Maintaining status records * Establishing and maintaining secure data access and control * Providing change control monitoring and review * Archiving data * Plans for backups and disaster recovery \\ *{+}Schedule{+}* This section of the plan should include information necessary to describe "the sequence and coordination for the identified activities and for all events affecting the plan's implementation." (NPR 7150.2)  The SCM schedule should coordinate with the project schedule and this part of the SCM plan should show that coordination.  Graphics (time-lines) may be useful. Typically, configuration items are uncontrolled until some "gate" or milestone is reached when they are required to be placed under configuration control.  Each configuration item or group of items may have its own "gate".  Because those "gates" can be points in the project time-line, consider describing those "gates" in this section. Also consider for the SCM schedule: * Time-line or phase for creation of planned baselines * SCM audit schedule \\ *{+}Resources{+}* {floatbox} "Software Configuration Management is usually performed using a tool (program). However, a file or folder should be maintained, to collect information that is not in electronic form. This information could include the design notes scribbled on a napkin or a fax that only exists in hard-copy. The point is to collect all pertinent information in one place. It is a good idea to catalog all the hard-copy information in the electronic SCM system, so that it can be found again when needed." (_[NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126]_, NASA-BG-8719.13).^1^ {floatbox} The resources section of the SCM plan should describe the software tools, techniques, and equipment that will be used to carry out SCM for the project.  References to the relevant documentation for installing and using these tools should be included as well as the configuration controls for each tool. Typical resources include: * Personnel (note level of effort and any required training and/or qualifications) * Tools for managing source code, documents, requirements, design and any other configuration items * Tools for managing change requests if not integrated with the main configuration management tool * Tools for managing data not subject to configuration control and CCB change authority such as meeting minutes, reports, action items, corrective actions * Manual procedures * Equipment to support or host SCM tools * Training for SCM personnel {floatbox} "Describe how the project will manage information throughout its life cycle, including the development and maintenance of an electronic program library. Explain how the project will ensure identification, control, and disposition of project records in accordance with NPD 1440.6, NASA Records Management, and NPR 1441.1, Records Retention Schedules." (NASA Space Flight Program and Project Management Requirements, [NPR 7120.5D|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D_]) {floatbox} *{+}Plan maintenance{+}* The maintenance section should provide information such as: * History of changes * Role responsible for monitoring the SCM plan * Frequency of scheduled updates * Process for evaluating and approving changes to the SCM plan * Process for implementing and communicating approved changes to the SCM plan *{+}Release management and delivery{+}* Per the [NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126] (NASA-BG-8719.13)^1^, "Configuration Management should act as the sole distributor of media and documentation for all system tests and for delivery to \[sub\]system integration and testing. Pulling the latest program off the developer's machine is not a good idea. One aspect of system testing is repeatability, which can only be assured if the software under test comes from a known, and fixed, source."^1^ The release management and delivery activity should be described in this portion of the SCM plan (see [SWE-085|SWE-085] for release management guidance), including formal control of the build, release, and delivery of software products and documentation. {note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance, templates, and resources related to the content of the configuration management plan. {note} Additional guidance related to the content of the configuration management plan may be found in the following related requirements in this handbook: | [SWE-079|SWE-079] \\ | Develop CM Plan \\ | | [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 \\ | {div3} \\ {div3:id=tabs-4} h1. 4. Small Projects Configuration management activities are based on risk, so projects designated small by size of the team or budget should ensure that their SCM plans include all the required content while including only those processes and the associated structure necessary to manage 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. 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} {div3:id=tabs-5} h1. 5. Resources # NASA Technical Standard, "[NASA Software Safety Guidebook|https://standards.nasa.gov/documents/detail/3315126]", NASA-GB-8719.13, 2004. # NASA Procedural Requirements, "[NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7120_005D_]", NPR 7120.5D, 2007. # IEEE Computer Society, "[IEEE Standard for Software Configuration Management Plans|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1502775&tag=1]", IEEE STD 828-2005, 2005. This link requires an account on the NASA START (AGCY NTSS) system ([http://standards.nasa.gov|http://standards.nasa.gov/] ).  Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards. # IEEE Computer Society, "[IEEE Guide to Software Configuration Management|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=89631&tag=1]", IEEE STD 1042-1987, 1987.  This link requires an account on the NASA START (AGCY NTSS) system ([http://standards.nasa.gov|http://standards.nasa.gov/] ).  Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards. # NASA Technical Standard, "[NASA Configuration Management (CM) Standard|https://standards.nasa.gov/documents/detail/3315133]", NASA-STD-0005, 2008. # GSFC Software Engineering Division, "[Requirements for Minimum Contents of Software Documents|http://software.gsfc.nasa.gov/AssetsApproved/PA1.0.0.2.doc]", 580-STD-077-01, 2010. # NASA IV&V, "[Sample Configuration Management Plan|http://www.nasa.gov/centers/ivv/pdf/170879main_T2401.pdf]", T2401, Revision A, 2009.  Note: This plan includes the following note, "This sample CMP was created by the Carnegie Mellon Software Engineering Institute. The original URL of this plan is [http://www.sei.cmu.edu/legacy/scm/papers/CM_Plans/CMPlans.AppendixB.html]. " # Madden, Michael, Unisys Corporation (for Langley Research Center), "[Simulation Project Software Configuration Management (SCM) Plan|http://sw-eng.larc.nasa.gov/spii/tools/other/SPSCMSP/SPSCMSP.html], 1996.  This is listed as a Best Practice on the LaRC PAL site ([http://sw-eng.larc.nasa.gov/resource.cfm|http://sw-eng.larc.nasa.gov/resource.cfm] ).  It is an example, not a practice/process.  Note that it is from 1996 and it is based on IEEE Std 828-1990 which has been superseded by 828-2005. # Langley Research Center, "[Software Configuration Management Plan|http://sw-eng.larc.nasa.gov/process/documents/pdfdocs/vmd-scmp-ver1-rev01.pdf]; - Example 2a", 2000. # [Software Configuration Management|http://software.grc.nasa.gov/processes/GRC%E2%80%93SW%E2%80%937150.9-Software%20Configuration%20Management.pdf], GRC-SW-7150-9, Revision B, Glenn Research Center (GRC), 2011. # Information Systems Division, Goddard Space Flight Center, [Configuration Management Plan Template|http://software.gsfc.nasa.gov/AssetsApproved/PA3.1.1.5.doc], 580-TM-065-01, 2007. {Toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned The NASA Lessons Learned database includes the following lesson learned related to software configuration management: *Project Attention to Configuration Control. Lesson Number 2476:*  "Project attention to the configuration control of flight scripts is likely to prevent the generation of unnecessary software iterations, improve the rigor of mission system engineering processes, and ensure consistency in the test and operations environments." (http://www.nasa.gov/offices/oce/llis/imported_content/lesson_2476.html) {div3} {tabclose} ----

applicable

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

Div

id	tabs-2

2. Rationale

Configuration management is the "process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the system life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items."

sweref

	276
	276

This work can only be properly accomplished if there exists a plan addressing all of these activities, which has been reviewed by an appropriate set of stakeholders and tailored for a specific project's needs.

Div

id	tabs-3

3. Guidance

The Software Configuration Management (SCM) Plan may be tailored by software classification. Goddard Space Flight Center's (GSFC's) 580-STD-077-01,

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.

When creating an SCM Plan, using a template ensures consistent plans for all projects at a Center. Consider the following guidance, listed by the required elements shown in the NPR 7150.2 text for this SWE, to ensure that all the required content is properly addressed and tailored for the project:

Project organization(s)

Consider the following when writing the project organization section of the SCM Plan:

Describe where SCM fits into the technical and managerial reporting chain of the project.
Identify by role project personnel responsible for managing the SCM activities for the project.
Identify by role those persons on the project who will carry out SCM activities for the project.

Responsibilities

The responsibilities of the SCM organization include:

Responsibilities for each role participating in SCM activities, including team personnel, leads, Change Control Board (CCB), quality assurance, managers, and any other roles relevant for the project.
Responsibilities for carrying out each of the SCM functions defined in the SCM Plan.
Responsibilities of each CCB established for the project, including references to their charters or other governing documents (purpose, objectives, scope of authority, duration of existence) and the hierarchy among the CCBs; charts or diagrams may be helpful here.
CCB participants, either by project name and role or by individual names.
CCB meeting schedules, if not captured elsewhere.
Responsibilities for releasing software, if not captured elsewhere.
Provider roles and integration of provider SCM into overall project SCM.
Responsibilities for maintaining SCM tools.

References to SCM policies and directives

This section of the SCM Plan needs to list any specific SCM policies and directives that apply to or impact SCM for the project. Those policies and directives may be named in a reference section of the plan, so referring to that section may be appropriate. However, the impact of those policies and directives on SCM for the project is described here.

Consider:

Existing CCB procedures.
Existing status accounting procedures.
Existing configuration identification procedures.
Existing audit procedures.

All functions and tasks required to manage the configuration of the software

This section of the plan describes configuration identification, configuration control, status accounting, and configuration audits and reviews. Guidance for each of these topics is found in the related requirements (see table below) in this Handbook.

This section of the SCM Plan describes how each of these SCM functions will be performed. Consider using a separate subsection for each of the four functions. As appropriate for the project, the following highlights are to be included but are not to be considered the only items to document:

List of configuration items (or reference to where this list can be found or how it can be obtained).
Naming convention for configuration items.
Activities to define, track, store, and retrieve configuration items.
Process for capturing a configuration item in the SCM system.
How to request a change (how to enter a change request and transition it into the review and approval process).
Levels of control for changes (CCBs).
Activities for verifying and implementing an approved change.
Schedule, purpose, responsible party for status accounting forms and reports, including metrics.
Access to status accounting data.
List, description, and purpose of planned SCM audits and reviews.

If the project uses data management in addition to SCM, those activities are described in this section of the SCM Plan, including:

Receiving data.
Cataloging data.
Maintaining status records.
Establishing and maintaining secure data access and control.
Providing change control monitoring and review.
Archiving data.
Plans for backups and disaster recovery.

Schedule

This section of the plan includes information necessary to describe "the sequence and coordination for the identified activities and for all events affecting the plan's implementation" (NPR 7150.2, section 5.1.2.1.e). The SCM schedule needs to coordinate with the project schedule, and this part of the SCM Plan shows that coordination. Graphics (timelines) may be useful.

Typically, configuration items are uncontrolled until some gate or milestone is reached, at which time they are required to be placed under configuration control. Each configuration item or group of items may have its own gate. Because those gates can be points in the project timeline, consider describing those gates in this section.

Also consider for the SCM schedule:

Timeline or phase for creation of planned baselines.
SCM audit schedule.

Resources

Floatbox

"Software Configuration Management is usually performed using a tool (program). However, a file or folder needs to be maintained, to collect information that is not in electronic form. This information could include the design notes scribbled on a napkin or a fax that only exists in hard-copy. The point is to collect all pertinent information in one place. It is a good idea to catalog all the hardcopy information in the electronic SCM system, so that it can be found again when needed."

sweref

	276
	276

The resources section of the SCM Plan describes the software tools, techniques, and equipment that will be used to carry out SCM for the project. References to the relevant documentation for installing and using these tools is included, as well as the configuration controls for each tool.

Typical resources include:

Personnel (note level of effort and any required training and/or qualifications).
Tools for managing source code, documents, requirements, design, and any other configuration items.
Tools for managing change requests if not integrated with the main configuration management tool.
Tools for managing data not subject to configuration control and CCB change authority, such as meeting minutes, reports, action items, corrective actions.
Manual procedures.
Equipment to support or host SCM tools.
Training for SCM personnel.

Floatbox

"Describe how the project will manage information throughout its life cycle, including the development and maintenance of an electronic program library. Explain how the project will ensure identification, control, and disposition of project records in accordance with NPD 1440.6, NASA Records Management, and NPR 1441.1, Records Retention Schedules."

sweref

	082
	082

Plan maintenance

The maintenance section provides information such as:

History of changes.
Role responsible for monitoring the SCM Plan.
Frequency of scheduled updates.
Process for evaluating and approving changes to the SCM Pan.
Process for implementing and communicating approved changes to the SCM Plan.

Release management and delivery

NASA-GB-8719.13, NASA Software Safety Guidebook,

sweref

	276
	276

states: "Configuration Management should act as the sole distributor of media and documentation for all system tests and for delivery to [sub]system integration and testing. Pulling the latest program off the developer's machine is not a good idea. One aspect of system testing is repeatability, which can only be assured if the software under test comes from a known, and fixed, source."

sweref

	276
	276

The release management and delivery activity is described in this portion of the SCM Plan (see SWE-085 for release management guidance), including formal control of the build, release, and delivery of software products and documentation.

Note
Consult Center Process Asset Libraries (PALs) for Center-specific guidance, templates, and resources related to the content of the configuration management plan.

Additional guidance related to the content of the configuration management plan may be found in the following related requirements in this Handbook:

SWE-079	Develop CM Plan
SWE-081	Identify Software CM Items
SWE-082	Authorizing Changes
SWE-083	Status Accounting
SWE-084	Configuration Audits
SWE-085	Release Management

Div

id	tabs-4

4. Small Projects

Configuration management activities are based on risk, so projects designated small by size of the team or budget need to ensure that their Software Configuration Management (SCM) Plans include all the required content, while including only those processes and the associated structure necessary to manage 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.

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 configuration management for multiple small projects.

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:

Place Flight Scripts Under Configuration Management Prior to ORT (Project attention to configuration control). Lesson Number 2476: "Project attention to the configuration control of flight scripts is likely to prevent the generation of unnecessary software iterations, improve the rigor of mission system engineering processes, and ensure consistency in the test and operations environments."

sweref

	574
	574

...

Content

Space Tools

Versions Compared

Old Version 49

New Version Current

Key

1. Requirements

1.1 Notes

1.2 Applicability Across Classes

2. Rationale

3. Guidance

4. Small Projects

5. Resources

6. Lessons Learned

Content

Space Tools

Page History

Versions Compared

Old Version 49

New Version Current

Key

1. Requirements

1.1 Notes

1.2 Applicability Across Classes

2. Rationale

3. Guidance

4. Small Projects

5. Resources

6. Lessons Learned