bannerd


SWE-081 - Identify Software CM Items

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

SWE-081 - Last used in rev NPR 7150.2D

RevSWE Statement
A

4.1.3 The project shall identify the software configuration items (e.g., software documents, code, data, tools, models, scripts) and their versions to be controlled for the project.

Difference between A and B

No change

B

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.

Difference between B and C

No change

C

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.

Difference between C and DNo change
D

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

3.1 Version Control

MIL-HDBK-61 Department of Defense Configuration Management Guidance Handbook

3.1 Configuration Identification Activity
"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."
351

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.

3.2 Configuration Identification

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 - Develop CM Plan and 5.06 - SCMP - Software Configuration Management Plan).

The project is responsible for assuring that software safety elements are properly identified and controlled.

3.3 Items To Be Controlled

When considering items to be controlled (SWE-081 - Identify Software CM Items), 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. (7.18 - Documentation Guidance)
  • 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

See also Topic 7.15 - Relationship Between NPR 7150.2 and NASA-STD-7009. SWE-187 - Control of Software Items,

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.

The models associated with auto-generated code should definitely be configuration managed, see Topic 8.11 - Auto-Generated Code

3.4 Control of Data / Data Management 

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 - Develop CM Plan.

3.5 Generating Identifiers

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.

See also SWE-085 - Release Management

3.6 Capturing Key Characteristics For Items

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).

See also SWE-082 - Authorizing Changes

3.7 Defining Acceptance Criteria

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.
The following diagram from the superseded 2005 version of the IEEE Standard for Software Configuration Management Plans (IEEE STD 828-2005), shows a sample process overview for identifying CIs:


3.8 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.9 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). 

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References


5.2 Tools


Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

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

SWE-081 - Identify Software CM Items
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.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm that the project has identified the configuration items and their versions to be controlled.

2. 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

    Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

    • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
    • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
    • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
    • Signatures on SA reviewed or witnessed products or activities, or
    • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
      • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
      • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
    • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

  • # of safety-related non-conformances identified by life cycle phase over time.

See also Topic 8.18 - SA Suggested Metrics.

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 - Identify Software CM Items) 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.

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

  • No labels