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

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-027 and the Lessons Learned 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-042.

 Data definitions and data sets

 Provide descriptions of the data (name, type, and units), formatting, and organizational and or filing conventions. See SDD - Software Data Dictionary.

Software ground products

Describe products that will be considered ground products, i.e., these are non-flight useable products. Differentiate between final as-built code for ground systems applications, and products that are to be used in lab situations only. See SwDD - Software Design Description.

Software build products

If software is to be developed and delivered in builds, provide the complete build with sufficient descriptive material to enable its operation. Include information to describe the additions expected in future build deliveries. See SwDD - Software Design Description.

Build tools

Describe tools and environments needed to operate build software. Include information about any items that are proprietary, sole source, are off the shelf. See SWE-136.

Software documentation

Include necessary documentation to enable operation of the software. If the delivered (i.e., electronic access) software requires specialized operating instructions or tools or environments, be sure to include descriptive information for them as well. See SUM - Software User Manual and SVD - Software Version Description.

Metric data

See SWE-092, SWE-093, and SWE-094  for the information to be provided. See Metrics - Software Metrics Report. for report requirements.

Software cost data and parameters

Costing data is typically organized and supplied according to the contract SOW financial and accounting information requirements. Sufficient summary information may be required to assist in planning future development and update/maintenance activities.

Software database(s)

If used to present work product information, or if used in the development of the code, include all database parameters, definitions, data sources, and update information (as appropriate).

Software development environment

Describe the development environment for the ground and flight code. Include any variations or alterations used in developing unit code, or intermediate builds, if any. Describe the controls and certifications necessary for the environment. See SWE-070  and SWE-136.

Results of software testing

Refer to SWE-067  and SWE-069  for the testing reporting requirements.

Results of software static analysis activities

Describe the activities for reviewing the developed code for defects. Include the results from running static analysis tools on the developed code. See SWE-135.

Bi-directional traceability for the software products

Describe the efforts to trace requirements through the various phases of the life cycle, both from design through implementation, and back from operation to system requirements development. See SWE-047, SWE-052, SWE-059, and SWE-072.

Software analyses and compliance data

Provide results of compliance assessment, peer reviews, and analysis of the state of the software. See SWE-125.

Other

Finally, review all information and data used to develop, test, and operate the software for possible inclusion in the list of products that will be made available via electronic access during the development cycle.

These above items are the suggested minimum content. Additional content may be included as appropriate for the project. This content may be entirely captured in a clause to the SOW, or it may be captured as required content in a software product delivery plan. When other plans list or describe any of the required items needing electronic access, reference those plans in the Software Development Plan (see SDP-SMP).

Additional guidance related to software product and software process information and reporting can be found in the following related requirements in this Handbook. As you decide how to capture, format, and store the software product and process information, consider how your decisions will satisfy or impact the need to provide electronic access to the information to NASA.

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...." ⁵⁵⁴