CM wird in allen Modellen als Aktivität gefordert, jedes Modell misst CM aber einen anderen Stellenwert zu und macht Vorgaben in unterschiedlicher Detailtiefe.
CMMI
CMMI als weit verbreitetes Vorgehensmodell in der Softwareindustrie fordert Configuration Management, um den Reifegrad 2 für den Softwareentwicklungsprozess zu erreichen, d.h. Configuration Management wird als Basis für ein kontrolliertes Arbeiten und das Erlangen höherer Reifegrade angesehen.
CM dient nach CMMI im wesentlichen dazu, die Integrität von Arbeitsergebnissen innerhalb des Softwarelebenszyklus sicherzustellen.
Es werden auf hohem Abstraktionsgrad Vorgaben zu Rollen und Verfahren gemacht Einzelne Aktivitäten wie das Festlegen von Baselines, das Steuern und Verfolgen von Änderungen, das Durchführen von Audits werden ebenfalls auf hohem Abstraktionsgrad beschrieben.
CMII
CMII ist ein Vorgehensmodell, welches CM mit seinen Basisaktivitäten Identification und Storage in den Mittelpunkt der Betrachtungen stellt und darauf aufbauend sehr detailliert und vollständig Rollen, Boards und deren Aufgaben, sowie einen in sich geschlossenen Änderungsprozess definiert.
SPICE – ISO 15504
SPICE (Software Process Improvement and Capability dEtermination) ist ein weitverbreiteter internationaler Standard und grundsätzlich CMMI ähnlich. SPICE wird zur Bewertung (Assessment) von Unternehmensprozessen und deren Verbesserung, anhand eines Referenzmodells eingesetzt.
Im SPICE Referenzmodell nimmt CM die Stellung eines Support Lifecycle ein (SUP.08), dessen Zweck ähnlich der Definition im CMMI-Modell ist.
Es werden im SPICE-Referenzmodell jedoch darüber hinaus, sehr konkret für den CM Prozess die Ergebnisse (Outcomes ), Aktivitäten (Base Practices) und Arbeitsprodukte (Work Products) definiert.
Zudem gibt es gegenüber CMMI die Trennung zwischen Configuration Management and Change Management.
CMII erweitert den Fokus von klassischem CM und propagiert einen einheitlichen Prozess für Requirements-, Change- und Problem Management. Insbesondere wird die aktive Planung von Konfigurationen in den Vordergrund gestellt.
RUP
Der Rational Unified Process spiegelt das Wissen einer Vielzahl von Software-Entwicklungsspezialisten wieder, ist praxisorientiert und wird in vielen Softwareunternehmen als konkrete Prozessvorgabe eingesetzt.
Innerhalb des RUP wird ein Konfigurations- und Änderungsmanagement Workflow als Core Workflow definiert, der für jedes Projekt etabliert werden muß. Es werden grob die Rollen und Gremien, sowie deren Aufgaben innerhalb des Workflows benannt und die wesentlichen Inhalte eines KM-Plans beschrieben. Außerdem erfolgt die Einordnung in den gesamten Softwareentwicklungsprozess.
V Modell XT
Das Vorgehensmodell des Bundes fasst das Configuration Management in einem so genannten verpflichtenden Vorgehensbaustein zusammen, der für alle Projekttypen des V-Modells (Auftraggeber, Auftragnehmer und Einführungsprojekt) obligatorisch ist.
Ziel des CM nach dem V-Modell XT ist die gegenwärtige und vergangene Produktkonfiguration eines Systems sowie den Stand der Erfüllung seiner physischen und funktionalen Anforderungen zu dokumentieren und jederzeit während des gesamten Systemlebenszyklus volle Transparenz darüber herzustellen. Die Aktivitäten innerhalb CM werden knapp und auf hohem Abstraktionsgrad beschrieben, ebenso die Inhalte des CM-Plan, Rollen und Boards (CM-Administrator, CM-Verantwortlicher, Lenkungsausschuss) und deren Aufgaben.
XP / agile Softwareentwicklung
Gerade aufgrund ihrer propagierten dynamischen und flexiblen Vorgehensweisen, insbesondere der kurzen Releasezyklen und dem weitgehenden Verzicht auf Dokumentation benötigen diese Modelle ein gut funktionierendes Version-, Change-, Build- und Test- Management.
In den Modellen selbst werden die Anforderungen an CM nicht definiert, es wird nur auf die Nutzung von bewährten Verfahren in diesem Bereich verwiesen.
Bei zunehmender Projektkomplexität sind allerdings die XP zugrunde liegenden Prinzipien problematisch und ergänzende formale Vorgehensweisen sollten eingesetzt werden.
