Über Modellbasierte System-Entwicklung
Ich würde sagen, zu den Hauptaufgaben der System-Entwicklung zählt es,
- die Anforderungen des Systems zu spezifizieren
- eine stabile System-Architektur zu entwerfen, auf der die anderen Disziplinen aufsetzen können
- das System gegen die Kundenanforderungen zu verifizieren
- das System in seiner Zielumgebung zu validieren
Im Vergleich zum Software Engineering scheint es im Systems Engineering wenig einheitliche Methodiken zu geben, die diese Aufgaben unterstützen. Viele System-Ingenieure entwerfen ihr System in ellenlangen Prosa-Spezifikationen, die keiner liest, oder anhand von wilden Blockdiagrammen, die keiner versteht.
Das International Council on Systems Engineering (INCOSE) ist weltweit anerkannt als die bedeutendste Organisation, die sich mit System-Entwicklung beschäftigt. INCOSE erwartet in den nächsten Jahren einen Übergang von dokumententen-zentrierter System-Entwicklung zu dem, was wir Modellbasierte System-Entwicklung nennen und betont dies in ihrer Vision für das Jahr 2020.
Modellbasierte System-Entwicklung (MBSE) unterstützt den Systemingenieur bei seinen Aufgaben durch die Erstellung eines Systemmodells, das während des gesamten Entwicklungsprozesses bei Spezifikation, Entwurf, Verifikation und Validierung komplexer Systeme als Basis verschiedenster Entscheidungen und Arbeitsergebnisse dient.
So ein Modell ist eine in sich konsistente Abbildung des zu entwickelnden Systems und erlaubt unterschiedliche Sichten auf die Informationen, die es beinhaltet. Solche Sichten sind grafische Visualisierungen in der speziell für die System-Entwicklung entwickelten Modellierungssprache Systems Modelling Language (SysML).
Als internationaler Standard dient die SysML somit bei der Modellierung als hilfreiches Werkzeug und erlaubt es, dass jeder Betrachter eines SysML-Diagramms dasselbe daraus liest. In diesem Sinne erleichtert die SysML die Kommunikation im Team erheblich und gestattet es, für jeden Mitarbeiter die Sichten auf das Modell zu erzeugen, die er benötigt.
Zum Einstieg in das Thema SysML kann ich das Buch von Tim Weilkiens empfehlen, der selbst an dem Standard mitarbeitet.
Ich würde sagen, es kommt immer auf den Standpunkt und den Blickwinkel an.
Eine Aussage: „Viele System-Ingenieure entwerfen ihr System in ellenlangen Prosa-Spezifikationen, die keiner liest, oder anhand von wilden Blockdiagrammen, die keiner versteht.“ beinhaltet in sich erhebliche Verallgemeinerungen [keiner liest, keiner versteht], die in sich nicht wirklich akzeptabel sind. Schließlich taugen sie nicht viel als Argumente.
Systems Engineering definiert primär den Prozess und beschäftigt sich nicht als Schwerpunkt mit den (gerade eben heute!!!) geltenden und verfügbaren Methoden und Tools. Der Systems Engineering Prozess kann sowohl mit Papier und Bleistift als auch mit „wilden“ Tools unterstützt werden (wohl bemerkt: unterstützt!!!). INCOS schaut dagegen auf die Tools und gerade aktuelle Methoden und es ist gut so.
Es ist auch notwendig, einen Blick in die geschichtliche Werkzeugkiste des Systems Engineering zu werfen um erst dann weitere Aussagen zu treffen (Beispiele: IDEF, unzählige gute Strukturvorlagen gute Dokumente etc). Ohne Systems Engineering gäbe es nicht viele erfolgreiche Raumprogramme, Verteidigungssysteme etc. Solche Vorhaben leben länger als manches Tool/Methoden-Hype und müssen entsprechende Stabilität aufweisen. Wenn eine Systementwicklung mit erheblichen SW-Anteilen z.B. 10 Jahre lang dauert und einen Wert von 3mrd. Euro hat, dann kann man schlicht nicht auf der aktuellen Hype-Welle reiten – die Risiken solchen Handelns könnten ziemlich bedeutend werden. Das Projekt dauert deutliche länger als schätzungsweise 2 Hype-Wellen!
Wenn ich allerdings ein Projekt von 6 Monaten habe, dann kann ich schon anders auf die Hype-Welle schauen und evtl. darauf aufspringen. Ich werde immer noch überlegen auf welche: die die geht, oder die die kommt… :-)
Ich möchte gerne die Projekte kennenlernen, in welchen die SysML-Modelle von allen gelesen werden und von allen verstanden werden und keinen Hauch von wilden Phantasien mitbringen…
Zum Einstieg in das Thema des Systems Engineering empfehle ich das Handbook of Systems Engineering von INCOSE (Mitgliedschaft ist die Voraussetzung) oder eines der Standards in diesem Bereich (es gibt einige mit unterschiedlichem Blickwinkel auf das Thema). Alternativ ist ein gutes Training durch nichts zu ersetzen.
Hallo Herr Malecki!
Vielen Dank für Ihren Kommentar.
Natürlich haben Sie recht. SysML an sich ist nicht die eierlegende Wollmilchsau, die einen System-Entwicklungs-Prozess ersetzt, sondern kann nur als untertützende Methodik dienen.
Trotzdem halte ich SysML mit meinen bisherigen Erfahrungen als sinnvolles Werkzeug im Zuge der Vereinheitlichung der System-Entwicklungs-Prozesse.
Inwieweit findet SysML bei Ihnen bereits Anwendung?
Hallo Herr Schneider,
ich sehe tatsächlich in SysML einen guten Anfang für eine Systemmodellierungsmethodik, die das Systems Engineering gut unterstätzten kann. Alles in Allem entscheidend ist die nicht-Softwareorthodoxe Sicht auf die Welt, auch wenn unzweifelhaft der Grundgedanke hierzu von UML und daher von der Software kommt. Ich sehe darin eine Zukunft.
In meinem Tätigkeitsfeld habe ich eben mit langläufigen Projekten zu tun die „irgendwo herkommen“ und „irgendwo hingehen“, daher beinahe immer historische Lasten mitbringen, die in potentielle, neue Welt gerettet und weiterentwickelt werden müssen. Da steckt gerade die Herausforderung drin. Die Erfolge/Miserfolge kann man allerding nicht so schnell sehen, wie bei Projekten, von welchen man z.B. 3 im Jahr macht, also, welche vergleichsweise kurze Lebensdauer haben.
Es ist aber immer eine Anstrengung wert, zunächst im kleinen etwas neues zu machen, um zu prüfen, ob der Wert, der Nutzen, im operativen Umfeld feststellbar ist. Das ist m.E. ein angemessener Einstieg in z.. das Thema SysML.
Hallo Herr Malecki,
tatsächlich ist es immer am einfachsten auf der grünen Wiese zu beginnen. Gerade bei Produktlinien müsste man eigentlich irgendwann mal den Aufwand spendieren, um alles „nachzumodellieren“, was man schon hat. Ab da sollte sich die Modellierung zukünftiger Produktvariaten durch Wiederverwendung extrem beschleunigen lassen. So die Theorie; in der Praxis sind wir davon auch noch weit entfernt.