Integration des Capability Maturity Model – Wikipedia

before-content-x4

Integration des Capability Maturity Model ((CMMI) ist ein Schulungs- und Bewertungsprogramm zur Verbesserung der Prozessebene. Verwaltet von der CMMI Institut, eine Tochtergesellschaft von ISACA, wurde an der Carnegie Mellon University (CMU) entwickelt. Es wird von vielen Verträgen der US-Regierung verlangt, insbesondere in der Softwareentwicklung. CMU-Ansprüche CMMI kann verwendet werden, um die Prozessverbesserung in einem Projekt, einer Abteilung oder einer gesamten Organisation zu steuern. CMMI definiert die folgenden Reifegrade für Prozesse: Anfänglich, verwaltet, definiert, quantitativ verwaltet und optimiert. Version 2.0 wurde 2018 veröffentlicht (Version 1.3 wurde 2010 veröffentlicht und ist das Referenzmodell für die verbleibenden Informationen in diesem Wiki-Artikel). CMMI ist von der CMU beim US-Patent- und Markenamt registriert.[1]

Überblick[edit]

Merkmale der Reifegrade.[2]

Ursprünglich befasst sich CMMI mit drei Interessengebieten:

  1. Produkt- und Serviceentwicklung – CMMI für Entwicklung (CMMI-DEV),
  2. Serviceeinrichtung, -verwaltung, – CMMI für Services (CMMI-SVC) und
  3. Produkt- und Servicebeschaffung – CMMI for Acquisition (CMMI-ACQ).

In Version 2.0 wurden diese drei Bereiche (die zuvor jeweils ein separates Modell hatten) zu einem einzigen Modell zusammengeführt.

CMMI wurde von einer Gruppe aus Industrie, Regierung und dem Software Engineering Institute (SEI) der CMU entwickelt. CMMI-Modelle bieten Anleitungen zur Entwicklung oder Verbesserung von Prozessen, die die Geschäftsziele einer Organisation erfüllen. Ein CMMI-Modell kann auch als Rahmen für die Beurteilung der Prozessreife der Organisation verwendet werden.[2] Bis Januar 2013 wurde die gesamte CMMI-Produktsuite vom SEI an das CMMI Institute übertragen, eine neu geschaffene Organisation bei Carnegie Mellon.[3]

Geschichte[edit]

CMMI wurde vom CMMI-Projekt entwickelt, das darauf abzielte, die Benutzerfreundlichkeit von Reifegradmodellen durch die Integration vieler verschiedener Modelle in ein Framework zu verbessern. Das Projekt bestand aus Mitgliedern der Industrie, der Regierung und des Carnegie Mellon Software Engineering Institute (SEI). Zu den Hauptsponsoren gehörten das Büro des Verteidigungsministers (OSD) und die National Defense Industrial Association.

CMMI ist der Nachfolger des Capability Maturity Model (CMM) oder Software CMM. Das KMG wurde von 1987 bis 1997 entwickelt. Im Jahr 2002 wurde Version 1.1 veröffentlicht, Version 1.2 folgte im August 2006 und Version 1.3 im November 2010. Einige wichtige Änderungen in CMMI V1.3 [4] sind die Unterstützung der agilen Softwareentwicklung,[5] Verbesserungen der Praktiken mit hoher Reife[6] und Ausrichtung der Darstellung (inszeniert und kontinuierlich).[7]

Laut dem Software Engineering Institute (SEI, 2008) hilft CMMI dabei, “traditionell getrennte Organisationsfunktionen zu integrieren, Ziele und Prioritäten für die Prozessverbesserung festzulegen, Leitlinien für Qualitätsprozesse bereitzustellen und einen Bezugspunkt für die Bewertung aktueller Prozesse bereitzustellen”.[8]

Im März 2016 wurde das CMMI-Institut von ISACA übernommen.

CMMI-Themen[edit]

Darstellung[edit]

In Version 1.3 gab es CMMI in zwei Darstellungen: kontinuierlich und inszeniert.[2] Die fortlaufende Darstellung soll es dem Benutzer ermöglichen, sich auf die spezifischen Prozesse zu konzentrieren, die für die unmittelbaren Geschäftsziele des Unternehmens als wichtig angesehen werden oder denen das Unternehmen ein hohes Maß an Risiken zuweist. Die inszenierte Darstellung soll eine Standardsequenz von Verbesserungen bieten und als Grundlage für den Vergleich der Reife verschiedener Projekte und Organisationen dienen. Die abgestufte Darstellung ermöglicht auch eine einfache Migration vom SW-CMM zum CMMI.[2]

In Version 2.0 wurde die obige Darstellungstrennung aufgehoben und es gibt nur noch ein zusammenhängendes Modell.

[9]

Modellrahmen (v1.3)[edit]

Abhängig von den verwendeten Interessenbereichen (Akquisition, Dienstleistungen, Entwicklung) variieren die darin enthaltenen Prozessbereiche.[10]Prozessbereiche sind die Bereiche, die von den Prozessen der Organisation abgedeckt werden. In der folgenden Tabelle sind die siebzehn CMMI-Kernprozessbereiche aufgeführt, die für alle CMMI-Bereiche von Interesse in Version 1.3 vorhanden sind.

Kernprozessbereiche der Capability Maturity Model Integration (CMMI)

Abkürzung Prozessbereich Kategorie Reifegrad
WAGEN Ursachenanalyse und -lösung Unterstützung 5
CM Konfigurationsmanagement Unterstützung 2
DAR Entscheidungsanalyse und Auflösung Unterstützung 3
IPM Integriertes Projektmanagement Projektmanagement 3
MA Messung und Analyse Unterstützung 2
OPD Definition des Organisationsprozesses Prozessmanagement 3
OPF Organisationsprozessfokus Prozessmanagement 3
OPM Organisatorisches Leistungsmanagement Prozessmanagement 5
OPP Leistung des Organisationsprozesses Prozessmanagement 4
OT Organisationstraining Prozessmanagement 3
PMC Projektüberwachung und -steuerung Projektmanagement 2
PP Projektplanung Projektmanagement 2
PPQA Prozess- und Produktqualitätssicherung Unterstützung 2
QPM Quantitatives Projektmanagement Projektmanagement 4
REQM Anforderungsmanagement Projektmanagement 2
RSKM Risikomanagement Projektmanagement 3
SAM Management von Lieferantenvereinbarungen Unterstützung 2

Reifegrad für Dienstleistungen[edit]

Die folgenden Prozessbereiche und ihre Reifegrade sind für das CMMI for Services-Modell aufgeführt:

Reifegrad 2 – verwaltet

  • CM – Konfigurationsmanagement
  • MA – Messung und Analyse
  • PPQA – Prozess- und Qualitätssicherung
  • REQM – Anforderungsmanagement
  • SAM – Lieferantenvertragsmanagement
  • SD – Servicebereitstellung
  • WMC – Arbeitsüberwachung und -steuerung
  • WP – Arbeitsplanung

Reifegrad 3 – definiert

  • CAM – Kapazitäts- und Verfügbarkeitsmanagement
  • DAR – Entscheidungsanalyse und Auflösung
  • IRP – Incident Resolution and Prevention
  • IWM – Integriertes Arbeitsmanagement
  • OPD – Definition des Organisationsprozesses
  • OPF – Organisationsprozessfokus …
  • OT – Organisationstraining
  • RSKM – Risikomanagement
  • SCON – Service Continuity
  • SSD – Service System Development
  • SST – Service System Transition
  • STSM – Strategisches Service Management

Reifegrad 4 – Quantitativ verwaltet

  • OPP – Organisatorische Prozessleistung
  • QWM – Quantitatives Arbeitsmanagement

Reifegrad 5 – Optimierung

  • CAR – Ursachenanalyse und -auflösung.
  • OPM – Organisatorisches Leistungsmanagement.

Modelle (v1.3)[edit]

Best Practices für CMMI werden in Dokumenten veröffentlicht, die als Modelle bezeichnet werden und jeweils einen anderen Interessenbereich ansprechen. Version 1.3 bietet Modelle für drei Bereiche von Interesse: Entwicklung, Akquisition und Services.

  • CMMI für Entwicklung (CMMI-DEV), v1.3 wurde im November 2010 veröffentlicht. Es befasst sich mit Produkt- und Serviceentwicklungsprozessen.
  • CMMI für die Akquisition (CMMI-ACQ), v1.3 wurde im November 2010 veröffentlicht. Es befasst sich mit Supply-Chain-Management-, Akquisitions- und Outsourcing-Prozessen in Regierung und Industrie.
  • CMMI für Dienste (CMMI-SVC), v1.3 wurde im November 2010 veröffentlicht. Es enthält Leitlinien für die Bereitstellung von Diensten innerhalb eines Unternehmens und für externe Kunden.

Modell (v2.0)[edit]

In Version 2.0 DEV wurden ACQ und SVC zu einem einzigen Modell zusammengeführt, in dem jeder Prozessbereich möglicherweise einen spezifischen Verweis auf einen oder mehrere dieser drei Aspekte enthält. Um mit der Branche Schritt zu halten, bezieht sich das Modell auch explizit auf agile Aspekte in einigen Prozessbereichen.

Einige wichtige Unterschiede zwischen den Modellen v1.3 und v2.0 sind nachstehend aufgeführt. Dies ist keine vollständige Liste.

  1. “Prozessbereiche” wurden durch “Übungsbereiche (PAs)” ersetzt. Letzteres ist nach Ebenen geordnet, nicht nach “Spezifischen Zielen”.
  2. Jede PA besteht aus einem “Kern” [i.e. a generic and terminology-free description] und “kontextspezifisch” [ i.e. description from the perspective of Agile/ Scrum, development, services, etc.] Sektion.
  3. Da jetzt alle Praktiken zur Einhaltung verpflichtet sind, wurde der Abschnitt “Erwartet” entfernt.
  4. “Allgemeine Praktiken” wurden in einen neuen Bereich mit dem Namen “Governance and Implementation Infrastructure” eingeordnet, während “Spezifische Praktiken” weggelassen wurden.
  5. Der Schwerpunkt liegt auf der Sicherstellung der Implementierung von PAs und darauf, dass diese kontinuierlich praktiziert werden, bis sie zur “Gewohnheit” werden.
  6. Alle Reifegrade konzentrieren sich auf das Schlüsselwort “Leistung”.
  7. Zwei und fünf optionale PAs aus den Bereichen “Sicherheit” und “Sicherheit” wurden aufgenommen.
  8. PCMM-Prozessbereiche wurden zusammengeführt.

Bewertung[edit]

Eine Organisation kann nicht in CMMI zertifiziert werden. stattdessen ist eine Organisation bewertet. Abhängig von der Art der Bewertung kann die Organisation eine Reifegradbewertung (1–5) oder ein Leistungsprofil für die Fähigkeitsstufe erhalten.

Viele Organisationen legen Wert darauf, ihren Fortschritt durch eine Bewertung zu messen. Bewertungen werden normalerweise aus einem oder mehreren der folgenden Gründe durchgeführt:

  1. Feststellen, wie gut die Prozesse des Unternehmens mit den Best Practices von CMMI verglichen werden, und Bereiche identifizieren, in denen Verbesserungen möglich sind
  2. Um externe Kunden und Lieferanten darüber zu informieren, wie gut die Prozesse des Unternehmens im Vergleich zu Best Practices von CMMI sind
  3. Um die vertraglichen Anforderungen eines oder mehrerer Kunden zu erfüllen

Bewertungen von Organisationen anhand eines CMMI-Modells[11] muss den Anforderungen entsprechen, die im Dokument „Appraisal Requirements for CMMI (ARC)“ definiert sind. Es gibt drei Bewertungsklassen, A, B und C, die sich darauf konzentrieren, Verbesserungsmöglichkeiten zu identifizieren und die Prozesse des Unternehmens mit den Best Practices von CMMI zu vergleichen. Von diesen ist die Beurteilung der Klasse A die formellste und die einzige, die zu einer Stufenbewertung führen kann. Bewertungsteams verwenden ein CMMI-Modell und eine ARC-konforme Bewertungsmethode, um ihre Bewertung der Organisation und ihre Berichterstattung über Schlussfolgerungen zu steuern. Die Bewertungsergebnisse können dann verwendet werden (z. B. von einer Prozessgruppe), um Verbesserungen für die Organisation zu planen.

Die Standard-CMMI-Bewertungsmethode zur Prozessverbesserung (SCAMPI) ist eine Bewertungsmethode, die alle ARC-Anforderungen erfüllt.[12] Die Ergebnisse einer SCAMPI-Bewertung können (sofern die bewertete Organisation zustimmt) auf der CMMI-Website des SEI veröffentlicht werden: Veröffentlichte SCAMPI-Bewertungsergebnisse. SCAMPI unterstützt auch die Durchführung von ISO / IEC 15504, auch bekannt als SPICE (Software Process Improvement and Capability Determination), Assessments usw.

Dieser Ansatz fördert, dass Mitglieder des EPG und der PATs im CMMI geschult werden, dass eine informelle Bewertung (SCAMPI C) durchgeführt wird und dass Prozessbereiche zur Verbesserung priorisiert werden. Modernere Ansätze, bei denen kommerziell erhältliche, CMMI-konforme Prozesse eingesetzt werden, können die Zeit bis zur Einhaltung erheblich verkürzen. SEI hat Statistiken über die “Zeit bis zum Aufstieg” für Unternehmen geführt, die sowohl das frühere Software-CMM als auch das CMMI einsetzen.[13] Aus diesen Statistiken geht hervor, dass seit 1987 die mittlere Zeit für den Wechsel von Stufe 1 zu Stufe 2 23 Monate und von Stufe 2 zu Stufe 3 weitere 20 Monate beträgt. Seit der Veröffentlichung des CMMI beträgt die mittlere Zeitspanne für den Übergang von Stufe 1 zu Stufe 2 5 Monate, während die mittlere Bewegung für Stufe 3 weitere 21 Monate beträgt. Diese Statistiken werden alle sechs Monate in einem Fälligkeitsprofil aktualisiert und veröffentlicht.[citation needed]

Die Team-Software-Prozessmethodik des Software Engineering Institute (SEI) und die Verwendung von CMMI-Modellen können verwendet werden, um den Reifegrad zu erhöhen. Ein neues Produkt namens Accelerated Improvement Method[14] (AIM) kombiniert die Verwendung von CMMI und TSP.[15]

Sicherheit[edit]

Um Sicherheitsbedenken der Benutzer auszuräumen, stehen zwei inoffizielle Sicherheitsleitfäden zur Verfügung. Berücksichtigung des Falls für Sicherheitsinhalte in CMMI for Services hat einen Prozessbereich, Sicherheitsmanagement.[16]Security by Design mit CMMI for Development, Version 1.3 hat folgende Prozessbereiche:

  • OPSD – Organisatorische Bereitschaft zur sicheren Entwicklung
  • SMP – Secure Management in Projekten
  • SRTS – Sicherheitsanforderungen und technische Lösung
  • SVV – Sicherheitsüberprüfung und -validierung

Diese Prozessbereiche haben zwar keinen Einfluss auf die Reife oder den Fähigkeitsgrad, können jedoch in den Bewertungsergebnissen angegeben werden.[17]

Anwendungen[edit]

Die SEI veröffentlichte eine Studie, in der 60 Organisationen Leistungssteigerungen in den Kategorien Kosten, Zeitplan, Produktivität, Qualität und Kundenzufriedenheit gemessen haben.[18] Die mittlere Leistungssteigerung variierte zwischen 14% (Kundenzufriedenheit) und 62% (Produktivität). Das CMMI-Modell befasst sich jedoch hauptsächlich mit Was Prozesse sollten implementiert werden, und nicht so sehr mit Wie Sie können implementiert werden. Diese Ergebnisse garantieren nicht, dass die Anwendung von CMMI die Leistung in jeder Organisation erhöht. Ein kleines Unternehmen mit wenigen Ressourcen profitiert möglicherweise weniger von CMMI. Diese Ansicht wird von der unterstützt Prozessreifeprofil (Seite 10). Von den kleinen Organisationen (<25 Mitarbeiter) werden 70,5% auf Stufe 2: Verwaltet bewertet, während 52,8% der Organisationen mit 1.001 bis 2.000 Mitarbeitern auf der höchsten Ebene bewertet werden (5: Optimierung).

Turner & Jain (2002) argumentieren, dass obwohl es offensichtlich große Unterschiede zwischen CMMI und agiler Softwareentwicklung gibt, beide Ansätze viel gemeinsam haben. Sie glauben, dass keiner der beiden Wege der „richtige“ Weg ist, um Software zu entwickeln, sondern dass es Phasen in einem Projekt gibt, in denen einer der beiden besser geeignet ist. Sie schlagen vor, die verschiedenen Fragmente der Methoden zu einer neuen Hybridmethode zu kombinieren. Sutherland et al. (2007) behaupten, dass eine Kombination aus Scrum und CMMI mehr Anpassungsfähigkeit und Vorhersagbarkeit bringt als beide allein.[19] David J. Anderson (2005) gibt Hinweise, wie CMMI agil interpretiert werden kann.[20]

CMMI Roadmaps,[21] Ein zielgerichteter Ansatz zur Auswahl und Bereitstellung relevanter Prozessbereiche aus dem CMMI-DEV-Modell kann Leitlinien und Schwerpunkte für eine effektive CMMI-Einführung liefern. Für die kontinuierliche Darstellung gibt es mehrere CMMI-Roadmaps mit jeweils spezifischen Verbesserungszielen. Beispiele sind die CMMI-Projekt-Roadmap,[22] Roadmaps für CMMI-Produkte und Produktintegration[23] und die Roadmaps für CMMI-Prozesse und -Messungen.[24] Diese Roadmaps kombinieren die Stärken sowohl der inszenierten als auch der kontinuierlichen Darstellungen.

Die Kombination der Projektmanagementtechnik Earned Value Management (EVM) mit CMMI wurde beschrieben (Solomon, 2002). Um mit einer ähnlichen Verwendung von CMMI abzuschließen, wurde Extreme Programming (XP), eine Software-Engineering-Methode, mit CMM / CMMI evaluiert (Nawrocki et al., 2002). Beispielsweise wurde der XP-Anforderungsmanagementansatz, der auf mündlicher Kommunikation beruht, als nicht CMMI-konform bewertet.

CMMI kann mit zwei verschiedenen Ansätzen bewertet werden: inszeniert und kontinuierlich. Der abgestufte Ansatz liefert Bewertungsergebnisse als eines von fünf Reifegrad. Der kontinuierliche Ansatz ergibt einen von vier Fähigkeitsstufen. Die Unterschiede in diesen Ansätzen sind nur in der Bewertung zu spüren; Die Best Practices sind gleichwertig, was zu gleichwertigen Ergebnissen bei der Prozessverbesserung führt.

Siehe auch[edit]

Verweise[edit]

Offizielle Quellen[edit]

SEI-Berichte
SEI-Webseiten

Externe Links[edit]


after-content-x4