Hintergrund zur Integration des Funktionsfälligkeitsmodells (CMMI)

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Der endgültige Leitfaden zur Funktionsfälligkeitsmodellintegration (CMMI) für die Entwicklung wird vom Software Engineering Institute als "CMMI: Guidelines for Process Integration and Product Improvement" veröffentlicht. Dieses Buch beschreibt insbesondere die CMMI for Development (CMMI-DEV) Version 1.3, die eine der Modelle in der CMMI-Produktsuite ist. Möglicherweise finden Sie auch "CMMI Destilliert: Eine praktische Einführung in integrierte Prozessverbesserung", um ein nützliches und barrierefreies Buch über CMMI zu sein.

Hinweis

Die hier bereitgestellten Anleitungen basieren auf Version 1.3 für CMMI und unterstützen den CMMI-Prozess, der mit Azure DevOps verfügbar ist. Derzeit sind keine Pläne vorhanden, um diese Inhalte zu aktualisieren, um spätere Versionen zu unterstützen.

Historische Notizen

Der CMMI begann 1987 als Capability Maturity Model (CMM), ein Projekt am Software Engineering Institute (SEI). SEI ist ein Forschungszentrum an der Carnegie-Mellon University, das vom USA Department of Defense gegründet und finanziert wurde. Erstmals veröffentlicht 1991 begann das CMM für Software als Checkliste kritischer Erfolgsfaktoren. Das Modell basiert auch auf forschungen der International Business Machines (IBM) Corporation und 20. Jahrhundert Qualitätssicherungsführer wie Philip Crosby und W. Edwards Deming. Sowohl der Name, das Fähigkeitsfälligkeitsmodell als auch die stufenweise Darstellung fünf Ebenen wurden von Crosbys Manufacturing Maturity Model inspiriert. Hauptsächlich auf Verteidigungsprogramme angewendet, erreichte CMM eine erhebliche Einführung und hat mehrere Überarbeitungen durchlaufen. Sein Erfolg führte zur Entwicklung von CMM für eine Reihe von Themen über Software hinaus. Die Verbreitung neuer Modelle war verwirrend. Als Reaktion finanzierte die Regierung ein zweijähriges Projekt, um ein einziges, erweiterbares Framework zu schaffen, das Systemtechnik, Softwaretechnik und Produktentwicklung integriert. Dieser Aufwand umfasste mehr als 200 Branchen- und akademische Experten. Das Ergebnis war CMMI.

CMMI-DEV ist ein Modell. Es handelt sich nicht um einen Prozess oder ein Rezept, das befolgt werden soll. Stattdessen stellt CMMI-DEV eine Reihe von Organisationsverhalten bereit, die sich als in der Softwareentwicklung und im Systems Engineering erwiesen haben. Wozu ein solches Modell? Welchem Zweck dient es? Und wie sollte man es am besten einsetzen? Diese kritischen Fragen sind vielleicht die am meisten missverstandenen Probleme mit CMMI.

Wozu ein Modell?

Verbesserungsmaßnahmen erfordern ein Modell der Funktionsweise Ihrer Organisation, welche Funktionen sie benötigen und wie diese Funktionen interagieren. Ein Modell bietet Ihnen ein Verständnis von Organisationselementen und hilft bei Diskussionen darüber, wie und was verbessert werden kann und verbessert werden soll.

Ein Modell bietet folgende Vorteile:

  • Stellt ein allgemeines Framework und eine sprache bereit, die ihnen bei der Kommunikation hilft
  • Nutzt langjährige Erfahrung
  • Hilft Benutzern, das große Bild zu berücksichtigen, während sie sich auf eine Verbesserung konzentrieren
  • Wird häufig von Trainern und Beratern unterstützt
  • Kann dazu beitragen, Meinungsverschiedenheiten zu lösen, indem vereinbarte Standards bereitgestellt werden

Wie ist die der Zweck des CMMI-Modells?

Der Zweck des CMMI-Modells besteht darin, die Reife der Prozesse einer Organisation zu bewerten und Anleitungen zur Verbesserung von Prozessen bereitzustellen, mit dem Ziel verbesserter Produkte. Außerdem ist CMMI ein Modell für das Risikomanagement und bietet eine Möglichkeit, die Fähigkeit einer Organisation zum Verwalten von Risiken zu messen. Die Fähigkeit, Risikofaktoren in einer Organisation zu verwalten, können qualitativ hochwertige Produkte liefern. Eine weitere Perspektive auf das Verwalten von Risiken besteht darin, wie gut eine Organisation unter Stress ausgeführt wird. Eine hohe Reife, eine Organisation mit hoher Funktion kann leicht auf unerwartete, stressige Ereignisse reagieren. Eine organisation mit geringer Reife und geringerEr Fähigkeit neigt dazu, unter Stress zu paniken, blind nach verworfenen Verfahren zu folgen oder alle Prozesse vollständig auszuwerfen und wieder ins Chaos zurückzurücken.

