5 Methoden für Qualität bei hoher Komplexität

Steigende Komplexität stellt hohe Anforderungen an das Qualitätsmanagement. Das ist besonders dann der Fall, wenn es bei der Qualität um (funktionale) Sicherheit geht. Eingebetteten Systeme gehören zu der Klasse von Produkten, bei denen das eine hohe Herausforderung ist. Das liegt unter anderem daran, dass Software einer der Haupttreiber für Komplexität ist. Ein typisches Beispiel wäre ein im Fahrzeug verbautes Steuergerät.

Zu diesem Thema hat Prof. Peter Fromm von der Hochschule Darmstadt kürzlich eine Keynote gehalten. Im folgenden eine Zusammenfassung der wichtigsten Ideen, inklusive der Top 5 Methoden, die Qualität bei hoher Komplexität unterstützen.

Die Keynote mit dem Titel How to build a safe embedded system hielt Prof. Fromm dieses Jahr auf den SAEC-Days, bei der es um Qualität im Embedded-Umfeld geht. „SAEC steht für Safety & Security“, „Agile Testing“, „Embedded Testing“ und „Clean Code“. Hier die (sehenswerte) Keynote bei Youtube:

Die Keynote

Die Keynote beginnt mit der hier im Blog schon oft diskutierten Frage: Was macht Software so besonders? Das sind die folgenden vier Eigenschaften, die Software von elektronischen oder mechanischen Lösungen unterscheiden:

• Software ermöglicht das schnelle lösen von komplexen und abstrakten Problemen.
• Software ermöglicht Wiederverwendung.
• Software kann leicht geändert werden — auch im Einsatz.
• Kunden erwarten, dass Software billig (oder kostenlos) ist.

Beim Thema Qualität steht dementsprechend auch die Software im Mittelpunkt. Natürlich gibt es auch bei Mechanik und Elektronik potentiell Qualitätsprobleme. Dennoch: Wir haben über die Jahrzehnte gut funktionierende Ansätze für Qualität bei Mechanik und Elektronik entwickelt. Diese Ansätze funktionieren in der Regel und sind wesentlich weniger drastisch vom Komplexitätswachstum betroffen.

Good – Cheap – Fast: Pick Two

Es gibt verschiedene Parameter, did die Softwarequalität beeinträchtigen. Mit steigender Komplexität steigen auch die Anzahl der Bugs. Das trifft allerdings auch auf Änderungen zu. Andere Parameter sorgen für gute Qualität, zum Beispiel Erfahrung — oder auch nur die richtige Ausbildung! Ebenso werden mit der Zeit auch Bugs entdeckt und bereinigt, wodurch sich die Zeit positiv auf die Qualität auswirken kann.

Aber eine der wichtigsten Parameter ist eine gute Architektur, bzw. ein gutes Design als Fundament für die Entwicklung. In der Praxis finden wir jedoch hier leider viele Projekte, bei denen genau das fehlt, oft aus wirtschaftlichen Gründen: DAs Team beendete das Vorgängerprojekt im „Feuerwehr-Modus“ und hat nicht die Zeit und Ressourcen, um ein vernünftiges Fundament zu schaffen.

Funktionale Sicherheit

Kein Wunder, das Themen wie die Entwicklung eines Sicherheitskonzepts oft nachgelagert werden. Das liegt nicht nur am Ressourcenmangel: Oft fehlt zu Beginn des Projekts auch das Verständnis dafür, welches das Team sich erste während des Projekts erarbeitet. Wenn es dann soweit ist, das Sicherheitskonzept umzusetzen, müssten eigentlich fundamentale Aspekte von Design und Architektur ebenfalls angepasst werden. Genau das ermöglichen agile Ansätze. Doch diese mit strengen gesetzlichen Vorgaben unter einen Hut zu bringen ist nicht einfach.

TOP 5 Methoden für sauberen Code und Architektur

Um dieses Dilemma aufzulösen, greift Prof. Fromm auf Altbewährtes zurück: Denn diese 5 Methoden sind nicht neu. Aber sie sind wichtiger denn je, um die Herausforderungen von Komplexität und Qualität zu meistern. Diese sind:

Das „Skinny Sheep“ ist ein Bild von Ivar Jacobson. Die Idee dahinter ist mit dem MVP verwandt: Über ein minimales, aber funktionierendes System kann das Team die wichtigsten Projektrisiken entschärfen. Danach wird auf diesem Gerüst das System weiter ausgebaut, bis es vollständig ist. Bei diesem Ansatz haben wir im Prinzip eine ausführbare Architektur.

Kulturell besteht oft eine Kluft zwischen Hardware und Softwareteams. Doch für die Qualitätssicherung ist dies ein großes Problem. Ein konkretes Beispiel: Die Diagnose von Hardwareproblemen wird heutzutage zu großen Teilen in der Software realisiert. Doch auch in der anderen Richtung ist eine enge Zusammenarbeit wichtig: Die Hardware muss ebenso die Software überwachen, zum Beispiel mit einem eigenen Safetycontroller.

Prof. Fromm gab offen zu, dass die von ihm vorgestellten Design-Richtlinien aus den 1970ern stammen: Klare Verantwortlichkeiten, lose Kopplung, gute Namenskonventionen und Ähnliches mehr. Die Liste beginnt im Video ab Minute 31.

