5 Dinge, die Systems Engineers frühzeitig und häufig machen sollten

Selbstverständlich gibt es noch mehr als die im Folgenden beschriebenen Dinge, die Systems Engineers durchführen müssen. Aber hier geht es um einfache Dinge, die mit wenig Aufwand greifbare Ergebnisse liefern („Low-hanging Fruit“). Auch sind die hier aufgeführten Dinge taktischer Natur: Sie können eingeführt werden, oder dass drastische Änderungen an Prozessen, Methoden oder Werkzeugen durchgeführt werden müssen.

1. Frühzeitig und häufig Reviews durchführen

Reviews können in drastischer Weise Entwicklungsrisiken senken und die Qualität erhöhen. Der Aufwand dafür hält sich sehr in Grenzen, wenn wir ehrlich sind.

Zugegeben, in der Vergangenheit waren Reviews nervig. Als noch dokumentenbasiert gearbeitet wurde, waren diese sehr unbequem, aufwändig und nervig: Oft wurden Dokumente per E-Mail verschickt, und es war schwierig, die Reviewergebnisse zusammenzuführen. Das lief dann oft auf stundenlange Reviewmeetings hinaus.

Die Softwareentwicklung hat schon lange gezeigt, dass konsequente Reviews möglich sind und auch funktionieren. Versionsverwaltung für Code macht dies möglich. Längst gibt es auch Werkzeuge wie Gerrit ermöglichen auch verteilte Reviews mit einem automatisierten Prozess. Dies funktioniert, da nur die Änderungen überprüft werden.

Ich habe schon Ende der 90er im kommerziellen Umfeld gearbeitet, wo konsequent jeder neue Code gereviewed wurde.

Doch auch bei anderen Artefakten ist ein systematischer Review möglich. Selbst mit Word, auch wenn hier schnell die Grenzen erreicht werden (bei mehr als 2-3 Seiten wird es kritisch, die Vergleichsfunktion ist einfach zu schlecht).

Doch für ernsthaftes Systems Engineering werden normalerweise datenbankbasierte Systeme verwendet, und mit diesen lässt sich dann auch ein vernünftiger Reviewprozess aufsetzen. Eines der besten Reviewsysteme für Anforderungen das ich kenne ist Teil von Jama Connect, doch auch andere Anforderungsmanagementwerkzeuge ermöglichen es, effizient Reviews durchzuführen. Selbst im Bereich der Modellierung gibt es inzwischen Lösungen. Mit Hilfe von LemonTree kann man bspw. Stände von Enterprise Architect-Modellen vergleichen und sich beim Review auf die Änderungen fokussieren.

2. Traceability früh anlegen und häufig pflegen

Nachverfolgbarkeit ist ein mächtiges Werkzeug im Systems Engineering. Doch um sie zu nutzen, müssen wir ihr vertrauen. Und um ihr zu vertrauen muss sie gepflegt werden. Sobald die Traceability nicht mehr vertrauenswürdig ist, hören wir auf sie zu nutzen. In diesen Teufelskreis dürfen wir gar nicht erst hineingeraten!

Zu häufig hatte ich gesehen, dass die Traceability während der Enwicklung nicht genutzt und dann erst zum Projektende für die Compliance nachgepflegt wurde. Was für eine Verschwendung!

Hier gibt es leider keine Patentlösung, um diese Aktivität einzufordern. Die Lösung ist auch zum Teil werkzeugabhängig. Sinnvolle Taktiken sind:

• Sicherstellen, dass die verwendeten Werkzeuge das Anlegen, Pflegen und Nutzen der Traceability nutzerfreundlich unterstützen
• Die Traceability leicht nutzbar machen, zum Beispiel über ein Dashboard, dass Lücken in der Abdeckung zeigt
• Von Anfang an eine aktuelle Traceability einfordern und klarstellen, dass ein falscher oder fehlender Trace ein ernsthafter Bug ist

Wenn die Mitarbeiter den Wert der Traceability erkennen, die Benutzbarkeit einfach ist, dann wird die Traceability auch gepflegt.

3. Frühzeitig und häufig integrieren

Gerade bei komplexen Systemen tauchen leider viele Probleme erst bei der Integration auf. Je früher integriert wird, desto besser. Auch diese Technik stammt aus der Softwareentwicklung, wo Continuous Integration (CI) schon seit vielen Jahren praktiziert wird.

Zwar ist frühzeitige Integration nicht ganz so einfach, wenn Hardware involviert ist, doch auch hier gibt es Taktiken:

• Produkte enthalten immer mehr Software. Selbst wenn auf Hardwareebene nicht frühzeitig integriert werden kann, so kann zumindest auf Softwareebene integriert werden
• Die Produktion von Prototypen wird günstiger und vor allem schneller, was für die Integration auf Hardwareebene benutzt werden kann.
• Hardware kann emuliert oder simuliert werden.

Auch hier hilft es nach der Motivation für die Integration zu fragen. Und die ist oft, um testen zu können. Daher die nächste Technik:

4. Frühzeitig und häufig Tests schreiben

Tests zu schreiben (durchführen kommt später) hilft, die zu testenden Inhalte zu schärfen. Bei Schreiben der Tests fallen oft schon Unklarheiten oder Widersprüche auf. Auch dieser Ansatz kommt aus der Softwareentwicklung, wo es den Test-First-Ansatz gibt. Diese Aktivität setzt natürlich voraus, dass auch getestet wird, wovon ich im Systems Engineering einmal ausgehe. Laut V-Modell gibt es auf jeder Entwicklungsebene Tests.

Weiterhin hilft das Schreiben der Tests auch bei der Planung der Integration: Wenn der Testexperte einen Integrationstest frühzeitig definiert, dann kommt möglicherweise eine Rückmeldung, die die Integration leichter macht, oder sogar Testaktivitäten von der Integrationsebene auf die Komponentenebene verschiebt.

5. Frühzeitig und häufig Tests durchführen

Eine wichtige Aufgabe von CI ist das durchführen von Tests. Denn letzten Endes bekommen wir nur durch das häufige durchführen von Tests auch die Rückmeldung, wo wir nachbessern müssen. Testdurchführung hat auch eine weitere Aufgabe: Sie gibt uns das Selbstbewusstsein, dass auch nach Änderungen das System wie erwartet funktioniert.

In der Hardwareentwicklung ist es nicht ganz so leicht, häufig zu testen. Doch hier können wir uns zunutze machen, dass sich Hardware wesentlich langsamer ändert als Software. Wenn es erst einmal Hardware gibt, auf der Tests durchgeführt werden können, so kann diese für Testläufe nach Softwareänderungen genutzt werden. Das funktioniert in der Regel nur, wenn automatisiert wird. Wie das funktionieren kann, hat Andreas Willert in einem Interview eindrucksvoll beschrieben.

Photo by Charlotte Coneybeer on Unsplash