Der CMMI ist jedoch kein nachgewiesener Indikator für die wirtschaftliche Leistung einer Organisation. Obwohl höhere Fälligkeitsorganisationen Risiken besser verwalten und vorhersehbarer sein können, gibt es Nachweise, dass höhere Fälligkeitsfirmen riskant sind. Risikoabwandlung kann zu einem Mangel an Innovation oder Nachweis einer größeren Bürokratie führen, die zu langen Leadzeiten und einem Mangel an Wettbewerbsfähigkeit führt. Firmen mit geringerer Reife sind tendenziell innovativer und kreativer, aber chaotisch und unvorhersehbar. Wenn die Ergebnisse erreicht wurden, dann ist das häufig das Ergebnis heroischer Anstrengungen Einzelner oder von Managern.

Was ist die beste Möglichkeit, das CMMI-Modell zu verwenden?

Das Modell wurde als Grundlage für eine Initiative zur Prozessverbesserung entwickelt. Sein Einsatz zur Bewertung stellt nur ein Hilfsmittel zur Messung von Verbesserungen dar. Die Erfolge bei seinem Einsatz sind durchwachsen. Nur allzu leicht kann man das Modell als Prozessdefinition verstehen und versuchen, ihm zu folgen, statt es als Karte zu betrachten, die Lücken in vorhandenen Prozessen aufzeigt, die es zu füllen gilt. Fundamentaler Baustein von CMMI ist ein Prozessbereich, der Ziele und eine Reihe von Aktivitäten definiert, die häufig eingesetzt werden, um diese zu erfüllen. Ein Beispiel für Prozessgebiete sind die Prozess- und Produktqualitätssicherungsaktivitäten. Ein anderer ist das Konfigurationsmanagement. Es ist wichtig zu verstehen, dass ein Prozessgebiet kein Prozess ist. Ein einzelner Prozess kann mehrere Prozessbereiche haben und ein ein Prozessbereich wiederum mehrere Prozesse.

CMMI-DEV ist im Grunde genommen zwei Modelle mit denselben zugrunde liegenden Elementen. Das erste und vertrauteste ist die Darstellung in Reifegraden, die die 22 Prozessgebiete darstellt, die einem der fünf Reifegrade von Organisationen zugeordnet sind. Eine Bewertung einer Organisation würde die Ebene bewerten, auf der sie tätig war, und diese Ebene wäre ein Indikator für ihre Fähigkeit, Risiken zu verwalten und wie ihre Zusagen zu erfüllen.

CMMI-Stufendarstellung

Die Reifegrade 4 und 5 werden oft als höhere Reifegrade bezeichnet. Es gibt oft einen klaren Unterschied zwischen höheren Fälligkeitsorganisationen, die das quantitative Management und die Optimierung von Verhaltensweisen und niedrigeren Fälligkeitsorganisationen veranschaulichen, die lediglich verwaltet oder definierten Prozesse folgen. Höhere Fälligkeitsorganisationen zeigen eine geringere Variabilität in Prozessen und verwenden häufig führende Indikatoren als Teil einer statistisch defensiblen Managementmethode. Daher neigen höhere Fälligkeitsorganisationen dazu, sowohl vorhersehbarer als auch schneller auf neue Informationen zu reagieren, vorausgesetzt, dass andere Bürokratie nicht auf die Art und Weise kommt. Wenn Organisationen mit niedriger Reife in der Regel heroische Anstrengungen demonstrieren, können Organisationen mit hoher Reife blind den Prozessen folgen, wenn sie unter Stress stehen und nicht erkennen, dass eine Prozessänderung eine geeignetere Reaktion sein kann.

Die Prozessfunktion für kontinuierliche Darstellungsmodelle innerhalb jeder der 22 Prozessbereiche individuell, wodurch die Organisation ihre Verbesserungsbemühungen auf die Prozesse anpassen kann, die den höchsten Geschäftswert bieten. Diese Darstellung entspricht dem ursprünglichen Modell von Crosby. Bewertungen anhand dieses Modells führen zu Profilen im Zusammenhang mit der Leistungsfähigkeit und nicht zu einer einzigen Zahl. Da die fälligkeitsebene der Organisation die Ebene ist, die die meisten Manager und Führungskräfte verstehen, gibt es Möglichkeiten, die Ergebnisse einer kontinuierlichen Modellbewertung in die fünf Stufen zuzuordnen.

KONTINUIERLICHE CMMI-Darstellung

