Background to Capability Maturity Model Integration (CMMI)

  • Articolo

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

La guida definitiva all'integrazione del modello di maturità (CMMI) per lo sviluppo è pubblicata dal Software Engineering Institute come "CMMI: Guidelines for Process Integration and Product Improvement". Questo libro descrive in modo specifico CMMI for Development (CMMI-DEV) versione 1.3, uno dei modelli all'interno della suite di prodotti CMMI. È anche possibile trovare "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" per essere un libro utile e accessibile su CMMI.

Nota

Le indicazioni fornite qui si basano sulla versione 1.3 per CMMI e supportano il processo CMMI disponibile con Azure DevOps. Al momento non esistono piani per aggiornare questo contenuto per supportare le versioni successive.

Note cronologiche

La CMMI è iniziata nel 1987 come Capability Maturity Model (CMM), un progetto presso il Software Engineering Institute (edizione Standard I). edizione Standard I è un centro di ricerca presso la Carnegie-Mellon University, che è stato istituito e finanziato dal dipartimento di difesa Stati Uniti. Pubblicato per la prima volta nel 1991, il CMM for Software è iniziato come elenco di controllo dei fattori critici di successo. Il modello si basa anche sulla ricerca presso International Business Machines (IBM) Corporation e leader di controllo qualità del XX secolo come Philip Crosby e W. Edwards Deming. Sia il nome, capability maturity model e i cinque livelli di rappresentazione a fasi sono stati ispirati dal modello di maturità di produzione di Crosby. Applicato principalmente ai programmi di difesa, CMM ha ottenuto una notevole adozione e ha subito diverse revisioni. Il suo successo ha portato allo sviluppo di CMM per una varietà di soggetti oltre il software. La proliferazione di nuovi modelli è stata confusa. In risposta, il governo ha finanziato un progetto di due anni per creare un unico framework estendibile che integra l'ingegneria dei sistemi, l'ingegneria del software e lo sviluppo di prodotti. Questo sforzo ha coinvolto più di 200 esperti accademici e del settore. Il risultato è CMMI.

CMMI-DEV è un modello. Non è un processo, né una prescrizione da seguire. CMMI-DEV offre invece un set di comportamenti organizzativi che hanno dimostrato di essere d'uso nella progettazione di sistemi e sviluppo software. Perché usare un modello di questo tipo? Qual è il suo scopo? E quanto meglio deve essere usato? Queste domande critiche sono forse i problemi più frainteso con CMMI.

Perché usare un modello?

Le attività di miglioramento richiedono un modello del funzionamento dell'organizzazione, delle funzioni necessarie e del modo in cui queste funzioni interagiscono. Un modello offre una comprensione degli elementi dell'organizzazione e assiste le discussioni su come e cosa può e dovrebbe essere migliorato.

Un modello offre i vantaggi seguenti:

  • Fornisce un framework e un linguaggio comuni per facilitare la comunicazione
  • Sfrutta anni di esperienza
  • Aiuta gli utenti a considerare l'immagine di grandi dimensioni concentrandosi sul miglioramento
  • Spesso è supportato da formatori e consulenti
  • Può aiutare a risolvere i disaccordi fornendo standard concordati

Qual è lo scopo del modello CMMI?

Lo scopo del modello CMMI è valutare la maturità dei processi di un'organizzazione e fornire indicazioni sul miglioramento dei processi, con l'obiettivo di migliorare i prodotti. CmMI è anche un modello per la gestione dei rischi e consente di misurare la capacità di un'organizzazione di gestire i rischi. Possibilità di gestire i fattori di rischio in un'organizzazione in grado di offrire prodotti di alta qualità. Un'altra prospettiva sulla gestione dei rischi è il livello di prestazioni di un'organizzazione sotto stress. Un'organizzazione ad alta maturità e elevata capacità può facilmente rispondere a eventi imprevisti e stressanti. Un'organizzazione di bassa maturità e capacità inferiore tende a prendere il panico sotto stress, seguire ciecamente le procedure obviate, o gettare tutto il processo completamente e tornare al caos.

Il CMMI, tuttavia, non è un indicatore comprovato delle prestazioni economiche di un'organizzazione. Anche se le organizzazioni con maturità più elevata possono gestire meglio i rischi e essere più prevedibili, esistono prove che le imprese di maturità più elevate tendono ad essere a rischio-inverso. L'avversione al rischio può portare a una mancanza di innovazione o a prove di una maggiore burocrazia che comporta tempi di piombo lunghi e una mancanza di competitività. Le imprese di bassa maturità tendono ad essere più innovative e creative, ma caotiche e imprevedibili. Quando si ottengono risultati, spesso sono il risultato di sforzi eroici da parte di individui o manager.

Qual è il modo migliore per usare il modello CMMI?

Il modello è stato progettato per essere utilizzato come base per un'iniziativa di miglioramento del processo, con il suo uso nella valutazione solo un sistema di supporto per misurare il miglioramento. Questo utilizzo ha avuto esito positivo. È troppo facile sbagliare il modello per una definizione di processo e provare a seguirlo, invece di una mappa che identifica le lacune nei processi esistenti che potrebbero dover essere riempiti. Il blocco predefinito fondamentale di CMMI è un'area di processo che definisce gli obiettivi e diverse attività che vengono spesso usate per soddisfarle. Un esempio di area di processo è Process e Product Quality Assurance. Un altro è Gestione configurazione. È importante comprendere che un'area di processo non è un processo. Un singolo processo può attraversare più aree di processo e un'area di processo singola può coinvolgere più processi.

CMMI-DEV è in realtà due modelli che condividono gli stessi elementi sottostanti. Il primo e più familiare è la rappresentazione a fasi, che presenta le 22 aree di processo mappate in uno dei cinque livelli di maturità dell'organizzazione. Una valutazione di un'organizzazione avrebbe valutato il livello di funzionamento, e questo livello sarebbe un indicatore della sua capacità di gestire i rischi e, come, mantenere le sue promesse.

Rappresentazione a fasi CMMI

I livelli 4 e 5 sono spesso definiti livelli di maturità più elevati. Spesso esiste una chiara differenza tra le organizzazioni con maturità più elevata, che illustrano la gestione quantitativa e l'ottimizzazione dei comportamenti e le organizzazioni con maturità inferiore, che sono semplicemente gestite o seguenti processi definiti. Le organizzazioni con maturità più elevata mostrano una variabilità inferiore nei processi e spesso usano indicatori principali come parte di un metodo di gestione statisticamente defensibile. Di conseguenza, le organizzazioni con maturità più elevata tendono a essere sia più prevedibili che più veloci a rispondere alle nuove informazioni, presupponendo che altre burocrazie non si ottengano nel modo. Quando le organizzazioni a bassa maturità tendono a dimostrare un impegno eroico, le organizzazioni con maturità elevata possono seguire i processi in caso di stress e non riconoscere che un cambiamento di processo può essere una risposta più appropriata.

La funzionalità di processo dei modelli di rappresentazione continua all'interno di ognuna delle 22 aree di processo singolarmente, che consente all'organizzazione di personalizzare i propri sforzi di miglioramento per i processi che offrono il massimo valore aziendale. Questa rappresentazione è più in linea con il modello originale di Crosby. Le valutazioni rispetto a questo modello comportano profili di capacità anziché un singolo numero. Poiché il livello di maturità dell'organizzazione è il livello che la maggior parte dei manager e dei dirigenti comprende, esistono modi per mappare i risultati di una valutazione continua del modello nelle cinque fasi.

Rappresentazione continua CMMI

