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


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

1. Requirements

4.1.4

The

project

shall

establish

and

implement

procedures

designating

the

levels

of

control

each

identified

configuration

item

must

pass

through;

the

persons

or

groups

with

authority

to

authorize

changes

and

to

make

changes

at

each

level;

and

the

steps

to

be

followed

to

request

authorization

for

changes,

process

change

requests,

track

changes,

distribute

changes,

and

maintain

past

versions.

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 {applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=0|dsc=1|dnsc=0|esc=1|ensc=0|f=1|g=p|h=p} {div3} {div3:id=tabs-2} h1. 2. Rationale Configuration control helps ensure that changes are managed in a structured way, that the impact of changes is assessed before those changes are implemented, and that changes are authorized before being implemented. Using various levels of control can reduce the time and effort it takes to disposition a change request based on the criticality and range of the affect of the change. Less critical or risky changes can use a lower-level of authority to make decisions about those changes while more critical or far-reaching changes can require authorization from a more formal body with a broader view of the system. {panel} Configuration control procedures are important because they help ensure that arbitrary changes are avoided and that the team understands how changes are to be managed for the project. {panel} {div3} {div3:id=tabs-3} h1. 3. Guidance The configuration management plan documents the configuration control and change authorization procedures (see [SWE-079] and [SWE-103]). When developing these procedures, all of the following topics are included: levels of control, change authority, authorization requests, change request process, and version maintenance. The STEP Level 2 Software Configuration Management and Data Management course taught by the Westfall Team includes recommendations and suggestions for change control, some of which is summarized in this guidance. h3. Levels of control Each identified configuration item has a defined level of control for making changes to that item. Documentation might have one level of change control, while source code might require a different level of control. For each identified configuration item or group/class of items, the change control procedures identifies the appropriate level of control. Consider the following when defining levels of configuration control: * Each configuration item or class of items has a defined "owner" who is responsible for authorizing changes to that item, e.g., the software CCB might be the designated owner for all software libraries while the documentation peer review team might be the owner for product marketing materials * Depending on the effect of the change, multiple levels of control may need to be defined, e.g., a change to software that is shared among projects may require change approval from multiple change authorities * Levels of control may "vary throughout the life cycle. For example, changes to code in the development cycle usually require a lower level of control to be authorized than changes to the same code after it has been released for general use."^4^ ([IEEE Guide to Software Configuration Management|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=89631&tag=1]) * Levels of control may be affected by the change originator, e.g., a change request from outside the organization, such as customers or end users, may require different authority for approval than changes requested by software developers h3. Change authority Change control procedures include defining the persons or groups with authority to authorize changes and to make changes at each level. Examples of change authority include Change Control Boards (CCB), Change Authorization Board (CAB), Engineering Change Boards (ECB), peer review teams, project manager, etc. The change approval authority may be determined by the complexity, cost, risk, or effect of the change. When defining the change authority, consider the following: * Include software assurance/safety personnel to ensure safety impact is considered * Involve stakeholders based on the expertise and authority required to disposition the change ** People with authority in the appropriate fields ** Experts in a particular field ** Policy makers ** Systems engineers ** Software engineers ** Hardware engineers * Use different levels of change authority, as appropriate, for cost and time savings ** Product level CCB for changes to functional baseline, product baseline, system-level changes or changes that will affect the fielded product ** Project level CCB for changes to allocated baselines, changes that only affect the project, not the system ** Software development CCB for changes to development baselines, changes that only affect the software, not hardware or documentation * If different levels of authority are used, ** Group size can be less at the lower levels ** Typically one representative from the lower level sits on the next level change authority board ** Escalation can occur if a lower level change authority cannot agree on disposition of a change ** An escalation plan is typically defined as part of the change control procedures ** Coordination plans may be required if multiple change authorities are required to disposition a change ** Typically costs more in time and effort to convene higher level change authority boards, so they tend to meet less frequently * Document the responsibilities of each level of authority, including, as applicable: ** Area of change authority such as software changes, system-level changes, documentation changes, etc. ** Review and disposition of change requests ** Authorizing release and delivery of baselined software products ** Documenting and retaining evidence of the group's authorization activities ** Informing the appropriate stakeholders of the results of those authorization activities h3.Authorization requests Change control procedures include steps to be followed to request authorization for changes. Consider the following when documenting the steps to request authorization for making a change: * Include instructions for choosing the proper change request to submit (Engineering Change Proposal (ECP), change request (CR), problem report (PR), etc. as appropriate and applicable for the project) * Include instructions for properly completing the change request, typically a form in an automated change control system (see [SWE-113] for change request contents), such that the change authority can make an informed disposition decision * Include instructions for supplying information not captured in the change request, but necessary for the change authority to disposition the request * Include instructions for determining the proper change authority * Include instructions for submitting a request to the proper change authority * Include information regarding when the change originator expects to receive the disposition decision from the change authority h3.Change request process The change request process consists of three steps described in the change control procedures: change request processing, tracking changes, and distributing changes. When developing procedures for processing change requests, consider: * Using a screener to ensure the changes requests are properly completed before higher level change authority boards spends time on incomplete or out of scope requests (see [SWE-113] for change request contents) * Giving the change authority board the ability to perform impact analysis (see [SWE-080]) themselves or to call on another group with greater specific expertise to do the analysis * Describing the disposition options (once the analysis is complete, the change authority dispositions the change request, typically, in one of three ways: approve for implementation, defer the change until some later point in time, or reject the change request) * Requiring the basis for the disposition to be documented and the disposition disseminated to the appropriate stakeholders A sample process flow might look like this chart adapted from the STEP Level 2 Software Configuration Management and Data Management course^1^: When developing procedures for tracking changes, consider: * Collecting status as the change request is processed (open, fixed, resolved, closed, etc.) along with the status change dates * Capturing the impact analysis for each change * Collecting disposition status (approved, deferred, rejected) and date * Capturing the solution implemented for each change * Capturing the verification activity and results for each implemented change * Capturing all configuration items affected by the change (requirements, design, tests, source code, documentation, etc.) * Using the features of configuration management tools to track changes and related metrics and data * Tracking changes to all identified configuration items (see [SWE-081]) * Reporting status of changes to project management on a regular basis; reporting frequency may be established based on the life cycle phase of the project with documentation in the configuration management plan * Guidance provided in [SWE-080] in this handbook for tracking and evaluating changes When developing procedures for distributing changes, consider: * Releasing changes only after verification and approval of their implementation * Releasing changes in a controlled manner, typically as part of a baseline (during development), patch or update (for changes to fielded software), or new fielded release * Using a software version description (SVD) or version description document (VDD) to identify the changes included in a software release h3.Version maintenance When developing procedures for maintaining past versions of the software, consider: * The ease of retrieving past versions to address issues found in fielded software * Tracking all released software that uses a particular version of a configuration item so that changes can be made to all affected software, not just the version for which the change was requested * Using features of configuration management tools, such as "tagging", to identify all items and their versions in a baseline or release {note} Consult center Process Asset Libraries (PALs) for Center-specific guidance and resources related to configuration control and authorizing changes. {note} Additional guidance related to authorizing changes may be found in the following related requirements in this handbook: |[SWE-079]| Develop CM Plan | |[SWE-080]| Track & Evaluate Changes | |[SWE-103]| Software Configuration Management Plan | |[SWE-113]| Software Change Request / Problem Report | {div3} {div3:id=tabs-4} h1. 4. Small Projects For projects with a small staff size, the change authority or CCB for baselines and modifications to configuration items may be a single person with the proper vision and oversight such as the software manager, systems manager, product development lead, etc. Small projects with limited budget or limited access to complex or expensive change request tools may choose to use a simpler spreadsheet tools such as the [Change Request Log Template|http://software.gsfc.nasa.gov/AssetsApproved/PA2.2.2.4.xls] or the [Problem Report Tool|http://software.gsfc.nasa.gov/toolsDetail.cfm?selTool=2.5.2.3] developed at Goddard Space Flight Center (GSFC) to manage change requests, authorizations, and obtain associated metrics. {div3} {div3:id=tabs-5} h1. 5. Resources # STEP Level 2 Software Configuration Management and Data Management course, SMA-SA-WBT-204, SATERN. A user account is needed to access [SATERN|https://saterninfo.nasa.gov/] courses. # Westfall, Linda, [The Westfall Team|http://www.westfallteam.com/], ["Risk-Based Configuration Control - Balancing Flexibility with Stability"|http://www.compaid.com/caiinternet/ezine/westfall-configurationcontrol.pdf], 2007. # NASA Technical Standard, ["NASA Software Safety Guidebook"|https://standards.nasa.gov/documents/detail/3315126], NASA-GB-8719.13, 2004. # 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 (need user account to access IEEE standards via this [NASA Technical Standards System|http://standards.nasa.gov/] link). # NASA Technical Standard, ["NASA Configuration Management (CM) Standard"|https://standards.nasa.gov/documents/detail/3315133], NASA-STD-0005, 2008. # Flight and Ground Software Division, MSFC, ["Software Development Process Description Document"|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499471%2FSDPDD_Rev%2BQ_080207.pdf], EI32-OI-001, Revision R, 2010. # [Software Review Board (SRB) Checklist|http://spi.msfc.nasa.gov/Process_Asset_Library-PAL/Software_Process_and_Reference_Materials/Checklists/SRB_Checklist.pdf], Marshall Space Flight Center (MSFC). # [Post-Software Review Board (SRB) Checklist|http://spi.msfc.nasa.gov/Process_Asset_Library-PAL/Software_Process_and_Reference_Materials/Checklists/Post-SRB_Checklist.pdf], MSFC, 2010. # Flight and Ground Software Division, MSFC, ["SRB Baseline and Change Process"|http://spi.msfc.nasa.gov/Process_Asset_Library-PAL/Software_Process_and_Reference_Materials/Work_Instructions/SRB_Baseline_and_Change_Process_ORG-WI-015.pdf], ORG-WI-015, 2009. # Boeing, ["Software Change Control"|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499394%2FBoeing_317.doc], Houston Procedure, HOU-EGP-317, 2002. # Boeing, ["Software Configuration Management"|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499397%2FBoeing_322.doc], Houston Procedure, HOU-EGP-322, 2002. # NASA JSC, [Shuttle Software Change Request Process|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499378%2F89051.pdf], 89051, 2001. {toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned The NASA Lessons Learned database contains the following lesson learned related to configuration change control. The lesson discusses hardware configuration control in the details, but the ultimate lesson learned could also apply to software: * Account for all levels of authorized changes: "Configuration control processes must account for all levels of authorized changes and provide feedback to affected program elements including training and operations." (http://www.nasa.gov/offices/oce/llis/1213.html) {div3} {tabclose}

