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

3. Guidance

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.

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.

Additional guidance related to CM and topics that have to be addressed in the SCM plan 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

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

1. Confirm that software items to be tested are under configuration management before the start of testing.

2. Confirm the project maintains the software items under configuration management through the completion of testing.

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

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

Note: configuration management needs to be maintained even if changes in the software need to be made to complete the test(s).