1. Requirements

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. 

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

The ultimate goal of software development is to provide a product to the customer. Documentation must accompany that delivery to ensure proper understanding, use, and maintenance of the delivered product.  

This requirement ensures that the delivered software product is accompanied by comprehensive and accurate documentation to facilitate operations, maintenance, and sustainment activities throughout its lifecycle. Proper documentation and as-built records are crucial for ensuring that the software can be accurately understood, operated, and maintained by the customer or other stakeholders, thereby enabling successful mission outcomes and reducing long-term risks and costs.

Key Aspects of the Rationale:

1. Enable Successful Operations

• Operations teams rely on clear and accurate documentation to operate the software safely and efficiently.
• Providing operational records—such as updated user manuals, release notes, and operational procedures—ensures that the system operates as designed and adheres to mission-critical safety and performance requirements.
• Without complete records, operators may encounter difficulties understanding system behaviors, leading to errors, inefficiencies, or mission failures.

2. Reduce Maintenance Risks and Complexity

• Maintenance activities, such as defect resolution, adaptive updates, and performance tuning, depend on access to the as-built records of the software. These records include the design, architecture, source code, configuration settings, test results, and all modifications made during development.
• Providing the customer with thorough as-built documentation ensures maintainers have sufficient insight into the software’s structure and functionality to implement changes without introducing unintended errors.
• Lack of complete as-built records increases the likelihood of miscommunication, longer turnaround times for fixes, and higher maintenance costs over the software’s lifecycle.

3. Support Long-Term Sustainability

• Many NASA software systems are intended for long-term use, sometimes spanning decades. Over time, team members may leave, tools may change, and institutional knowledge may be lost. Comprehensive records allow future teams to sustain and manage the software system effectively, regardless of personnel turnover or reliance on legacy technologies.
• Having the full historical context of the software’s design and development ensures that legacy systems can evolve to meet new mission needs without requiring complete redevelopment.

4. Facilitate Verification and Validation (V&V)

• The as-built records provide the customer and stakeholders with visibility into how the software was developed, validated, and verified. This allows the customer to confirm that the delivered product aligns with the original system requirements and meets safety, reliability, and performance criteria.
• Providing these records ensures traceability between the system’s requirements, design, implementation, and test results, giving the customer confidence in the quality of the delivered product.

5. Mitigation of Knowledge Gaps Post-Delivery

• Proper documentation allows customers to bridge the knowledge gap between the development team and the operations/maintenance team.
• Transferring detailed, verifiable records minimizes the risk of operational or maintenance personnel misunderstanding the system’s intricacies, reducing the risk of introducing errors during operations, updates, or problem resolution.

6. Risk Management During Handover

• A documented handover process that includes as-built records reduces the risk associated with transitioning the software to another entity or team.
• Inadequate documentation at delivery can lead to lost knowledge that would require expensive reverse engineering or a steep learning curve for the new team.
• Clearly organized and complete records reduce the possibility of mission downtime or interruptions during transitional periods.

7. Regulatory and Contractual Compliance

• Many NASA missions are subject to external reviews, audits, and compliance requirements. This requirement ensures that all documentation and records are available and archived to fulfill these obligations.
• Delivering as-built records allows the customer to evaluate adherence to standards, such as NASA-STD-8739.8, NPR 7150.2, or project-specific agreements and protocols. Furthermore, this documentation supports lessons-learned efforts and continuous improvement in other NASA projects.

8. Allows for Improved Scalability and Reusability

• By providing the customer with detailed as-built records, the delivered software is better positioned for scalability or reuse in comparable projects. This aligns with NASA’s goal of efficient resource use and long-term cost-effectiveness.
• Reusable software or components require proper documentation to allow a new development team to adapt them to new mission objectives or hardware platforms.

Summary of Key Objectives for the Rationale:

