Ich möchte in diesem Beitrag auf die GP (Generic Practices) der Automotive SPICE zu sprechen kommen. Allerdings will ich mich mal jenseits von SPICE und PAM/PRM an die Sache heranwagen. Wenn man bspw. ein kleines Projekt selber betreibt, wie einen Blog oder auch ein anderes Projekt in einer Firma, dann hört man oft "was man nicht messen kann kann man nicht steuern". Dabei steckt in diesem Satz viel, was ich als Ausgang hier benutzen möchte:

• Man braucht für ein Projekt immer ein Zielvorgabe. Dieses Ziel kann man sich natürlich auch selber stecken. Wenn ich nicht weiß wo ich eigentlich hin will, kann man nachher auch schlecht sagen, ob ich angekommen bin. Konkret angewendet heißt das, ich habe keinerlei wirklich Einflussgröße auf das Projekt selber. Um eingreifen zu können, muss ich wissen wann und wo ich das tun kann. Mit einem Ziel ist das deutlich einfacher und das Projekt ist dann zielgerichtet. Das ist erstmal unabhängig von SPICE. Eine Zieldefinition zu überlegen und aufzuschreiben ist mit in der GP 2.1.1 verankert.
• Wenn ich ein Ziel habe, dann kann ich auch ganz prima einen IST / SOLL Vergleich machen. Das bietet sich an, denn durch die Vorgabe des Ziels und dem aktuellen Status, kann ich bestimmen, ob ich mich dem Ziel nähere oder eben nicht. Zusätzlich kann ich mir auch hier noch Termin setzen, bis wann ich was erreicht haben will. In der Automotive SPICE findet sich sowas in der GP 2.1.2.
• Was passiert denn wenn man das Ziel nicht erreicht? Genau diese Fragestellung wird ganz oft vergessen oder nicht betrachtet. Hier gibt es die Möglichkeit zum Einschreiten und das sollte man auch tun, um wieder Kurs zum Ziel aufzunehmen. Sowas wird in der GP 2.1.3 der Automotive SPICE beschrieben.

Wir haben an den drei Beispielen gesehen, dass die generelle Vorgehensweise mit gesundem Menschenverstand schon ziemlich nahe an die Anforderungen von der Automotive SPICE kommt. Man muss hier noch etwas genauer werden und obiges Szenario an die Prozessausführung anpassen. Bei Projekten sieht man typischerweise oft zwei Fehler/Auffälligkeiten:

1. Man macht sich vor dem Projekt nicht ausreichend Gedanken über das, was man eigentlich will (hinsichtlich der Prozessausführung bei SPICE oder auch allgemein bei kleineren Projekten selber). Was genau soll der Prozess denn aussagen bzw. als konkretes Ziel haben?
2. Bei Abweichungen, wird oft gar nicht reagiert. Man hat zwar festgestellt durch irgendeine Messung, dass etwas nicht in Ordnung war, aber es folgt keine Aktion.

Ich treffe oft den Fall an, dass gemessen wird. Das macht man in der deutschen Kultur wohl ganz gerne. Nur wenn man hier halt nicht genau weiß, wofür man das eigentlich macht, dann ist das auch nicht zielführend. Ein ähnliches Konzept ist auch "plan-do-act-check". Man sieht hier auch, dass die Automotive SPICE ganz allgemeine Techniken mit in das PAM integriert hat und diese abfragt. Durch ein vorab logisch geplantes und durchgeführtes Projekt hat man die besten Chance hier richtig zu liegen.

Nicht zu vergessen bleibt dann, den Kreis zu schließen. Habe ich Abweichungen erkannt muss man sich die Frage stellen, in wie weit hat das Auswirkungen auf die gesteckten Ziele?

Zwei zentrale Begriffe wenn es um die ISO 15504 geht sind

• PAM = Process Assessment Model und
• PRM = Process Reference Model

 In dem folgenden Beitrag gehe ich auch beide Begriffe ein und beschreibe diese.

PRM = Process Reference Model

Dieses ist dafür da die Prozesse zu definieren.In einem PRM wird eine bestimmte Menge von Prozessen beschrieben. Dabei muss laut ISO 15504-2 das PRM folgende Dinge erfüllen:

• Es muss eine Domain deklarieren
• Eine Beschreibung des Prozessess enthalten welches konform zur ISO 15504-2 Abschnitt 6 ist:
  • Ein Prozess soll mit seiner Absicht und den Outcomes beschrieben sein
  • In jeder Prozessbeschreibung soll die Anzahl der Outcomes nötig und ausreichend sein um die Absicht des Prozesses zu erlangen
  • Und generell dürfen die Beschreibungen keine Aspekte des PAMs über Level 1 enthalten
• Eine Beziehung beschreiben zwischen dem PRM und dem Inhaltsbezug
• Die Beziehung zwischen den Prozessen innerhalb des PRMs beschreiben

In der folgenden Abbildung ist ein Prozess ACQ.3 Contract Agreement aus dem PRM Automotive Spice entnommen. Dort findet man die Prozess ID, den Namen, die Absicht und die Outcomes.

PAM = Process Assessment Model

Ein PAM ist immer an ein oder mehrere verschiedene PRM(s) abgelehnt. Dabei legt es praktisch die Grundlage zum Messen und zur Bewertung der gefunden Hinweise.

Das PAM beschreibt 2 Dimensionen, wobei die Prozesse (x-Achse) dem Mapping von Fähigkeitslevel/PA (y-Achse) gegenübergestellt werden und damit eine Bewertung ermöglichen.

Das PAM gibt dabei natürlich immer an,

• auf welche PRM(s) es sich bezieht,
• welche konkreten Prozesse aus dem PRM genommen worden sind (es müssen nicht alle genommen werden, sondern es kann eine selektive Auswahl erscheinen)
• welche Level aus dem PAM benutzt werden.

Desweiteren soll das PAM sogenannte Indikatoren zur Verfügung stellen, welche explizit die Outcomes des PRMs prüfen kann. PAMs müssen die Ergebnisse in einer Form die verifizierbar ist, ausdrücken können.

In der ISO 15504-2 werden verschiedene Level beschrieben, die erreicht werden können. Ein Prozesslevel besitzt verschiedene Attribute, sogenannte Prozessattribute (PA) die jedem Level zugeordnet sind.

Wir betrachten das Level 0 an der Stelle nicht - hier spricht man von einem incomplete Process, welcher auch keine PA besitzt.

Wie man oben sehen kann existieren 5 Level, jeder - bis auf Level 1 - besitzt zwei Prozess Attribute.

Diese PA's werden später benutzt für das Process Attribute Rating. Für diese PA's gibt es wiederum verschiedene GP (Generic Practices) und BP (Base Practices). Diese werden in einem Assessment bewertet, was letztendlich zu dem kompletten PA Bewertung führt.