Reengineering: Software neu organisieren

Wenn Software im Lauf von Jahren immer weiterentwickelt wird, hat dieses organische Wachstum oft zur Folge, dass das Programmpaket allmählich unübersichtlich wird. Die Software funktioniert zwar noch in weiten Umfängen, aber es werden unter Umständen nicht mehr benötigte Algorithmen mitgeschleppt, unerklärliche Fehler treten auf und für neue Mitarbeiter ist der ursprüngliche Quellcode kaum noch nachvollziehbar. Irgendwann können keine neuen Funktionen mehr integriert werden, ohne dass es zu Fehlern kommt.

In Fällen dieser Art hilft eine Codeanalyse allein nicht mehr weiter und die Daimler-Forscher machen sich an das sogenannte Software-Reengineering, also die Neuorganisation ganzer Programme. „Dabei schauen wir das Bestehende an und entwickeln daraus das Gute weiter“, umschreibt Bernhard Hohlfeld die Arbeit seiner Abteilung Software-Strukturen und nennt als Beispiel die elektronische Differenzschlupfregelung (DSR) bei Bussen und den Mercedes-Benz-Trucks Atego, Axor und Actros. Mithilfe der Differenzschlupfregelung wird anhand der Raddrehzahlen die Achslastverteilung errechnet und die Bremskraft optimal verteilt.

Umbau nach 20 Jahren

Für Hohlfeld und seine Mitarbeiter gab es in Sachen DSR gleich mehrere Anlässe, das Softwarepaket aufzuschnüren und neu zu strukturieren. Zum einen war die 1987 im Actros eingeführte DSR-Software im Lauf der Jahre „gewachsen“ und sollte nun neu geordnet werden, um sie künftig besser warten und erweitern zu können. Ziele waren eine höhere und kostengünstige interne Wiederverwendung, die Reduktion von Fehlerrisiken und schließlich ein schnelleres Erweitern um neue Zusatzfunktionen. Hinzu kam, dass die Nutzfahrzeugentwickler einen zweiten Zulieferer wünschten, dem man das Know-how klar strukturiert zur Verfügung stellen wollte.

„Bei diesem Projekt entfernten wir einige Softwareelemente aus dem Paket. Den Großteil der Funktionalität aber haben wir beibehalten und neu strukturiert“, berichtet Steffen Görzig. „Bei einem solchen Softwareumbau wollen wir ja nicht das Rad neu erfinden, sondern bewährte Algorithmen in eine tragfähige Form überführen und so dokumentieren, dass sie auch für neue Mitarbeiter nachvollziehbar ist.“

Hilfe für Entwickler

Dass die Arbeit der Forscher bei ihren Kollegen in der Nutzfahrzeugentwicklung auf fruchtbaren Boden fällt, zeigt die Differenzschlupfregelung. „Mit Hilfe der Softwareexperten aus der Forschung ist es uns möglich, die aktuelle Seriensoftware in kleine, klar überschaubare Teile zu trennen. Dadurch können wir uns verstärkt auf den Kern der Anwendung, konkret die Funktions­weiterentwicklung – unabhängig von der Hardware – konzentrieren. Dies stellt einen wichtigen Beitrag zur effizienten Weiterent­wicklung mit geringerem Fehlerrisiko dar“, sagt etwa Entwicklungsingenieur Stephan Reichle aus der Abteilung „Brake and Chassis Electronics“ in der Lkw-Entwicklung.

Ziel der Forscher ist es, durch Reengineering saubere Softwarearchitekturen zu schaffen. Bisher erfolgt ein solcher Programmumbau meist in einem späten Stadium, in dem die Strukturen oft schon sehr unübersichtlich sind und nach einem hohen Einsatz an Zeit und Personal verlangen. Die Teams in der Abteilung von Bernhard Hohlfeld arbeiten deshalb auch an Methoden, mit denen sich das Reengineering zumindest ein Stück weit automatisieren lässt. „Unser Wunschbild“, sagt Steffen Görzig mit einem Augenzwinkern, „ist der Softwareumbau auf Knopfdruck.“