• Transparency: Delivering records improves visibility into the software’s capabilities, processes, and design.
• Operability: Ensures operators have clear instructions for using the software in a safe and efficient manner.
• Maintainability: Provides maintainers with the tools and knowledge to extend the software’s lifecycle and address defects or updates with minimal disruption.
• Sustainability: Helps future teams manage the software system regardless of changes in personnel, tools, or technology.
• Risk Reduction: Reduces long-term mission risks by mitigating knowledge loss and ensuring proper continuity between development and operational phases.

By meeting this requirement, project management fulfills a critical responsibility to ensure the delivered software product is not only functional at delivery but remains a robust, maintainable, and reliable asset throughout its intended lifecycle.

3. Guidance

3.1 Delivery Package

This updated guidance builds on the original text to provide additional clarity, structure, and actionable recommendations for creating and delivering a comprehensive software delivery package. It emphasizes the importance of including all necessary artifacts to support software operations, maintenance, and retirement while ensuring consistency, traceability, and quality compliance.

Definition of Delivery Package

A comprehensive software delivery package is the collection of software artifacts, executable deliverables, and supporting documentation necessary for the customer to operate, maintain, and manage the software effectively throughout its lifecycle. The delivery package should align with the project’s requirements, classification, and contractual obligations, ensuring no critical gaps exist in information transfer.

Typical Contents of a Software Delivery Package

A typical delivery package includes the following essential items:

1. Software Artifacts:

   • Source Code: Includes all libraries, modules, and scripts required to compile and execute the software.
   • Executables: The compiled and tested software product ready for deployment.
   • Version Description Document (VDD): Provides details about the delivered software version, including instructions for recreating the executable software and applying approved modifications.

2. Core Documentation:

   • Final Software User Manual: Describes the software functionality, operating instructions, reference material, limitations, assumptions, and safety-critical procedures (See Topic 5.12 - SUM - Software User Manual guidance).
   • As-Built Records: Documents capturing the final verified and validated state of the software, including requirements verification data, design details, and configuration snapshots.
   • Change Management Summaries: History and status of all approved Change Requests since baseline, detailing their impact on the delivered software.
   • Test Reports: Summary and results of verification, validation, and performance tests conducted prior to delivery.
   • Problem Reports: Summary and analysis of all documented issues encountered during development and their resolutions.

3. Safety and Risk Artifacts (as applicable):

   • Software Safety Plan: Outlines the procedures for identifying and mitigating risks related to safety-critical elements of the software throughout its lifecycle.
   • Hazard Analyses: Detailed assessment of safety risks identified during development and how they are addressed.
   • Safety Verification Reports: Summary of safety-related testing and validation undertaken to ensure safety-critical requirements are met.
   • Open Software-Related Risks: Documentation of unresolved risks, their implications, and the mitigation or contingency plans in place.

4. Operational and Maintenance Content:

   • Installation Instructions: Detailed guidance for installing the software, including hardware/environment requirements.
   • Configuration Files: Specifies required settings or parameters for the software environment.
   • Operational Constraints: Documentation of environmental limitations, dependencies, or conditions under which the software operates correctly.
   • Training Documentation: Manuals and materials to support training operators and maintainers.

5. Additional Deliverables (as necessary for maintenance support):

   • Development Environment Details: Description of specialized hardware, software, or tools needed to compile and modify the delivered software over its lifecycle.
   • Specialized Testing Equipment: Any proprietary or mission-specific hardware required for software testing during maintenance.
   • Maintenance Agreements: Process and support agreements for ongoing updates or service activities.

6. Intellectual Property and Licensing:

   • Open-Source Licenses: Reviewed and approved by the Chief of Patent/Intellectual Property Counsel.
   • Commercial/Government Licenses: Documentation related to the use of off-the-shelf (OTS) software or licensing restrictions.

7. Final Project Documentation Archive:

   • Software Management Plan (SMP), Software Development Plan (SDP), Configuration Management Plan (CMP), Test Plans.
   • Historical Quality Metrics: Summary of quality measures collected throughout the project.
   • Lessons Learned: Insights and recommendations for future projects (particularly related to operations and maintenance).

Ensuring Alignment with Software Classification

• Tailor the delivery package to the software classification (see SWE-020 - Software Classification). Higher-class software may require more rigorous documentation, safety artifacts, and risk analysis to fulfill compliance obligations.

3.2 Generating and Delivering the Package

1. Generating the Delivery Package

• Use Configuration Management (CM) System:

  • All delivered software and documentation should be generated or delivered as baselines from the project’s configuration management system to ensure version accuracy and traceability (See SWE-085 – Release Management).
  • The CM system should include verified source code, test results, VDDs, and documentation baselines.

• Maintain Up-to-Date Documentation:

  • Ensure documentation is consistently updated throughout the lifecycle to minimize inconsistencies or delivery delays.
  • Near the completion of the lifecycle, review and align all technical documentation with the final delivered software to avoid mismatches.

2. Delivery Package Verification

• Perform Pre-Delivery Audits:

  • Conduct formal audits to verify that "all delivered products are complete, contain the correct versions, and that all discrepancies, openwork, deviations, and waivers are properly documented and approved."
  • Include configuration audits to check the integrity and consistency of baselines stored in the CM system.

• Ensure Traceability:

  • Confirm that requirements traceability matrix verifies all baselined requirements have been fulfilled and validated by the as-built software and supporting documentation.

• Customer Checklists:

  • Develop delivery acceptance checklists to ensure delivery artifacts meet expectations, minimize risks, and address customer contract requirements.

3. Contract-Specific Deliverables (for acquired software):

For software acquired via contract, ensure the delivery package is described in the contractual documentation (See SWE-042 - Source Code Electronic Access). Typical considerations include:

• Ownership Agreements:
  • Ensure the source code, executables, and associated documentation are explicitly included and assigned to the customer.
• Usage Provisions for OTS Software:
  • Define allowable use, licensing restrictions, and maintenance obligations for proprietary OTS software.
• Delivery Format and Security Protocols:
  • Specify file formats, encryption requirements, and safe transfer methods for deliverables.
• Acceptance Criteria:
  • Include specific criteria for customer acceptance, ensuring they outline functional requirements, traceability, and artifact completeness (See SWE-034 - Acceptance Criteria).

4. Delivery Format and Method

• Select Appropriate Delivery Format:

  • Deliver software in machine-readable and compiled formats, accompanied by source code stored in standard CM repositories (e.g., Git, Bitbucket).
  • Ensure physical drives, tapes, or other hardware mediums are suitable for the customer’s requirements and environment.

• Secure Delivery:

  • Use encryption and secure delivery channels (physical or online) to protect sensitive software and documentation.
  • Include integrity checks (e.g., checksums, cryptographic hashes) for delivered software files.

Additional Guidance

Post-Delivery Considerations

1. Customer Feedback:

   • Engage the customer for feedback on the delivery package and identify outstanding concerns or additional needs for operational success.

2. Operational Verification Support:

   • Provide technical assistance during the initial installation phase to verify delivered software operates as intended in the customer’s environment.

Conclusion

By ensuring that the software delivery package is comprehensive, accurate, and tailored to the software's lifecycle phase and classification, NASA projects can achieve seamless hand-offs, reduce risks, and support long-term operability and maintainability of delivered systems. A well-structured delivery process builds trust with the customer and ensures the success of subsequent phases, including operations, maintenance, and retirement.

See also Topic 5.16 - VDD - Version Description Document, SWE-063 - Release Version Description

See also SWE-075 - Plan Operations, Maintenance, Retirement, 

See topic 7.03 - Acquisition Guidance in this Handbook for additional guidance regarding delivery for contracted software development.

3.3 Additional Guidance

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

3.4 Center Process Asset Libraries

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

4. Small Projects

For small projects, the emphasis is on streamlining processes while maintaining the quality, completeness, and compliance of the delivery package necessary to sustain operations, maintenance, and eventual software retirement. The approach for fulfilling this requirement can be scaled to meet the reduced complexity, staffing, and resource constraints typical of small projects.

Key Considerations for Small Projects

1. Simplified Documentation: Focus only on essential documentation necessary for operations and maintenance activities, while omitting non-critical items that may not add value to small software systems.
2. Automation and Standardized Tools: Leverage simple version control systems, templates, or automated tools to create and manage records efficiently.
3. Team Collaboration: Small teams can allocate single roles for overlapping functions (e.g., configuration management and documentation updates) to avoid redundancies.
4. Customer Alignment: Engage closely with the customer to understand their specific needs and directly tailor the delivery package to their expectations.

Small Project Software Delivery Package

The following streamlined delivery package items are recommended for small projects:

Core Elements (Essential for Any Small Project):

1. Source Code: Provide the project’s source code files, organized with clear directory structures and comments for maintainability.

   • Use a simple configuration management system (e.g., Git or Subversion) to store and version control the code.
   • Add simple build scripts or notes to explain how to compile the software from source.

2. Executable Files: Deliver all compiled executables, ready for deployment or testing in the customer’s environment.

3. Version Description Document (VDD):

   • Summarize the delivered version, including version number, notable changes, software dependencies, and build instructions.
   • Provide instructions for modifying the software, if necessary.

4. User Manual:

   • Develop a simplified Software User Manual containing operating instructions, critical commands, and troubleshooting guidance.
   • Include lists of known limitations, assumptions, and error messages along with corrective actions.

5. Testing Results Summary:

   • Deliver a concise summary of software testing (e.g., unit, functional, performance testing), including major issues resolved and any known risks.
   • Highlight any safety-critical testing results in systems involving hazardous or mission-critical components.

6. Configuration Documentation:

   • Provide a basic overview of the software’s configuration files and settings.
   • Include instructions for applying these configurations to set up the software successfully in the customer’s environment.

Additional Elements (Optional for Small Projects):

If applicable, include these items based on the software's scope, classification, or customer requirements:

1. Change Request Summary: Provide a summarized list of approved changes made to the baseline requirements or design, if significant updates occurred during development.
2. Problem Reports: Deliver a brief record of prior issues that were resolved or remain open at delivery, focusing on their impact and resolution status.
3. Risk Assessment Summary: Document any notable software-related risks still open and identify recommended mitigation strategies for the customer.
4. Development Environment Information: If the software requires specialized tools for maintenance, include details about the development environment (e.g., hardware specifications, compilers, frameworks).

Delivery Format for Small Projects

1. File Organization

• Organize the delivery package into clearly titled folders for the source code, executables, documentation, and testing results.
• Use zip files or cloud-based repositories (with appropriate security measures) for simplified delivery.

2. Secure Delivery Method

• For small projects, deliver the package using secure methods such as:
  • Online Delivery: Encrypted file transfer (e.g., NASA-supported secure FTP servers).
  • Physical Delivery: USB drives or external storage devices with encryption for transferring large files or sensitive software.

Streamlined Process for Small Projects

Follow these simplified steps to generate and deliver the software package efficiently:

Step 1: Finalize Documentation

• Examine all project artifacts (e.g., change records, test reports, user manuals) and update them to reflect the final state of the software.
• Use simple tools or templates to ensure consistency across all project documents.

Step 2: Package Software

• Ensure source code and executables are the latest verified versions, pulled from the configuration management system or code repository.
• Ensure that build instructions or scripts for recreating the software are documented clearly.

Step 3: Perform Pre-Delivery Audit

• Conduct a small-scale checklist-based review prior to delivery:
  • Verify that all files are included and versions are consistent.
  • Check for documentation updates to reflect the as-built state of the software.
  • Confirm completeness of testing records (including failure resolutions).

Step 4: Deliver to the Customer

• Provide the delivery package through a secure method.
• Provide the customer with an Acceptance Checklist, listing expected deliverables and allowing them to confirm successful receipt and review.

Best Practices for Small Projects

