This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
4.6.3 The project manager shall complete and deliver the software product to the customer with appropriate records, including as-built records, to support the operations and maintenance phase of the software's life cycle.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
The ultimate goal of software development is to provide a product to the customer. It is necessary that documentation accompany that delivery to ensure proper understanding, use and maintenance of the delivered product.
Typical contents of a software delivery package for a completed software project include the source files, executables (the product), a user's manual, and a version description document that describes the delivered product and contains procedures for creating executable software and modifying the software. Suggestions for documentation contents are defined in Topic 7.18 – Documentation Guidance of this Handbook. Open source software licenses are also considered part of the delivery package and are reviewed by the Center's Chief of Patent/Intellectual Property Counsel before being accepted. Other documentation considered for delivery as appropriate for project and its software classification (SWE-020) includes:
- 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 Reports 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 open work, if any.
- Software configuration records defining the verified and validated software, including requirements verification data (e.g., requirements verification matrix).
- Final version of the software documentation, including the final Software Version Description document(s).
- Summary and status of any open software-related risks.
In addition to the items listed in this requirement, consider the following items for the software delivery package:
- Certifications. 278
- Software safety plan. 271
- Hazard analyses. 271
- Safety-critical software development audit reports. 271
- Safety-related verification reports. 271
- Installation instructions, including description of hardware environment. 276
- Operational constraints, including environmental limitations. 276
- Configuration files. 276
- Project documentation (e.g., software development/management plan (SDP/SMP), assurance plan, software requirements specification (SRS), design documents, configuration management plan (CMP), test plan). 276
- Testing performed and the results of those tests. 276
- Training manuals 041, training agreement. 224
- Maintenance/service/support agreement, processes, procedures. 224
- Development environment (any specialized hardware and software needed to build the executable software during the maintenance phase).
- Hardware needed to test the software, if specialized hardware is needed (for maintenance).
Once the project team establishes the set of documentation to be delivered with the software, the team keeps documents up-to-date throughout the project life cycle to avoid any delays in delivery. Near the end of the project life cycle the team updates any inconsistent documentation to ensure it includes the information needed to maintain the software in the future.
Before software delivery, a check of the software is made to verify that it conforms as-built to its technical documentation. When mismatches occur this close to software delivery, the project team updates the documentation to match the delivered software prior to delivery to the customer. It is important to perform an audit prior to delivery to ensure that "all delivered products are complete, contain the proper versions, and that all discrepancies, open work, and deviations and waivers are properly documented and approved." 278
Both the delivered software and the delivered documentation are generated/pulled from the project's configuration management system (SWE-085) as a baseline to ensure the latest versions are delivered to the customer.
Delivery package contents from a contracted software provider need to be fully described in the contract to ensure the acquirer receives all critical information required to operate and maintain the software. Other contract considerations related to delivery include:
- Ownership and delivery of source code.
- Usage considerations for off-the-shelf (OTS) software.
- Delivery format, security. 273 and method for all deliverables.
- Acceptance criteria (SWE-034).
See Topic 7.3 - Acquisition Guidance in this Handbook for additional guidance regarding delivery for contracted software development.
NASA users should consult Center Process Asset Libraries (PALs) for Center-specific guidance related to delivery of software products.
NASA-specific software delivery information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
Additionally, guidance related to delivery of software products may be found in the following related requirements in this Handbook:
4. Small Projects
No additional guidance is available for small projects.
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 notes the following:
- International Space Station (ISS) Program/Command and Data Handling/Firmware Documentation (Firmware Documentation.) Lesson Number 1024: "NASA should ensure that all firmware code...is properly documented and archived for future reference. Further, NASA should ensure that it retains the rights to such software.... Direction to deliver copies of the documentation (requirement, design, test, etc.) of the firmware controller software prepared as part of their software development process is being given to each vendor." 534