A SPICE #3 – Anpassungen der „Vorgaben“ aus ASPICE sind nicht gestattet

Willkommen zurück in unserer Blogserie, in der wir uns in die Welt von Automotive SPICE (ASPICE) vertiefen. In den vorherigen Teilen haben wir uns auf Mythen des Automotive SPICE Standards konzentriert, und heute möchten wir einen häufigen Mythos aufklären: Die Unmöglichkeit, Anpassungen an den „Vorgaben“ des ASPICE-Standards vorzunehmen.

Es ist ein Mythos, dass die Vorgaben im Automotive SPICE starr und unveränderlich sind. In unseren Kundenprojekten erleben wir immer wieder, dass jede Abweichung von den „Automotive SPICE-Vorgaben“ zu Nichtkonformität führt. Dies kann jedoch dazu führen, dass Entwicklungsteams und Unternehmen die Flexibilität verlieren, die notwendig ist, um sich an die dynamischen Bedürfnisse des Marktes bzw. Unternehmens anzupassen.

Weiterlesen

KI im Requirements & Systems Engineering

Morgen macht die KI meine Arbeit!

…“Boah, schau mal was das Ding alles kann!“
So oder so ähnlich war bestimmt auch Ihre Reaktion, als Sie eine der zahlreichen und öffentlich verfügbaren KIs (Künstliche Intelligenzen) ausprobiert haben. Und wenn auch nicht laut ausgesprochen, so war diese Reaktion zumindest in Ihrem Kopf präsent. Auch der nächste Gedanke: „Das Ding nimmt mir demnächst den Job weg!“ könnte Ihnen dann gekommen sein. Wäre zumindest nicht verwunderlich.
Und auch all die Reportagen, Videos und Schlagzeilen, dass der Einsatz von Künstlicher Intelligenz nicht nur eine technische Neuerung darstellt, sondern einer Revolution gleichkommt, haben wir alle im Verlauf des letzten Jahres öfter gehört! 

Wie Sie sich vorstellen können, haben wir SOPHISTen einen etwas anderen Approach bezüglich dem Einsatz von KIs. Wir arbeiten mit unseren Kunden im Requirements Engineering (RE) und Systems Engineering (SE) an Produkten, Systemen und Services, die ebenso wie die Welt um sie herum, zunehmend komplexer und vernetzter werden. KI sollte auch hier die Möglichkeit bieten, die Effizienz und Qualität der Entwicklungsprozesse erheblich zu steigern.

Weiterlesen

A SPICE #2 – Prozessgruppen entsprechen Architekturebenen des „Systems of Interest“

Im zweiten Teil unserer Artikelserie rund um Automotive SPICE möchten wir einen weiteren Mythos aufdecken. Es handelt sich um die Annahme, dass Prozessgruppen in Automotive SPICE 1:1 den Architekturebenen des Systems of Interest entsprechen.

In unseren Kundenprojekten erleben wir immer wieder, dass die Prozessgruppen in Automotive SPICE direkt den verschiedenen Architekturebenen des Systems of Interest zugeordnet werden. Demnach würde jeder Prozess im Rahmen der Systementwicklung nur genau einmal durchlaufen werden (siehe Abbildung 1), abgesehen von Iterationen für das gesamte System of Interest. Das Problem hierbei ist, dass es in der Realität aufgrund der umfangreichen Systeme häufig mehr als eine System- und eine Softwareebene gibt, entlang dieser Ebenen Verantwortlichkeiten verteilt werden und das Zusammenarbeitsmodell wesentlich durch die Architektur bestimmt wird.

Weiterlesen

Man muss doch nicht gleich in die Luft gehen!

Aber wir wollten es ja nicht anders 😊
Sie verstehen gerade nicht, um was es geht?
Wir sprechen vom Festkomitee-Event, der im Regelfall am Abend vor unserem monatlichen Mitarbeitenden-Meeting stattfindet. Und dieses Mal ging es in den AIRTIME Trampolinpark Nürnberg. Wir waren zwar nur eine kleine Delegation bestehend aus 8 SOPHISTen, weil viele der Kollegen noch Urlaub hatten oder anderweitig verhindert waren, aber das hat dem Spaß keinen Abbruch getan.

Weiterlesen

A SPICE löst Probleme in der Entwicklung

Teil 1 unserer Artikel-Serie über A SPICE.
Lesen Sie auch unseren Einführungsartikel Drei Mythen rund um A SPICE.

Bevor wir im ersten Teil der Serie in die Tiefe gehen, gibt es eine wichtige Denkweise bzw. Betrachtungsweise, die wir im Vorfeld näher betrachten möchten:

Dr. Gerhard Wohland [1], grandioser Systemtheoretiker, Autor des Buchs „Denkwerkzeuge der Höchstleister“ und Leiter des Instituts für dynamikrobuste Organisation (IdO) unterscheidet zwischen der blauen Welt stabiler, vorhersehbarer Umgebungen mit festen Prozessen und der roten Welt unsicherer, dynamischer Umgebungen, die Flexibilität erfordern.
In der blauen Welt steht Effizienz durch standardisierte Regeln im Vordergrund.
Die rote Welt erfordert Anpassungsfähigkeit und den Umgang mit Ungewissheit und Überraschungen. In beiden Welten tauchen Probleme auf… Aber was genau sind Probleme?

Probleme werden, von Dr. Gerhard Wohland, als Signale beschrieben, die man nicht ignorieren kann. Wenn man sie trotzdem ignoriert, kann das später zu Schwierigkeiten führen. Das bedeutet, wir müssen uns mit solchen Problemen auseinandersetzen.

Wie werden Probleme in der blauen und/oder roten Welt gesehen?

  • Die blaue Welt und Probleme:

In der blauen Welt werden Probleme oft als Störungen des normalen Betriebs betrachtet. Die idealisierte Annahme ist, dass, wenn alles nach Plan läuft, es keine roten Probleme geben sollte. Es gibt häufig vorgefertigte Lösungswege oder Richtlinien, wie mit bestimmten Problemen umzugehen ist. Die Lösung der blauen Probleme erfolgt mithilfe von Wissen, das z.B. in Prozessen, Methoden oder Arbeitsanweisungen konserviert ist.

  • Die rote Welt und Probleme:

In der roten Welt werden Probleme oft als Gelegenheiten für Lernen und Weiterentwicklung gesehen. Das Auftreten eines Problems signalisiert, dass es etwas Neues zu entdecken oder zu verstehen gibt. Anstatt auf vorgefertigte Lösungen zurückzugreifen, werden in dieser Welt kreative und innovative Ansätze zur Problemlösung benötigt und gefördert. Die Person, die eine Lösung für das Problem, zu dem es noch kein Wissen geben kann, erarbeiten soll, ist entscheidend. Rote Probleme lassen sich nur durch Können und nicht durch Wissen lösen.

Weiterlesen