bannerc
SWE-148 - Contribute to Agency Software Catalog

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

Click here to view the history of this requirement: SWE-148 History

1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = 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 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 cost and risk.

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 are applicable 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 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. 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.

 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. 

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 for 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


Unable to render {include} The included page could not be found.
 

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-148 - Contribute to Agency Software Catalog
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. 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.

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.


Objective Evidence

Record showing that appropriate software has been entered into the NASA Internal Sharing and Reuse Software systems.

 Definition of objective evidence

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


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.



  • No labels