1. Requirements

4.5.4 The project manager shall place software items under configuration management prior to testing.

1.1 Notes

This includes the software components being tested and the software components being used to test the software, including components such as support software, models, simulations, ground support software, COTS, GOTS, MOTS, OSS, or reused software components.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Before software testing begins, all software items are placed under configuration control. This configuration control captures and identifies the versions of what is being tested. This serves several purposes: 1) Ensures that the correct version of the software is being tested. 2) Other items that are needed for the testing should also be under configuration control such as the test scripts, input data, versions of the operating system. This allows the tests to be repeatable to assist in finding defects. 

3. Guidance

3.1 Configuration Management

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." ²⁷⁶  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. See also SWE-079 - Develop CM Plan. 

Before any independent testing (informal, formal, system, or regression), the software items associated with the software build should be placed under configuration management. This helps to keep a record of what is being tested and the underlying files and components that make it up. It includes the software components being tested and the software components being used to test the software, including components like support software, models, simulations, ground support software, COTS, and MOTS. See also SWE-080 - Track and Evaluate Changes, SWE-081 - Identify Software CM Items. See also Topic 5.01 - CR-PR - Software Change Request - Problem Report, 

3.2 Additional Guidance

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

3.3 Center Process Asset Libraries

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

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

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

7.2 Software Assurance Products

• None at this time.

  
  

  Objective Evidence

  • Software configuration management data
  • Software Assurance audit results on the configuration data process
  • Software test procedure(s)
  • Software test report(s)
   Definition of objective evidence

  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 software work product Non-Conformances identified by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance

Software assurance will review the list of items to be tested as well as all of the items needed to support the tests and confirm that all of these items are put under configuration management before the start of testing. Confirm that all items remain under configuration management throughout the completion of testing.

In addition to the software that is being tested, consider the following items that are needed for testing:

• Any test scripts or software components being used to test the software
• Components like support software
• Models, simulations, simulators
• Ground support software
• COTS, GOTS, MOTS, OSS, or reused software components
• Operating systems

7.5 Additional Guidance

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