Die Verwendung des stufenden Modells als Grundlage für ein Prozessverbesserungsprogramm kann gefährlich sein, wenn Implementierunger vergessen, dass der CMMI kein Prozess oder ein Workflowmodell ist. Stattdessen soll der CMMI Ziele für Prozess und Workflow bereitstellen. Die Erfüllung solcher Ziele verbessert die Reife der Organisation und die Wahrscheinlichkeit, dass Ereignisse wie geplant auftreten. Der wahrscheinlich größte Fehler besteht darin, das Erreichen eines Reifegrads als Ziel zu setzen und dann Prozesse und eine Infrastruktur zu schaffen, um das Appraisal zu bestehen. Das Ziel jeder Prozessverbesserungsaktivität sollten messbare Verbesserungen sein und nicht eine Zahl.

Das kontinuierliche Modell hat Erfolg als Leitfaden zur Prozessverbesserung genossen. Einige Beratungsunternehmen wählen nur Anleitungen rund um das Fortlaufende Modell aus. Der offensichtlichste Unterschied besteht darin, dass ein Prozessverbesserungsprogramm, das um das fortlaufende Modell konzipiert ist, keine künstlichen Ziele hat, die von Fälligkeitsstufen bestimmt werden. Das kontinuierliche Modell bietet sich auch für die Anwendung von Prozessverbesserungen in Bereichen, in denen es am wahrscheinlichsten ist, einen wirtschaftlichen Vorteil für die Organisation zu nutzen. Deshalb erhalten alle, die dem fortlaufenden Modell folgen, auch eher positive Rückmeldungen von einer Initiative, die auf dem CMMI-Modell basiert. Außerdem führt positives Feedback eher zur Entwicklung einer Aufwärtsspirale von Verbesserungen.

Elemente des CMMI-Modells

In der folgenden Tabelle sind die 22 Prozessbereiche aufgeführt, die das CMMI-Modell (Version 1.3) umfassen:

Akronym Prozessbereich
CAR Kausale Analyseauflösung &
CM Konfigurationsverwaltung
DAR Entscheidungsanalyseauflösung &
IPM Integriertes Projektmanagement (Integrated Project Management)
NI Messanalyse &
OID Bereitstellung von Organisationsinnovationen &
OPD Organisatorische Prozessdefinition
OPF Organisationsweiter Prozessfokus
OPP Organisatorischee Prozessleistung (Organizational Process Performance)
OT Organisatorische Aus- und Weiterbildung
PI Produktintegration
PMC Projektüberwachungssteuerung &
PP Projektplanung
PPQA Prozessqualitätssicherung &
QPM Quantitatives Projektmanagement (Quantitative Project Management)
RD Anforderungsdefinition (Requirements Definition)
REQM Anforderungsmanagement (Requirements Management)
RSKM Risikomanagement
SAM Verwaltung von Lieferantenvereinbarungen (Supplier Agreement Management)
TS Technische Lösung (Technical Solution)
VER Überprüfung
VAL Überprüfen

In der Darstellung in Reifegraden werden die Prozessgebiete jeder Stufe zugeordnet, wie in der folgenden Abbildung dargestellt.

Phasendarstellung mit Prozessbereichen

In der fortlaufenden Darstellung werden die Prozessbereiche funktionalen Gruppierungen zugeordnet, wie in der folgenden Abbildung dargestellt.

Fortlaufende Darstellung mit Prozessbereichen

Jedes Prozessgebiet besteht aus benötigten, erwarteten und informativen Komponenten. Nur die verpflichtenden Komponenten sind tatsächlich erforderlich, damit einer Bewertung anhand des Modells entsprochen wird. Die benötigtem Komponenten sind die spezifischen und allgemeinen Ziele für jedes Prozessgebiet. Die erwarteten Komponenten sind die spezifische und allgemeine Praktiken für jedes spezifische oder allgemeine Ziel. Beachten Sie: Nur weil eine erwartete Komponente einfach erwartet wird und nicht erforderlich ist, kann das heißen, dass eine spezifische oder allgemeine Praktik durch eine vergleichbare ersetzt werden kann. Die erwarteten Praktiken stellen Leitlinien für die mit der Umsetzung und Bewertung betrauten Personen dar. Wird eine alternative Praktik gewählt, ist der Umsetzende aufgefordert, dies dem Bewerter zu kommunizieren und zu begründen, weshalb eine alternative Praktik angezeigt ist. Informative Komponenten liefern Details, die die Umsetzenden dabei unterstützen, eine Prozessverbesserungsinitiative in Gang zu bringen, die sich am CMMI-Modell orientiert. Informative Komponenten umfassen Unterpractices von generischen und spezifischen Methoden und typischen Arbeitsprodukten.

Nur generische und bestimmte Ziele sind erforderlich. Alles andere stellt eine Leitlinie dar. Beispiele für erwartete und informative Komponenten haben die CMMI-Literatur Daten aus großen Raum- und Verteidigungssystemen-Projekten abgerufen. Diese Projekte spiegeln möglicherweise nicht die Art von Projekten wider, die in Ihrer Organisation durchgeführt werden, oder sie spiegeln die jüngsten Trends in der Branche wider, z. B. die Entstehung von agilen Softwareentwicklungsmethoden .