1. Requirements

3.1.9 The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information, and non-conformances in electronic format, including software development and management metrics.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

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 produced. Appropriate use of software project insight (see SWE-039 - Software Supplier Insight), 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 - 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, Information and Communication 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 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, and 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 - Use of Commercial, Government, and Legacy Software and the Lessons Learned tab for additional guidance on this topic.

See also Topic 7.03 - Acquisition Guidance, 

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

3.1 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 - Source Code Electronic Access.

3.2 Data definitions and data sets

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

3.3 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 the 5.13 - SwDD - Software Design Description.

3.4 Software build products

If the 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 the 5.13 - SwDD - Software Design Description.

3.5 Build tools

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

3.6 Software documentation

Include necessary documentation to enable the 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 5.12 - SUM - Software User Manual and 5.16 - VDD - Version Description Document.

3.7 Metric data

See SWE-092 - Using Measurement Data, SWE-093 - Analysis of Measurement Data, and SWE-094 - Reporting of Measurement Analysis  for the information to be provided. See 5.05 - Metrics - Software Metrics Report. for report requirements.

3.8 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.

3.9 Software database(s)

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

3.10 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 - Models, Simulations, Tools  and SWE-136 - Software Tool Accreditation.

3.11 Software Test Procedures 

Refer to SWE-062 - Unit Test and section 4.5 in NPR 7150.2 for the testing requirements, including SWE-065 - Test Plan, Procedures, Reports, SWE-066 - Perform Testing, SWE-191 - Software Regression Testing, as well as 5.14 - Test - Software Test Procedures.  Include testing of specific code, especially if needed to perform additional V&V activities not at the developer’s site.

3.12 Results of software testing 

Refer to section 4.5 in NPR 7150.2 for the testing reporting requirements, including SWE-065 - Test Plan, Procedures, Reports, SWE-068 - Evaluate Test Results, as well as 5.11 - STR - Software Test Report.

3.13 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 - Static Analysis.

3.14 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-052 - Bidirectional Traceability.

3.15 Software analyses and compliance data

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

3.16 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.

The 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 5.08 - SDP-SMP - Software Development - Management Plan).

3.17 Additional Guidance

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. 

3.18 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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 the 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 the 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...."

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

7.2 Software Assurance Products

• No products have been identified at this time.

  Objective Evidence

  • Evidence of electronic accessibility confirmation for software artifacts, including any risks or issues.
   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

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 ensure the software work products are being developed efficiently and that the end products that are called for in the project and software requirements are produced.

What Needs To Be Accessible?

• Software, executable, and source code
• Models and simulations
• Programmable Logic Device logic and software
• Trade study data, including software tools, is used to help formulate an analysis of alternative results if any scenarios need to be re-run later
• Prototype software, including prototype architectures/designs
• Data definitions and data sets
• Software ground products
• Software build products
• Build tools
• Software documentation, including data presented during any early design reviews
• Metric data
• Software cost data and parameters
• Software database(s)
• Software development environment
• Software Test Scripts and the results of software testing
• Results of software static analysis activities
• Bi-directional traceability for the software products
• Software analyses and compliance data

Other documentation and products to consider include:

• Summary and status of all accepted Change Requests to the baselined Software Requirements Specifications.
• Summary and status of all major software capability changes since baselining of the Software Design Documents
• Summary and status of all major software tests (including development, verification, and performance testing).
• Summary and status of all Problem Report written against the software.
• Summary and status of all software requirements deviations and waivers.
• Summary and status of all software user notes.
• Summary and status of all quality measures historically and for this software.
• Definition of openwork, if any.
• Software configuration records define the verified and validated software, including requirements verification data (e.g., requirements verification matrix).
• The final version of the software documentation, including the final Software Version Description document(s).
• Summary and status of any open software-related risks.

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: