bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-148 - Contribute to Agency Software Catalog

1. Requirements

3.14.3 The project manager shall evaluate software for potential reuse by other projects across the Agency and contribute reuse candidates to the Agency Software Catalog.

1.1 Notes

The Agency Software Catalog is maintained as a part of the NASA Technology Transfer Portal. Each software code listed in the catalog is evaluated for access requirements and restrictions per the software release process (see http://technology.nasa.gov/ and NPR 2210.1) 373.

1.2 Applicability Across Classes

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

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

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

Level

Summary

Description

1

Limited reusability; the software is not recommended for reuse.

Little is provided beyond limited source code or pre-compiled, executable binaries. There is no support, contact information for developers or rights for reuse specified, the software is not extensible, and there is inadequate or no documentation.

2

Initial reusability; software reuse is not practical.

Some source code, documentation, and contact information are provided, but these are still very limited. Initial testing has been done, but reuse rights are still unclear. Reuse would be challenging and cost-prohibitive.

3

Basic reusability; the software might be reusable by skilled users at substantial effort, cost, and risk.

Software has some modularity and standards compliance, some support is provided by developers, and detailed installation instructions are available, but rights are unspecified. An expert may be able to reuse the software, but general users would not.

4

Reuse is possible; the software might be reused by most users with some effort, cost, and risk.

Software and documentation are complete and understandable. Software has been demonstrated in a lab on one or more specific platforms, infrequent patches are available, and intellectual property issues would need to be negotiated. Reuse is possible, but may be difficult.

5

Reuse is practical; the software could be reused by most users with reasonable cost and risk.

Software is moderately portable, modular, extendable, and configurable, has low-fidelity standards compliance and a user manual, and has been tested in a lab. A user community exists but may be a small community of experts. Developers may be contacted to request limited rights for reuse.

6

Software is reusable; the software can be reused by most users although there may be some cost and risk.

Software has been designed for extensibility, modularity, and portability, but software and documentation may still have limited applicability.  Tutorials are available, and the software has been demonstrated in a relevant context. Developers may be contacted to obtain formal statements on restricted rights or to negotiate additional rights.

7

Software is highly reusable; the software can be reused by most users with minimum cost and risk.

Software is highly portable and modular, has high-fidelity standards compliance, provides auto-build installation, and has been tested in a relevant context. Support is developer-organized, and an interface guide is available. Software and documentation are applicable for most systems. Brief statements are available describing limited rights for reuse and developers may be contacted to negotiate additional rights.

8

Demonstrated local reusability; the software has been reused by multiple users.

Software has been shown to be extensible and has been qualified through test and demonstration. An extension guide and organization-provided support are available. Brief statements are available describing unrestricted rights for reuse, and developers may be contacted to obtain formal rights statements.

9

Demonstrated extensive reusability; the software is being reused by many classes of users over a wide range of systems.

Software is fully portable and modular, with all appropriate documentation and standards compliance, encapsulated packaging, a GUI installer, and a large support community that provides patches. Software has been tested and validated through successful use of application output. Multiple statements describing unrestricted rights for reuse and the recommended citation are embedded into the product.

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

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

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

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

Additional guidance related to reusability may be found in the following related requirements in this Handbook:

SWE-027

Use of Commercial, Government, and Legacy Software

SWE-033

Acquisition vs. Development Assessment

SWE-147

Specify Reusability Requirements

4. Small Projects

No additional guidance is available for small projects. 


5. Resources


5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

 

6. Lessons Learned

No lessons learned have been identified for this requirement.


  • No labels