See edit history of this section
Post feedback on this section
- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
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 appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:
a. Software Title.
b. Software Description.
c. The Civil Servant Software Technical POC for the software product.
d. The language or languages used to develop the software.
e. 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 and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
f. Release notes.
1.1 Notes
Currently, there are more than one Agency-wide software inventories and repositories, several options can be found in NASA-HDBK-2203. In order to obtain and reuse the internal software reuse candidates from these repositories, NASA civil servants may request a copy by requesting and completing a simple Acknowledgment of Receipt of the software form that identifies any restrictions on NASA’s right to use the software, including limiting its use to governmental purposes only. The Civil Servant Software Technical POC for the software product will keep a list of all contributors to the software. Any software shared 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
Class A B C D E F 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
3.1 Evaluating Software For Reuse
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 a substantial effort, cost, and risk. | The 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. The 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 maybe 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 costs and risks. | The 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 apply to 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. | The software is extensible and has been qualified through tests and demonstrations. 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. The software has been tested and validated through the successful use of application output. Multiple statements describing unrestricted rights for reuse and the recommended citation are embedded into the product. |
3.2 Reuse Requirements
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, 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.
3.3 Selecting Software For Reuse
It is important to select software for future reuse early in the software life cycle so that reusability requirements (see SWE-147 - Specify Reusability Requirements) 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 - Internal Software Sharing and Reuse for:
- 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.
- 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.
3.4 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
Related Links |
---|
3.5 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).
SPAN Links |
---|
4. Small Projects
No additional guidance is available for small projects.
5. Resources
5.1 References
- (SWEREF-373) NPR 2210.1C, Space Technology Mission Directorate, Effective Date: August 11, 2010, Expiration Date: January 11, 2022
- (SWEREF-479) Marshall, James. And Downs, Robert, IEEE, 2008. Retrieved from http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4779626 on August 19, 2015.
- (SWEREF-480) Downs, Robert and Marshall, James. Data Science Journal, Volume 9, July 24, 2010.
5.2 Tools
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
a. Software Title.
b. Software Description.
c. The Civil Servant Software Technical POC for the software product.
d. The language or languages used to develop the software.
e. 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 and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
f. Release notes.
7.1 Tasking for Software Assurance
7.2 Software Assurance Products
- None at this time.
Objective Evidence
- 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.
See also Topic 8.18 - SA Suggested Metrics.
7.4 Guidance
See the SWE-147 - Specify Reusability Requirements software assurance guidance information.
7.5 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook: