Ein paar Gedanken aussem Ländle

Spice-Level - einfach erklärt

Nach einem CMMI-Kurs habe ich lernen dürfen, dass es sich nicht um Spice-Level handelt, sondern um CMMI-Reifegrade. Und einiges andere ist mir klarer geworden – Beitrag folgt

Was ist das CMM?

Wenn man Spice verstehen will, dann muss dort hin schauen wo alles anfängt, nämlich bei der CMM-Seite des Software engineering institutes – carnegie Mellon SEI.

CMM steht hierbei wie im Acronymtitel bereits vermerkt für den Begriff Capability Maturity Model und kann mit “Reifegradmodell” übersetzt werden. Und dieses Reifegradmodell ist schlicht und einfach erstmalig definiert worden von der Carnegie Mellon University in Pittsburgh.

Hinweis: Genau besehen gibt es Detailunterschiede im CMN und im Spice-Modell (es sind zwei verschiedene Modelle) aber diese sind für den vorliegenden Beitrag irrelevant.

Hier gibt es Reifegrade und diese haben die ganzzahlige Bewertung 1 bis 5, wobei in vielen Darstellungen die 1 als sehr schlecht suggeriert wird, die 5 als sehr gut. Doch im Grunde beschreibt es nur unterschiedliche Arbeitslevel.

Die Stufe 1 – Initial

Auf diesem Level kann jeder arbeiten, ohne dass man sich groß anstrengen muss. So jedenfalls klingt es überall heraus. Diese Arbeitsweise nennt man abwertend auch ungeplant, obwohl das eigentlich nicht zutrifft. Es ist eher eine Arbeit unter Verzicht auf die im Folgenden genannten Techniken.

Diese Stufe zeichnet sich dadurch aus, dass Erfolge extrem an Einzelne nicht austauschbare Personen gebunden sind und das der Erfolg eben ausschließlich von diesen Einzelpersonen abhängt.

Donald Rumsfeld hatte einmal den etwas hastigen und den Nachschub abhängenden Einmarsch der USA in den Irak mit “Speed Kills” bezeichnet und darum geht es hier. Hier geht es um Pionierarbeiten und um das rechtzeitig oder sogar als erster “im Markt sein”.

Beim Flugzeugbau wären damit die Arbeiten der Flugpioniere eben “initial”. Ein solches Projekt zeigt die Machbarkeit einer Sache auf und legt für spätere Projekte die Marschrichtung fest. Am Beispiel der Flugpioniere können wir auch die Projektgrößen abschätzen, die sich erreichen lassen. Einen Doppeldecker kann man “initial” entwickeln, bei einem Airbus hätte man auch nicht ansatzweise eine Chance, wollte man so vorgehen.

Vorteile der Methode sind eben die Geschwindigkeit, die Flexibilität und die Möglichkeit auch spontan die Entwicklungsrichtung zu ändern. Die Nachteile sind: Kosten, Zeiten und Qualität sind nicht vorhersehbar, mit den falschen Leuten verheizt man nur das Geld und bei einem Verkehrsunfall (die wichtigen Leute fallen aus) tritt in der Regel auch ein Totalausfall ein.

Die Stufe 2 – Repeatable

Die Stufe Repeatable setzt einen grundsätzlichen Projektentwicklungsprozess erst einmal voraus. Das bedeutet: Man hat Erfahrungen mit ähnlichen Projekten – zum Beispiel hat man einen Prototypen bereits entwickelt – und man setzt diese um, zu einer besseren Planung. Repeatable ist wie der Name bereits andeutet nur dann anwendbar, wenn man eben mindestens ein ähnliches Projekt bereits abgewickelt hat, setzt also mindestens ein “initial”-Projekt voraus.

Man muss allerdings noch eines beachten: Wenn man initial eine Melkmaschine gebaut hat, dann wird man niemals repeatable einen Mähdrescher bauen können. Infrastrukturen für Repeatable-Projekte sind leere Hülsen, wenn man nicht auf mindestens ein Initial-Projekt wird zurückgreifen können. Das muss man sich bewußt machen: Eine Firma kann per Zulassung durchaus auf dem Level “Repeatable” tätig sein, relevant sind nur die Projekte, die in diesem Dokumentationslevel zur Verfügung stehen.

Weiterhin muss man erkennen, dass dieser Level auch die Entwicklung mit unterschiedlichen Technologien voraussetzt. Eine Aufzugsteuerung kann realisiert werden elektronischen Relais, einer TTL-Logik, einer FPGA-Steuerung oder auch mit einer Steuerung über eine kommerziell erhältliche SPS. Repeatable bedeutet, dass man mit unterschiedlichen Technologien eine Lösung erarbeitet hat und hier jeweils zu brauchbaren Ergebnissen gekommen ist.

