Context:

Re-using software from previous projects can offer significant cost savings, schedule advantages, and risk reduction. However, if the re-used software:

1. Is not a good match for the program requirements, or
2. Is not fully understood due to missing or incomplete feasibility studies,

then the benefits of re-use are lost, and additional risks are introduced to the program. Re-used software often requires modifications, adaptations, and a deep understanding of existing functionality, interfaces, quality, and compliance with mission goals.

When re-used software fails to meet the mission or is not appropriately assessed, it creates risks such as misaligned functionality, unexpected failures, and increased costs due to late-stage rework or replacement.

Key Risks of Poorly Matched or Insufficiently Vetted Re-Used Software

1. Misalignment with Mission Goals or Requirements

• Issue: Software selected for re-use may not completely meet the requirements of the current mission, leading to misaligned functionality or gaps in capability.
• Risk to Program:
  • Functionality gaps make the software unsuitable for fulfilling mission-critical requirements, leading to program redesign or additional software development.
  • Programs expend effort modifying the software, introducing complexity, unintended bugs, or excessive schedule delays.

2. Compatibility Issues

• Issue: Re-used software may be developed using hardware, operating systems, or interfaces that are no longer compatible with the proposed mission environment.
• Risk to Program:
  • Integration problems, such as data transfers, timing issues, or hardware mismatches, cause software malfunctions in the target system.
  • Expensive customizations are needed to make the software compatible with modern platforms, adding time and cost.

3. Poor Understanding of Legacy Software

• Issue: When feasibility studies are incomplete, programs may lack sufficient understanding of the re-used software’s internal workings, design, limitations, dependencies, and maintenance history.
• Risk to Program:
  • Teams encounter unanticipated issues during testing or implementation.
  • Undocumented features, shortcuts, or legacy defects emerge during mission-specific use cases, jeopardizing reliability.
  • Debugging becomes time-consuming due to a lack of adequate documentation or expertise in the original software.

4. Inheriting Legacy Defects or Risks

• Issue: Re-used software brings pre-existing defects, design flaws, cybersecurity vulnerabilities, or other risks that were either accepted or unaddressed in the original program.
• Risk to Program:
  • Critical defects emerge during verification or operation, requiring significant late-stage fixes.
  • Security vulnerabilities persist, potentially exposing mission-critical systems to attack.

5. Overestimated Modifiability

• Issue: Assumptions are made that re-used software requires “minimal modifications,” but feasibility studies fail to reflect the actual effort or resources needed for necessary adjustments.
• Risk to Program:
  • Modifying the software becomes expensive, complex, and time-intensive, negating the cost-savings benefit of re-use.
  • Delays to delivery schedules as teams struggle to reconfigure, refactor, and test software updates.

6. Non-Compliance with Standards

• Issue: Re-used software may not comply with updated standards, guidelines, or regulations (e.g., NASA-STD-8739.8, NPR 7150.2, safety-critical standards like DO-178C).
• Risk to Program:
  • Projects fail audits or milestone reviews due to insufficient alignment to modern safety assurance or certification requirements.
  • Rewriting large portions of the software may be required to bring it into compliance, causing schedule delays.

7. Unrealistic Expectations for Maintainability

• Issue: Re-used software may be poorly documented or use outdated development practices, making it difficult to maintain, modify, or enhance for the proposed mission.
• Risk to Program:
  • Programs face increased maintenance costs post-launch.
  • Teams struggle to apply hotfixes or updates for mission extensions, jeopardizing operational continuity.

8. Testing Coverage Gaps

• Issue: Without feasibility assessments, it may not be clear whether re-used software was tested rigorously for its intended use (e.g., real-time control, fault tolerance, safety-critical operations).
• Risk to Program:
  • Gaps in testing coverage lead to untested failure conditions, such as extreme performance scenarios or mission-critical edge cases.
  • Latent defects emerge after system-level integration, risking mission success.

9. Integration Risks with New Subsystems

• Issue: Re-used software may experience unanticipated challenges when integrated with new subsystems built for the current mission’s objectives.
• Risk to Program:
  • Integration failures (e.g., inconsistent interfaces, timing conflicts, or interoperability issues) increase costs and cause delays.
  • Late-stage system-wide testing efforts are overburdened by defect resolution.

10. Loss of Stakeholder Confidence

• Issue: If the proposed software re-use strategy is implemented poorly, stakeholders may lose confidence in the program's readiness and cost efficiency.
• Risk to Program:
  • Stakeholders challenge the program’s ability to meet milestones, increasing oversight requirements or imposing additional constraints.
  • Repeated failures from re-used software could impair the organization’s long-term credibility.

