Effizientes Arbeiten mit einer standardisierten Sprache

Veröffentlicht am: 12 Mai 2023

Autor:

Nieke Roos

Chefredakteur bei Bits&Chips

Lesen Sie mehr über Nieke Roos

Experte:

Eric Burgers

Trainer

Lesen Sie mehr über Eric Burgers

Aktie

---

Bei Neuentwicklungen wenden Ingenieure oft bewährte Designs an, mit oder ohne kleine Änderungen. Warum gelingt es ihnen dann immer noch nicht, die von den Kunden geforderten Lösungen zu liefern? In der Regel ist die Kommunikation der größte Stolperstein. Der Trainer des High Tech Institute , Eric Burgers, erklärt, wie SysML dabei hilft, Designideen für komplexe Systeme erfolgreich zu kommunizieren. Eric Burgers unterrichtet den Kurs Einführung in SysML und Systemmodellierung mit SysML.

Im Idealfall beginnt ein Projekt mit perfekten Anforderungen: eindeutig, spezifisch und präzise, und gerade ausreichend, um das zu lösende Problem zu beschreiben, mit genügend Raum für Kreativität und Innovation. Die Entwürfe, die diese Anforderungen erfüllen, sind vollständig, spezifizieren die Dekomposition, das Verhalten und die Zusammenarbeit vollständig und sind in jeder Hinsicht 100 Prozent konsistent und testbar. Letztendlich wird ein System geliefert, das den Anforderungen entspricht und den beabsichtigten Zweck erfüllt.

In einer Albtraumversion geht ein Projekt von inkonsistenten oder widersprüchlichen Anforderungen aus, die Formulierungen wie „das System wird … erleichtern“ oder „zu … beitragen“ enthalten. Die Grenzen des Systems sind schwer zu definieren. Das Ganze wird in vage Komponenten zerlegt, z.B. in (Kategorien von) Geräten oder sogar in beliebige Gruppen von „Dingen“. Das gewünschte Verhalten, wenn es denn spezifiziert ist, scheint vom Design getrennt zu sein oder ist faktisch unvollständig und lässt viel Raum für Interpretationen. In der ultimativen Albtraumversion eines Projekts wird ein System gebaut, das nicht auf dem eigentlichen Design basiert. Mängel werden behoben, indem eine Notiz nach der anderen angehäuft wird, so dass die Entwurfsdatei ein absolutes Durcheinander ist. Nur wenn alles in der richtigen Reihenfolge gelesen wird, kann der eigentliche Entwurf abgeleitet werden.

Boehms zweites Gesetz der Technik: Während eines Softwareprojekts steigen die Kosten für das Finden und Beheben von Fehlern mit der Zeit.

Die meisten Projekte sind keine kompletten Albträume, aber sie sind auch nicht ideal. Die erstellten Entwürfe erfüllen nicht immer alle Anforderungen und können Inkonsistenzen, Auslassungen oder andere Fehler enthalten. Diese Fehler sind eine potenzielle Quelle für Fehlerkosten: Fehler, die während der Anforderungsanalyse oder des Entwurfs eingeführt werden, sind umso teurer zu beheben, je später sie behoben werden. Und das, obwohl sie hätten vermieden werden können.

Dies wirft einen Konflikt auf: Entwürfe sollen das Risiko verringern, dass falsche oder fehlerhafte Systeme gebaut werden. Dennoch werden bei Projekten sehr oft Entwürfe erstellt, die die Anforderungen des Kunden nicht widerspiegeln und damit den gesamten Zweck eines Entwurfs zunichte machen. Warum ist das so und was kann man dagegen tun?

Bottom-up-Ansatz

Projekte gibt es in allen Formen und Größen und lösen einfache bis schwierige Probleme. Relativ einfache, kleine Projekte sind nicht allzu schwierig zu realisieren. Das Risiko des Scheiterns steigt, wenn ein Projekt komplexer wird. Die Komplexität eines Projekts hängt mit der Komplexität (in Bezug auf Größe oder Schwierigkeit) des herzustellenden Produkts und der Größe des Unternehmens zusammen, das das Projekt durchführt.

Große(re) Projekte sind oft in disziplinspezifischen Entwicklungsgruppen organisiert. Diese Gruppen besprechen zwar ihre Schnittstellen miteinander, aber es gibt in der Regel keinen übergreifenden Ansatz, der beschreibt, wie alle Komponenten in ein funktionierendes Ganzes integriert werden können. Manchmal hat es sogar den Anschein, dass Schnittstellen ad hoc erstellt werden.