Bei einem Projekt des Levels Repeatable sind die Zeiten einigermaßen kontrollierbar. Die Kosten und die Qualität unterliegen immer noch starken Schwankungen.

Die Stufe 3 – Defined

Nach mehreren durchgeführten und intern dokumentierten “repeatable”-Projekten etabliert sich ein Standard-Entwicklungsprozess, der von einer eigenen Abteilung oder Arbeitsgruppe verwaltet und gepflegt wird. Diese Arbeitsgruppe benötigt dazu natürlich eigene “Prozesse” und damit kann man sagen: Eine Firma, die über Prozesse verfügt, die eigenen Prozesse an spezifische Probleme zu adaptieren, die erreicht den Level “defined”. Die besagte Arbeitsgruppe entwickelt und managed also den Entwicklungsprozess.

Auf dem Entwicklungslevel kann man zum Beispiel schnell abschätzen, welche technologie zu welchen Preisen führt und hier weitaus besser die einzusetzende Technologie vorgeben.

Man sagt also: Mit diesem und jenem Bundle an Technologien und Prozessen kann man dieses und jene Projekt optimal abwickeln und bearbeiten.

Das führt dazu, dass man den Prozess nicht während des Projektes adaptieren muss, sondern diesen von Anfang an schon in nahezu optimaler Form vorliegen hat. Die Folgen sind: Kosten und Zeiten sind hier einigermaßen zuverlässig bewertbar, aber die Qualität ist immer noch Schwankungen ausgesetzt.

Die Stufe 4 – Managed (oder auch bei CMMI Quantitatively Managed)

Das Adaptieren eines eigenen Prozesses oder auch die Entscheidung für eine Technologie ist zunächst einmal eine rein “emotionale Vorgehensweise”. Man hat weniger Ärger gehabt, wenn man dieses und jenes so und so macht und so weiter. Erst mit der wachsenden Zahl von Projekten, ist man in der Lage, diesen unvorhersehbaren Ereignissen eine Messmetrik gegenüberzustellen und diese monetär – also in Form von internen Entwicklungsparameters – zu bewerten. Denkbar wäre hier eine Bewertung der Art “Ärgerquotient Ä_q“

Ä_q = Anzahl der gemeldeten Bugs/Anzahl der implementierten Funktionen.

Das würde dann so aussehen, dass man ein Softwarepaket einmal in C++ entwickelt und einmal in Java und hier müsste man dann für jede Technologie Ä_q ermittel. Ggf. ist das auch abhängig von der Aufgabe und so kommt man über diese Daten eben schnell zur kostengünstigesten Technologie für die jeweilige Aufgabenstellung.

Was hier geeignet ist und was nicht, dass wird eben in der Stufe 3 herausgearbeitet und festgelegt und mit dem Festlegen eines solchen Parametersatzes kann man nun den Prozess auch numerisch optimieren.

Nun gilt: Sowohl für das Produkt als auch für den Prozess werden quantitative Ziele vorgegeben, ihre Erreichung gemessen und überwacht. Zeiten, Kosten und Qualität sind zuverlässig kontrollierbar.

Die Stufe 5 – Optimizing

Mit einer genügenden Anzahl von entsprechenden Projektparametern kann man mehr und mehr ein Projekt bezüglich der Kosten voroptimieren. Das “kalkulieren des Projektes” ist dann ein erfolgreich abgeschlossenes internes Projekt des Auftragnehmers, wenn er diese Stufe nach außen kommuniziert.

Zusammenfassung

Bei Spice-Level ist es wie mit vielem anderen auch. Die Begriffe sind nützlich und hilfreich einige Dinge zu klären bzw. kompakt an andere zu vermitteln. Sie sind ein wichtiges Werkzeug, wenn es darum geht, ein Projekt zu steuern und zu kontrollieren. Sie geben ähnlich bei beim Banken einen Ranking-Wert vor. Dessen ungeachtet muss nicht immer und überall mit Kanonen auf Spatzen geschossen werden.

Die ersten Flugzeugbauer hatten zu einem höheren Level als den Level 1 keine Chance. Trotzdem sind die Flugzeuge geflogen. Und das Fliegen war wichtig. Hier kamen “initial”-Aufträge und man konnte die Firmenstruktur aufbauen. Und heute wäre es undenkbar ein Verkehrsflugzeug unterhalb von Level 5 zu entwickeln, einfach auf Grund der inzwischen zusammenkommenden Menge an Anforderungen.

Spice-Level sind also Kennzeichen eines internen Entwicklungsstandes einer Entwicklungsabteilung eines Betriebes.

_

— Wolfgang Uhr · Freitag Dezember 19, 2008

Kommentare

Hinweise zur Kommentareingabe

Merken

Name


E-Mail


Web


Nachricht