2. Rationale

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.

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 on future NASA projects.

Electronic access is needed during all phases of the software development life cycle. This enables software supplier activities to be monitored to assure the software work products are being developed efficiently and that the end products that are called for in the project and software requirements are actually produced. Appropriate use of software project insight (see SWE-039), which is in part enabled by electronic access to the in process products, allows NASA to detect problems early and to take corrective action if necessary.

3. Guidance

SWE-040 conveys the need for providing the appropriate levels of electronic access to the supplier's software work products and software processes to the NASA team. Access levels are those that enable NASA to properly exercise its insight and oversight responsibilities on the contract (see SWE-039SWE-039 - Software Supplier Insight).

The requirement for electronic access applies to applicable NASA software procurements (e.g., reuse of existing software, modification of existing software, contracted and subcontracted software, and/or development of new software.) Consider the requirements of NPR 2800.2, Electronic and Information Technology Accessibility ⁰¹⁸, when establishing the electronic access where NPR 7150.2 applies or is included in the contract Statement of Work (SOW). Electronic access can be provided to NASA in a variety of ways. Direct access to the software supplier's configuration management and document repositories may be the simplest to provide and the easiest to control using the supplier's security systems and password protocols. Another approach might be to set up a dedicated server for access by NASA. This method limits access to only the files, code, and documents entered into the dedicated server. It does require additional support and maintenance to keep the stored documents up to date, properly cataloged, and consistent with project baselines. The project may also consider the benefits and drawbacks of setting up electronic access only at designated time periods using magnetic media (e.g., disc storage media and or thumb drives). NASA's development team and its supplier together must consider the classification of the software, its safety criticality, and the levels of risk that are involved for each of these approaches. The methods chosen for electronic access need to be included in the contract SOW. Provisions for the maintenance and update of these choices also need to be considered and documented as appropriate.

Adequate controls by both the supplier and the NASA development team are needed to ensure proper access to project information to avoid confusion, misuse of information, and to protect proprietary or other controlled information. While commercial-off-the-shelf (COTS) software is not covered by SWE-040 when it is a standalone package, access to any COTS or proprietary software that is embedded in software developed for the government must be adequately negotiated as part of the contract SOW. See SWE-027SWE-027 - Use of Commercial, Government, and Legacy Software and the $paramlinktext tab for additional guidance on this topic.

When developing the list of items for the contract SOW that require electronic access, consider the items given below:

Software, executable and source code

Describe the discrete products to be provided electronically. Include delivery schedules, fidelity criteria, and process tracking information sufficient to exercise the code. See SWE-042SWE-042 - Source Code Electronic Access.

4. Small Projects

Electronic access to software work products and software process tracking information is required for every project. However, access plans need to be written to a level of detail (e.g., limited schedules, minimum deliveries) appropriate for and commensurate with the size, complexity, risk, and safety aspects of the project.

5. Resources

5.1 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

A documented lesson from the NASA Lessons Learned database illustrates the value of having appropriate electronic access to the necessary software products and processes and their results:

Accident Investigations/Information Technology and Database Security. Lesson No. 1448: "Electronic tools ... should have a secure, automated, user-friendly access system". While this lesson was derived from the Columbia Accident Investigation activities, the recommendations are perceived as applicable in many situations. Consider use of the following recommendations when securing electronic access to the projects' products and processes:

• "Do not allow computer connectivity and cross-platform issues to prevent efficient access between dispersed members.
• "Identify a single authority to integrate and manage security systems and make sure they are compatible.
• "Maximize use of COTS tools to enhance product support and rapid startup."
• ...
• "Identify which tools will contain ITAR data and, therefore, require 2-factor security.
• "Define the...Security Policy upfront – some items may require more security than others.
• "Make the security access tool web enabled with sufficient security protection so ...(users)...can have remote access...." ⁵⁵⁴