Classes

Classes G and H 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
f1
gp
hp
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc0
dnsc0
dsc1
ensc0
 



Div
idtabs-2

2. Rationale

Configuration control helps ensure that changes are managed in a structured way, that the impact of changes is assessed before those changes are implemented, and that changes are authorized before being implemented. Using various levels of control can reduce the time and effort it takes to disposition a change request based on the criticality and range of the affect of the change. Less critical or risky changes can use a lower level of authority to make decisions about those changes while more critical or far-reaching changes can require authorization from a more formal body with a broader view of the system.

Panel

Configuration control procedures are important because they help ensure that arbitrary changes are avoided and that the team understands how changes are to be managed for the project.



Div
idtabs-3

3. Guidance

The configuration management (CM) plan documents the configuration control and change authorization procedures (see SWE-079 and SWE-103). When developing these procedures, all of the following topics are included: levels of control, change authority, authorization requests, change request process, and version maintenance. The STEP Level 2 Software Configuration Management and Data Management course

sweref
343
343
 taught by the Westfall Team includes recommendations and suggestions for change control, some of which is summarized in this guidance.

Levels of control

Each identified configuration item (CI) has a defined level of control for making changes to that item. Documentation might have one level of change control, while source code might require a different level of control. For each identified CI or group/class of items, the change control procedures identify the appropriate level of control. Consider the following when defining levels of configuration control:

  • Each CI or class of items has a defined "owner" who is responsible for authorizing changes to that item, e.g., the software Configuration Control Board (CCB) might be the designated owner for all software libraries while the documentation peer review team might be the owner for product marketing materials.
  • Depending on the effect of the change, multiple levels of control may need to be defined, e.g., a change to software that is shared among projects may require change approval from multiple change authorities.
  • Levels of control may "vary throughout the life cycle. For example, changes to code in the development cycle usually require a lower level of control to be authorized than changes to the same code after it has been released for general use."
    sweref
    212
    212
  • Levels of control may be affected by the change originator, e.g., a change request from outside the organization, such as customers or end users, may require different authority for approval than changes requested by software developers

