1. Requirements

3.1.10 The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format. 

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. This requirement should include MOTS software, ground test software, simulations, ground analysis software, ground control software, science data processing software, hardware manufacturing software, and Class F software.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

NASA requires electronic access to software source code developed by suppliers with NASA funding to enable independent evaluations, checks, reviews, and testing.  Source code is also needed to be able to run static code analysis on the product to check for software errors, security issues, and coding standard compliance. 

The electronic availability of the software work products, and associated process information, facilitates post-delivery testing that is necessary for assessing as-built work product quality, and for the porting of products to the appropriate hosts. 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

This requirement intends 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 upfront in the Statement of Work (SOW), task agreement, or other assignment paperwork. Special care needs to be used to 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 secures 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.

This requirement intends to provide the NASA software development team with direct access 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 the 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 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 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 source code in producing NASA-funded software on new projects. Some contractors also prefer to restrict code access to their website where internal access controls can be applied. Security features do need to be used to protect the software if it is not 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 the 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 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 need 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 ¹⁸⁶ (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 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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 the delivery of source code could compromise their contractors' proprietary data. The ISS has initiated discussions with all partners to reach an 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.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that software developers are providing NASA with electronic access to the source code generated for the project in a modifiable form.

7.2 Software Assurance Products

• No products have been identified at this time.

  
  

  Objective Evidence

  • Evidence of electronic access to all the source code products.
   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 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

• None at this time

7.4 Guidance

This requirement intends to provide the NASA software development team with direct access to NASA to the source code, configuration data, software data loads, programmable logic, legacy software, and heritage software. 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. COTS software is not subject to this requirement, but see SWE-027 for discussions and guidance regarding embedded software.

Source code is needed to be able to run static code analysis on the product to check for software errors, security issues, and coding standard compliance. 

All software products acquired for NASA projects are to be made available in electronic format so they can be delivered accurately and used efficiently as part of the project. The electronic availability of the software work products, and associated process information, facilitates post-delivery testing that is necessary for assessing as-built work product quality, and for the porting of products to the appropriate hosts. Electronic access to software projects reduces NASA's project costs.

The availability of the products can be easily verified by checking with project team members who need the types of data listed below to determine whether there are any access issues. Any access issues should be brought to the attention of the project manager.

This access also accommodates the longer-term needs for performing maintenance, including defect repairs and software component augmentations, assessing operation or system errors, addressing hardware and software workarounds, and allowing for the potential reuse of the software in future NASA projects.

What Needs To Be Accessible?

•Flight and ground software source code

•Models and simulations source code

•Programmable Logic Device logic and software source code

•Prototype software, including prototype architectures/designs source code

•Data definitions and data sets

•Software ground products source code

•Software build products source code

•Software database(s)

•Software Test Scripts source code 

During this phase of the software planning, ensure the requirements and any restrictions for the software are in the software planning documentation along with the method as to not violate any proprietary rights of the software to transfer the software. Confirm the software development planning documents define the delivery method and access for the software source code per the intellectual property rights of the software.