LBC Software Handover

The ideal handover scenario includes planning, presentation, training, a build/run exercise and a support agreement with the developer.
The non-ideal handover scenario includes a lot of reverse-engineering.

LBC Software Handover is the non-ideal scenario. INAF individuals are very involved with the hardware, but the software individual is mostly unavailable. There is a lot of documentation available, but it has not been kept up-to-date.


Planning for a handover should include
  • Assigning responsible individuals for handover process (both sides)
  • Identifying handover materials (designs, ICDs, as-built updates, etc.)
  • Preparing presentation by the current responsible engineer(s)
  • Preparing for documentation and code transfer
  • Plan for a build exercise
  • Plan for a runtime exercise
  • Factor any continuing support


The current responsible engineer should provide a presentation to the LBTO responsible engineer that includes:

  • Software Overview
    • Requirements
    • Use Cases
    • Reference Documentation
    • Development Metrics (LOC, overall complexity, etc.)
  • Design Concepts
    • Software Architecture and Strategy
    • 3rd party products and interfaces
    • Communications Strategy
    • Languages/Scripts
    • User Interface (GUIs)
    • Performance / Design Contraints
  • Build/Run-time Concepts
    • Source Control
    • Makefiles, scripts
    • Configuration files
    • Start/Stop/Monitoring tools
    • Logging / Analysis concepts


  • Documents Review / Feedback / Questions
  • Build Exercise
    • Source Management / Extraction
    • Build
    • Deploy/Install
  • Runtime Exercise
    • Start/Stop
    • Monitoring logs, errors, and performance
    • Post-run analysis (ensure performance and products are as expected)
  • Engineering Tools?
  • Test/Debug Procedures & Tools?
  • Simulation capabilities?
  • Off-Line Data Analysis Tools?

Reverse Engineering

Reverse engineering exercises should be avoided whenever possible
  • Prone to errors and misunderstandings
  • Often leads to loss of functionality, code breakage, or “frozen” software.

But, when needed (i.e. lack of a better option):
  • Determine what documents are available
  • Determine what is good, vs. what is unreliable/bad
  • Perform a Code Review and derive:
    • Architecture, interfaces, critical comm, 3rd party products, languages used, GUIs, etc.
    • Implemented Requirements and Use Cases
  • Attempt to Access (if possible) Original Expertise
  • Develop Risk Mitigation strategy for keeping original release working while getting ready for new build/release.

System Administration

  • Identify all accounts and logins
  • Identify all equipment makes, models, OS, and versions
  • Document how computers were set up and configured
  • 3rd party interfaces/equipment
  • Installed programs/packages
  • Required Licenses & Maintenance agreements
  • Periodic procedures (cron jobs) identified


Port mapping, Switch map, Etc.

As-built Network Architecture diagram

Internal equipment
Connectivity to backbone


Strategy and vendors

This topic: Software > WebHome > LBCSoftwareHandover
Topic revision: 19 Oct 2018, YangZhang
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback