1. Requirements
1.1 NotesNPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement. 1.2 History1.3 Applicability Across Classes |
2. RationaleAll 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), 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. GuidanceSWE-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 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 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 the 5.07 - 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 the 5.13 - SwDD - Software Design Description. 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. Build tools Describe the 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 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. Metric data See SWE-092, SWE-093, and SWE-094 for the information to be provided. See 5.05 - 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, including 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 section 4.5 in NPR 7150.2 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-052. 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. 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). 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 ProjectsElectronic 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. Resources5.1 References
5.2 Tools |
6. Lessons Learned6.1 NASA Lessons LearnedA 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:
6.2 Other Lessons LearnedNo other Lessons Learned have currently been identified for this requirement. |
7. Software Assurance7.1 Tasking for Software Assurance1. Confirm that software artifacts are available in electronic format to NASA. 7.2 Software Assurance Products
7.3 Metrics
7.4 GuidanceAll 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?
Other documentation and products to consider include:
|