Concetto: Gestione della configurazione e delle richieste di modifica
Questo concetto presenta l'ambito e l'operazione di Gestione delle richieste di modifica e configurazione.
Relazioni
Descrizione principale

I principali aspetti di un sistema CM in genere includono:

  • Gestione delle richieste di modifica
  • Gestione della configurazione (CM - Configuration Management)
  • Traccia delle modifiche
  • Selezione della versione

I sistemi CM possono includere anche:

  • Produzione software
  • Contabilità dello stato della configurazione e misurazione

Il cubo CM riportato di seguito, suggerendo la mutua interdipendenza, serve ad rendere graficamente i principali aspetti di un sistema CM.

Concetti: Gestione delle richieste di modifica Concetti: Gestione delle richieste di modifica Concetti: Gestione delle richieste di modifica Diagramma del cubo CM che mostra la relazioni fra Gestione delle richieste di modifica, Misurazione e Configuration Managment



  1. Gestione delle richieste di modifica (CRM, Change Request Management) - si occupa dell'infrastruttura organizzativa richiesta per valutare l'impatto, sui costi e sui tempi, di una modifica richiesta sul prodotto esistente. CRM indirizza le attività di un team di revisione delle modifiche o del quadro di controllo delle modifiche (CCC - Change Control Board).
  2. Contabilità dello stato della configurazione (Misurazione) - viene utilizzato per descrivere lo 'stato' del prodotto in base al tipo, numero, frequenza e severità dei difetti individuati e corretti durante il corso dello sviluppo del prodotto. La metrica derivata sotto questo aspetto, mediante audit o data non elaborati, è utile per determinare lo stato di completezza generale del progetto.
  3. Gestione della configurazione (CM - Configuration Management) - descrive la struttura del prodotto ed identifica gli elementi costituenti della configurazione che vengono considerati come singole entità versionabili nel processo di gestione della configurazione. CM definisce le configurazioni, crea ed etichetta, raccoglie prodotti di lavoro che dispongono di una versione in insiemi costituenti e gestisce la tracciabilità fra queste versioni.
  4. Traccia delle modifiche - descrive cosa viene effettuato sugli elementi, per quale motivo e quando. Serve da cronologia e fondamento logico delle modifiche. E' piuttosto diverso dalla valutazione dell'impatto delle modifiche proposte descritto in 'Gestione delle richieste di modifica'.
  5. Selezione della versione - lo scopo di una buona 'selezione di versione' è di garantire che siano selezionate le giuste versioni di elementi di configurazione per la modifica o l'implementazione. La selezione della versione confida in una solida base di 'identificazione della configurazione'.
  6. Produzione software - copre la necessità di automatizzare i passi per compilare, testare e impacchettare il software per la distribuzione.

RUP (Rational Unified Process) descrive un sistema CM completo che copre tutti gli aspetti della gestione della configurazione (CM). Lo scopo è di consentire un processo CM efficace che:

  • viene creato nel processo di sviluppo software.
  • facilita la gestione dell'evoluzione dei prodotti di lavoro dello sviluppo software.
  • consente agli sviluppatori di eseguire attività CM con una minima intrusione nel processo di sviluppo.

Un obiettivo del processo CM Rational è di incoraggiare il controllo delle versioni dei prodotti di lavoro catturati nei tool di sviluppo e di togliere enfasi dalla produzione inefficiente di risorse di documentazione cartacea (hardcopy).

un altro obiettivo del processo CM Rational è di verificare che il livello di controllo applicato ad ogni prodotto di lavoro si basi sul livello di maturità del prodotto. Col maturare dei prodotti di lavoro, l'autorizzazione alle modifiche passa dall'implementatore all'integratore del sottosistema o sistema, al responsabile di progetto e infine al cliente.

Per una buona l'efficienza del processo è importante verificare che le attività burocratiche associate al processo di gestione delle richieste di modifica siano coerenti con la maturità del prodotto.

Ad esempio, nelle prime iterazioni il processo CRM (Change Request Management) può essere relativamente informale. nelle fasi successive del ciclo di sviluppo il processo CRM può essere reso più rigido per essere sicuri che le risorse di test e della documentazione necessarie possano gestire e valutare la potenziale instabilità che una modifica potrebbe introdurre. Un progetto che non è in grado di personalizzare il livello di controllo durante il processo di sviluppo non è eseguito nel modo più efficiente possibile.