1. Reuse Templates and Tools: Simplify the creation of documentation by reusing existing templates, tools, or processes from prior NASA small projects.
2. Customer Engagement: Work closely with the customer throughout the development and delivery process to clarify their expectations and avoid unnecessary deliverables.
3. Test Verification: Ensure delivered executables match the functional and safety requirements verified through testing.
4. Minimize Complexity: Avoid over-documentation; focus on the critical artifacts necessary for operations and maintenance in the customer’s environment.

Conclusion

For small projects, the delivery package should prioritize critical items that ensure the customer's ability to use, maintain, and update the software effectively, while streamlining the generation and auditing processes. By focusing on essential deliverables and leveraging streamlined tools and methods, small projects can fulfill Requirement 4.6.3 efficiently without compromising quality or customer satisfaction.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

NASA has accumulated substantial lessons from past projects, highlighting the critical importance of ensuring proper delivery practices for software and its associated documentation. One such lesson recorded in the NASA Lessons Learned database emphasizes the challenges and risks posed by insufficient documentation and archival practices for firmware and software products.

Key Lesson: Firmware Documentation (Lesson Number 1024)

International Space Station (ISS) Program / Command and Data Handling / Firmware Documentation

Summary of Lesson Learned:
This documented lesson underscores the importance of delivering comprehensive software and firmware documentation to support ongoing operations, maintenance, and potential future reuse of systems. It particularly applies to software and firmware developed by external vendors or contractors, where NASA must maintain control over the delivered artifacts. Key takeaways from the lesson include:

1. Ensure Complete Documentation is Delivered and Archived:

   • All firmware and software code must be thoroughly documented and archived. This includes requirements, design specifications, and test artifacts produced during the development process.
   • Without complete documentation, future teams face significant challenges in maintaining and modifying the software, risking increased costs, operational inefficiencies, and mission vulnerabilities.

2. Retain Rights to Software and Documentation:

   • NASA must secure rights to access, modify, and use the delivered software, firmware, and associated documentation.
   • Contracts with vendors must specify the ownership and delivery of source code, design documentation, and test results to ensure NASA does not become overly reliant on external entities for maintenance or operational support.

3. Vendors Must Deliver Development Artifacts as Part of the Delivery Package:

   • Vendors contracted to develop firmware or software are required to deliver all development-related documentation as part of their final product. This includes requirements, design documents, testing procedures, test results, and any unique considerations relevant to maintaining the software.
   • This direction ensures that all key artifacts remain accessible to NASA, ensuring continuity even in cases of vendor transition or long-term system reusability.

Application to Requirement 4.6.3

This lesson directly applies to Requirement 4.6.3, reinforcing the critical need for complete, well-documented, and traceable delivery packages. Following these practices ensures that NASA projects retain control over the software lifecycle, mitigate unexpected maintenance burdens, and preserve essential knowledge for future work.

Practical Recommendations Based on the Lesson Learned:

1. Comprehensive Delivery Package:

   • For both in-house and contracted software, ensure that all lifecycle documentation is included in the delivery package.
   • Essential artifacts include a user manual, as-built records, test results, the source code, design documents, and traceability records.

2. Vendor Contractual Requirements:

   • Explicitly mandate the delivery of all software development artifacts in vendor contracts (e.g., requirements, design, test cases, and results).
   • Include clauses regarding intellectual property (IP) rights to secure ongoing access to software and firmware even after vendor contracts end.

3. Archival and Accessibility:

   • Archive delivered records in configurations that are easily searchable and accessible for future maintenance teams.
   • Use approved NASA repositories or configuration management systems to ensure long-term availability and version traceability.

4. Planning for Long-Term Maintenance:

   • Confirm that documentation is detailed and structured in a way that enables future developers to maintain or enhance the software with minimal knowledge transfer gaps.

5. Independent Audits Prior to Delivery:

   • Before software is accepted and archived, perform audits to verify the quality of delivered documentation and ensure it adequately supports operations and maintenance.
   • Address any gaps (missing deliverables, ambiguous documentation, etc.) with vendors or internal teams before project closure.

