CMMI 1.3 Änderungen

CMMI in Version 1.3 ist nun auch schon Ewigkeiten veröffentlicht und nun mache ich endlich mal den das CMMI Version 1.3 Model Upgrade Training. Das Training kann man für 200 US-Dollar online absolvieren und ich versuche mal, parallel die Änderungen grob aufzulisten.

Allgemeine Änderungen

• Disciplines sind umbenannt worden in areas of interest, also acquisition, development oder services
• Der Begriff constellation (Kostellation) ist neu.
• Eine core process area ist ein Prozessgebiet, das es in allen CMMI Modellen gibt. 16 Prozessgebiete gibt es sowohl in CMMI for Developement, Acquisition, als auch Service.
• Eine shared process area gibt es in mindestens zwei Modellen.
• Beschreibungen der einzelnen Modellkomponenten wurden angepasst.
• Typical work products wurden umbenannt in example work products, da sie als informative Modellkomponente zu wichtig genommen wurden.
• Die stages representation galt als erprobt und wurde in der Vergangenheit detaillierter beschrieben; dies wurde angeglichen.
• Die Modellkomponente amplification war immer etwas steifmütterlich behandelt und daher verwirrend. Sie wurde gestrichen. Sinnvolle Anmerkungen findet man nun in Form von Notizen oder Beispielen.
• Referenzen innhalb des Modells wurde verbessert.
• In den Prozessgebiet-Kategorien wurde aufgeräumt, so dass bspw. im CMMI-DEV-Modell REQM in Project Management verschoben wurde, um konsistent zu sein mit den anderen Modellen.
• Die Konsistenz zwischen den drei Modellen (Development, Acquisition, Service) wurde verbessert.
• Die Definition von Begriffen wurde verbessert; Inkonsistenzen zwischen den Modellen, aber auch zum ISO-Standard wurden eleminiert, missverständliche Formulierungen überarbeitet.
• Das vorher optionale Add-on Integrated Product and Process Developement (IPPD) wurde in weniger als 5% der vergangenen Appraisals bewertet. Das Add-on wurde entfernt, da Team-Bildung aber oft entscheidend für den Projekterfolg ist, wurden die Teaming-Konzepte für alle drei Modelle konsistent integriert.
• Der Begriff integrated team wurde durch Team ersetzt.
• CMMI-DEV erhält wie schon CMMI-ACQ und CMMI-SVC IPM SP 1.6 Teams etablieren.
• Der Begriff „Projekt“ war verständlich für Entwickler und Einkäufer, aber nicht für Dienstanbieter, so dass er in CMMI-SVC ersetzt wurde durch andere Begriffe (etwa work, word group). Somit ändert sich der Prozessbereich Project Planning (PP) in Work Planning (WP). Konsequenterweise wird der Project Plan dann auch zum Work Plan.
• Diverse Wörter in Ziel- und Praktiktiteln wurden ausgetauscht, um Missverständnissen vorzubeugen. Vermieden wurden etwa Wörter wie appropriate, best, designated, effectively, essential, most important, necessary, realistic, reasonable, relevant.
• Irreführende Formulierungen in den Generischen Praktischen wurde entsprechend geändert.
• CMMI funktioniert auch für Agile Entwicklung. Diverse Prozessbereiche wurde durch entsprechende Anmerkungen ergänzt, für CMMI-DEV sogar ein eigenes Kapitel eingefügt (Interpreting CMMI When Using Agile Approaches).
• Der Prozessbereich Ursachenanalyse und -beseitigung (CAR) liegt auf Reifegrad 5, viele unreifere Organisation sehen darin aber auch schon Sinn. Daher wurde bspw. QPM SP 2.3 Ursachenanalyse durchführen eingefügt.
• Kundenzufriedenheit wurde bisher wenig adressiert; informatives Material wurde entsprechend ergänzt.
• Viele Inhalte bzgl. Engineering-Methodiken in v1.2 sind mehr als zehn Jahre alt. Konzepte wie nicht-funktionale Anforderungen, Produktlinien, System of sytems oder architektur-zentrierte Entwicklung sind kaum adressiert. Das Glossar und das informative Material wurde entsprechend ergänzt, RD SP 3.2 beinhaltet nun auch neben Funktionalität auch die Nennung von Qualitätsattributen.
  
