National Aeronautics and Space Administration

Glenn Research Center

Public Metadata

This form must be completed in one session unless you use the Save/Restore buttons below. If you have any questions about this form, please send email to strs-repository-manager@lists.nasa.gov.

The following metadata is to be stored in the STRS Application Repository.
Except for the submitter's email address, it will be publicly available.

Go to (Beginning, Submittal)

  1. Name of Item Submitted
    Enter the unique
    This name should be used in all other forms, paperwork, and email for identification.
    NASA only: This name should be the same as the name used in the New Technology Report (NTR).
    Non-NASA: Use the name from your release process.

    Enter the if known:

    Enter the if known:
  2. Type of Item Submitted
    Enter the
    (Click on one of the example buttons provided to avoid typing: , , , , , )
    If none of the above, please enter a one-word or two-word summary of type.
  3. Description
    Enter the (maximum of 80 characters)

    Enter the

    NASA only: Most of the usage and functional description may be created from the NTR data's descriptive title (1), abstract (9), description of the problem (Section I), and purpose (Section II). The capabilities should include such items as: Frequency range(s), Modulation, Spreading, Functionality, Forward Error Correction/Encoding/Decoding, User Data Rates, Over-the-air Symbol Rates, Scrambling, and Data Formatting.
  4. Capabilities
    Enter the (Click on one of the example buttons provided to avoid typing:
    , , , , , , , , )
    If none of the above, please enter a one-word or two-word summary of capabilities.
  5. Target Platform
    Enter the

  6. Software classification
    Enter the )
  7. Safety critical
    Is the application developed for a safety critical system? (Choose: , , ).
    NASA only: For more information, Safety Critical software is defined in detail in NASA-STD-8739.8, Appendix A, The Software Assurance Classification Assessment.
  8. Deployment date
    Enter the
    Leave blank; i.e. click if this application has not been deployed.
    Deployment date is when the item is first used in the target environment rather than a test environment.
  9. Architecture
    Enter the .
  10. Release category
    Enter the (Choose: )
    (NASA only: more detail in NPR 2210.1 in section A.2)
  11. Release restrictions
    Are there any export control restrictions (ITAR, SBU, EAR, etc.):





    The export control restrictions may be International Traffic in Arms Regulations (ITAR), Sensitive But Unclassified (SBU), Export Administration Regulations (EAR), etc.
    Enter any contract restrictions:




  12. Models
    Enter the availability of models (Choose: , )
    Models of interest are in files that may be used by a tool to perform simulations or generate code. The description of these models and the associated tools are required elsewhere but the availability of such models to speed up the reuse process is desirable for evaluation of reuse level of effort.
  13. Technology Readiness Level (TRL):
    Enter the
    (NASA only: more detail in NPR 7123.1B, Appendix E.)
  14. TRL justification
    Enter a short (publicly viewable)

    This is usually an indication of mission and operational environment where tested and used.
  15. Target/operational environment
    Enter whether the target/operational environment is Space or Ground (Choose: , , ) .
    Note that this is to support TRL above.
  16. Compute Reuse Readiness Levels (RRL) :

    The Reuse Readiness Level (RRL) Assessment will be stored in the STRS Application Repository. For background information, see NASA's Earth Observing System Data and Information System (EOSDIS) web site. Specifically, NASA's Earth Science Data System Working Group (ESDSWG) has studied reuse. References:

    1. Reuse Readiness Levels as a Measure of Software Reusability
    2. Example

    Select one item for each RRL category below:

    RRL Category RRL Assessment
    (1) Documentation
    (2) Extensibility
    (3) Intellectual Property Issues
    (4) Modularity
    (5) Packaging
    (6) Portability
    (7) Standards Compliance
    (8) Support
    (9) Verification and Testing
    (not editable)
    1. RRL justification
      Enter a short (publicly viewable)

      This is usually an indication of the level of effort for design, documentation, test, configuration management, standards used, etc.
    2. Contact
      Enter

      in case there are any questions relating to the metadata.
      Except for the submitter's email address, the data will be publicly available.
      Would you like to receive a copy of your Public Metadata submitted? (Choose: )
      If you have checked the Yes box to get a copy of the Public Metadata, for verification.

      Thank you.

    Go to (Beginning, Submittal)

    To restore previously saved data, click on the button below using the same computer/browser as when saved:

    To save data entered on the form, to restore later, click on the buttons below.
       
    To get more information, click on the button below:

    To reset entries to blank:

    To send the form by email, click on:

    If "Errors in STRS Form Data" is shown below, fix the errors and try again. If no errors are displayed, the RRL Average above is computed before submitting.

    Thank you for your participation in creating the STRS Application Repository public metadata. The public metadata will be stored in the STRS Application Repository for the benefit of all potential users of the application.

    Back to top.

    '