Broader Implications of the Lesson Learned

This lesson demonstrates the downstream consequences of inadequate delivery practices. For example:

• A lack of adequate documentation can delay or prevent timely software fixes, especially in critical systems like the ISS.
• Insufficient control over software artifacts can result in unexpected costs, vendor lock-in, or legal complexities, especially for long-duration NASA missions where system sustainability is a priority.
• Conversely, delivering well-documented software reduces risks, costs, and operational bottlenecks in the long run, ensuring NASA’s ability to sustain critical systems with minimal disruptions.

Conclusion

The lesson from ISS firmware documentation highlights the importance of proper delivery processes for all NASA software systems. By adhering to Requirement 4.6.3 and ensuring that software packages include all necessary artifacts while retaining rights to software and documentation, NASA can achieve greater operational continuity, efficient maintenance cycles, and long-term sustainability of its missions. Small- and large-scale projects alike must plan for and implement these best practices to ensure their software’s lifecycle is fully supported post-delivery.

6.2 Other Lessons Learned

The Goddard Space Flight Center (GSFC) Lessons Learned online repository ⁶⁹⁵ contains the following lessons learned related to software requirements identification, development, documentation, approval, and maintenance based on analysis of customer and other stakeholder requirements and the operational concepts. Select the titled link below to access the specific Lessons Learned:

• Dedicate more hours to FSSE preparation for post-commissioning. Lesson Number 79: The recommendation states: "Dedicate more hours to FSSE preparation for post-commissioning, particularly in the preparation of the Lab as long-term asset for the mission."
• Plan for the impacts of assembling and moving the Flight Software simulator. Lesson Number 108: The recommendation states: "Plan for the impacts of assembling and moving the Flight Software simulator."
• When using commercial BSP for VxWorks don't forget to include yearly maintenance fees. Lesson Number 304: The recommendation states: "When costing a mission that has software licenses, these fees must be accounted for the duration of the mission, including post launch (through Phase E)." 

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

Software Assurance (SA) plays a critical role in verifying that the software product and all associated artifacts delivered to the customer meet the applicable standards, requirements, and quality expectations. The guidance below refines and expands upon the original, focusing on ensuring thorough oversight, accurate audits, metric tracking, and comprehensive testing to certify readiness for operations and maintenance.

1. Baseline Verification and Configuration Management Audit:

• Compile a Software Configuration Management Baseline Verification Report to ensure that the latest, approved versions of all software and documentation artifacts match the delivery baseline in the project’s configuration management system.
  • Verify that the configuration management processes align with the planned procedures and that the delivered products comply with these processes.
  • Confirm that all deviations, waivers, or open change requests are approved and documented before delivery.

2. Key Audit Deliverables:

Software assurance should ensure the following products and deliverables are prepared during the delivery process:

• Configuration Management Process/Procedure Audit Report:

  • Assess findings from audits of the configuration management process, identifying gaps, risks, or non-conformances.
  • Ensure corrective actions are defined and tracked to closure.

• Delivery Product Verification:

  • Perform configuration management audits to confirm that the final delivery includes all planned artifacts, as defined in the project's Version Description Document (VDD) and delivery plan.
  • Record all audit findings (including any missing or incorrect components, as well as mismatches in software versions) and ensure that discrepancies are fully resolved before delivery.

• Version Description Documentation Review:

  • Verify the accuracy of the Version Description Document (VDD) for the delivered build, including:
    • Changes made since prior builds.
    • Updated requirements traceability matrices, reflecting the successful implementation and verification of all as-built capabilities.

• Software Configuration Records Review:

  • Validate software configuration logs (e.g., change records) to confirm adherence to the project baseline.

• Defect and Change Records Review:

  • Confirm that all implemented defect resolutions, feature requests, and late-stage changes are documented and that associated test results are included in the delivery package.
  • Verify that any unresolved defects (e.g., deferred changes, items with workarounds) are listed in the delivery documentation, with associated risks clearly noted.