Root Causes of Poor Matches or Missing Feasibility Studies

1. Inadequate Initial Assessments:
   • Programs fail to perform rigorous trade studies or engineering assessments to evaluate re-use viability.
2. Misaligned Requirements:
   • Software selected for re-use was designed with requirements that differ significantly from the current mission.
3. Lack of Expertise:
   • Teams lack familiarity with legacy software, development tools, or prior documentation.
4. Overconfidence in Re-Use:
   • Pressure to save cost/time leads to optimistic assumptions about feasibility without thoroughly analyzing re-use challenges.
5. Oversight of Hidden Dependencies:
   • Dependencies such as environmental constraints, hardware compatibility, code quality, or safety requirements are overlooked.
6. Unavailability of Legacy Documentation:
   • Programs inherit software without detailed technical documentation, feasibility studies, or lessons learned from prior projects.
7. Evolving Standards or Priorities:
   • The software that matched historical program goals no longer aligns with updated standards, risks, or best practices for the current mission.

Mitigation Strategies

1. Conduct Rigorous Feasibility Studies

• Before committing to software re-use, perform detailed assessments to evaluate:
  • Fit for Purpose: Alignment of software functionality with mission-specific requirements.
  • Resource Requirements: Effort, cost, and schedule for adapting re-used software.
  • Risk Assessment: Identify risks, legacy flaws, or gaps in testing.
• Use feasibility studies to create a cost-benefit analysis for re-use versus new development.

2. Perform Gap Analysis of Requirements

• Compare the original requirements of re-used software with the mission goals to identify any gaps early.
• Ensure the analysis is well-documented and signed off by key stakeholders.

3. Validate Compatibility

• Assess re-used software compatibility with modern platforms, including:
  • Operating systems
  • Hardware environments
  • Interfacing systems and subsystems
  • Communication protocols
• Identify and mitigate mismatches during the feasibility stage.

4. Mandate Reverse Engineering for Legacy Understanding

• For poorly documented software:
  • Use reverse engineering techniques to understand the source code, dependencies, and architectural design.
  • Update legacy software documentation to improve clarity.

5. Perform Risk-Based Testing on Re-Used Software

• Require targeted regression and stress testing on re-used software to evaluate performance under real-world mission scenarios.
• Create test cases addressing mission-critical edge cases, failure modes, and safety risks.

6. Incorporate Certified Software Assurance Practices

• Require re-used software to comply with NASA assurance standards (e.g., NASA-STD-8739.8) before adoption.
• Engage independent software assurance teams to assess legacy software for safety-critical systems.

7. Include Plans for Updates and Maintenance

• Identify the modifiability and technical debt of re-used software, creating plans to address:
  • Bug fixes
  • Long-term maintainability
  • Real-time patches during operations

8. Engage Experts on Original Software

• Consult teams or individuals with knowledge of the original software's design, testing history, and constraints.
• Gather lessons learned and performance data to make informed decisions about re-use feasibility.

9. Avoid Over-Reliance on Re-Use

• If feasibility assessments reveal substantial gaps in functionality, compatibility, or quality:
  • Pivot to re-engineering or building new software components.
• Resist the urge to prioritize cost savings over long-term mission risks.

10. Establish a Re-Use Review Board

• Create a governance structure for re-used software, responsible for:
  • Approving feasibility studies and trade-offs.
  • Assessing program impacts of using re-used versus new software.
  • Enforcing program-wide standards for software re-use.

Consequences of Poor Software Re-Use Decisions

1. Mission Delays:
   • Time-intensive modifications increase schedule risks, impacting planned milestones.
2. Cost Overruns:
   • Additional testing, re-engineering, and adaptations nullify expected savings from re-use strategies.
3. System Failures:
   • Critical mission failures occur due to latent defects, compatibility failures, or gaps in testing.
4. Loss of Stakeholder Trust:
   • Confidence in the program diminishes due to perceived inefficiencies or repeated re-use issues.
5. Compromised Safety:
   • In human-rated missions, re-used software introduces safety risks that could jeopardize lives and assets.

Conclusion:

Re-using software can provide significant benefits, but it must be approached with care through rigorous feasibility studies, gap analysis, and adherence to modern certification standards. Programs should prioritize understanding the nuances of legacy systems, ensuring that they align with current mission goals and compliance requirements. By investing in early-stage analysis and testing, programs can mitigate risks, maximize re-use benefits, and ensure both mission success and stakeholder confidence.

3. Resources

3.1 References