Change authority

Change control procedures include defining the persons or groups with authority to authorize changes and to make changes at each level. Examples of change authority include CCBs, Change Authorization Board (CAB), Engineering Change Boards (ECBs), peer review teams, project manager, etc. The change approval authority may be determined by the complexity, cost, risk, or effect of the change. When defining the change authority, consider the following:

  • Include software assurance/safety personnel to ensure safety impact is considered.
  • Involve stakeholders based on the expertise and authority required to disposition the change.
    • People with authority in the appropriate fields.
    • Experts in a particular field.
    • Policy makers.
    • Systems engineers.
    • Software engineers.
    • Hardware engineers.
  • Use different levels of change authority, as appropriate, for cost and time savings.
    • Product level CCB for changes to functional baseline, product baseline, system-level changes or changes that will affect the fielded product.
    • Project level CCB for changes to allocated baselines, changes that only affect the project, not the system.
    • Software development CCB for changes to development baselines, changes that only affect the software, not hardware or documentation.
  • If different levels of authority are used,
    • Group size can be less at the lower levels.
    • Typically one representative from the lower level sits on the next level CAB.
    • Escalation can occur if a lower level change authority cannot agree on disposition of a change.
    • An escalation plan is typically defined as part of the change control procedures.
    • Coordination plans may be required if multiple change authorities are required to disposition a change.
    • Typically costs more in time and effort to convene higher level change authority boards, so they tend to meet less frequently.
  • Document the responsibilities of each level of authority, including, as applicable:
    • Area of change authority, such as software changes, system-level changes, documentation changes, etc.
    • Review and disposition of change requests.
    • Authorizing release and delivery of baselined software products.
    • Documenting and retaining evidence of the group's authorization activities.
    • Informing the appropriate stakeholders of the results of those authorization activities.

Authorization requests

Change control procedures include steps to be followed to request authorization for changes. Consider the following when documenting the steps to request authorization for making a change:

  • Include instructions for choosing the proper change request to submit (Engineering Change Proposal (ECP), change request (CR), problem report (PR), etc. as appropriate and applicable for the project).
  • Include instructions for properly completing the change request, typically a form in an automated change control system (see SWE-113 for change request contents), such that the change authority can make an informed disposition decision.
  • Include instructions for supplying information not captured in the change request, but necessary for the change authority to disposition the request.
  • Include instructions for determining the proper change authority.
  • Include instructions for submitting a request to the proper change authority.
  • Include information regarding when the change originator expects to receive the disposition decision from the change authority.

Change request process

The change request process consists of three steps described in the change control procedures: Change request processing, tracking changes, and distributing changes.

When developing procedures for processing change requests, consider:

  • Using a screener to ensure the change requests are properly completed and have been checked for technical correctness before higher-level CABs spend time on incomplete or out-of-scope requests (see SWE-113 for change request contents).
  • Giving the change authority board the ability to perform impact analysis (see SWE-080) themselves or to call on another group with greater specific expertise to do the analysis.
  • Describing the disposition options (once the analysis is complete, the change authority dispositions the change request, typically, in one of three ways: Approve for implementation, defer the change until some later point in time, or reject the change request).
  • Requiring the basis for the disposition to be documented and the disposition disseminated to the appropriate stakeholders

A sample process flow might look like this chart adapted from the STEP Level 2 Software Configuration Management and Data Management course:

sweref
343
343

Image Added

When developing procedures for tracking changes, consider:

  • Collecting status as the change request is processed (open, fixed, resolved, closed, etc.) along with the status change dates.
  • Capturing the impact analysis for each change.
  • Collecting disposition status (approved, deferred, rejected) and date.
  • Capturing the solution implemented for each change.
  • Capturing the verification activity and results for each implemented change.
  • Capturing all CIs affected by the change (requirements, design, tests, source code, documentation, etc.).
  • Using the features of CM tools to track changes and related metrics and data.
  • Tracking changes to all identified CIs (see SWE-081).
  • Reporting status of changes to project management on a regular basis; reporting frequency may be established based on the life cycle phase of the project with documentation in the CM plan.
  • Guidance provided in SWE-080 in this Handbook for tracking and evaluating changes.

When developing procedures for distributing changes, consider:

  • Releasing changes only after verification and approval of their implementation.
  • Releasing changes in a controlled manner, typically as part of a baseline (during development), patch or update (for changes to fielded software), or new fielded release.
  • Using a software version description (SVD) or version description document (VDD) to identify the changes included in a software release.

Version maintenance

When developing procedures for maintaining past versions of the software, consider:

  • The ease of retrieving past versions to address issues found in fielded software.
  • Tracking all released software that uses a particular version of a CI so that changes can be made to all affected software, not just the version for which the change was requested.
  • Using features of CM tools, such as "tagging," to identify all items and their versions in a baseline or release.
Note

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to configuration control and authorizing changes.

Additional guidance related to authorizing changes may be found in the following related requirements in this Handbook:

SWE-079

Develop CM Plan

SWE-080

Track and Evaluate Changes

SWE-103

Software Configuration Management Plan

SWE-113

Software Change Request / Problem Report



Div
idtabs-4

4. Small Projects

For projects with a small staff size, the change authority or Configuration Control Board (CCB) for baselines and modifications to CIs may be a single person with the proper vision and oversight, such as the software manager, systems manager, product development lead, etc.

Small projects with limited budget or limited access to complex or expensive change request tools may choose to use a simpler spreadsheet tools such as the Change Request Log Template

sweref
011
011
 or the Problem Report Tool developed at Goddard Space Flight Center (GSFC) (see the Tools Table under the
Tablink
1Resources section
tab5
linktextResources section
 of this SWE) to manage change requests, authorizations, and obtain associated metrics.


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 related to configuration change control. The lesson discusses hardware configuration control in the details, but the ultimate lesson learned could also apply to software:

  • Configuration Control at All Levels of Change. Lesson Number 1213: Account for all levels of authorized changes: "Configuration control processes must account for all levels of authorized changes and provide feedback to affected program elements including training and operations."
    sweref
    546
    546