1. Requirements

3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the NASA Internal Sharing and Reuse Software systems. However, if the project manager is a contractor, then a civil servant must pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:

1. 1. Software Title.
   2. Software Description.
   3. The Civil Servant Software Technical Point of Contact for the software product.
   4. The language or languages used to develop the software.
   5. Any third party code contained therein and the record of the requisite license or permission received from the third party permitting the Government’s use, if applicable.

1.1 Notes

The NASA Internal Sharing and Reuse Software Inventory will be accessed through Launchpad, and the software list will be available to NASA civil servants and contractors; however, only NASA civil servants will be the recipient of software via the systems in the Inventory. The Inventory will provide the NASA civil servant a simple Acknowledgment of Receipt of the software that identifies any restrictions on NASA's right to use the software, including limiting its use to governmental purposes only. This Acknowledgment will be done via click-wrap acceptance. The Civil Servant Software Technical Point of Contact for the software product must keep a list of all contributors to the software. Any software shared via the NASA Internal Sharing and Reuse Software Inventory will contain appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided "as is" without any warranty, express, or implied and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors (see paragraph 2.1.5.17).

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Reusing software can have many benefits for the Agency, including, but not limited to, cost savings.  For this reason, software project managers consider future reuse of software components created for their projects and make those selected components available to future projects through an Agency repository.

3. Guidance

When evaluating software for potential reuse, remember to consider single components as well as entire software products.

When evaluating software for future reuse, consider the concept of “reuse readiness levels” which can be used to determine “the extent to which software components of interest meet the conditions for reuse. “ ⁴⁸⁰

The table below was generated from A Proposal on Using Reuse Readiness Levels to Measure Software Reusability by Robert Downs and James Marshall.  It provides a set of reuse readiness levels with associated descriptions that provide some guidance on the aspects of the software that need to be considered when evaluating software for its potential for reuse. ⁴⁸⁰

 In addition to assessing software at these readiness levels, “Software development characteristics, identified as both critical and challenging for software reuse,” ⁴⁷⁹ should be considered as part of the software reuse evaluation:

• Documentation.
• Extensibility.
• Intellectual Property Issues.
• Modularity.
• Packaging.
• Portability.
• Standards compliance.
• Support.
• Verification and Testing. ⁴⁷⁹

Some additional considerations when assessing software for its potential reuse include:

• Potential for use in future applications (cost-benefit of software reuse).
  • Costly to develop (therefore, the potential for future cost savings is high).
  • Well-tested and high quality (saving time and effort in the future).
  • Multiple projects or industry applicability (potential for greater reuse opportunities).
  • Ease of future integration
    • Self-contained.
    • Clear boundaries and interfaces.
    • Clear design documentation.
    • Clear usability documentation.
  • Ease of future verification and validation.

Once the evaluation criteria have been chosen and approved by the project, evaluation of project software is done by the project team. 

It is important to select software for future reuse early in the software life cycle so that reusability requirements (see SWE-147) can be included as part of the development process for those components to ensure they are created with reusability in mind.

See the guidance in SWE-214 for:

1. The acknowledgment of receipt of software is for the NASA civil servant to a NASA civil servant transfer and a NASA civil servant to a NASA contractor transfer.
2. The Software Internal Sharing Questionnaire

At the end of the project, the software selected for future reuse is provided to the designated repository and/or  NASA Internal Sharing and Reuse Software systems through the Center’s Technology Transfer Office.

Additional guidance related to reusability 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 any project software contributed as a reuse candidate has the identified information in items “a” through “e.”

7.2 Software Assurance Products

• None at this time.

7.3 Metrics

•  # of products submitted for reuse.
•  # of developed products submitted for reuse vs. total # of developed products.
•   #  of developed products entered in NASA Internal Sharing & Reuse System vs. total # of developed products.
•  # of products submitted for reuse vs. # of products entered into NASA Internal Sharing & Reuse System.

7.4 Guidance

See the SWE-147 software assurance guidance information.