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.
When is it necessary to completely overhaul old code? Essentially, there are three criteria that can be used to assess whether a redesign makes sense. The roles responsible for this within the development process also ensure its quality.
The Process quality describes the maturity of the processes surrounding product development and is monitored by the process owner.
The external product quality This defines the quality of the product as perceived by the user or machine. Several roles, from the product manager to the board of directors, are responsible for this.
The internal product quality is known only to the development team itself and is the responsibility of the development manager.
Figure 1: The criteria of process quality, external product quality, and internal product quality influence when a software redesign makes sense.
Deficiencies in established and current embedded software
In most companies today, embedded software has evolved organically over many years or even decades through various developers, sometimes spanning multiple generations. It's not uncommon for developers to leave companies, taking with them the knowledge that wasn't preserved there. To make matters worse, in the past, most embedded software developers were trained electrical engineers, not (technical) computer scientists.
This results in a number of shortcomings in current and existing embedded software. Requirements, architecture, design, and documentation are often completely or partially missing, as are software (regression) tests. Furthermore, employees often lack a thorough understanding of the software's functionalities. In addition, the code contains numerous individual coding styles in various programming languages. As a result, software changes can lead to undesirable side effects.
One of the reasons for these shortcomings lies in the corporate and general market culture. A business approach that is successful in the short term operates quickly and cost-effectively, but rarely considers the future. If project management is rewarded with bonuses for short-term goals such as meeting deadlines and budgets, this effectively "punishes" development through high project pressure and makes achieving long-term goals, such as establishing quality standards, virtually impossible.
The reasons for this usually lie in management's lack of software understanding. This is particularly true for companies developing mechatronic systems, as their management typically comes from an engineering background. Often, these companies also lack general software development expertise. Development methodologies, tools, requirements, architecture, design, coding, and testing are unfamiliar concepts to those in charge.
With increasing software complexity and a growing number of embedded software developers (for example, through mergers and acquisitions), these shortcomings become even more significant. If software development is distributed internally or outsourced, ensuring the required quality levels becomes extremely difficult and requires considerable effort to guarantee long-term benefits for the company.
Triggers for embedded software changes
There are a number of reasons why embedded software needs to be revised and modified. Besides classic bug fixes and the integration of new features, new necessary software components, or changes to already integrated software components, technological market adjustments can also provide important impetus for further development; keywords include "Internet connectivity," "Artificial Intelligence," and "Industry 4.0.".
If, over time, it becomes apparent that the hardware computing power is insufficient, software distribution or a migration to multithreaded, multicore, or manycore processors may be considered. Cost savings or product discontinuations can also lead to changes in hardware components; new regulations may necessitate product certification.
Nothing stays the same. Employees change and bring new software paradigms (e.g., object-oriented instead of procedural) or a new programming language (e.g., C++ instead of C) to the team. Development, or parts of it, can also suddenly be outsourced to external suppliers, and functionalities can be integrated into purchased products.
To maintain external product quality in the long term, it is necessary on the one hand to improve internal software quality in order to design the software to be viable for the future, and on the other hand to improve process quality in order to ideally work faster, more cost-effectively and with higher quality.
The above-mentioned factors for modifying embedded software simultaneously trigger an embedded software redesign. Software redesign is the umbrella term for reverse engineering, refactoring, and reengineering, and refers to the approach of changing software and its development process.
________________________________________________________
The second part of the series This addresses the question of whether changes and extensions to the current software are very time-consuming or no longer possible without side effects. 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 2 „Recognizing the necessity“
Part 3 „Requirements and Checklist“
Further information
MicroConsult Training & Coaching on the topic of software quality
MicroConsult expertise on the topic of software quality
