See edit history of this section
Post feedback on this section
- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
1. Requirements
5.1.5 The project manager shall establish and implement procedures to:
a. Designate the levels of control through which each identified software configuration item is required to pass.
b. Identify the persons or groups with authority to authorize changes.
c. Identify the persons or groups to make changes at each level.
1.1 Notes
IEEE 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering describes configuration management processes to be established, how they are to be accomplished, who is responsible for doing specific activities, when they are to happen, and what specific resources are required. It addresses configuration management activities over a product's life cycle. Configuration management in systems and software engineering is a specialty discipline within the larger discipline of configuration management. Configuration management is essential to systems engineering and software engineering.
1.2 History
1.3 Applicability Across Classes
Class A B C D E F Applicable?
Key: - Applicable | - Not Applicable
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 effect 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.
3. Guidance
3.1 Control Procedures
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.
The software configuration management (SCM) plan documents the configuration control and change authorization procedures (see SWE-079 - Develop CM Plan and 5.06 - SCMP - Software Configuration Management Plan). 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 Software Configuration Management and Data Management course 343 taught by the Westfall Team, and now on video in SATERN, includes recommendations and suggestions for change control, some of which are summarized in this guidance.
3.2 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 Change 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 the software that is shared among projects may require change approval from multiple change authorities.
- Levels of control may vary throughout the life cycle, e.g., changes to code in development may require a lower level of control than changes to the same code after it has been released.
- 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.
3.3 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 managers, 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.
- Policymakers.
- 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 the 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.
3.4 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 (e.g., 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 5.01 - CR-PR - Software Change Request - Problem Report for recommended 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.
3.5 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 5.01 - CR-PR - Software Change Request - Problem Report for change request contents).
- Giving the change authority board the ability to perform impact analysis (see SWE-080 - Track and Evaluate Changes) 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).
- Requires 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: 343
When developing procedures for tracking changes, consider:
- Collecting status as the change request is processed (e.g., open, fixed, resolved, closed, etc.) along with the status change dates.
- Capturing the impact analysis for each change.
- Collecting disposition status (e.g., approved, deferred, rejected) and date.
- Capturing the solution implemented for each change.
- Capturing the verification activity and results for each implemented change.
- Identifying and updating all CIs affected by the change (e.g., 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 - Identify Software CM Items).
- Reporting status of changes to project management regularly; reporting frequency may be established based on the life cycle phase of the project with documentation in the CM plan.
- The guidance provided in SWE-080 - Track and Evaluate Changes 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 document (5.16 - VDD - Version Description Document) to identify the changes included in a software release.
See also SWE-024 - Plan Tracking,
3.6 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.
When establishing change authority, consider coordinating or applying the same concepts as part of data management activities. A basic description of data management is provided in SWE-079 - Develop CM Plan.
3.7 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
3.8 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
SPAN Links |
---|
4. Small Projects
For projects with a small staff size, the change authority or Change 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 a limited budget or limited access to complex or expensive change request tools may choose to use a simpler spreadsheet tool such as the Problem Report Tool to manage change requests and authorizations, and obtain associated metrics.
5. Resources
5.1 References
- (SWEREF-011) Change Request Log Template, NASA Goddard Space Flight Center, 2015. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-212) IEEE Computer Society, IEEE STD 1042-1987, 1987. This link requires an account on the NASA START (AGCY NTSS) system (https://standards.nasa.gov ). Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards.
- (SWEREF-216) IEEE STD IEEE 828-2012, 2012., NASA users can access IEEE standards via the NASA Technical Standards System located at https://standards.nasa.gov/. Once logged in, search to get to authorized copies of IEEE standards.
- (SWEREF-276) NASA-GB-8719.13, NASA, 2004. Access NASA-GB-8719.13 directly: https://swehb-pri.msfc.nasa.gov/download/attachments/16450020/nasa-gb-871913.pdf?api=v2
- (SWEREF-337) Souppaya, Murugiah, Scarfone, Karen, NIST Special Publication NIST SP 800-40r4, April, 2022
- (SWEREF-343) This NASA-specific information and resource is available in at the System for Administration, Training, and Educational Resources for NASA (SATERN), accessible to NASA-users at https://saterninfo.nasa.gov/.
- (SWEREF-357) Westfall, Linda, The Westfall Team (2007), Contains video slide presentation and copy companion paper.
- (SWEREF-546) Public Lessons Learned Entry: 1213.
5.2 Tools
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
6.1 NASA 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 detail, but the ultimate lesson learned could also apply to software:
- Configuration Control at All Levels of Change. Lesson Number 1213 546: 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."
6.2 Other Lessons Learned
No other Lessons Learned have currently been identified for this requirement.
7. Software Assurance
a. Designate the levels of control through which each identified software configuration item is required to pass.
b. Identify the persons or groups with authority to authorize changes.
c. Identify the persons or groups to make changes at each level.
7.1 Tasking for Software Assurance
1. Confirm that software assurance has participation in software control activities.
7.2 Software Assurance Products
Software Configuration Management Procedure Audit Report
- CM audit results and findings, including risks and issues.
Objective Evidence
- Software configuration management plan
- Software configuration management system data
- Software assurance audit results of the change management processes.
7.3 Metrics
- # of findings open versus # of findings identified.
- # of software process Non-Conformances by life cycle phase over time.
- # of process Non-Conformances (e.g., activities not performed) identified by SA vs. # accepted by the project.
- Trends of # Open vs. # Closed over time.
- # of Non-Conformances per audit (including findings from the process and compliance audits, and process maturity).
- # of Configuration Management Audits conducted by the project – Planned vs. Actual.
- Trends of # of Non-Conformances from audits over time (Include counts from process and standards audits and work product audits.).
- # of Compliance Audits planned vs. # of Compliance Audits performed.
- # of Open vs. Closed Audit Non-Conformances over time
See also Topic 8.18 - SA Suggested Metrics.
7.4 Guidance
To assess the compliance with NPR 7150.2 and Center requirements on configuration management procedures, gather any Center configuration management procedures that apply to the project as well as the configuration management processes and procedures listed in NPR 7150.2. The requirements in NPR 7150.2 also include configuration management activities that must be followed and need to be considered in the Project configuration management processes and procedures may be found below in section 7.5 Additional Guidance.
The project procedures for configuration management, including data management, should be documented in either the project or 5.08 - SDP-SMP - Software Development - Management Plan, or a stand-alone Configuration Management Plan (5.06 - SCMP - Software Configuration Management Plan). Data Management Plans can be documented either in a separate plan or in the Software Configuration Management Plan. Compare the descriptions of the documented project configuration management procedures with the Center procedures and the requirements listed in the NPR requirements above. Record any issues or discrepancies as non-conformances, report those to the project management, and track them to closure.
Review the project CM documentation that discusses the establishment of CCBs, identification of authorized personnel, and identification of CCB membership. Confirm that the documentation describes the levels of control through which a configuration item must pass for approval. (Small projects may only have one level.). The documentation should also describe the membership of the different level control boards and indicate who has the approval authority in each. In addition, the person or people who are allowed to make changes at each level should be documented. Confirm that a software assurance person is a voting member of each control board. (See the software Requirements Mapping Matrix for applicability.) Additional information can be found on this requirement can be found in the Guidance section for this software requirement (SWE-082 - Authorizing Changes). See also SWE-053 - Manage Requirements Changes,
Every task that involves performing an audit should also clarify that all audit findings are promptly shared with the project and will be addressed in the handbook guidance.
7.5 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook: