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.
Wann ist es nötig, alten Code komplett zu überarbeiten? Im Wesentlichen gibt es drei Kriterien, durch die sich einschätzen lässt, ob ein Redesign sinnvoll ist. Ihre Qualität sichert zusätzlich die dafür verantwortlichen Rollen im Entwicklungsvorgehen:
Die Prozessqualität beschreibt die Reife der Prozesse rund um die Produktentwicklung und wird vom Prozessverantwortlichen überwacht.
Die äußere Produktqualität definiert die Qualität des Produktes, die der Benutzer/Anwender oder die Maschine wahrnimmt. Dafür verantwortlich sind gleich mehrere Rollen vom Produktmanager bis hin zum Vorstand.
Die innere Produktqualität ist nur der Entwicklung selbst bekannt und wird vom Entwicklungsleiter verantwortet.
Bild 1: Die Kriterien Prozessqualität, äußere Produktqualität und innere Produktqualität beeinflussen, ab wann ein Software-Redesign sinnvoll ist.
Defizite bei gewachsener und aktueller Embedded-Software
In den meisten Unternehmen ist Embedded-Software heute über viele Jahre oder sogar Jahrzehnte durch unterschiedliche Entwickler und teilweise über mehrere Entwickler-Generationen gewachsen. Nicht selten haben Entwickler Unternehmen verlassen und das dort nicht konservierte Wissen mitgenommen. Erschwerend kommt hinzu, dass in der Vergangenheit die meisten Embedded-Softwareentwickler ausgebildete Elektrotechniker und keine (technischen) Informatiker waren.
Daraus ergibt sich eine Reihe von Defiziten in aktueller und gewachsener Embedded-Software. So fehlen Anforderungen, Architektur, Design und Dokumentation der Software oft gänzlich oder teilweise, ebenso wie Software-(Regressions-)Tests. Auch das Verständnis bei Mitarbeitern über die Software-Funktionalitäten ist in vielen Fällen nicht vorhanden. Dazu kommen beliebig viele individuelle Coding-Styles in unterschiedlichen Programmiersprachen im Code. Software-Änderungen führen so zu unerwünschten Nebeneffekten.
Eine der Ursachen für diese Defizite liegt in der Unternehmens- und in der generellen Marktkultur. Ein kurzfristig erfolgreiches unternehmerisches Vorgehen arbeitet schnell und kostenoptimiert, hat jedoch kaum gleichzeitig die Zukunft im Blick. Wird die Projektleitung durch Erfolgsprämien für kurzfristige Ziele wie Einhaltung von Zeit und Kosten belohnt, entspricht das einer „Bestrafung” der Entwicklung durch hohen Projektdruck und macht das Erreichen langfristiger Ziele, wie z.B. die Etablierung von Qualität, so gut wie unmöglich.
Die Gründe dafür liegen meist im mangelnden Software-Verständnis des Managements. Insbesondere trifft das auf Unternehmen zu, die mechatronische Systeme entwickeln, da dort das Management meist aus dem Konstruktionsbereich stammt. Nicht selten fehlt in diesen Unternehmen auch ein generelles Fachwissen in der Softwareentwicklung. Entwicklungsvorgehen, Tools, Anforderungen, Architektur, Design, Codierung und Tests sind den Verantwortlichen fremd.
Mit wachsender Software-Komplexität sowie einer steigenden Anzahl der Embedded-Softwareentwickler (zum Beispiel durch Unternehmenszusammenschlüsse) fallen diese Defizite nochmal ins Gewicht. Wird die Softwareentwicklung unternehmensintern verteilt oder durch Outsourcing ausgelagert, lassen sich die Qualitätsebenen nur noch mit hohem Aufwand so sichern, wie es die Software verlangt, um dem Unternehmen langfristig Vorteile zu bringen.
Auslöser für Embedded-Software-Änderungen
Es gibt eine Reihe von Anlässen, die dazu führen, dass Embedded-Software überarbeitet und verändert werden muss. Neben der klassischen Fehlerbehebung und der Einarbeitung neuer Features, neuer notwendiger Softwarekomponenten oder Änderungen bei bereits eingebundenen Softwarekomponenten können auch technologische Marktanpassungen wichtige Impulse für die Weiterentwicklung geben; Stichwort „Internetanbindung”, „Künstliche Intelligenz” und „Industrie 4.0”.
Stellt sich im Laufe der Zeit heraus, dass die Hardware-Rechenleistung unzureichend ist, kommt eine Softwareverteilung beziehungsweise eine Migration nach Multithreaded, Multicore oder Manycore in Frage. Kosteneinsparungen oder Abkündigungen können ebenfalls zu Änderungen von Hardwarekomponenten führen; neue Regularien erfordern eine Notwendigkeit der Produktzertifizierung.
Nichts bleibt so, wie es mal war. Mitarbeiter wechseln und bringen neue Softwareparadigmen (z.B. objektorientiert statt prozedural) oder eine neue Programmiersprache (z.B. C++ statt C) mit ins Team. Auch kann die Entwicklung oder Teile davon plötzlich an externe Zulieferer und Funktionalitäten in Zukaufprodukte ausgelagert werden.
Um langfristig die äußere Produktqualität zu erhalten, braucht es einerseits die Verbesserung der inneren Softwarequalität, um die Software tragfähig für die Zukunft auszulegen, und andererseits die Verbesserung der Prozessqualität, um idealerweise schneller, kostengünstiger und qualitätssteigernder zu arbeiten.
Die oben aufgeführten Impulse für eine Änderung der Embedded-Software sind gleichzeitig Trigger für ein Embedded-Software-Redesign. Software-Redesign ist der Überbegriff für Reverse Engineering, Refactoring und Reengineering und meint den Ansatz der Veränderung von Software und deren Entwicklungsvorgehen.
________________________________________________________
Der zweite Teil der Beitragsreihe widmet sich der Frage, ob Änderungen und Erweiterungen der aktuellen Software ohne Seiteneffekte sehr zeitintensiv oder nicht mehr möglich sind. Im dritten Teil wird unter anderem beleuchtet, wie sich mit den passenden Wissensträgern die Anforderungen erfassen und dokumentieren lassen.
Mehr lesen
Embedded-Software-Redesign Guide:
Teil 2 „Notwendigkeit erkennen“
Teil 3 „Anforderungen und Checkliste“
Weiterführende Informationen
MicroConsult Training & Coaching zum Thema Softwarequalität
MicroConsult Fachwissen zum Thema Softwarequalität