Das erinnerte mich sehr an den auch sehr betagten Security Code of Practice. In einer Keynote im Jahr 2018 lamentierte Haydn Povey, wie viel besser wir dran wären, wenn alle Entwickler diese 13 einfachen Regeln beachten würden.

Was für das Design gilt, sollte auch für den Programmcode gelten. Auch Code-Richtlinien gibt es schon seit vielen Jahrzehnten. Richtlinien ergänzen und unterstützen. Sie können weder einen guten Programmierer ergänzen noch Code-Reviews ersetzen. Dennoch: Programmier-Richtlinien sind unglaublich einfach einzusetzen und haben ein sehr gutes Kosten-Nutzen-Verhältnis. Außerdem können diese teilweise auch automatisch überprüft werden, zum Beispiel über statische Codeanalyse.

Damit sind wir wieder beim Anfang: Einer der größten Treiber für Qualitätsprobleme bei Software sind Änderungen. Weiterhin ist eine gute Architektur das Fundament für Qualität, insbesondere bei steigender Komplexität. Daher reicht es nicht, in der ersten Woche eine Architektur in einem Dokument zu skizzieren, die einen Tag später bereits veraltet ist.

Der von Prof. Fromm daraufhin vorgestellte Lösungsansatz heißt µRTE. Dabei handelt es sich um einen Architekturansatz mit Werkzeugunterstützung. µRTE wurde von Thomas Barth, einem Studenten am Lehrstuhl, auf Basis von Eclipse entwickelt. Die µRTE Webseite ist im Moment noch minimal, wird aber demnächst ausgebaut.

Wer sich für µRTE interessiert, kann sich das Video ab Minute 35 anschauen. Im Folgenden möchte ich allerdings auf die zugrundeliegende, werkzeugunabhängige Idee eingehen.

Ein ganzheitlicher Ansatz zur Entwicklung und Pflege der Systemarchitektur

Inspiriert wurde µRTE unter anderem von AUTOSAR, welches allerdings eher schwergewichtig ist. Die Ziele sollten sein:

• Wir brauchen ein ganzheitliches aber einfach verständliches Modellierungskonzept für Anforderungen, Hardware und Software.
• Im Fokus ist der Signalfluss auf Anwendungsebene.
• Die Laufzeitumgebung wird aus dem Modell heraus generiert.
• Das Modell ermöglicht die Generierung eines Teils der Dokumentation.
• Anspruchsvolle Änderungs- und Refaktoroperationen müssen unterstützt werden

Aus der Liste wird vielleicht klar, dass auch ein modernes Modellierungswerkzeug diese Fähigkeiten hat. Allerdings erfordert dabei der erste Punkt (einfach, verständlich) eine aufwändigen Anpassung.

Von SysML inspiriert

µRTE verwendet ein minimales Subset der SysML. Das folgende Diagramm vermittelt einen Eindruck von einem Top-Level funktionalen Modells. Natürlich verstecken sich hinter den einzelnen Blöcken und Ports noch weitere Schichten:

Die Idee, nur ein kleines Subset einer Modellierungssprache zu verwenden, ist nicht neu. Hier musste ich unmittelbar an Capella/Arcadia für das es eine eigene Gegenüberstellung zur SysML gibt.

Codegenerierung ermöglicht es, Softwareerosion Einhalt zu gebieten

Der Begriff Softwareerosion bezeichnet die schleichende Verschlechterung einer bestehenden Software. Wenn jedoch das Skelett der Software auf Knopfdruck mit der aktualisierten Architektur neu generiert werden kann, können wir die Erosion unterbinden. Im Video sehen wir, wie das mit µRTE funktioniert. Ich habe in der Vergangenheit selbst mit Codegenerierung aus Modellierungswerkzeugen gearbeitet. Wenn die Entwicklungsumgebung erst einmal richtig aufgesetzt ist, funktioniert das erstaunlich gut.

Aber das schöne an Modellen ist, dass wir nicht nur Code, sondern auch alle möglichen anderen Artefakte generieren können, allen voran die Dokumentation. Insbesondere bekommen damit alle wichtigen Stakeholder relevante, aktuelle Dokumente, insbesondere auch die Hardwareentwicklung. Das Modell beschreibt das ganze System und verwaltet die Aufspaltung in Hardware und Software.

Fokus auf Einfachheit ermöglicht Qualität bei hoher Komplexität

Der Charme von diesem Ansatz ist die Einfachheit und der klare Scope der Modellierung. Viele Ansätze, wie MagicGrid oder Capella/Acardia scheinen viele Anwender schnell zu überfordern. Darauf basierte mein Kommentar, dass SysML für die nächsten 10 Jahre ein Nischendasein führen wird.

Aber unabhängig davon haben viele Teams das Problem, dass sie die Architektur nicht pflegen. Und oft noch viel schlimmer: Dass sie die Architektur nicht kennen! Und darum geht es beim letzten (oder ersten) Punkt nicht um ein Werkzeug oder eine Methode. Sondern darum, die Architektur zu einem Entwicklungsartefakt erster Klasse zu machen. Das ist essenziell um Qualität und Komplexität unter einen Hut zu bekommen.

Image by Gerd Altmann from Pixabay