(Embedded) Software Maintenance: How Can You Optimize the Effort?

• Software is used and must be maintained over a long period of time today (e.g. due to its high complexity, redeveloping it from scratch is often not realistic).
• A great deal of expertise is embedded in the software (source code) and is not documented anywhere. This means that if the software were to be redeveloped, this knowledge would have to be rebuilt from scratch.
• Today, maintenance is often necessary or desirable while the software is in use.
• The effort required for maintenance often increases steadily over time, and in some cases even exponentially. As a result, the effort and duration of updates become so great that the software can no longer be used effectively. Therefore, the goal should be to achieve efficient maintenance that minimizes this increase in effort.

• Bug fixes
• Security issues
• Outdated software components (e.g., operating systems: does anyone still know Windows CE?)
• New features (new functionality)
• New regulatory requirements/standards
• “Modernization” (e.g., state-of-the-art user experience)
• Performance improvements (improvement of a feature, general software performance, e.g., latency, throughput)
• Discontinued electronic components and issues with component availability and supply
• Cost optimization (e.g., using more affordable hardware components in embedded software)
• Preserving the value of the development/product, as maintenance is often more cost-effective than new development
   

• Scope of functionality: products with a narrower scope of functionality are easier to maintain
• Maintenance-intensive functionality: for example, features involving connectivity are costly to maintain due to cybersecurity concerns
• Knowledge management
• Documentation
• Traceability (requirements, bugs, design, tests)
• Knowledge transfer (e.g., training new developers)
• Software quality (functional and non-functional)
• Development costs vs. product costs: for example, hardware resource usage (cost-optimized vs. hardware reserves)

• How long will my product be on the market?
• Requirements regarding maintenance, e.g., security requirements under the CRA (Cyber Resilience Act)?
• How important is the scalability of my software?

Decisions regarding these points should take maintenance into account:

• Minimalism: implement only the functionality that is actually needed
• Documentation: offers many opportunities, but also carries significant risks! Therefore, it should be planned carefully, and a shared understanding should be developed
  • How much documentation makes sense?
    • It is important to find a good balance: without documentation, knowledge cannot be preserved. However, too much documentation hinders efficiency.
    • During maintenance, the documentation must always be kept up to date.
    • If the accuracy of the documentation isn’t guaranteed, it won’t be used.
  • What should be documented?
    • Often, details of the software being developed are described. However, this information can often be easily extracted from the current code (especially today with the help of AI). Therefore, background information such as rationale (why a particular solution was chosen) and contextual details (e.g., design decisions) is more useful.
  • Where and how can documentation be created?
    • Separate documents (text, diagrams such as UML)
    • Comments in the source code
    • Meta-information in version control (e.g., detailed information in Git commit logs)
• Software Architecture
• Resource Optimizations
  • RAM, ROM, computation time/processor load, interface bandwidth usage: Is there room for expansion?
• Software Quality (Functional): Reducing maintenance by avoiding errors
  • Reviews (focus on correct functionality)
  • Test strategy: Planning what, how, and when to test
    • Full tests vs. regression tests?
    • Manual vs. automated?
    • Test coverage according to the chosen strategy
• Software Quality (Non-Functional)
  • Reviews (focus on non-functional aspects such as readability and extensibility)
  • Refactoring (code as well as architecture)
  • Automated code analysis (making quality measurable, for example, using cyclomatic complexity)
  • AI (Artificial Intelligence)-generated code: Plan the use of AI and continuously review and improve maintainability
• Simple deployment
• Development tools
  • For example, will I still be able to obtain the licenses in the future?

Maintenance is a good area of application for AI (Artificial Intelligence); it can assist with the following tasks:

• Analysis of existing software
• Creating missing documentation with the help of AI
• Refactoring / technical debt
  • First, increase test coverage with AI so that correctness can be better verified after refactoring
  • Identifying code that is no longer needed
  • Code reviews

• How much longer will my product remain on the market?
• Changes to maintenance requirements, e.g., security in accordance with the CRA (Cyber Resilience Act)?
• What is currently making maintenance difficult?
  • And then act on those difficulties
• Are there any issues or risks regarding the licensing of development tools or software components?

• Reducing complexity: Removing functionality that is no longer relevant
• Software architecture: Refactoring
• Continuous code cleanup
  • Removing old, unused code
  • Maintaining/improving code readability
  • Redesign; e.g. cleaning up any „quick fixes” and workarounds
• Adjustments, changes to development tools (e.g. switching to state-of-the-art tools)
• Employ experienced and competent developers