Eine BLOG-Serie in drei Teilen.

KI (Künstliche Intelligenz) und deren Einsatz im Bereich der Softwareentwicklung ist ein spannendes Thema und wir werden oft gefragt, welche Aufgaben die KI denn aktuell schon übernehmen kann. Sei es nun die Erstellung von Anforderungen nach Satzschablone, das Erstellen von Software-Architekturen oder die Erstellung von Testfällen.
Wir beschäftigen uns mit diesen Fragen intensiv und haben deswegen auch einen ChatBot namens K(a)I RESE entwickelt, der bei uns als KI-Mitarbeiter und Kollege tätig ist.

Aber unter welchen Rahmenbedingungen kann K(a)I RESE eigentlich in den Entwicklungsprozessen eingesetzt werden?

Seit schon fast 20 Jahren ist meine berufliche Heimat die Automobilbranche und genau deswegen habe ich da die Automotive-SPICE Prozesswelt im Hinterkopf.
Auch wenn es sicher eine spannende Frage ist, ob irgendwann in der Zukunft eine KI als eigenständiger Mitarbeiter gewertet wird, werde ich in diesem Artikel nur K(a)I RESE als eingesetztes Tool im Projekt bewerten. Welchen Einfluss wird K(a)I RESE auf die verschiedenen Automotive-SPICE Prozessgruppen haben. Es geht darum, welche Base Practices betroffen sind und welche Evidenzen erzeugt werden müssen.

Moment…. Was sind eigentlich Base Practices und was sind Evidenzen?

Base Practices definieren Aufgaben, die im Rahmen einer Prozessgruppe durchgeführt werden müssen. Diese wurden aus der Erfahrung vergangener Projekte definiert und sind ein Faktor für ein erfolgreiches Projekt und damit das Ergebnis den Anforderungen des Kunden genügt. Im Projekt werden die Base Practices mit der Definition von Praktiken umgesetzt.

Evidenzen sind Arbeitsprodukte, die den Nachweis erbringen, dass die definierten Praktiken zu den Base Practices durchgeführt wurden. Das können Anforderungen, Analysedokumente oder Review Protokolle sein. Diese Evidenzen werden in einem Automotive-SPICE-Assessment geprüft, um die Umsetzung der Base-Practices zu bewerten.

OK, also geht es nicht nur darum, das Arbeitsprodukt zu erstellen, es geht auch darum, die gewünschte Qualität des Endergebnisses sicher zu stellen.
Wie muss K(a)I RESE im Entwicklungsprozess berücksichtigt werden? Die relevanten Prozessgruppen sind einerseits Projektmanagement (MAN.3), Risiko-Management (MAN.5), Konfigurations-Management (SUP.8) und Quality-Management (SUP.1) für die Planung von Ressourcen, andererseits die Entwicklungsdisziplinen von System (SYS.1 bis SYS.3), Software(SWE.1 bis SWE.3) und Hardware(HWE.1 bis HWE.2).

Im ersten Teil geht es um die Planung, dass die richtige KI für die notwendigen Aufgaben eingesetzt wird, im zweiten Teil geht es um den Entwicklungsprozess selbst und im letzten Teil werden die neuen Zusätze in Automotive-SPICE zur Entwicklung von Machine-Learning-Komponenten für den Einsatz im Fahrzeug besprochen (MLE.1 bis MLE.4 und SUP.11).

Also fangen wir mit der Planung von Ressourcen an.
Das Projekt-Management muss sicherstellen, dass die Projektmitarbeiter die für ihre Arbeit notwendigen Fähigkeiten besitzen und im Falle von Lücken entsprechende Entwicklungsmaßnahmen definieren und deren Erfolg überprüfen. Sowohl das Aufnehmen der Fähigkeiten wie auch die Entwicklungsmaßnahmen mit dem Nachweis, dass die Maßnahmen erfolgreich umgesetzt wurden, sind Evidenzen für die Base Practice MAN.3.BP6 (Define and monitor required skills, knowledge, and experience). Zu den neuen Fähigkeiten gehört das Aufsetzen von K(a)I RESE für den Einsatz im Projekt, die richtige Auswahl der Daten, für das Training von K(a)I RESE, und die Prompt Erstellung, damit K(a)I RESE die Arbeitsprodukte mit der gewünschten Qualität erstellen kann. Der Kontinuierliche Trainingsprozess von K(a)I RESE wird dann im Entwicklungsprozess eingebunden.