L'uso del modello a fasi come base per un programma di miglioramento del processo può essere pericoloso quando gli implementatori dimenticano che cmmi non è un processo né un modello di flusso di lavoro. CmMI è invece progettato per fornire obiettivi per il processo e il flusso di lavoro da raggiungere. Il raggiungimento di tali obiettivi migliora la maturità dell'organizzazione e la probabilità che gli eventi si verifichino come pianificati. Forse la modalità di errore più grande sta facendo raggiungere un livello l'obiettivo e quindi creare processi e infrastrutture semplicemente per superare la valutazione. L'obiettivo di qualsiasi attività di miglioramento del processo deve essere un miglioramento misurabile, non un numero.

Il modello Continuo ha avuto successo come guida al miglioramento del processo. Alcune società di consulenza scelgono solo di offrire indicazioni sul modello continuo. La differenza più ovvia è che un programma di miglioramento del processo progettato per il modello continuo non ha obiettivi artificiali determinati dai livelli di maturità. Il modello Continuo si presta anche all'applicazione del miglioramento del processo in aree in cui è più probabile sfruttare un vantaggio economico per l'organizzazione. Di conseguenza, coloro che seguono il modello Continuo hanno maggiori probabilità di ricevere feedback positivo da un'iniziativa basata sul modello CMMI. Inoltre, è più probabile che il feedback positivo porti allo sviluppo di un ciclo virtuoso di miglioramenti.

Elementi del modello CMMI

La tabella seguente elenca le 22 aree di processo che comprendono il modello CMMI (versione 1.3):

Acronimo Area processo
CAR Analisi e risoluzione causali
CA Gestione della configurazione
DAR Analisi e risoluzione delle decisioni
IPM Gestione integrata dei progetti
MA Misurazione e analisi
OID Innovazione e distribuzione dell'organizzazione
OPD Definizione del processo organizzativo
OPF Focus sul processo organizzativo
OPP Prestazioni del processo organizzativo
OT Formazione organizzativa
PI Integrazione del prodotto
PMC Monitoraggio e controllo del progetto
PP Pianificazione di progetti
PPQA Process & Product Quality Assurance
QPM Gestione di progetti quantitativi
RD Definizione dei requisiti
REQM Gestione dei requisiti
RSKM Gestione dei rischi
SAM Gestione degli accordi con i fornitori
TS Technical Solution
VER Verifica
VAL Convalida

Nella rappresentazione a fasi le aree di processo vengono mappate a ogni fase, come illustrato nella figura seguente.

Rappresentazione in fase che mostra le aree di processo

Nella rappresentazione continua le aree di processo vengono mappate in raggruppamenti funzionali, come illustrato nella figura seguente.

Rappresentazione continua che mostra le aree di processo

Ogni area di processo è costituita da componenti obbligatori, previsti e informativi. Solo i componenti necessari sono effettivamente necessari per soddisfare una valutazione rispetto al modello. I componenti necessari sono gli obiettivi specifici e generici per ogni area di processo. I componenti previsti sono le procedure specifiche e generiche per ogni obiettivo specifico o generico. Si noti che, poiché un componente previsto è semplicemente previsto e non obbligatorio, ciò indica che una pratica specifica o generica può essere sostituita da una pratica equivalente. Le procedure previste sono disponibili per guidare gli implementatori e gli strumenti di valutazione. Se viene scelta una pratica alternativa, spetta al responsabile dell'implementazione consigliare una valutazione e giustificare il motivo per cui una pratica alternativa è appropriata. I componenti informativi forniscono dettagli che consentono agli implementatori di iniziare a usare un'iniziativa di miglioramento del processo guidata dal modello CMMI. I componenti informativi includono le procedure generiche e specifiche e i prodotti di lavoro tipici.

Sono necessari solo obiettivi generici e specifici. Tutto il resto viene fornito come guida. Per esempi di componenti previsti e informativi, la letteratura CMMI ha estratto dati da progetti di sistemi di difesa e spazi di grandi dimensioni. Questi progetti potrebbero non riflettere il tipo di progetti intrapresi nell'organizzazione, né potrebbero riflettere tendenze più recenti nel settore, ad esempio l'emergere di metodi di sviluppo software Agile.