Fokus auf Wiederverwendbarkeit

In der Automobilindustrie wachsen die Komplexität der Softwarefunktionen und die geforderten Qualitätsnormen, wie z. B. CMMI und ISO 26262, weiterhin. Gleichzeitig werden immer kürzere Release-Zyklen erwartet. Zudem wandelt sich das Fahrzeug immer mehr zu einem intelligenten Gerät, das in der Lage ist, mit seiner Umgebung zu interagieren und autonom zu reagieren. Folglich erhalten weitere Aspekte, wie Sicherheit oder Datenschutz, eine höhere Priorität.

Dieses aktuelle Szenario ist ein gutes Beispiel für die häufig wechselnden und kaum vorhersehbaren Anforderungen der heutigen Automobilindustrie.

• Wer kann garantieren, dass die Funktionen, die heute als notwendig gelten, morgen noch in ähnlicher Form erforderlich sind?
• Was ist angesichts immer kürzerer Release-Zyklen ein angemessener Zeitrahmen für langfristige Strategien?

PERSIST (Powertrain Control Architecture Enabling Reusable Software Development For Intelligent System Tailoring / wiederverwendbare Antriebsstrang-Steuerarchitektur-Software-Entwicklung zur Gestaltung intelligenter Systeme) von FEV wurde gegründet, um vorläufige Antworten auf diese Fragen zu geben. Dieser Ansatz stellt agile Methoden bereit, die flexible Reaktionen auf Änderungen bei den Anforderungen ermöglichen. So lassen sich die Dauer eines Entwicklungszyklus reduzieren und die Qualitätsrisiken prognostizieren, die mit kontinuierlicher Integration verbunden sind.

Die Etablierung und die Pflege einer Software-Produktlinie (SPL) gehen im Arbeitsalltag eines Lieferanten mit mehreren gleichzeitig ablaufenden Projekten einher. Daher ist ein Ansatz erforderlich, der es den Projektteams erlaubt, sich auf die Implementierung des benötigten Produkts zu konzentrieren. Gleichzeitig müssen die Etablierung und die Pflege einer Software-Produktlinie mit minimalem Aufwand erfolgen. Durch gezielte Zusammenarbeit zwischen der agilen Softwareentwicklung (Agile Software Development, ASD) und dem Software-Produktlinien-Engineering (Software Product Line Engineering, SPLE) entsteht das leistungsfähige, agile Software-Produktlinien-Engineering (Agile Software Product Line Engineering, APLE).

Software-Produktlinien-Entwicklung mit Fokus auf die Anwendungstechnik

FEV hat eine SPL-Entwicklungsmethode entwickelt, die während der täglichen Projektarbeit wichtiges Feedback für die SPL zur Verfügung stellt und gleichzeitig die zusätzliche Projektarbeit auf ein Minimum reduziert. Die Methode erfordert keine langfristigen Entscheidungen, hält die SPL auf dem neuesten Stand und identifiziert neues Potenzial für wiederverwendbare Komponenten, falls erforderlich.

Die wichtigsten, in diesem Verfahren verwendeten, Entwicklungsartefakte sind die Referenzarchitektur, Projektarchitektur, Komponentenspezifikation, Testfälle und die Komponentenimplementierung. Die vorgeschlagene Methode folgt einem komponentenbasierten Project-First-Ansatz: Dies bedeutet, dass das wichtigste Element in der Software-Architektur eine Komponente ist, und dass alle Spezifikationen für eine Komponente zuerst während der Projektentwicklung definiert werden. Eine Komponente gilt nur als in allgemeinerer Weise neu entwickelt, wenn nachgewiesen werden kann, dass eine entsprechende Nachfrage vorhanden ist und eine allgemein genutzte Komponente eine realistische Möglichkeit in mehreren Projekten ist. AE (Application Engineering, Anwendungstechnik) wird den größten Nutzen aus einer bereits etablierten Produktlinie ziehen, und aus Komponenten, die gegenwärtig in verschiedenen Projekten entwickelt werden, ohne eine Verlangsamung durch die Abhängigkeit von allgemein genutzten Komponenten.

Schrittweiser Prozess

1 Im ersten Schritt wird eine neue Komponente mittels eines ersten Entwurfs der Schnittstelle mit der damit verbundenen funktionalen Beschreibung definiert.

2 Ihre Position in der Software-Architektur wird unter Berücksichtigung der SPL-Referenzarchitektur beurteilt. Komponenten sind bei PERSIST hierarchisch in einer Reihe von Anordnungen gruppiert. Wenn eine geeignete Komponente identifiziert werden kann, die der angegebenen Komponente scheinbar ähnlich oder mit dieser identisch ist, werden der Name und die Position der Komponente an die Referenzarchitektur angepasst. Dies ist der erste Schritt, in dem die SPL die Projektentwicklung unterstützt. Komplexe Architektur-Entscheidungen können oft durch frühere Erfahrungen unterstützt werden, die in der Referenzarchitektur gespeichert sind.

