bannerd


SWE-187 - Control of Software Items

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

SWE-187 - Last used in rev NPR 7150.2D

RevSWE Statement
A


Difference between A and B

N/A

B


Difference between B and C

NEW

C

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

Difference between C and DNo change
D

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



1.3 Applicability Across Classes

 

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

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

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

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

  • (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-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


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

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

SWE-187 - Control of Software Items
4.5.4 The project manager shall place software items under configuration management prior to testing.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

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)

    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


Configuration Management needs to be maintained even if changes in the software need to be made to complete the test(s).

7.5 Additional Guidance

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


  • No labels