Eine BLOG-Serie in drei Teilen – Teil 2

Das Projekt brennt, das Entwickler Team stößt an seine Grenzen. Überstunden, Wochenendarbeit und, und, und. Alles, um das Projekt durch die Tür zu bringen.  

Dann, die Eingebung. Warum wird denn keine KI im Entwicklungsprozess eingesetzt?
K(a)I RESE kann doch auch Aufgaben im Projekt übernehmen. 

Klingt nach einer guten Idee. Endlich haben Projekte von Anfang an die notwendigen K(a)I RESEs, um das Projekt in Gang zu bringen und nicht auf die menschlichen Mitarbeiter, die noch in anderen Projekten Überstunden schieben, zu warten. Bleibt die Frage, wie das in die Prozesse eingebunden werden muss. Für diesen Artikel wird das Prozessmodell rund um Automotive SPICE als Basis genommen. 

Im Teil 1 dieser Blog-Serie habe wir bereits festgelegt, dass K(a)I RESE noch als Tool gewertet wird. Vor allem weil K(a)I RESE noch nicht selbstständig Aufgaben übernimmt und auch noch nicht selbstständig lernt. Er muss von außen angestoßen werden, damit Aufgaben übernommen werden oder ein Lernprozess stattfindet. 

Wenn aber K(a)I RESE ein Tool ist, können dann die von ihm erzeugten Arbeitsprodukte als Evidenzen für die Durchführung von Praktiken (Base Practices) gewertet werden? Zum Beispiel die Anforderungen auf Systemebene, die K(a)I RESE erzeugt hat. Diese sind die Evidenz für SYS.2 Base Practice 1 (Specify System Requirements). Das diese noch validiert werden müssen und verschiedene Rahmenbedingungen analysiert werden müssen, spielt da noch keine Rolle. Also können die Arbeitsprodukte von K(a)I RESE als Evidenz für die Durchführung einzelner Base Practices gewertet werden.

Wenn K(a)I RESE mehrmals die gleiche Aufgabe bekommt, so können (und werden) die Anforderungen jedes Mal anders sein. Die Formulierungen müssen nicht gleich sein. Also sind die Anforderungen nicht unbedingt reproduzierbar. Deshalb müssen die Anforderungen, die K(a)I RESE erstellt hat, entsprechend gesichert werden.

Und welche Base Practices kann K(a)I RESE alles übernehmen? Das ist nicht die richtige Frage. Die Frage ist, wie weit wir K(a)I RESE vertrauen, dass die Arbeitsprodukte die gewünschte Qualität haben. Ach so, und einem menschlichen Mitarbeiter vertrauen wir, dass die Arbeitsprodukte unbesehen die gewünschte Qualität haben? Natürlich nicht! Dafür gibt es doch die Validierung. Meistens durch alle Rollen im Projekt, die ein Interesse an dem Arbeitsprodukt haben. Also ist das auch die falsche Frage. Die Frage ist, welche Maßnahmen werden eingeführt, um die entsprechende Qualität der Arbeitsprodukte abzusichern.

Mit dieser Frage geht es nicht mehr um die einzelnen Base Practices, sondern um die Validierung der Arbeitsprodukte. Damit kann K(a)I RESE alles machen, solange es eine Validierung gibt. So wie es bei einem menschlichen Mitarbeiter auch ist. Diese Validierung ist meistens ein Review mit vordefinierten Kriterien.

Die Qualitätssicherung ist schon deswegen relevant, weil daraus das Feedback für das Training von K(a)I RESE generiert wird. Mit dem Training soll sich die Qualität der von K(a)I RESE erzeugten Arbeitsprodukte mit der Zeit verbessern.

Wir reden hier immer nur von Arbeitsprodukten.
Was bedeutet das jetzt konkret für Anforderungen oder Architekturobjekte?

In der Prozessgruppe SYS.2 (System Requirements Analysis) kann K(a)I RESE:

• die Anforderungen erstellen und strukturieren. (SYS.2.BP1 und 2 Specify and Structure system requirements)
• Mit den Quellen für die Anforderungen kann er auch die Verfolgbarkeit aufbauen. (SYS.2.BP5 Ensure consistency and establish bidirectional traceability)
• Die technische Machbarkeit analysieren (SYS.2.BP3 Analyze system requirements)
• Die Analyse des Einflusses auf die Umgebung durchführen (SYS.2.BP4 Analyze the impact on the system context)
• Die Konsistenz der Anforderungen überprüfen (SYS.2.BP5 Ensure consistency and establish bidirectional traceability)

Für andere Prozessgruppen, wie zum Beispiel SYS.3 (System Architecture Design), SWE.1 (Software Requirements Analysis), können genauso Base Practices gefunden werden, die von K(a)I RESE durchgeführt werden können.

Wenn K(a)I RESE mehrmals die gleiche Aufgabe bekommt, so können (und werden) die Anforderungen jedes Mal anders sein. Die Formulierungen müssen nicht gleich sein. Also sind die Anforderungen nicht unbedingt reproduzierbar. Deshalb müssen die Anforderungen, die K(a)I RESE erstellt hat, entsprechend gesichert werden.

Das bedeutet, dass die Anteile, die von K(a)I RESE erzeugt werden, im Prozess entsprechend angegeben werden müssen. Die Details, wie die Qualität der Arbeitsprodukte sichergestellt wird, werden benötigt.

Also ist K(a)I RESE kein rundum-sorglos-Tool, das die Ergebnisse sofort verwendbar ausgibt. Wo genau ist dann der Vorteil von K(a)I RESE in der Projektarbeit? Am Ende muss sich doch trotzdem wieder jemand mit den Anforderungen beschäftigen und die Qualität überprüfen. Wo ist da die Zeitersparnis?

Für den Experten möglicherweise nicht, weil die Expertise in beiden Fällen für das Review benötigt wird. Für die Requirements Engineers aber schon, denn K(a)I RESE übernimmt das initiale schreiben der Anforderungen mit dem Aufbau der Verfolgbarkeit. Der Requirements Engineer muss sich nach dem ersten Review nur noch um die Themen kümmern, wo im Review sehr komplexe Probleme aufgetreten sind, die K(a)I RESE (noch) nicht korrigieren kann.

Genau das ist die Starthilfe, die ein Projekt am Anfang benötigt, wenn noch nicht alle benötigten Ressourcen zum Schreiben der Anforderungen verfügbar sind.

Im letzten Teil geht es um die Entwicklung von Machine Learning Mechanismen für den Einsatz im Fahrzeug.

Quelle: VDA Automotive SPICE V4.0