Was ist aus den fünf Prognosen zum Systems Engineering geworden?

Letztes Jahr habe ich fünf Prognosen zum Systems Engineering in 2016 gemacht. Heute möchte ich untersuchen, was aus diesen fünf Prognosen geworden ist.

1. Agilität und Modellierung sorgen für effektiveres Systems Engineering: Nun ja, wirklich sichtbarer Fortschritt war hier leider nicht zu sehen. Agilität ist im Bereich Anforderungsengineering und -management auf dem Vormarsch, als auch in der Implementierung (zumindest bei Software). Aber in den anderen Bereichen ist nicht viel davon zu spüren. Modellierung ist zwar ein fester Bestandteil in der Entwicklung, aber auch da eher im Design- und Implementierung (CAD, Softwareentwicklung), aber übergreifend ist nur punktuell etwas zu spüren.

2. INCOSE und GfSE werden ihre Sichtbarkeit drastisch erhöhen: Die Mitgliedszahlen der GfSE sind nach wie vor am wachsen, aber ich treffe trotzdem häufig noch Menschen aus Firmen, die zwar SE betreiben, aber noch nie von GfSE oder INCOSE gehört haben. Gefühlt besteht hier noch viel Nachholbedarf. Positiv zu bewerten ist, dass die GfSE dieses Jahr die Syscamps übernommen hat, wodurch über einen weiteren Kanal die entsprechende Zielgruppe erreicht wird.

3. Eclipse wir den Durchbruch (noch) nicht schaffen: Hier reden wir vom Durchbruch im Systems Engineering, denn in der Softwareentwicklung ist Eclipse ja längst etabliert. Zunächst: Um Eclipse brummt es nach wie vor, und auch große Konzerne mischen mit, wie Ericsson bei Papyrus oder Thales by Capella. Trotzdem sehe ich nach wie vor viel Skepsis, insbesondere was den produktiven Einsatz betrifft. Zum einen haben sich da einfach zu viele in der Vergangenheit die Finger verbrannt, zum anderen ist vielen bewusst, wie viel Arbeit notwendig ist, um ein Werkzeug für den produktiven Einsatz zu tailoren. Hinzu kommt, dass kommerzielle Werkzeuge für die Modellierung einfach zu günstig sind: Enterprise Architect kostet etwas über €100 in der günstigsten Version (um nur ein Beispiel zu nennen), und es gibt viele Alternativen – sowohl günstiger als auch luxuriöser. Als Eclipse sich den Markt für Java-Entwicklungswerkzeuge einverleibt hatte, da kosteten kommerzielle Werkzeuge hunderte oder tausende von Euros/Dollars, und die waren noch nicht mal sonderlich gut.

Kommerzielle Modellierungs-Werkzeuge sind zu gut und zu günstig, um Eclipse einen großen Markanteil zu ermöglichen Twittern

Das bedeutet: Eclipse wird so schnell kein Mainstream-Werkzeug im SE: In der Modellierung gibt es einfach zu viel Wettbewerb, und im SE kann Eclipse noch lange nicht mithalten. Mal schauen, ob und wann sich das ändert.

4. Offene Ansätze werden immer mehr von den Kunden gefordert: Hier muss man drei Gruppen unterscheiden:

  • Große Firmen schauen verstärkt auf offene Ansätze, insbesondere bei langen Produktlebenszyklen. Die Auflagen für Nachweisführung und die Notwendigkeit, auch nach Jahrzehnten noch nachzubessern, sorgen für einen enormen Druck. Außerdem haben sich zu viele hier schon die Finger verbrannt.
  • Kleine Firmen sind da pragmatisch, denn offene Ansätze sind – zumindest kurzfristig – eher günstiger, jedenfalls wenn die Total Cost of Ownership (TCO) mit in Betracht gezogen wird.
  • Akademische Nutzer hingegen weisen proprietäre Lösungen in der Regel kategorisch zurück. Zum einen schränkt das die Freiheitsgrade der Forschung stark ein, oder wird so wahrgenommen. Zum anderen scheuen sich insbesondere Studenten oft, sich mit den Formalitäten der Software-Beschaffung auseinanderzusetzen.

