Embedded-Software-Redesign Guide Teil 2: Notwendigkeit erkennen

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äutert dabei die Begriffe Reverse-Engineering, Refactoring und Reengineering.

Kundenunzufriedenheit sollte heute in jedem Unternehmen ein wichtiger Antrieb für Innovation sein. Bemerkt schon der Kunde Defizite bei der inneren Softwarequalität bzw. Prozessqualität, dann ist es kurz nach zwölf!

Never change a running system?

Sind Änderungen und Erweiterungen der aktuellen Software ohne Seiteneffekte sehr zeitintensiv oder nicht mehr möglich, ist dies ebenfalls ein klares Signal für ein Embedded-Software-Redesign. Das kann sich auch bei der Wiederverwendung in neuen Projekten zeigen, die sich als zu aufwendig oder als nicht mehr möglich herausstellt.

Ist die Software-Komplexität nicht mehr beherrschbar oder steigen die Fehler-Behebungszeiten, lohnt sich erst recht ein genauer Blick auf die innere Softwarequalität. Meist kommen einem jedoch unzufriedene Entwickler zuvor, denen die Produkt- und Prozessqualität der Embedded-Software immer wieder Schwierigkeiten bereitet. Augenscheinlich wird dies bei der Einarbeitung neuer Mitarbeiter, wenn diese die Software-Funktionalitäten schwer oder gar nicht verstehen. So kann ein unsteter Mitarbeiterstamm bereits viel über die Softwarequalität aussagen.

Das Vorhaben eines Embedded-Software-Redesigns ist ein eigenes Projekt mit Zielen, Zeiten, Kosten und Qualitäten, das als Ganzes die volle Aufmerksamkeit des Entwicklerteams benötigt und nicht neben dem Tagesgeschäft erledigt werden sollte. Für ein erfolgreiches Software-Redesign schafft man am besten im Vorfeld die richtigen Voraussetzungen.

Bild 2: Voraussetzungen für ein erfolgreiches Redesign

Idealerweise existieren zur aktuellen Embedded-Software die Anforderungen mit den dazugehörigen Abnahmekriterien und die Dokumentation zu Architektur, Design und Programmcode. Auch besteht im Idealfall eine durchgängige Konsistenz von Anforderungen über Programmcode bis hin zu den Tests. Alle Softwaretests sollten sich automatisch und nachvollziehbar mit dem Ergebnis „PASS” ausführen lassen.

Liegen diese zur Embedded-Software passenden Artefakte nicht vor, ist es ratsam, diese mittels eines Software-Reverse-Engineerings zu erstellen. Das meint meist eine ausführliche Dokumentation basierend auf Programmcode-Anforderungen, Abnahmekriterien, Architektur, Design, Programmcode und Test.

Bild 3: Flowchart-Entscheidungshilfen fürs Embedded-Software Reverse-Engineering, Teil 1

Im Vorfeld ist es ist wichtig, die Notation der Software-Dokumentation zu entscheiden. Hierzu eignet sich die UML (Unified Modeling Language) hervorragend, die sowohl für C- als auch für C++ Code mit prozeduralem oder objektorientiertem Programmieransatz anwendbar ist. Basierend auf dem Programmcode entsteht die Dokumentation in Form eines Softwaremodells. Praxisbewährte UML-Tools, wie beispielsweise der Enterprise Architect der Firma SparxSystems, erlauben es uns, Software zu modellieren und auch ein Reverse-Engineering durchzuführen.

Beim Reverse-Engineering liest das Tool bestehende Programmcode-Verzeichnisse ein und erstellt darauf basierend erste Strukturmodelle. Daraus erkennt man den Modul- bzw. Klassenaufbau und die Include-Pfade. Manchmal ist das Spinnennetz der Include-Pfade dominierend, so dass Module/Klassen nur noch schwer erkennbar sind. Je dichter das Spinnennetz, desto höher das Optimierungspotential in Architektur und Design. Hier sollte man manuell „entflechten“. Ablaufdiagramme (z.B. Zustandsfolge- oder Aktivitätsdiagramme) müssen jedoch weiterhin händisch erstellt werden.

Wichtig: In vielen Fällen lässt sich erst während oder nach der Erstellung der Software-Dokumentation bewerten und entscheiden, ob die Software tatsächlich noch sinnvoll redesigned werden kann oder ob es nicht erfolgversprechender ist, die Software neu zu entwickeln.

_____________________________________________________

Der erste Teil der Beitragsreihe widmet sich der Frage, wann es nötig ist, alten Code komplett zu überarbeiten, und betrachtet die Kriterien Prozessqualität, äußere Produktqualität und innere Produktqualität. Im dritten Teil wird unter anderem beleuchtet, wie sich mit den passenden Wissensträgern die Anforderungen erfassen und dokumentieren lassen.