{"id":3289,"date":"2026-01-30T00:00:00","date_gmt":"2026-01-29T23:00:00","guid":{"rendered":"https:\/\/kunden.weissblaumedia.de\/microconsult\/2020\/03\/10\/tb_embedded-sw-redesign_teil3\/"},"modified":"2026-02-09T14:48:45","modified_gmt":"2026-02-09T13:48:45","slug":"tb_embedded-sw-redesign_part3","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/tb_embedded-sw-redesign_teil3\/","title":{"rendered":"Embedded Software Redesign Guide Part 3: Requirements and Checklist"},"content":{"rendered":"

Manchmal ist es nicht mehr damit getan, alten Code zu erweitern: Eine Rundumerneuerung muss her. Dieser Beitrag beschreibt Vorgehen rund um das Embedded-Software-Redesign und erl\u00e4utert dabei die Begriffe Reverse-Engineering, Refactoring und Reengineering.<\/strong><\/p>\n

Veranstaltungsformen wie Workshops eignen sich ideal, um mit den passenden Wissenstr\u00e4gern die Anforderungen zu erfassen und zu dokumentieren. Um Anforderungen aus dem Programmcode abzuleiten, existieren keine Tools am Markt. Hier ist manuelle Arbeit gefragt. Erfahrungsgem\u00e4\u00df ist es nicht m\u00f6glich, 100% aller in der Software implementierten Anforderungen zu erfassen.<\/p>\n

<\/p>\n

Zu den erfassten Anforderungen werden nun die zugeh\u00f6rigen Abnahmekriterien entwickelt und dokumentiert. Neben manchen UML-Tools eignen sich ALM- (Application Lifecycle Management) bzw. PLM- (Product Lifecycle Management) Tools wie z.B. IBM<\/a> DOORS zur Dokumentation der Anforderungen und Abnahmekriterien.<\/p>\n

\"Entscheidungshilfen<\/p>\n

Bild 4: Flowchart-Entscheidungshilfen f\u00fcrs Software-Reverse-Engineering, Teil 2<\/em><\/p>\n

Idealerweise l\u00e4sst sich auf Basis der Abnahmekriterien ein automatisierter und nachvollziehbarer Softwaretest durchf\u00fchren, um das nach au\u00dfen beobachtbare Verhalten der Software zu \u00fcberpr\u00fcfen. W\u00e4hrend des Software-Redesigns darf sich dieses Verhalten genauso wenig \u00e4ndern wie die Anforderungen und Abnahmekriterien. Als Kompromiss beschr\u00e4nkt sich das Reverse-Engineering in der Praxis h\u00e4ufig \u201enur\u201c auf die Erstellung der Software-Dokumentation.<\/p>\n

Sind die Voraussetzungen f\u00fcr ein erfolgreiches Embedded-Software-Redesign geschaffen, k\u00f6nnen Sie mit dem Software-Refactoring beginnen. Software-Refactoring verbessert die interne Softwarestruktur und Codierung der fertigen Software, ohne dabei das von au\u00dfen beobachtbare Verhalten zu ver\u00e4ndern.<\/p>\n

Man unterscheidet zwischen \u201ekleinem\u201d und \u201egro\u00dfem\u201d Refactoring. Ein kleines Refactoring bezeichnet \u00c4nderungen auf der Sourcecode-\/ Designebene, das gro\u00dfe ist f\u00fcr \u00c4nderungen auf der Architekturebene zust\u00e4ndig. Die Konsequenz eines gro\u00dfen Refactorings sind automatisch mehrere kleine Refactorings.<\/p>\n

\"Voraussetzungen<\/p>\n

Bild 5: Voraussetzungen f\u00fcr ein erfolgreiches Redesign mit Refactoring<\/em><\/p>\n

Wie bereits erw\u00e4hnt, darf sich die Embedded-Software nach einem Refactoring nach au\u00dfen hin nicht anders als zuvor verhalten. Dies sollte nach jedem Refactoring durch erneutes Ausf\u00fchren der unver\u00e4nderten Softwaretests \u00fcberpr\u00fcft werden. Erg\u00e4nzen Sie bitte erst nach einem erfolgreichen Refactoring neue Features.<\/p>\n

Das Vorgehen im Embedded-Software-Refactoring kann wie folgt aussehen.<\/p>\n

\"Embedded-Software-Refactoring\"<\/p>\n

Bild 6: Embedded-Software-Refactoring<\/em><\/p>\n

Unter Ber\u00fccksichtigung der Zieldefinition identifizieren Sie Refactoring-Potenziale, sogenannte \u201eSmells\u201c, in der Embedded-Software (siehe folgende Tabelle):<\/p>\n\n\n\n\n\n
Refactoring-Potenzial \u201eSmell\u201c<\/strong><\/td>\nRefactoring-Kategorie<\/strong><\/td>\nRefactoring-Auswahl<\/strong><\/td>\n<\/tr>\n
Large Method [3]<\/sup>
\n->Kleines Refactoring<\/td>\n		Simplify Conditional Expression [3]<\/sup><\/td>\nDecompose Conditional [3]<\/sup><\/td>\n<\/tr>\n
Betriebssystem-Portierung nicht m\u00f6glich
\n-> Gro\u00dfes Refactoring<\/td>\n		Architektur-Schichtenmodell erweitern<\/td>\nOSAL (Operating System Abstraction Layer) einziehen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Tabelle 1: Refactoring-Beispiele<\/em><\/p>\n

In vorgefertigten Refactoring-Katalogen finden Sie einzelne Refactorings in Kategorien unterteilt. Dort w\u00e4hlen Sie das f\u00fcr Ihr Problem passende Refactoring aus und implementieren es. Gerade in der Embedded-Software ist der Refactoring-Bedarf h\u00e4ufig sehr speziell, so dass Sie Ihre eigenen Refactorings und Kategorien selbst entwickeln m\u00fcssen.<\/p>\n

Ein moderner Programmcode-Editor wie Eclipse<\/a> oder dazu passende Plug-Ins unterst\u00fctzen bei der Refactoring-Implementierung. Dazu m\u00fcssen Sie den zu refaktorierenden Programmcode selektieren; eine Men\u00fcauswahl bietet Ihnen passende Refactorings an und setzt diese direkt bei der Auswahl um.<\/p>\n

Gro\u00dfe Refactorings setzen wir manuell in kleinen und geplanten Schritten um. Nehmen Sie \u00c4nderungen auf der Software-Codeebene vor, m\u00fcssen Sie meist auch die Unit-Tests adaptieren.<\/p>\n

Wichtig: In vielen F\u00e4llen l\u00e4sst sich erst w\u00e4hrend des Refactorings der Software bewerten und entscheiden, ob sie tats\u00e4chlich noch sinnvoll refaktoriert werden kann oder ob es nicht erfolgversprechender ist, die Software neu zu entwickeln.<\/strong><\/p>\n

Zusammenfassend unterteilt sich das Software-Redesign in ein optionales Reverse-Engineering, falls eines der daf\u00fcr ben\u00f6tigten Artefakte fehlt. Anschlie\u00dfend f\u00fchren Sie so lange Refactorings durch, bis Sie Ihr Ziel erreicht haben.<\/p>\n

Als weiterf\u00fchrende Quelle zum Thema Refactoring m\u00f6chte ich Martin Fowler nennen. Neben seinem Buch \u201cRefactoring<\/a>\u201d ist auch sein Refactoring Online Portal<\/a> empfehlenswert.<\/p>\n

\"Flowchart<\/p>\n

Bild 7: Flowchart zum Software-Redesign<\/em><\/p>\n

Sind alle Refactorings umgesetzt und die Embedded-Software verh\u00e4lt sich wie zuvor (Nachweis \u00fcber Softwaretests<\/strong>), dann m\u00fcssen Sie sp\u00e4testens jetzt die Software-Dokumentation<\/strong> anpassen. Nur so bleibt die Konsistenz der Embedded-Software-Artefakte erhalten.<\/p>\n

Profi-Tipp<\/strong>: \u00dcbertragen Sie die durchgef\u00fchrten Refactorings in Richtlinien<\/strong>, damit sich die gleichen Fehler nicht nochmals einschleichen. Abh\u00e4ngig vom Refactoring erg\u00e4nzen Sie damit zus\u00e4tzlich Ihre Architektur-, Design-, Modellier- und\/oder Codier-Richtlinien.<\/p>\n

Manchmal reicht ein Software-Redesign im Sinne von Reverse-Engineering und Refactoring nicht aus<\/h4>\n

Ein noch nicht ausgereiftes Entwicklungsvorgehen verursacht teilweise auch die Defizite der inneren Softwarequalit\u00e4t. In diesem Fall m\u00fcssen Sie das Entwicklungsvorgehen optimieren, was wir als Embedded-Software-Reengineering<\/strong> bezeichnen. Ein generischer Ansatz, dies zu tun, kann wie folgt dargestellt aussehen:<\/p>\n

\"Embedded-Software-Reengineering\"<\/p>\n

Bild 8: Embedded-Software-Reengineering<\/em><\/p>\n

Die Optimierungsziele ergeben sich aus den aktuellen Herausforderungen, die im Entwicklungsvorgehen nicht gel\u00f6st sind. Unternehmensabh\u00e4ngig ist das Entwicklungsvorgehen nicht dokumentiert. Oder es ist dokumentiert, wird aber durch die Mitarbeiter nicht oder unterschiedlich gelebt. Insbesondere in diesen F\u00e4llen sollten wir uns das tats\u00e4chliche Entwicklungsvorgehen bewusst machen.<\/p>\n

Danach hat jeder Beteiligte die gleiche Sicht auf das Entwicklungsvorgehen, und die zielbezogene Analyse ist durchf\u00fchrbar. Hierbei gilt es, die Ursachen f\u00fcr die Defizite zu finden. Um die Ursachen zu eliminieren, optimieren wir zielbezogen das Entwicklungsvorgehen.<\/p>\n

Nun muss sich das optimierte Vorgehen in der Praxis bew\u00e4hren. In einem Pilotprojekt wenden wir das optimierte Entwicklungsvorgehen an und verifizieren am Projektende, ob wir die urspr\u00fcnglich definierten Optimierungsziele erreicht haben. Wenn nein, m\u00fcssen wir einen weiteren Optimierungslauf mit einem n\u00e4chsten Pilotprojekt ausf\u00fchren.<\/p>\n

Haben wir unser Optimierungsziele erreicht, dann beginnen wir wieder mit der Definition neuer Optimierungsziele. Embedded-Software-Reengineering ist ein kontinuierlicher Prozess.<\/strong><\/p>\n

Checkliste: Wie l\u00e4sst sich ein n\u00f6tiges Redesign vermeiden?<\/h4>\n

Die Notwendigkeit von Embedded-Software-Redesigns l\u00e4sst sich mit folgenden Ma\u00dfnahmen effektiv minimieren:<\/p>\n