Bei kleinen Firmen werden offene Ansätze aus Kostengründen (TCO) oft abgelehnt Twittern

5. Die Krise der Automobilindustrie wird sich verschärfen: Wie weit die deutsche Automobilindustrie wirklich in der Klemme steckt, ist unklar. Noch gibt es keine (nennenswerten) Entlassungen. Aber in der Presse findet sich die Industrie häufig: Sei es mit dem immer noch nicht endenden VW-Diesel-Skandal, Elektroautos oder autonomen Autos. Mein Bauch sagt mir, dass die wirkliche Krise noch gar nicht sichtbar ist. Mal sehen, was 2017 bringt.

Was meinen Sie? Stimmen Sie dieser Analyse zu? Was sind Ihre Prognosen fürs nächste Jahr? Diskutieren Sie im Kommentarbereich mit!

Bildquelle: Trish2

Dieser Artikel erschien zuerst bei se-trends.de.

  • pica

    Hallo Michael,

    irgendwie sind Deine Voraussagen nicht SMART

    Specific – target a specific area for improvement.

    Measurable – quantify or at least suggest an indicator of progress.

    Assignable – specify who will do it.

    Realistic – state what results can realistically be achieved, given available resources.

    Time-related – specify when the result(s) can be achieved.

    Zu meinen Lieblingsthema „Eclipse wir den Durchbruch (noch) nicht schaffen“

    Wie ist der „Durchbruch“ definiert?

    Eclipse — ich nehme an Polarsys, bzw. Papyrus im Speziellen ist gemeint — bedient einen vollständig anderen Markt als Sparx Enterprise Architect. Papyrus ist eher eine Konkurenz zu IBM Rational Rhapsody bzw. IBM Rational RSA und Mentor Graphics Bridgepoint. So ist bereits die UML/RT Erweiterung von Zeligsoft für IBM Rational RSA als EOL deklariert, da auf Druck der großen Kunden diese von Zeligsoft auf Papyrus migriert hat. Ebenso gliedert sich der Mentor Graphics Spin Off One Fact unter Papyrus ein.

    Entsprechend sind die „Kunden“ von Papyrus große Firmen mit langer MDSE Tradition wie z.B. Airbus, Ericsson oder Saab Engineering um nur einige zu nennen.

    Also wie ist der „Durchbruch“ definiert?

    Beste Grüße,
    Carsten

    • Hallo Carsten,

      Recht muss ich Dir hier schon geben, wirklich SMART sind die Vorhersagen nicht. Andererseits handelt es sich hier ja auch nicht um Anforderungen, sondern um den Blick in die Kristallkugel, der traditionell etwas vernebelt ist. 🙂

      > Also wie ist der „Durchbruch“ definiert?

      Selbstverständlich lassen sich die Prognosen SMART machen, und bei Eclipse als Java-IDE war dies ja auch in der Form von Marktanteilen klar sichtbar und messbar.

      Für mich könnte Durchbruch bedeuteten: „Mindestens 25% der produktiven SE-Werkzeugkette werden mit Eclipse-basierten Werkzeugen umgesetzt, bei einem Marktanteil von 10%.“ Ich würde mich hier auch nicht auf Papyrus festlegen, da SE ja weit umfassender ist (siehe IEC 15288, insbesondere die technischen Prozesse).

      > So ist bereits die UML/RT Erweiterung von Zeligsoft für IBM Rational RSA
      als EOL deklariert, da auf Druck der großen Kunden diese von Zeligsoft
      auf Papyrus migriert hat.

      Nicht (nur) der Druck der Kunden, sondern auch die Tatsache, dass Papyrus für Zeligsoft eine strategische Entscheidung ist. Die Kunden, die zu Papyrus migrieren, bleiben Kunden der Firma Zeligsoft, nur eben mit einem anderen Tool.

      > Entsprechend sind die „Kunden“ von Papyrus große Firmen mit langer MDSE
      Tradition wie z.B. Airbus, Ericsson oder Saab Engineering um nur einige
      zu nennen.

      Bei Ericsson sieht es zur Zeit ja vielversprechend aus; bei Airbus ist Eclipse nie über die F&E-Phase hinausgekommen, soweit ich weiß. Und das ist auch ein bisschen das, worauf ich hinaus wollte: Wenn es nicht zumindest ein paar sichtbare Erfolgsgeschichten bei solchen Konzernen gibt (und soweit ich weiß ist das nicht der Fall), dann ist der Durchbruch noch nicht geschafft.

      Gruß,
      – Michael

  • pica

    Hallo Michael,

    bei den Mängeln, die ich bei Sparx EA v6 bemerkt habe und für die Versionen 6, 7, 10 und 11 an Sparx gemeldet habe, nehme ich Sparx EA nicht freiwillig.

    OK, ein Fehler ist mit Version 13 endlich Geschichte. Hier ging es darum, dass Nachrichten in Sequenz Diagrammen Operationen nicht referenzierten, sondern statt dessen die Signatur der Operation als Name der Nachricht verwendet wurde. Nach einem Refactoring der Operation war das „Modell“ inkonsistent.

    Weitere für mich schwerwiegende Mängel sind:
    * das Löschen z.B. einer Klasse löscht nicht die mit der Klasse verbundenen Assoziationen. Dies führt zu XMI Dateien mit xmi:ref Elementen die nicht vorhandene Elemente referenzieren. Im Klartext: Sparx EA kann nicht einmal die referentielle Integrität eines Modells sicherstellen.
    * Aktivitätsmodelle werden im XMI als BPMN Modelle abgebildet. Macht Transformationen unnötig komplex.
    * eine ausschließliche Nutzung definierter Elemente kann nicht erzwungen werden. Dies führt, da kein Mensch unfehlbar ist mehr oder weniger zwingend zu inkonsistenten Modellen. Ich musste einmal ein Sparx EA Modell bearbeiten in dem der Datentyp String mit über 70 Schreibweisen (z.B. „string“, „String“, „STRING“, „STring“, „striing“, „strimg“ um nur einige zu nennen) „deklariert“ war. MDSE war damit gestorben.

    Meine vollständige Liste (habe ich diese noch?) umfasste über 30 für mich schwerwiegende Mängel. Entsprechend ist mein Vertrauen in Sparx EA getrübt.

    Auch weil sich bei (m)einer Anfrage Sparx als auch LieberLieber sich weigerten Sparx EA ISO 26262 zu zertifizieren.

    Beste Grüße,
    Carsten

    PS Bei Papyrus ist eine Zertifizierung nach ISO 51508, CENELEC, ISO 26262, DO178 oder auch ECSS möglich 😉

    • Hallo Carsten,

      > bei den Mängeln, die ich bereits bei Sparx EA v6 bemerkt habe (…) nehme ich Sparx EA
      nicht freiwillig.

      Das scheint dennoch viele nicht davon abzuhalten, EA zu nutzen: Beim Modeling Barcamp hatte ich eine nicht-representative Umfrage zu Modellierungswerkzeugen durchgeführt, und EA hat mit Abstand geführt.

      Allerdings kenne ich auch viele Power-User, die einen Bogen um EA machen.

      Ich erkläre das damit, dass EA für viele Anwendungen „gut genug“ ist. Vielleicht ähnlich wie Microsoft Word, das ja auch „gut genug“ zum Schreiben eines Briefes ist, aber überhaupt nicht für das Schreiben eines Buchs geeignet ist.

      Gruß,

      – Michael