3 Wenn die Komponente nicht zugeordnet werden kann, muss eine spezifische Position in der Software-Architektur des Projekts definiert werden.

4 In diesem Schritt wird die Entscheidung aus Schritt 3 durch das SPL-Team neu bewertet, um falsch-negative Ergebnisse zu vermeiden.

5 Wenn die Komponente nicht zugeordnet werden kann, wird die vollständige Implementierung von Grund auf durchgeführt. Die neue Komponente wird der Referenzarchitektur hinzugefügt, nachdem ihre Position festgelegt wurde. Wenn die im Rahmen des Projektes spezifizierte Komponente einer Komponente zugeordnet werden kann, wird eine extrinsische Gleichheit in Bezug auf die Referenzarchitektur etabliert.

6 Diese Verbindung kann nicht nur verwendet werden, um die in der Entwicklung befindliche Komponente mit allgemein genutzten Komponenten der SPL zu vergleichen, sondern auch, um sie mit anderen einzelnen, extrinsisch gleichen Komponenten aus verschiedenen Projekten zu vergleichen.

Darüber hinaus können weitere Analysen hinsichtlich Struktur (Schnittstellen) und Semantik (Testfälle, Funktionsmodelle) durchgeführt werden.

7 Wird ein Kandidat mit einer Ähnlichkeit von weniger als 100 Prozent identifiziert, kann das Projektteam diesen zur Finalisierung der eigenen Spezifikationen verwenden, und die Implementierung kann auf den zur Verfügung gestellten Entwicklungsartefakten basieren.

Das Projektteam unternimmt keine zusätzlichen Anstrengungen zur Implementierung einer wiederverwendbaren Komponente, die in der Lage ist, die Anforderungen von beiden oder weiteren ähnlichen Komponenten zu erfüllen. Die identifizierten Ähnlichkeiten dienen nur zur Beschleunigung der Projektentwicklung.

8 In einem parallelen Schritt bewertet das SPL-Team, ob die identifizierten Ähnlichkeiten ausreichend Potential für eine allgemein genutzte, wiederverwendbare Komponente bieten. Basierend auf der Anzahl der ähnlichen Komponenten und dem Grad der Ähnlichkeit auf struktureller und semantischer Ebene muss eine Entscheidung darüber getroffen werden, ob die Komponente auf Grundlage einer ähnliche Komponente [7] zu implementieren ist oder ob mit Schritt [9] fortgefahren werden soll: Wenn das Potenzial hoch genug ist, wird das SPL-Team eine allgemein genutzte Komponente implementieren, die dann in weiteren Projekten wiederverwendet werden kann.

9 Die vorgeschlagenen Schritte gewährleisten, dass die Projektteams nur solche Komponenten spezifizieren, die so nahe wie möglich an der bereits etablierten Referenzarchitektur sowie an den verfügbaren Komponenten liegen. Im besten Fall können allgemein genutzte Komponenten direkt wiederverwendet werden. Darüber hinaus können alle Ableitungen von der Referenzarchitektur automatisch erkannt und der Grad der Variation bewertet werden. Somit können die potenzielle Degeneration einer etablierten Produktlinie kontinuierlich beobachtet und die Synchronisation zwischen Produkt und Produktlinie iterativ durchgeführt werden.

Bewertung

Die Aktivitäten 1 bis 5 sind bereits gut etabliert, die notwendige Automatisierung für die Aktivitäten 6 bis 8 befindet sich derzeit in der Finalisierungsphase. Allgemein genutzte Komponenten, die in mehreren Projekten verwendet werden, wurden zwar bereits etabliert, basieren jedoch immer auf intensiven manuellen Prüfungen oder einem proaktiven Ansatz. Die Möglichkeit, eine beliebige Referenzarchitektur während der Spezifikation einer neuen Komponente zu untersuchen, wird nicht als zusätzlicher Aufwand betrachtet. Vielmehr bietet die Referenzarchitektur hilfreiche Informationen für Architektur-Entscheidungen.
Gemäß dem aktuellen Status besteht die Referenzarchitektur aus 219 Komponenten, wobei 125 Komponenten (57 Prozent) kein extrinsisch gleiches Gegenstück haben. 94 Komponenten (43 Prozent) der Referenzarchitektur gehören zu mehr als einem Projekt und 61 dieser Komponenten (28 Prozent) sind ebenfalls Teil von mindestens drei Projekten.

Schlussfolgerung

Der vorgeschlagene Ansatz ermöglicht es, die projektorientierte Implementierungsarbeit direkt im Projekt zu realisieren, ohne dabei auf die Vorteile einer entsprechenden SPL zu verzichten. Jedes Projektteam kann von der etablierten Referenzarchitektur profitieren und seine Architektur-Entscheidungen somit beschleunigen, während die Ähnlichkeitsanalyse zusätzliche Grundlagen für die tatsächliche Implementierung bieten kann.