• Besonders in CMMI-DEV wurden Prioritäten des Kunden kaum beachtet. So spricht RD SP 1.2 nun vom Überführen von Stakeholder-Bedürfnissen in Kundenanforderungen, nicht mehr nur vom Entwickeln dieser.
• Einige informative Komponenten behandeln nun die Existenz von organisationsweiten Verträgen, etwa bevorzugte Lieferanten.
• Formulierungen, die Probleme bereiten könnten beim Übersetzen des Modells in andere Sprachen, wurde vermieden.

Änderungen in den Prozessgebieten

Im folgenden seien einige Änderungen gelistet, die sich in den einzelnen Prozessgebieten ergeben. Ich betrachte dabei nur die CMMI-DEV Prozessgebiete, wobei die ersten auch in CMMI-ACQ und CMMI-SVC vorhanden sind. In allen Prozessgebieten wurde das informative Material geändert.

Configuration Management (CM)

• Keine gravierenden Änderungen.
• Aus dem Glossar entfernt wurden die Begriffe functional configuration audits und physical configuration audits.
• Infos zum Behandeln von Hardware wurden hier und da hinzugefügt.
• Anwendung von CM in agilen Umgebungen
• Subpraktiken bzgl. Zugangskontrolle zum CM-System oder Kategorisierung von Change Requests
• beim Prüfen der Baseline-Integrität muss die Konsistenz zwischen den CIs geprüft werden

Decision Anlysis and Resolution (DAR)

• keine großen Änderungen an Zielen und Praktiken

Integrated Project Managemennt (IPM)

• SG3 (IPPD) gelöscht
• Subpraktik 5 in SP 1.5 hinzugefügt, um zu erinnern, dass Ursachenanalyse Sinn macht
• SP 1.6 „Teams etablieren“ hinzugefügt
• im Glossar wurden die folgenden Begriffe überarbeitet: project, project startup, team
• der Begriff program wurde aus dem Glossar gelöscht

Measurement and Anaylses (MA)

• kieine wesentlichen Ändeurngen an Zielen, Praktiken und Begriffen
• Zusammenhang zwischen information needs and objectives, measurement objectives und business/project objectives besserherausgearbeitet
• Infos zu Kundenzufriedenheit hinzugefügt
• Tabelle mit Beispielen hinzugefügt

Organizational Process Definition (OPD)

• IPPD entfernt (inkl. SG 2)
• SP 1.7 „Regeln und Richtlinien für Teams etablieren“ hinzugefügt
• Begriff integrated team durch team ersetzt

Organizational Process Focus (OPF)

• keine wesentlichen Änderungen
• Formulierung vereinfacht vom Sammeln von process-related work products, measures, and improvement information zum Sammeln von  process related experience
• Hinweise zum Auswerten von Kundenzufriedenheit als Quelle für Prozessverbesserung

Organizational Training (OT)

• Anpassungen, da der Begriff „technische“ Schulung nicht zu allen drei Modellen passt
• der subjektive Begriff necessary wurde aus der Zielbeschreibung entfernt (Provide Necessary Training)
• keine wesentlichen Änderungen sonst

Project Monitoring and Control (PMC)

• keine wesentlichen Änderungen an Zielen und Praktiken
• im Glossar wurden die folgenden Begriffe überarbeitet: project, project startup
• der Begriff program wurde aus dem Glossar gelöscht

Project Plannung (PP)

• keine wesentlichen Änderungen an Zielen und Praktiken
• im Glossar wurden die folgenden Begriffe überarbeitet: project, project startup
• der Begriff program wurde aus dem Glossar gelöscht
• Informationen hinzugefügt, wie PP für Produktlinien und agilen Ansätzen anzuwenden ist
• IPPD-Material entfernt
• einige Subpraktiken hinzugefügt

Process and Product Quality Assurance (PPQA)

• keine wesentlichen Änderungen an Zielen oder Begriffen
• designated geändert zu selected, um klarzustellen, dass nicht nur benannt, sondern auch ausgewählt werden soll, was betrachtet wird
• klargestellt, dass PPQA sich auf Projekt- und Organisationsebene bezieht
• in der Einleitung wurde darauf Bezug genommen, wie PPQA in agilen Umgebungen angewandt wird
• Subpraktiken verallgemeinert formuliert

Requirements Management (REQM)

• keine wesentlichen Änderungen an Zielen oder Begriffen
• SP 1.5 geändert (jetzt „Abstimmung zwischen Projektarbeit und Anforderungen sicherstellen„), um die Intention der Praktik klarer zu machen. Es geht mehr darum, dass Pläne und Arbeitsergebnisse zu den Anforderungen passen, als um das Finden von Inkonsistenzen.
• Infos, wie REQM in agilen Umgebungen Anwendung findet
• Traceability in SP 1.4 verdeutlicht
• agreed-on requirements geändert approved requirements, um klarzustellen, was die Basis für die weitere Entwicklung ist
• REQM gehört nun nicht mehr zur Kategorie Engineering, sondern zu Project Management

Risk Managemennt (RSKM)

• keine wesentlichen Änderungen an Zielen oder Begriffen
  
• Infos, wie RSKM in agilen Umgebungen Anwendung findet
• weitere Beispiele und Infos gegeben

 Supplier Agreement Management (SAM)

• keine wesentlichen Änderungen an Zielen
• in SP 1.3 von format agreements zu supplier agreements geändert
• SP 2.2 (Monitor Selected Supplier Agreements) und SP 2.3 (Evaluate Selected Supplier Work Products) wurden als SPs gestrichen und werden nun als Subpraktiken von SP 2.1 geführt; SP 2.5 wird damit zu SP 2.3
• SP 2.3 (ehemals SP 2.5) berücksichtigt nun Fälle, wo der Lieferant direkt an den Kunden liefert
• zusätzliche Glossar-Begriffe: acquirer, contractual requirements, deliverable, solicitation package, supplier agreement
• das Konzept products and processes of significant value to the project wurde hinzugefügt, um die Frage zu erleichtern, was überwacht und bewertet werden sollte

Requirements Development (RD)

• SG 3, SP 3.2, informatives Material und Begriffe wurden angepasst, um moderne Entwicklungs-Methoden einzubeziehen
• SP 1.2 wurde umbenannt von Transform Stakeholder Needs zu Transform Customer Needs, um klarzustellen, dass das Ergebnis priorisierte Kundenanforderungen sein sollten
• Infos hinzugefügt, wie RD in agilen Umgebungen Anwendung funktioniert
• neue oder geänderte Begriffe: quality attributes, architecture, definition of required functionality and quality attributes, allocated requirement, functional analysis, product line

Technical Solution (TS)

• keine wesentlichen Änderungen an Praktiken, Zielen, Begriffen
• reflektieren moderner Entwicklungs-Methoden
• Infos, wie TS in agilen Umgebungen funktioniert
• weitere Beispiele und Hilfen

Product Integration (PI)

• keine wesentlichen Änderungen an Zielen
• in SP 1.1 geändert von integration sequence zu integration strategy, um die Komplexität dieser Aktivität klarzustellen
• reflektieren moderner Entwicklungs-Methoden
• Infos, wie PI in agilen Umgebungen funktioniert
• weitere Beispiele und Hilfen

Verification (VER)

• keine wesentlichen Änderungen an Zielen, Praktiken, Begriffen
• reflektieren moderner Entwicklungs-Methoden
• Infos, wie VER in agilen Umgebungen funktioniert
• weitere Beispiele und Hilfen

Validation (VAL)

• keine wesentlichen Änderungen an Zielen, Praktiken, Begriffen
• klargestellt, wann Validierung innerhalb des Produktlebenszyklus‘ stattfindet
• inkrementelle Auslieferung als Beispiel-Validierungsmethode aufgelistet
• das Lösen von Defekten addressiert, die während der Validierung gefunden wurden

High Maturity Änderungen

Diverse Änderungen gab es an den High Maturity Konzepten (Reifegrade 4 und 5). Die Konzepte und Begriffe waren verwirrend, Erklärungen gab es nicht an zentraler Stelle, die Wahrnehmung war verdreht, etwa

• Kunden: „Reifegrad 5 ist teuer und bringt nicht mehr als Reifegrad 3.“
• Industrie: „Reifegrad 5 ist nicht für jedes Unternehmen das Richtige.“

Ich werde die einzelnen Änderungen hier nicht auflisten. Sorry. Wer sich mit Reifegrad 4 und 5 beschäftigt, braucht diesen Artikel ohnehin nicht ;-)