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.4 The project manager shall identify the software configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project.
1.1 Notes
The items to be controlled include tools, items or settings, used to develop the software, which could impact the software. Examples of such items include compiler/assembler versions, makefiles, batch files, and specific environment settings.
1.2 History
1.3 Applicability Across Classes
Class A B C D E F Applicable?
Key: - Applicable | - Not Applicable
2. Rationale
For Software Configuration Management to be implemented on a project, the project has to identify what software configuration items are to be controlled for the project. Software Configuration Management encompasses the practices and procedures for administering source code, producing software development builds, controlling change, and managing software configurations for all of the software products, tools, data, and components produced by the project.
3. Guidance
Per the Department of Defense Configuration Management Guidance Handbook 351, MIL-HDBK-61, "Effective configuration identification is a pre-requisite for the other configuration management activities (configuration control, status accounting, audit), which all use the products of configuration identification. If CIs and their associated configuration documentation are not properly identified, it is impossible to control the changes to the items' configuration, establish accurate records and reports, or validate the configuration through the audit. Inaccurate or incomplete configuration documentation may result in defective products, schedule delays, and higher maintenance costs after delivery."
One of the main functions of configuration management (CM) is version control, which facilitates the identification of all releases.
Version control manages the changes to the items under configuration control and allows access to previous versions of those items if a problem is found.
Configuration identification can be thought of as consisting of four elements.
- Identifying the items to be controlled.
- Providing unique identifiers for each item.
- Capturing the key characteristics of each item.
- Defining the acquisition point for each item (the point in the project where the item first enters configuration control).
The process elements are documented in the CM plan (see SWE-079 and 5.06 - SCMP - Software Configuration Management Plan).
The project is responsible for assuring that software safety elements are properly identified and controlled.
When considering items to be controlled, include the following:
- Source code.
- Data that is part of the delivered product.
- Internal software work products and data, such as requirements, interface documents, test data, build scripts, test documents, test scripts, etc.
- Support tools, such as compilers, linkers, build tools, operating systems, documentation tools, test tools, CM tools, templates, modeling tools, simulators, etc.
- Support tool documentation, such as certifications, licenses, customizations, upgrades, etc.
- Vendor-supplied software.
- Customer-supplied software ( e.g., Commercial Off the Shelf (COTS) / Government Off the Shelf (GOTS) / Modified Off the Shelf (MOTS)).
- Marketing materials, such as release notes.
- Databases.
- Training materials.
- Executables.
- Documents, such as Software Assurance Plans, Verification, and Validation (V&V) plans, CM plans, Data Management plans, Software Development/Management Plans (SDP/SMP), standards, etc.
- Baselines and the identification of all items included in each baseline (see key characteristics discussion below).
- All software safety elements., such as hazard analyses and reports, safety analyses, etc.
- Software Classification determination, Safety Criticality Determination
- Other software assurance products such as analyses, reports
- Software Requirements Mapping Matrix with approved tailoring, SA Tasking table with approved tailoring, Tailored Project and SA Processes and procedures
When determining the items to be controlled, a second consideration is the granularity of the items, i.e., is it appropriate to simply control the entire document or should each chapter be controlled separately? However, tradeoffs may need to occur since controlling each page of a document likely doesn't provide a lot of benefit versus the overhead required to manage the pages as separate items. Granularity considerations include:
- Frequency of change for the item (i.e., the work breakdown structure (WBS) will likely change more frequently than the SDP/SMP which contains it and so is appropriate to control as a separate item).
- Software architecture structure.
- Plans for reuse (reused items need to be their item, not part of a larger item).
- Requirements allocation and traceability needs.
- Functionality.
- Item size.
- Host or target computer.
- Criticality.
- Interface considerations.
- The specific need for separate documentation and control.
- Author assignments.
- Supplier.
- Need for change visibility.
When identifying items to be controlled, also consider this activity as part of data management activities. A basic description of data management is provided in SWE-079.
When establishing the process for generating identifiers, keep in mind that some tools include versioning features and just adding the item to the tool will generate an identifier. However, not all configuration items (CIs) may be entered into the tool, e.g. physical items, such as hardware or software CDs or DVDs. Also, if a project already has a system for identifying CIs, the software can simply be added to that system and the existing identification scheme used. When creating a new identification scheme, consider the following:
- Unique identifiers for each version of each item.
- Matching the identifier to the level where the item is controlled.
- Use data such as the following:
- Revision, version, release number.
- Document name or identifier.
- Module, data-name, or identifier.
- Baseline identifier.
When capturing key characteristics for each item (including related elements used to describe, define, create, etc. the item), consider the following as appropriate for a particular project:
- Allocated requirements.
- Associated design.
- Associated test cases.
- Associated user documents.
- For baselines, the items and their unique versions that make up the baseline as well as any procedures used to create it.
- Performance, functional, interface, and physical attributes, typically for a subsystem or system.
- Information required to assemble the next higher level of the software, e.g., all the modules in a subsystem, subsystems in a system, components in a computer software configuration item (CSCI), chapters in a document, etc.
- Owner of a CI, i.e., who has the authority to approve changes to the item, such as a change control board (CCB).
When defining the acquisition point for each item or class of items, it is important to also define acceptance criteria for the item or class of items. Acceptance criteria may be based on risk or other project factors and include "all issues fixed," "all action items closed," or "signoff." The CI is acquired for control at the acquisition point and if the acceptance criteria are met, e.g., acquire the requirements document after the Software Requirements Review (SwRR) and the document have been signed off.
When defining CI acquisition points, consider the following choices for setting the acquisition point for software:
- Before peer review (might allow all changes after a clean compile to be tracked as formal changes).
- After peer review and approval (could allow all changes made during the unit test to be tracked as formal changes).
- After passing the unit test (could allow all changes made during integration and system test to be tracked as formal changes).
- When the product is shipped to the field (allows issues found in the field to be tracked formally - this point is likely too late in the life cycle for large projects).
Other acquisition points to consider include:
- For software, after completion of a defined set of components.
- For software, after a baseline is reached.
- For documents after formal review or signoff may be early enough so the captured document is stable, but late enough to provide flexibility to the author.
- For test cases, after peer review vs. Test Readiness Review (TRR).
- For plans, after peer review vs. after formal signoff.
- For design, after a formal review.
NASA-specific configuration management information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
Additional guidance related to identifying software CM items may be found in the following related requirements in this Handbook:
4. Small Projects
No additional guidance is available for small projects.
5. Resources
5.1 References
- (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.nasa.gov/download/attachments/16450020/nasa-gb-871913.pdf?api=v2
- (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-351) U.S. Department of Defense (1997). Editor Note: Revision A is the reference. This URL is the download page for this document. The download is free.
- (SWEREF-506) Public Lessons Learned Entry: 391.
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:
- Galileo Spacecraft Safing Recovery Anomalies. Lesson Number 0391 506: Issues caused by not keeping software/documentation current: "The Galileo mission twice experienced difficulties with recovery from safing errors due to a lack of a formal safing recovery plan and to software/documentation that had not been kept current on spacecraft states. Maintain and update an anomaly recovery plan, log spacecraft event updates, take care in reusing previously successful command packages, and identify nonstandard ground system configurations."
6.2 Other Lessons Learned
No other Lessons Learned have currently been identified for this requirement.
7. Software Assurance
7.1 Tasking for Software Assurance
- Confirm that the project has identified the configuration items and their versions to be controlled.
- Assess that the software safety-critical items are configuration managed, including hazard reports and safety analysis.
7.2 Software Assurance Products
- Software Design Analysis
- Assessment of Hazard Analyses and Reports
- Source Code Analysis
- Verification Activities Analysis
SA assessment of CM for safety-critical items, including risks and issues.
- Hazard Analyses (under CM -See Task 2).
Objective Evidence
- Software configuration management plan
- Software configuration management system data
7.3 Metrics
- # of safety-related non-conformances identified by life-cycle phase over time.
7.4 Guidance
For the assurance on this requirement, the software assurance personnel need to confirm that the project has identified those items that need to be configuration controlled and has reviewed the list for completeness. The software guidance for this requirement (SWE-081) provides a list of the types of items that are typically kept under configuration management that can be used for reference.
Another important task for this requirement is to assess the list of safety-critical components, and the associated hazard reports, and any safety analysis and check that these safety items are included on the list of configuration items.