• Software Assurance Audit Results:

  • Provide a consolidated SA Audit Report detailing findings from all process, procedure, and product audits.

7.3 Metrics for Software Assurance

To continually monitor delivery readiness and identify trends, SA should collect the following metrics and share them during project reviews:

1. Configuration Management Metrics:

• Number of configuration management audits conducted (Planned vs. Actual).
• Number and type of configuration management non-conformances identified during delivery audits.
• Open vs. Closed configuration-related non-conformances over time.
• Trends in the number of non-conformances by life cycle phase (e.g., requirements, design, testing, and delivery).

2. Software Process and Compliance Metrics:

• Number of compliance audits planned versus performed.
• Non-conformance trends for both compliance and software process audits.

3. Release Documentation Quality:

• Number of defects or non-conformances identified in release documentation.
• Open vs. Closed non-conformances in release documentation over time.

4. Build and Delivery Metrics:

• Number of software components planned for release versus delivered in each build (e.g., programs, modules, files).
• Number of process deviations or missed activities (e.g., skipped regression testing) identified by SA versus officially accepted by the project.

5. Risk Metrics:

• Known defects and their status at the time of delivery.
• Trends in the number of open risks associated with deliverables.

Refer to Topic 8.18 - Software Assurance Suggested Metrics for further detailed metrics that support continuous improvement.

7.4 Guidance for Software Assurance

Software assurance must verify that all aspects of the software, deliverables, and documentation align with customer expectations and requirements. SA’s responsibilities include certifying the following:

1. Delivery Completeness and Baseline Verification

• Verify that all software planned for delivery has been implemented, including all features listed in the baseline requirements.
• Confirm that all changes made since baseline have been documented, implemented, and successfully tested.

2. Software Testing Completion

• Ensure that the software meets acceptance test criteria, demonstrating full traceability to system, functional, and performance requirements.
• Confirm that regression testing has verified there are no adverse impacts from changes, and verify that defect resolutions are properly retested.

3. Documentation and Release Artifacts

• Ensure that all planned documentation is included in the delivery, such as:
  • Software User Manuals, As-Built Documentation, Operations Manuals.
  • Build Procedures or Scripts.
  • Regression Test Sets with Expected Results.
  • Maintenance Handbooks.
• Confirm that the delivery identifies any deferred or unresolved defects (along with their risks, workarounds, or rationale).

Functional Configuration Audit (FCA)

To verify that the delivered software meets its operational and functional requirements, SA will:

• Conduct (or participate in) an FCA to ensure every requirement has been implemented and is verified/tested.
• Confirm that changes or defect resolutions have been successfully validated, including via regression testing.

Physical Configuration Audit (PCA)

The PCA ensures the delivered software package matches the associated documentation and that all items are complete. SA will:

• Perform or participate in the PCA to confirm that the final delivery items match their planned baseline.
• Verify that all recorded version numbers match the configuration management system records.
• Ensure that discrepancies, deviations, waivers, or openwork items are fully accounted for in delivery documents, such as the VDD or delivery correspondence.

Handling Known Defects in the Delivered System

If the software is delivered with known defects:

1. Document the defects and their implications (e.g., risks to safety, security, or reliability).
2. Confirm customer approval of delivery despite these defects, noting any workarounds provided.
3. Highlight any critical risks in the SA report, particularly for defects affecting safety-critical operations, and (if necessary) recommend delaying delivery until risks are resolved.

Post-Delivery Follow-Up

Software assurance should ensure that the customer has the necessary records to operate and maintain the software. If necessary, provide oversight or audits for post-delivery changes or updates.

Conclusion

By following this improved guidance, software assurance ensures that the delivered software product is complete, verified, and ready for operations and maintenance. SA activities, including audits, metrics tracking, testing oversight, and risk analysis, provide transparency and confidence in the integrity of the delivery process. All findings must be clearly communicated to the project team to address potential issues promptly and ensure compliance with Requirement 4.6.3.

7.5 Additional Guidance

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

8. Objective Evidence