Agile Software-Entwicklung mit ihren kurzen Entwicklungszyklen und der Konzentration auf die Ergebnisse hat einen Siegeszug durch die IT-Abteilungen angetreten. Start-ups und etablierte Unternehmen wissen die Vorteile der frühen und stetigen Auslieferung von Software und der engen Zusammenarbeit von Fachexperten und Entwicklern zu schätzen und setzen immer häufiger auf dieses Software-Entwicklungsmodell, mit grundlegenden Auswirkungen auf die Organisation und die Arbeitsweise ihrer Teams.

Die Entscheider stehen vor der Herausforderung, Agilität so umzusetzen, dass sie zu den unternehmenstypischen Ansprüchen an Planbarkeit und Budgetsicherheit passt. Agilität muss im Unternehmenskontext funktionieren. Vor dieser Herausforderung stehen Unternehmen auch, wenn es um die Entwicklung von Cyber-Physical Systems (CPS) geht. Denn agile Software-Entwicklung passt nur eingeschränkt zu den Herausforderungen, die CPS an Unternehmen stellen.

CPS sind Software-intensive Systeme, deren Architektur beziehungsweise Funktionalität deutlich komplexer und direkter mit den Abläufen der realen Welt verwoben ist, als dies bei klassischen Softwaresystemen der Fall ist. Denn je nach Aufbau und Einsatzzweck müssen CPS große Datenmengen nicht nur sauber erfassen, sondern auch eigenständig auswerten und anschließend die richtigen Maßnahmen einleiten. Eine Tatsache, die sich auch in ihren Entwicklungsprozessen widerspiegelt. Das Verständnis der Abläufe im eigenen Unternehmen und der Besonderheiten der eigenen Branche, das schon bei ­herkömmlichen Informationssystemen wichtig für den Projekterfolg und die Systemqualität ist, ist für CPS von noch zentralerer Bedeutung. Denn einen ‚Undo-Button‘ für die Realität gibt es nicht. Mögliche Fehler in einem CPS schlagen direkt durch in die physische Welt, wo sie möglicherweise irreversibel sind.

Herausforderung ­Zusammenarbeit

Eine weitere Besonderheit ist die Interdisziplinarität der Systementwicklung. Im Gegensatz zur klassischen Software-Entwicklung, in der die Fachseite häufig nur die Rolle des Auftraggebers für die IT-Seite einnimmt, und daher oft nur sporadisch in Entwicklungs- und Entscheidungsprozesse eingebunden wird, erfordern CPS eine kontinuierliche Zusammenarbeit mit den Fach- und Technologie-Experten aus den betrieblichen Anwendungsbereichen. So sind Ingenieure nicht nur Auftraggeber, sondern gleichzeitig auch als Konstrukteure für die physischen Komponenten des CPS verantwortlich. Sie tragen im Entwicklungsteam demnach dieselbe Verantwortung für den Projekt-Erfolg wie die Software-Experten.

Aufgrund der Anforderungen, die Cyber-Physical Systems mit sich bringen, empfiehlt sich – im Vergleich zu klassischen Softwaresystemen – eine angepasste Schwerpunktsetzung bezüglich des verfolgten Software-Entwicklungsparadigmas. Eigentlich ist der oben beschriebene hohe Grad an Abstimmungsnotwendigkeit zwischen Fach- und Technologieseite ein klarer Indikator für die Wahl eines agilen Prozessmodells. Denn agil bedeutet eine intensive Kommunikation zwischen allen Prozessbeteiligten, unabhängig von der Abteilungszugehörigkeit.

Gleichzeitig entwickeln agil arbeitende Teams früh im Prozess Prototypen, die Anwender beziehungsweise Kunden testen können. Diese frühe Verfügbarkeit spielt bei der erfolgreichen Entwicklung von CPS eine große Rolle: Das Testen des Zusammenspiels aller Komponenten, das Prüfen ihres Verhaltens unter außergewöhnlichen Bedingungen und insbesondere das Kalibrieren von Automatismen in teilautonomen Systemen hilft allen Beteiligten, funktionsfähige Lösungen zu entwickeln, die sich im Unternehmensalltag bewähren.

Aber: Agilität kommt bei Planung und Umsetzung von Cyber-Physical Systems an ihre Grenzen. So sind detaillierte Modelle und Spezifikationen bei der agilen Entwicklung nicht gänzlich unbekannt oder unbedeutend. Sie treten jedoch im Vergleich zu eher klassischen Entwicklungsmethoden, wie beispielsweise das Wasserfallmodell, in den Hintergrund. So heißt es schon im Grundlagenpapier der agilen Bewegung, dem ‚Agile Manifesto‘ aus dem Jahr 2001: „Funktionierende Software steht über einer umfassenden Dokumentation.“ Ein Punkt, der bei der CPS-Entwicklung zu Problemen führen kann.