Dies hat alle Züge eines Bottom-up-Ansatzes, bei dem disziplinspezifische Teile zunächst entworfen und produziert und dann zusammengesetzt werden, in der Hoffnung, ein funktionierendes Produkt zu erhalten. Ein solcher Ansatz kann bei weniger komplizierten Projekten funktionieren, bei denen die Ingenieure das gesamte Produkt mit all seinen Details verstehen können. Wenn sich jedoch Teile durch ihr Verhalten oder ihre Eigenschaften gegenseitig beeinflussen können, kann es schwierig sein, abzuschätzen, wie sich das Ganze verhalten wird, insbesondere wenn die Bausteine aus unterschiedlichen Disziplinen stammen.

Die Risiken der zunehmenden Komplexität

Zeichnungen

Eine Möglichkeit, große, komplexe Projekte zu bewältigen, ist die Erstellung umfangreicher Dokumentationen, um die Designideen an alle beteiligten Ingenieure weiterzugeben. In technischen Bereichen wie dem Maschinenbau, dem Software-Engineering, der industriellen Automatisierung und dem Bauwesen gibt es dafür oft standardisierte Verfahren. In der Praxis wird die Dokumentation durch Zeichnungen ergänzt, die mit gängigen Tools wie Powerpoint oder Visio (Windows) oder Omnigraffle (Mac OS) erstellt werden. Darüber hinaus wird Excel für den Austausch großer Informationsmengen verwendet.

Bei multidisziplinären Projekten werden zunehmend ergänzende Zeichnungen und andere projektspezifische Hilfsmittel verwendet, um die Kluft zwischen den Disziplinen zu überbrücken. Daran ist im Prinzip nichts auszusetzen. Der Transfer von Designideen und Informationen zwischen den Disziplinen ist dringend erforderlich. Ohne die Überbrückung der interdisziplinären Lücken wird ein Projekt auf ernsthafte Integrationsprobleme stoßen. Allerdings bedeutet „projektspezifisch“ auch, das Rad immer wieder neu zu erfinden, vor allem wenn die Arbeit von Konsortien geleistet wird, die von Projekt zu Projekt wechseln.

Ein weiteres Problem bei diesen Zeichnungen ist, dass es keine allgemeine Vereinbarung darüber gibt, was sie darstellen sollen. Außerdem gibt es keine Garantie dafür, dass sie vollständig und konsistent sind. Daher besteht die Gefahr, dass die Zeichnungen, obwohl sie für den Autor klar sind, von den Lesern falsch interpretiert werden, was wiederum zu Mängeln am Produkt führt, die erst in späteren Phasen des Projekts entdeckt werden.

Sehr oft werden diese Arbeitsweise und die damit verbundenen Integrationsprobleme einfach akzeptiert. Wenn sich das Projekt dem Abschlusstermin nähert, werden die Probleme durch Nacharbeit oder Flickschusterei gelöst, oder sie werden einfach als „zukünftige Arbeit“ im Projekt belassen. Ein alternativer Ansatz besteht darin, die Kommunikation von Design-Ideen auf Projekt- oder sogar Unternehmensbasis zu standardisieren. Dies hat den Nachteil, dass die Konventionen „lokal“ für das jeweilige Projekt sind – jeder Teilnehmer muss sie lernen.

Es ist sinnvoller, einen Industriestandard zu übernehmen, einschließlich der unterstützenden Tools. Dann müssen die Konventionen nur einmal erlernt werden, um sie unabhängig vom Projekt oder der Organisation immer wieder anwenden zu können. Umso besser, wenn der Standard es ermöglicht, Dokumente und Zeichnungen durch eine einzige Quelle der Wahrheit zu ersetzen, die immer auf dem neuesten Stand ist.

Sprache modellieren

Die Komplexität von Projekten oder der Technologie im Allgemeinen nimmt immer weiter zu. Denken Sie an den Unterschied zwischen den ersten Telefonen und den heutigen Smartphones. Oder vergleichen Sie die ersten Autos mit den Fahrzeugen, die heute auf den Straßen unterwegs sind. Während die Hauptfunktion die gleiche geblieben ist (Kommunikation, Fahren), werden die heutigen Systeme zunehmend in ein größeres Ganzes integriert, um den Benutzern zusätzliche Dienste zu bieten, die von den Systemen selbst nicht geleistet werden können. Dieser Trend wurde in vielen Quellen identifiziert und beschrieben, unter anderem in den Visionsdokumenten von Incose – Vision 2025 und in jüngerer Zeit Vision 2035.

