bannerd


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

SWE-148 - Last used in rev NPR 7150.2D

RevSWE Statement
A


Difference between A and B

NEW

B

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.

Difference between B and CChanged "NASA" to "Agency";
Changed "Agency Software Catalog" to "NASA Internal Sharing and Reuse Software systems";
Added caveats for approval conditions if the project manager is a contractor.
C

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.

Difference between C and D

Added items e and f per the request of the OGC and OCIO

D

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

  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.

3.4 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

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

4. Small Projects

No additional guidance is available for small projects. 

5. Resources

5.1 References

5.2 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

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

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm that any project software contributed as a reuse candidate has the identified information in items “a” through “f.”

7.2 Software Assurance Products

  • None at this time.


Objective Evidence

  • None at this time.

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 a 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.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

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:

  • No labels