Autoren: Achim Krallmann, Dr. Kai-Uwe Gawlik
Automobilhersteller geben Ihren Kunden heute ein einzigartiges Fahrerlebnis über ihre Marken von Premium-Segment bis hin zur Low-Cost-Variante. Qualität genießt einen hohen
Stellenwert, was auch die Software-Qualität einschließt. Die Anzahl der Lines of Code im Auto wächst kontinuierlich, da auch innovative Mechanismen, wie das autonome Fahren unterstützt werden. Softwarefehler verhindern heute die gesamte Produkteinführung. Dennoch geht es heute nicht mehr nur um die Software im Auto selbst.
Vielmehr gibt es bereits eine Vielzahl von Interaktionen des Autos mit Backend-Systemen, um im Problemfall Ersatzteile in Werkstätten vorzuhalten, die dem Fahrer über im Auto integrierte Online-Dienste vorgeschlagen werden. Kunden können über Apps und Internet Autos öffnen und schließen. Schon beim Kauf beginnt die Customer Journey als End-to-End Prozess mit der softwareunterstützten Konfiguration des Wunschfahrzeugs sowie der Unterstützung von Finanzierung oder Versicherung. Das Benutzer-Erlebnis und damit auch die dahinterliegende Software sind prozessorientiert und Fokus von Digitalisierung.
Nachhaltigkeit und die Grundeinstellung junger Generationen hinterfragen den Besitz von Autos. Autohersteller gehen auch hier den nächsten Schritt. Dem Kunden wird jetzt ein Mobilitätserlebnis gegeben. In der Frage, wie ich von A nach B komme, stehen Mechanismen wie die geteilte Nutzung von Fahrzeugen und auch Teiletappen mit
Bahn oder Flugzeug zur Verfügung. Selbst Hotelübernachtungen oder Taxifahrten werden einbezogen. Der Prozess selber wird als Service monetisiert. Hohe Komplexität der Prozesslandschaft durch steigende Anzahl von Business-Partnern und möglicher Schaden in digitalen Ökosystemen macht Software-Qualität noch bedeutungsvoller.
Weitere Innovation adressiert Geschäftsprozesse, in denen Automobilhersteller ihren Datenraum, der kontinuierlich wächst, monetisieren. Daten sind Bestandteil der Geschäftsprozesse von Business-Partnern der Autohersteller und haben mit der Automobilindustrie ggf. nicht mehr viel zu tun. Dennoch werden Cities durch Verkehrsführung smarter. Daten erlauben auch die Schaffung neuer Kontaktpunkte mit Kunden, welche eine Geschäftsbeziehung oder in einen Kauf aus einem der Bereiche Benutzer-, Fahr- bzw. Mobilitäts-Erlebnis oder den neuen datengetriebenen Geschäftsmodellen initiieren.
Der digitale Zwilling von prozessorientierten Systemen
In der Autoindustrie gibt es digitale Zwillinge, welche das zu bauende Fahrzeug digital als Design-Artefakt repräsentieren aber bereits Simulationen wie Crash-Tests auf dem Rechner erlauben. Korrekturen im Design können einfach, kostengünstig und ohne Bau von Prototypen erfolgen. Das Prinzip ist anwendbar auf die Software-Entwicklung:
- Digitaler Repräsentant: Prozessmodell im Sinne einer Syntax, welche Business und
Endkunden verstehen (Shift Left) - Simulation: Walkthrough, bei dem Daten durch das Prozessmodell verfolgt und das
Verhalten dokumentiert werden.
Das konsequente Anwenden dieser Vorgehensweise stiftet hohen Nutzen:
- Verschlankung der Anforderungen auf, das, was wirklich gebraucht wird (Angemessenheit)
- Automatische Generierung von Testfällen bis hin zur Automation Unterstützung der Agilität im Sinne von Behaviour Driven Development in der Sprache des Business
Um Diskussionsmöglichkeiten zu geben, werden Anforderungen in eine initiale Version geschäftsprozessorientierter Darstellung gebracht. Das kann auf der Ebenen von anwendungsübergreifenden End-to-End-Geschäftsprozessen oder auf anwendungsinternen Use-Cases erfolgen. Zusätzlich zum Ablauf werden erste Datensätze
(Eingaben und Ausgaben, schematisch dargestellt), deren Veränderung im Ablauf das Verhalten der Anwendungen repräsentieren und die im Test von Relevanz sind, im Ablauf festgehalten. Auf diese Weise entsteht im ersten Schritt die Dokumentation der Produktvision als initialer Wunsch mit eineindeutiger Versionierung.
Abstimmungen werden über die „Simulation” durchgeführt. Hierzu werden relevante Stakeholder aus Entwicklung, Betrieb und den Fachanwendern eingeladen, um den initialen
Wunsch in einem Workshop zu besprechen. Datensätze werden im Ablauf detailliert verfolgt, vervollständigt und ergänzt, als wäre die Anwendung bereits fertiggestellt. Dieses Vorgehen besitzt die folgenden Vorteile:
- Jeder Stakeholder bringt seine Interessen ein und reflektiert diese.
- Ein abgestimmtes Soll wird hergestellt, welches dem tatsächlichen Bedarf entspricht und sich vom reinen Wunschdenken selbstkritisch entfernt.
- Das Ergebnis beschreibt den Prozess vollständig inklusive des Verhaltens über die dokumentierten Datensätze.
- Im weiteren Verlauf der Entwicklung sind Rückfragen die reine Ausnahme.
- Eine eineindeutige Version der tatsächlich zu implementierenden Anforderung – der
digitale Zwilling – wird hergestellt. - Änderungswünsche in der Weiterentwicklung werden dann konsequent auf dieser
Version des Prozessmodells diskutiert und als fortgeschriebener digitaler Zwilling versioniert, was die agile, verhaltensorientierte Softwareentwicklung in der Sprache
der Fachanwender ermöglicht. - Gemäß unserer Erfahrung werden auf diese Weise Entwicklungskosten und –zeit bis
auf die Hälfte reduziert.
Der Vorteil dieses Vorgehens besteht darin, die Testfälle durch einfaches Verfolgen der Datensätze abzuleiten, da der Prozess diesbezüglich schon vollständig dokumentiert ist, insbesondere wenn die Qualitätssicherung als Stakeholder in die Abstimmungen von Beginn an aktiv mitwirkt. Bei entsprechend formaler Dokumentation können über ein Framework Testfälle automatisch generiert werden.
Der digitale Zwilling in der Werkzeugkette
Aus den bisherigen Überlegungen sollte deutlich geworden sein, dass die Umsetzung und Einführung dieser Vorgehensweise nicht von heute auf morgen bewerkstelligt werden kann. Es ist ein nachhaltigen und stringent geplanter Change Management Prozess aufzusetzen, mit all den bekannten notwendigen Inhalten, wie professionelle Kommunikation der Änderungen, Abholen und Einbinden der Mitarbeiter, Unterstützung durchs Top Management sowie die Einführung und Erprobung über Pilot Projekte. Dieser letzte Punkt soll nun der Ausgangspunkt für eine weitere Analyse der konkreten Umsetzung dienen. Ein Pilot Projekt stellt zwar die kleinste Einheit dar, an der eine Umsetzung stattfinden kann, nichtsdestotrotz müssen hier alle grundlegenden Fragen beantwortet sein, bzw. beantwortet werden.
Die Fragen lassen sich auf drei Dimensionen aufteilen:
- Welche Vorgehensweisen werden eingesetzt?
- Welche Methoden werden in welchen Disziplinen verwendet?
- Mit welchen Werkzeugen werden Vorgehen und Methoden unterstützt und verzahnt?
Im Folgenden soll die dritte Dimension, der Frage nach den Werkzeugen,
weiter analysiert werden. Dabei werden die beiden ersten Dimensionen
zwangsläufig mitberücksichtigt und in
die Diskussion mit eingebunden. Als Startpunkt soll die Abbildung “Werkzeuge” dienen, die eine typische Werkzeugsituation bei vielen Kunden abbildet. Die Abbildung ist schon optimiert auf die Bedürfnisse einer digitalen Transformation, insbesondere ersichtlich an den Schnittstellen zwischen den Werkzeugen.
Informationsablage durch modellbasierte Ansätze
In einem ersten Schritt ist zu überlegen, wie anfallende oder auch bereits bekannte Informationen aus einem Unternehmen (Anforderungen, Systeme, Schnittstellen, Geschäftsprozesse, Geschäftsobjekte, etc.) abgelegt werden sollen. Hier haben sich in den letzten Jahren modellbasierte Ansätze in den einzelnen Disziplinen immer mehr durchgesetzt.
In der Geschäftsprozessanalyse wird verstärkt die Modellierungssprache Business Process Model and Notation (BPMN) eingesetzt. Weitestgehend bekannt ist die Modellierung von Geschäftsprozesses mittels ereignisgesteuerter Prozessketten mit dem Werkzeug ARIS. Die Modellierungssprache Unified Modelling Language UML hat sich von einer reinen Sprache für die Modellierung von IT-Systemen schon lange emanzipiert und dient nun verstärkt für die Aufnahme und Dokumentation von Anforderungen (Modellbasiertes Requirements Engineering, siehe [2]).
Auch im Testmanagement kommen immer mehr UML-basierte Modellierungstechniken zum Einsatz (Modellbasiertes Testen, siehe [4]). In der Systementwicklung, insbesondere im Automotive Bereich und der dazugehörigen Definition von eingebetteten Systemen wird immer mehr auf einen Dialekt bzw. eine Spracherweiterung zur UML gesetzt: System Modelling Language (SysML). Jede dieser angesprochenen Sprachen definieren erst mal nur eine Syntax mit einer dahinterliegenden Semantik. Wie diese Sprachen in einem Projekt konkret einzusetzen sind, ist mit einer zusätzlich auszuwählenden Methodik genauer zu bestimmen. Zu jeder Sprache gibt es unterschiedliche Methodiken, die über Fachbücher einsehbar sind (siehe z.B.: [1], [5], [6]), aber letztendlich entscheidet ein Unternehmen für sich, welche Methodik mit welcher Sprache eingesetzt und für konkrete Bedürfnisse adaptiert wird.
Modellierungswerkzeuge
Bei dem oben beschriebenen Vorgehen gilt verstärkt, das auf modellbasierte Ansätze nicht verzichtet werden kann, und dies impliziert wiederum den Einsatz eines professionellen Modellierungswerkzeugs, welches dann die Heimat des Digitalen Zwillings ist. Alles, was einen Digitalen Zwilling ausmacht, ist im Modellierungswerkzeug abgelegt. Ein professionelles Modellierungswerkzeug unterscheidet sich im Vergleich zu häufig noch verwendeten Werkzeugen wie PowerPoint oder Visio neben vielen anderen Vorteilen
insbesondere um zwei Fähigkeiten, die hier von Interesse sind:
Bereitstellung einer offenen Schnittstelle mit Zugriff auf alle modellierten Daten, die in einer Datenbank abgelegt sind. Und die Möglichkeit, sich über ein sogenanntes AddIn in das Werkzeug einzuklinken. In der Abbildung Werkzeuge ist als Modellierungswerkzeug der Enterprise Architect der Firma Sparx Systems ausgewählt. Dieses Werkzeug hat eine offene Schnittstelle, die über eine .NET Api zugreifbar ist. Über diese Schnittstelle können alle modellierten Informationen abgerufen und auch geändert werden. Die Anlage von neuen Informationen ist auch möglich.
Der Digital Connector
Diese offene Schnittstelle nutzt nun der Digital Connector. Bei dem Digital Connector handelt es sich um Eigenentwicklung des Unternehmens Expleo, der als zentraler Knotenpunkt unterschiedliche Werkzeuge miteinander verbindet, um die Nachvollziehbarkeit (Traceability), Konsistenz und Kohärenz der Informationen zwischen den eingesetzten Werkzeugen sicherzustellen. Zusätzlich kann der Digital Connector dafür verwendet werden, neue Informationen oder Daten zu generieren. (Dies wird weiter unten an zwei Beispielen verdeutlicht.) Um diese zusätzlichen Funktionen aufrufen zu können, stellt der Digital Connector keine eigene Oberfläche zur Verfügung, sondern nutzt die oben erwähnte AddIn Funktion des Modellierungswerkzeugs: Der Digital Connector stellt eine Dynamic Link Library (DLL) bereit, die in den Enterprise Architect integriert wird. Mit dieser DLL werden zusätzliche Menüfunktionen direkt im Enterprise Architect für den Benutzer erreichbar, um damit den Digital Connector steuern zu können.
Die Funktion des Digital Connector
Mit dem Digital Connector kann nun eine Funktion abgebildet werden, die weiter oben im Zusammenhang mit dem Digitalen Zwilling angesprochen wurde: Die Verbindung von Prozessen mit Daten, um eine Simulation durchzuführen. Werden die Prozesse im Enterprise Architect mittels der Modellierungssprache BPMN und die Daten über Klassen und deren Instanzen (UML Konzepte) abgebildet, so kann über eine Funktion eine Simulation angestoßen werden, die zum einen prüft, ob die modellierten Geschäftsprozesse mit den Daten in sich stimmig, konsistent und vollständig sind und zum anderen können dann aus diesen Geschäftsprozessen über einen Algorithmus mittels Pfadabdeckung entsprechende Testfälle generiert werden.
Diese generierten Testfälle können als Word oder Excel Dateien erstellt werden. Professioneller ist es natürlich, die Testfälle direkt in ein Testmanagementwerkzeug zu importieren. Auch dieses leistet der Digital Connector, indem, wie in der Abbildung ersichtlich, das Testmanagementwerkzeug Application Lifecycle Management der Firma Micro Focus (früher HP-ALM) angebunden wird. Dieses Werkzeug stellt auch eine offene Schnittstelle zur Verfügung, die dann zur Generierung von Testfällen aus Geschäftsprozessen verwendet werden kann.
Zusätzlich kann dann bei der Generierung eine Verknüpfung zwischen Geschäftsobjekten und Testfällen vom Digital Connector erzeugt werden, sodass ein Anwender (z.B.: Business Analyst) aus dem Enterprise Architect von einem Geschäftsobjekt direkt in die zugehörigen Testfälle im ALM springen kann; oder ein Test Engineer direkt aus einem Testfall in den zugehörigen Geschäftsprozess im Enterprise Architect navigiert. Diese Methode der Testfallgenerierung beschränkt sich nicht auf Geschäftsprozesse, sondern kann auch auf ein Aktivitätsdiagramm, welches zu einem Anwendungsfall (Use Case) gehört, angewendet werden (siehe [2]). Als letztes soll das oben angesprochen Thema Agilität in den drei Dimensionen (Vorgehen, Methode, Werkzeug) verortet werden.
Im agilen Projektmanagement wird sehr häufig das Werkzeug Jira eingesetzt. Dabei wird dieses Werkzeug nicht nur für ein agiles Projektmanagement, sondern durch entsprechende Werkzeugerweiterungen, auch für das Anforderungs- und Testmanagement eingesetzt. Erfahrungen zeigen, dass diese Vermischung von unterschiedlichen Disziplinen in einem Werkzeug im Zusammenhang mit größeren Projekten nicht sinnvoll ist. Anforderungen sollten in einem Anforderungsmanagementwerkzeug, Testfälle in einem Testmanagementwerkzeug abgelegt und verwaltet werden.
Damit wird dann aber die Frage nach der Nachverfolgbarkeit zwischen den unterschiedlichen Informationen virulent. Auch hier hilft der Digital Connector, indem die offene Schnittstelle von Jira (in diesem Fall ein REST API, siehe Abbildung Werkzeuge) eingebunden wird, um somit zum Beispiel aus einem Anwendungsfall im Enterprise Architect ein Epic in Jira zu erzeugen und beide miteinander zu verknüpfen. Es obliegt dann dem agilen Team, dieses Epic in mehrere User Stories aufzuteilen und zu realisieren. In diesem Fall bleiben dann User Stories das, als was sie originär gedacht waren: Abzuarbeitende Arbeitspakete (siehe [3]).
Fazit
Die Realisierung eines Digitalen Zwillings in der Softwareentwicklung hängt sehr stark von den eingesetzten Werkzeugen und deren Verknüpfung ab. Dabei haben die Werkzeuge aktuell einen Stand erreicht, der kaum noch Wünsche offenlässt. Anders sieht es hingegen bei der Verknüpfung der Werkzeuge aus. Der Digital Connector muss hochgradig an unterschiedliche Unternehmenskontexte adaptierbar sein. Dabei sind die hier dargestellten
Prinzipien übertragbar auf andere Industrien.
LITERATUR
[1] J. Freud,B. Rücker: Praxishandbuch BPMN 2.0, Carl Hanser Verlag, 2014. [2] A. Krallmann, D. Dockter, A. Ritter: Modellbasiertes
Requirements Engineering, Entwickler Press, 2017 [3] A. Krallmann: Modellbasiertes Requirements Engineering – Geht das auch
agil?; ObjektSpektrum 03/2018 [4] T. Roßner, C. Brandes, H. Götz, M. Winter, Basiswissen modellbasierter Test, dpunkt.verlag, 2010
[5] C. Rupp: UML glasklar, Carl Hanser Verlag, 2012. [6] T. Weilkiens: Systems Engineering mit SysML/UML, d.punkt, 2014
[/sq_restrict_conten]
