EN 
DE 
Sometimes simply extending old code isn't enough: a complete overhaul is needed. This article describes the process of embedded software redesign and explains the concepts of reverse engineering, refactoring, and reengineering.
Customer dissatisfaction should be a key driver of innovation in every company today. If customers notice deficiencies in internal software or process quality, then it's almost too late!
Never change a running system?
If changes and extensions to the current software are very time-consuming or no longer possible without side effects, this is also a clear indication for an embedded software redesign. This can also become apparent when reusing the software in new projects, which turns out to be too complex or no longer feasible.
If software complexity becomes unmanageable or bug fix times increase, a closer look at the internal software quality is all the more worthwhile. However, dissatisfied developers often anticipate these issues, as they repeatedly encounter problems with the product and process quality of the embedded software. This becomes apparent during the onboarding of new employees, when they struggle to understand the software functionalities or don't understand them at all. Thus, a fluctuating workforce can reveal a great deal about the software's overall quality.
An embedded software redesign is a project in its own right, with its own goals, timeline, costs, and quality standards. It requires the full attention of the development team and should not be handled alongside daily tasks. Creating the right conditions beforehand is essential for a successful software redesign.
Figure 2: Prerequisites for a successful redesign
Ideally, the requirements for the current embedded software, including the corresponding acceptance criteria, and documentation for the architecture, design, and program code exist. Ideally, there is also complete consistency from requirements through program code to testing. All software tests should be able to be executed automatically and traceably with a "PASS" result.
If these artifacts suitable for the embedded software are not available, it is advisable to create them using software reverse engineering. This usually means comprehensive documentation based on program code requirements, acceptance criteria, architecture, design, program code, and testing.
Figure 3: Flowchart decision aids for embedded software reverse engineering, Part 1
It is important to decide on the notation for the software documentation beforehand. The following is suitable for this purpose: UML (Unified Modeling Language) Excellent, applicable to both C and C++ code with procedural or object-oriented programming approaches. Based on the program code, the documentation is created in the form of a software model. Proven UML tools, such as the Enterprise Architect from [Company Name], are used. SparxSystems, allow us to model software and also to perform reverse engineering.
During reverse engineering, the tool reads existing program code directories and creates initial structural models based on them. This reveals the module and class structure and the include paths. Sometimes the spiderweb of include paths is so dense that modules and classes become difficult to identify. The denser the spiderweb, the greater the optimization potential in architecture and design. In such cases, manual unbundling is recommended. However, flowcharts (e.g., state sequence or activity diagrams) still need to be created manually.
Important: In many cases, it is only during or after the creation of the software documentation that it can be assessed and decided whether the software can actually be meaningfully redesigned or whether it is more promising to develop the software from scratch.
_____________________________________________________
The first part of the series This addresses the question of when it is necessary to completely revise old code and considers the criteria of process quality, external product quality, and internal product quality. third part Among other things, it will examine how requirements can be identified and documented with the help of suitable knowledge holders.
Go to calendar view
Embedded software redesign guide:
Part 1 „Deficits and Triggers“
Part 3 „Requirements and Checklist“
Further information
MicroConsult Training & Coaching on the topic of software quality
MicroConsult expertise on the topic of software quality