Um den zunehmenden Grad der Integration zu bewältigen, fördert Incose den Übergang zum modellbasierten Systems Engineering (MBSE). Dabei werden Modelle verwendet, um komplexe Systeme zu entwerfen und zu verifizieren. Einer der ersten Schritte in Richtung MBSE ist die Einführung einer Sprache, die für die Erstellung solcher Modelle geeignet ist. SysML ist eine solche Sprache.

SysML ermöglicht die Darstellung verschiedener Arten von Systemen und deren Verhalten sowie deren Interaktionen mit der Umgebung.

Die Systems Modeling Language (SysML) ist eine universelle Modellierungssprache, die Ingenieuren bei der Entwicklung und Dokumentation komplexer Systeme mit einer großen Anzahl von Komponenten hilft. Die Sprache ist in Branchen wie der Luft- und Raumfahrt, der Automobilindustrie, der Infrastruktur und der Verteidigung weit verbreitet. Die bereitgestellte grafische Notation ermöglicht die Darstellung verschiedener Systemtypen und ihres Verhaltens sowie ihrer Interaktionen mit der Umgebung. Dies ermöglicht es Ingenieuren, ihre Ideen effektiv und effizient zu kommunizieren und sicherzustellen, dass alle am Entwicklungsprozess Beteiligten dasselbe Verständnis des zu entwickelnden Produkts haben. Da die Sprache nicht disziplinspezifisch ist, können Systeme auf einer übergreifenden Ebene beschrieben werden.

Die vier Säulen der SysML

1. Struktur: Ein System kann in kleinere Teile zerlegt werden, die Schnittstellen zueinander haben.
2. Verhalten: Es können drei Arten von Verhalten – flussbasiert, ereignisbasiert und nachrichtenbasiert – festgelegt und miteinander in Beziehung gesetzt werden.
3. Anforderungen: Systemanforderungen und deren Tests können definiert werden.
4. Parametrik: Einmal beschrieben, kann ein System auch simuliert werden.

Erhöhte Präzision

Wenn Sie SysML verwenden, werden Sie als erstes feststellen, dass die Entwürfe präziser sind und daher mehr Arbeit erfordern. Diese Präzision stellt jedoch auch sicher, dass alle Beteiligten die Entwürfe auf dieselbe Weise interpretieren können wie der Autor und dass Fehler und Auslassungen viel leichter zu erkennen und zu vermeiden sind. Da es fast unmöglich ist, ein inkonsistentes Design zu erstellen, werden Fehlerkosten vermieden. Wenn diese Kosten die anfängliche Investition übersteigen, lohnt sich der Einsatz von SysML für Sie.

Die Implementierung von SysML kann sich als gewaltige Aufgabe erweisen. Auf den ersten Blick kann es wie eine große Herausforderung erscheinen, ein ganzes komplexes System in ein für Analyse und Simulation geeignetes Modell zu gießen. In der Praxis erfolgt der Übergang oft schrittweise, und Unternehmen verwenden SysML nach und nach immer häufiger zur Beschreibung von Designs. Langsam aber sicher werden Dokumente entweder durch Modelle ersetzt oder zu Sichten auf das Modell, bis es auf den höheren Reifegraden überhaupt keine Dokumente mehr gibt, weil alle Informationen in Modellen gekapselt sind.

Da SysML eine umfassende Sprache ist, braucht man Zeit, um alle Details zu beherrschen. Eine angemessene Schulung wird die Einführung erheblich beschleunigen. Die Ingenieure werden sich sicherlich auch an die höhere Präzision gewöhnen müssen, mit der die Entwürfe von Anfang an erstellt werden. Sobald SysML erfolgreich eingeführt ist, wird es die Kommunikation und die Qualität des Designs verbessern.

Für Spezifikationen mit vielen geometrischen Informationen, wie sie oft im Bauwesen erstellt werden, ist SysML weniger effektiv. Die Sprache eignet sich besonders gut für cyber-physische, softwareintensive Systeme. Ein gutes Beispiel ist ein Infrastrukturprojekt in Amsterdam-Zuid, bei dem die Entwürfe vom Lieferanten erstellt und vom Auftraggeber überprüft wurden. Hier führte der Einsatz von SysML zu einer erheblichen Steigerung der Entwicklungsgeschwindigkeit, wobei die Anzahl der gefundenen Fehler deutlich unter dem Durchschnitt lag. Auch anderswo beweist SysML, dass es Albträume verhindern und Projekte näher an das Ideal bringen kann.

Dieser Artikel wurde von Nieke Roos, Tech-Redakteur bei Bits&Chips, geschrieben.