Denn, und hier zeigt sich die Nähe von Cyber-Physical Systems zu eingebetteten Systemen, auch die präzise Modellierung des Verhaltens einzelner Komponenten spielt eine bedeutende Rolle. Gerade an den Schnittstellen zwischen physischer und digitaler Welt sind die Details entscheidend, insbesondere wenn hohe Zuverlässigkeitsanforderungen an die Steuerung von Aktoren gelten oder wenn die Korrektheit von Sensordaten kritisch ist. Das Gleiche gilt für die Rahmenbedingungen und Entscheidungsmechanismen in den Regelwerken teilautonomer Systeme. Das Entwicklungsteam muss die Komplexität der Cyber-Physical Systems und die Vielfalt der Situationen, in denen sie ­eigenständig Entscheidungen treffen sollen, in allen Facetten verstehen und gegebenenfalls auch verifizieren, um untolerierbare Zustände ausschließen zu können. Für diese Aspekte der ­Entwicklung empfiehlt es sich für die Verantwortlichen, auf eine detaillierte, unter Umständen sogar formal verifizierbare Spezifikation zu setzen.

Das interdisziplinäre Team aus Software-Entwicklern, Anwendern und Ingenieuren steht nun vor der Aufgabe, die Teile des CPS-Projektes zu identifizieren, die sich für den agilen Ansatz eignen beziehungsweise für die sich das klassische Vorgehen empfiehlt. Denn richtig verknüpft können beide Entwicklungsansätze die Entwicklung eines Cyber-Physical System voranbringen. Wie auch bei der Entwicklung klassischer Informationssysteme kommt der Wahl des angemessenen Agilitätsmaßes eine entscheidende ­Rolle zu.

Der 'Interaction Room'

Ein Instrument, das den Projektbeteiligten bei dieser Unterscheidung hilft und das gleichzeitig dafür sorgt, dass die Kommunikation innerhalb des interdisziplinären Teams effizient funktioniert ist der sogenannte ‚Interaction Room‘ (IR). Dabei handelt es sich um einen ‚echten‘ Projektraum, in dem die Teammitglieder regelmäßig zusammenkommen. Den vier Wänden dieses Raumes, den ‚Landkarten‘, kommt eine tragende Rolle zu. Auf ihnen dokumentieren die Beteiligten Geschäftsmodelle, Prozesse, Schnittstellen oder offene Punkte gut sichtbar und einfach verständlich. Die Projektmitglieder erkennen in dem Raum, was sonst nur schwer zu fassen ist: die Abhängigkeiten zwischen Prozessen, Daten und Anwendungslandschaften.

Eine Übersicht über einen Teil der Annotationen, die sich in die Modelle eintragen lassen

© Adessso

Ziel der Arbeit im IR ist es, auf Basis des gemeinsamen Verständnisses aller Beteiligten – unabhängig von Fachabteilung und Know-how – so früh wie möglich potenzielle Wert-, Risiko- und Komplexitätstreiber eines Projektes zu identifizieren. Hierzu setzt der IR eine intuitive Visualisierungsmethodik, sogenannte Annotationen ein (siehe Bild 1). Annotationen sind Symbole, die eine bestimmte Bedeutung besitzen und mit denen die Projektbeteiligten Zusatzinformationen in Modelle eintragen. So unterliegen manche Aspekte besonderen Sicherheitsanforderungen, andere besitzen algorithmische Komplexität oder werden gegebenenfalls nicht ausreichend verstanden. Allein die Verortung der Symbole in den Modellen durch simples Aufkleben der Annotationen hilft schon, kritische Punkte zu erkennen. Der eigentliche Erkenntnisgewinn durch die Nutzung des Interaktionsraums entsteht jedoch, wenn die Begründung des Experten, der die Annotation eingesetzt hat, diskutiert wird. Wesentlicher Bestandteil für das Herbeiführen eines gemeinsamen Verständ­nisses ist somit die Diskussion über unterschiedliche Einschätzungen. Dieses Bewertungsverfahren eignet sich auch für die Arbeit an CPS: Wie kritisch ist eine Schnittstelle? Welche Auswirkungen hätte der Ausfall eines Systemteils? Das so ermittelte Gesamtbild kann für die Experten die Grundlage für die Entscheidung sein, welche Bestandteile eines CPS agil und welche klassisch entwickelt werden sollten.

Um die potenziellen Auswirkungen des Ausfalls (oder Teilausfalls) eines Sensors oder Aktors zu untersuchen und um explizit zu verdeutlichen, ­inwiefern ein Ausfall kritisch wäre, sollte das Team bekannte Zuverlässigkeitstechniken wie ‚Failure Mode and Effects Analysis‘ (FMEA) oder ‚Failure Mode and Effects and Criticality Analysis‘ (FMECA) aus dem Umfeld der eingebetteten Software anwenden. Um ein CPS aufzubauen, das die entsprechenden Anforderungen erfüllt, können die Projektbeteiligten bei geringen Zuverlässigkeitsanforderungen womöglich agil entwickeln. So könnten die Verantwortlichen die Entscheidung treffen, bei der Entwicklung der Bedienoberfläche zur Darstellung der im CPS erfassten Daten auf ein agiles Modell zu setzen. Das hat den Vorteil, dass IT und Anwender schnell zu funktionierenden Gestaltungsansätzen und Lösungen kommen. Diese Bedienoberfläche ist zwar ein wichtiges Element des Systems, aber kein systemkritisches. Bei strikten Anforderungen, deren Nicht-Erfüllung mit hohen Risiken gekoppelt ist, wird womöglich die ­Verifikation der Systemeigenschaften nötig. Dann reicht eine rein agile ­Entwicklung nicht aus; die Updates der Systeme können allein wegen der erforderlichen Verifikation teuer werden.

Die Cyber-Physikalität eines Systems führt folglich nicht zwangsläufig zu weniger agiler Entwicklung, macht sie aber im Großen und Ganzen in geringerem Umfang zum alleinigen Mittel der Wahl. Pauschale Aussagen lassen sich hier kaum treffen, aber Tendenzen sind zu erkennen: Je näher ein CPS-Bestandteil an der echten Welt ist, desto eher sollten die Experten über klassische Entwicklungsmethoden nachdenken. Dieses „Verhaftet sein in der Physik“ schlägt durch in die Software-Entwicklung und macht hier exakte Spezifikationen notwendig. Im Umkehrschluss gilt, je weiter weg von der Physik, desto eher kann agil entwickelt werden. Dazwischen gibt es eine Grauzone von Komponenten, die die Experten detailliert im ‚Interaction Room‘ analysieren müssen.

Agile und klassische Software-Entwicklung

Das Ziel agiler Software-Entwicklung ist es, mit einem schlanken Entwicklungsprozess schlanke Software zu entwickeln. Das Konzept setzt auf die schnelle Entwicklung von lauffähiger Software, die regelmäßige Veröffentlichung von kleinen Releases und die Selbstorganisation von Teams. Eher Plan-orientierte Konzepte setzen darauf, dass Spezifikationen bereits zu Beginn des Projektes vollständig erfasst sind. Diese werden abgearbeitet, am Ende der Ent­wicklung wird ein Release mit allen neuen Funktionen veröffentlicht.

Beide Konzepte bringen für die Entwicklung von Anwendungen Vorteile: So ist es schlicht unrealistisch, dass das Projektteam bereits zu Beginn der Software-Entwicklung alle Anforderungen vollständig erfasst. Anpassungen die sich erst im Projektablauf ergeben, können nicht einfach außen vor bleiben. Auf der anderen Seite lässt sich vollständige Flexibilität nicht mit vorgegebenen Lieferterminen oder planbaren Budgets vereinbaren. Grundlegende Anforderungen an die Planbarkeit von Projekten müssen erfüllt sein, damit diese im Unternehmensumfeld überhaupt auf- und umgesetzt werden können. Um von den Vorteilen beider Ansätze zu profitieren, gilt es für die IT-Verantwortlichen, die Flexibilität der agilen Software-Entwicklung mit der planerischen Sicherheit zu kombinieren; sie müssen die Agilität zähmen.

Beispiel aus der Versicherungsbranche

Ein Beispiel aus der Versicherungsbranche

© Adesso

Diese Landkarte aus dem ‚Interaction Room‘ verdeutlicht den Einsatzzweck der Annotationen. Hervorgehoben sind die Annotation für Mobilität (Bedeutung: In der Zusammen­arbeit mit seinen Maklern sollte das Versicherungsunternehmen insbesondere dem mobilen Zugriff auf Daten Bedeutung schenken), Rahmenbedingungen (Bedeutung: Beim Übertragen von statistischen Daten an den Gesamtverband der Deutschen Versicherungswirtschaft muss das Versicherungsunter­nehmen darauf achten, die gesetzlichen Vorgaben bezüglich des Datenschutzes einzuhalten) und Sicherheit (Bedeutung: Bei der internen Weiterverarbeitung von Versichertendaten besteht noch Verbesserungsbedarf bezüglich der Datensicherheit).

Autor:
Prof. Dr. Volker Gruhn ist Vorsitzender des Aufsichtsrats bei Adesso.