This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
View this section on the website
See edit history of this section
Post feedback on this section
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
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:
4. Small Projects
No additional guidance is available for small projects.
5. Resources
Renew your license to continue
Your evaluation license has expired. Contact your administrator to renew your Reporting for Confluence license.
5.1 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
No lessons learned have been identified for this requirement.