Das Task-Management für das automatisierte Annehmen von Aufgaben aus einem Backlog sollte relativ einfach sein und wird in diesem Beitrag nicht weiter betrachtet.

Die Trainingsdaten für K(a)I RESE sind ein mögliches Konfigurationselement, das im Konfigurations-Management (SUP.8.BP1 – Identify configuration items) berücksichtigt werden muss. Das dient der Wiederherstellung von K(a)I RESE oder der Instanziierung von neuen K(a)I RESE Instanzen. Da sich die Trainingsdaten für den kontinuierlichen Trainingsprozess verändern ist eine Versionsverwaltung für die Daten notwendig. Damit ist sichergestellt, dass K(a)I RESE auf eine vorherigen Zustand zurückgesetzt werden kann, falls sich die Qualität der erstellten Arbeitsprodukte nach dem Training verschlechtert.

War es das mit dem Konfigurations-Management?
Nein! K(a)I RESE braucht auch Zugriff auf bestimmte Ressourcen, um arbeiten zu können. Das wird ebenfalls mit dem Konfigurations-Management definiert (SUP.8.BP2 – Define configuration item properties) und darf auf keinen Fall vergessen werden.

Was muss noch betrachtet werden?
Das Risikomanagement (MAN.5) gibt es auch noch! Sicherheitsprobleme, wenn K(a)I RESE aus dem Internet aufgerufen wird oder ist K(a)I RESE eine lokale Installation ohne Zugriff auf das Internet. Wenn K(a)I RESE Zugriff auf sensible Daten hat, müssen potenzielle Sicherheitslücken aufgenommen werden. Da K(a)I RESE eine Ressource zur Erzeugung von Arbeitsprodukten ist, muss auch die Verfügbarkeit mit der Ausfallwahrscheinlichkeit durch Netzwerkprobleme oder Erreichbarkeit des Serviceproviders berücksichtigt werden. Die Eintrittswahrscheinlichkeiten und die Auswirkungen, müssen in die zu definierenden Maßnahmen einfließen.

Dann ist da noch die Quality Assurance (SUP.1). Da geht es um die Qualität der Arbeitsprodukte und die Einhaltung der Prozesse.
Was bedeutet das im Zusammenhang mit K(a)I RESE? Der Quality Manger muss ein Auge auf den kontinuierlichen Lernprozess von K(a)I RESE haben, damit die, von ihm, erzeugten Arbeitsprodukte die gewünschte Qualität haben und die notwendigen Evidenzen für den Einhalt der Prozesse vorhanden sind.

Natürlich kann K(a)I RESE auch für eine schnelle Analyse von Fehlern im Problem Resolution Management (SUP.9) und Änderungswünsche im Change Request Management (SUP.10) eingesetzt werden. Das ist jedoch eine eher triviale Aufgabe, wenn bei der Entwicklung die entsprechenden Arbeitsprodukte zur Verfolgbarkeit erstellt wurde. Man könnte sagen, dass dann K(a)I RESE für die Aufgabe überqualifiziert wäre.

Damit ist fast alles zu den Management und Supporting Process groups (MAN und SUP) gesagt.
Wir behalten im Hinterkopf, dass die neuen Prozesse zur Entwicklung von Machine Learning für den Einsatz im Fahrzeug im dritten und letzten Teil der BLOG-Serie besprochen werden. Im nächsten Blogbeitrag geht es erst einmal um die Prozesse rund um die System-, Software- und Hardware-Entwicklung.

Ich freue mich über Anregungen und Feedback.

Als dann bis zum nächsten Teil der BLOG-Serie zum Thema K(a)I RESE und ASPICE,

Ihr Carsten Freining

Hilfreicher Link:
A-SPICE Standard 4.0 bei VDA:
https://vda-qmc.de/automotive-spice/automotive-spice-veroeffentlichungen/