bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-042 - Source Code Electronic Access

1. Requirements

3.12.10 The project manager shall require the software supplier(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format, including modified off the shelf (MOTS) software and non-flight software (e.g., ground test software, simulations, ground analysis software, ground control software, science data processing software, and hardware manufacturing software).

1.1 Notes

The electronic access requirements for the source code, software products and software process tracking information implies that NASA gets electronic copies of the items for use by NASA at NASA facilities.

1.2 Applicability Across Classes

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.


2. Rationale

NASA requires electronic access to software source code developed by suppliers with NASA funding to enable independent evaluations, checks, reviews, and testing.  This access also accommodates the longer-term needs for performing maintenance, assessing operation or system errors, addressing hardware and software workarounds and allowing for the potential reuse of the software on future NASA projects..

3. Guidance

The intent of this requirement is to provide NASA the required electronic access to software source code developed by suppliers with NASA funding to enable independent evaluations, checks, reviews, and testing. This access also accommodates the longer-term needs for performing maintenance, assessing operation or system errors, addressing hardware and software workarounds and allowing for the potential reuse of the software on future NASA projects.

This is a key requirement that must be addressed on all NASA software projects. Access needs to be defined up front in the Statement of Work (SOW), task agreement, or other assignment paperwork. Special care needs to be used to clearly identify this requirement in the primary contractor and subcontractor requirements. NASA needs direct insight into all software development on a project. In the context of this requirement, "electronic access" is interpreted as access that does not require a physical presence at the software supplier or contractor location. It does allow for a secure File Transfer Protocol (FTP) or secure remote web access from a NASA Center or a NASA-approved site. Sometimes due to NASA Information Technology (IT) policies or a contractor's IT policies (firewall issues), it is not possible to get direct electronic access into a contractor's development system. In such cases, as a last resort, it would be acceptable to have the contractor provide the code on a USB flash drive or disk.

The intent of this requirement is to provide the NASA software development team with direct access at NASA to the source code, configuration data, software data loads, programmable logic, commercial software, legacy software, heritage software, and software related telemetry. The access includes the executable code so that NASA can perform independent assessments, reviews, analyses, and run the work products through NASA's own set of static analysis tools, as needed by the project. It allows the team to evaluate progress being made by the vendor as a part of the government's insight/oversight responsibility (see SWE-039). COTS software is not subject to this requirement, but see SWE-027 for discussions and guidance regarding embedded software.

A secondary intent for this requirement is to allow NASA to support long-term maintenance. This is a capability NASA needs to have since the initial software development vendor may leave or no longer be involved in the maintenance of the software for the project. NASA software engineers or other NASA vendors may need to do the maintenance later in the life cycle of the work products (see SWE-019) possession of the electronic, modifiable version of the source code and related documentation (see SWE-040 and SWE-077) allows for these future events.

Another reason for having the electronic access is to provide for the future reuse of the delivered software on new or follow-on projects where the software vendor is different from the original developer.

This electronic access may be resisted by contractors. It often occurs that vendors reuse their own source code in producing NASA funded software on new projects. Some contractors also prefer to restrict code access to its website where internal access controls can be applied. Security features do need to be used to protect the software if it is not totally government funded. The mixing of vendor funded and NASA funded source code results in a difficult decision in the contract. See Lessons Learned No. 1130, "Evidence of Recurrence Control Effectiveness," first paragraph. The NASA software development team can eliminate these problems with sufficient language in the contract SOW regarding intellectual property rights, licensing, and copyright privileges.

Known contract requirements are addressed in the solicitations and included in the resulting contract. Additionally, if the project needs to control further use and distribution of the resulting software or requires unlimited rights in the software (e.g., right to use, modify, and distribute the software for any purpose), the project can consider having the software copyright assigned to the government. A list of software deliverables needs to be addressed in the solicitations, if the software is being procured. The project can consult with the Center's Chief of Patent/Intellectual Property Counsel regarding required rights associated with the software. See SWE-077 for a list of Software Operations, Maintenance, and Retirement deliverables.

Proprietary rights will need to be considered for prime contractor suppliers to ensure that intellectual property rights are not being violated between the prime contractor and suppliers in order for NASA to obtain access or right to the software acquired or developed by suppliers of the prime contractor. In many cases the suppliers and prime contractors have defined access rights but access rights also needs to be considered with the NASA customer. Proprietary rights of the suppliers are also critical for the long-term maintenance or operations of the software that may be managed in the future by NASA and not the prime contractor.

The contract SOW clearly states when (each build release, final delivery) and for what types of software (e.g., flight, modified off the shelf (MOTS), ground) electronic access is to be provided. All NASA acquisitions that include software as a part of the acquisition need to access and determine the applicability of the Federal Acquisition Requirements 186 (FAR) clause 52.227-14 Rights in Data---General.

Data rights are addressed in the FAR requirements; projects should ensure that the correct data rights FAR requirements are included in any acquisition activity. 

4. Small Projects

No additional guidance is available for small projects.

5. Resources


5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

Computer Hardware-Software/International Space Station/Software Configuration Management. Lesson No: 1130: Although it was "grandfathered" out of NPR 7150.2 compliance, the experience regarding source code for the International Space Station (ISS) is an important caveat when establishing software supplier agreements. NASA does not have source code access for all partners' deliveries for the ISS. The partners cite their concerns that delivery of source code could compromise their contractors' proprietary data. The ISS has initiated discussions with all partners to reach agreement on what level of source code visibility is necessary to ensure adequate knowledge by the control centers for on-orbit anomaly resolution. It is not clear how much extra effort these discussions have taken 541.

  • No labels