Condividi tramite


Informazioni generali su CMMI

La guida definitiva a Capability Maturity Model Integration (CMMI) per lo sviluppo è pubblicata a cura del Software Engineering Institute con il titolo "CMMI: Guidelines for Process Integration and Product Improvement". Nel libro viene offerta una descrizione specifica di CMMI for Development (CMMI-DEV) versione 1.3,uno dei modelli della famiglia di prodotti CMMI più recente al momento della pubblicazione del presente documento. Questo modello è estremamente stabile e dovrebbe rimanere attuale ben oltre il 2010. È anche disponibile "CMMI Distilled: A Practical Introduction to Integrated Process Improvement", un'altra utile e accessibile pubblicazione sullo stesso argomento. Per altre informazioni su entrambi i libri sopra menzionati, vedere Risorse aggiuntive più avanti in questo argomento.

CMMI nasce nel 1987 come Capability Maturity Model (CMM), un progetto del Software Engineering Institute, che è un centro di ricerca della Carnegie-Mellon University. Il centro fu istituito e finanziato dal Dipartimento della difesa degli Stati Uniti. La prima pubblicazione di CMM for Software risale al 1991 e si basa su un elenco di controllo di fattori di successo cruciali nell'ambito dei progetti di sviluppo software tra la fine degli anni '70 e l'inizio degli anni '80. Il modello è ispirato anche dalla ricerca scientifica di International Business Machines (IBM) Corporation e dai leader del controllo di qualità del XX secolo Philip Crosby ed W. Edwards Deming. Tanto il nome Capability Maturity Model, quanto i cinque livelli nella rappresentazione scalare (descritti più avanti in questo argomento) sono ispirati al Manufacturing Maturity Model di Crosby. Applicato principalmente a programmi di difesa, CMM ha ottenuto tassi di adozione considerevoli ed è stato sottoposto a numerose revisioni e iterazioni. Il suo successo ha portato allo sviluppo di modelli CMM per una varietà di soggetti anche non inerenti al settore del software. La proliferazione di nuovi modelli creava notevole confusione, quindi il governo decise di finanziare un progetto della durata di due anni, in cui furono coinvolti più di 200 esperti del mondo accademico e dell'industria, finalizzato alla creazione di un singolo framework estendibile che integrasse progettazione dei sistemi, progettazione software e sviluppo dei prodotti. Il risultato è il modello CMMI.

Il concetto più importante da comprendere di CMMI-DEV è il fatto che si tratta di un modello. Non si tratta quindi di un processo o di una prescrizione specifica da seguire, bensì di un set di comportamenti organizzativi che si sono rivelati validi nelle attività di sviluppo software e di progettazione di sistemi. Perché usare un simile modello? Qual è il suo scopo? Come è possibile usarlo al meglio? Si tratta di domande cruciali che, probabilmente, rappresentano le problematiche più fraintese relative al modello CMMI.

Perché usare un modello

Senza un modello relativo al funzionamento delle organizzazioni, alle funzioni necessarie e alle modalità di interazione di tali funzioni, è difficile indirizzare le attività verso il miglioramento. Un modello consente la comprensione di elementi discreti nelle organizzazioni e aiuta a sviluppare un linguaggio e discussioni su cosa deve essere migliorato e sul modo in cui ottenere tale miglioramento. Un modello offre i vantaggi seguenti:

  • fornisce un framework e un linguaggio comuni per agevolare la comunicazione

  • si basa su anni di esperienza

  • aiuta gli utenti non perdere di vista il quadro generale concentrando al contempo l'attenzione in modo specifico sul miglioramento

  • è spesso supportato da istruttori e consulenti

  • può fornire uno standard per consentire di risolvere i disaccordi

Scopo del modello CMMI

Il libro indica che lo scopo del modello è quello di valutare la maturità dei processi di un'organizzazione e di fornire istruzioni su come perfezionarli per ottenere il miglioramento dei prodotti. Le persone del Software Engineering Institute, se interpellate direttamente, potrebbero affermare che il modello CMMI è un modello per la gestione dei rischi, che indica appunto la capacità di un'organizzazione di gestire il rischio. Questa indicazione è l'evidenza della probabilità con cui l'organizzazione riuscirà a mantenere le proprie promesse o di fornire prodotti di qualità elevata che possano conquistare il mercato. Il modello può anche essere considerato come un buon indicatore delle prestazioni di un'organizzazione in condizioni di stress. Un'organizzazione con un elevato livello di maturità e capacità affronterà senza problemi gli eventi imprevisti e difficili, reagirà, cambierà e continuerà per la propria strada. Un'organizzazione con un basso livello di maturità e di capacità tenderà ad andare nel panico in situazioni di stress, a seguire ciecamente procedure da evitare o a scartare tutto il processo nella sua globalità ritrovandosi di nuovo nel caos.

Il modello CMMI non si è dimostrato un buon indicatore delle prestazioni economiche di un'organizzazione. Anche se le organizzazioni con un livello di maturità superiore possono gestire meglio i rischi ed essere più prevedibili, è evidente che tali imprese tendono a evitare i rischi. Questo può portare a una carenza di innovazione o all'evidenza di una maggiore influenza della burocrazia, con conseguenti lead time lunghi e mancanza di competitività. Le imprese con un livello di maturità inferiore tendono a essere più innovative e creative, ma anche caotiche e imprevedibili. Quando vengono ottenuti risultati, si tratta spesso della conseguenza di sforzi eroici da parte di singoli individui o manager.

Uso ottimale del modello CMMI

Il modello è stato progettato per essere usato come base per un'iniziativa di miglioramento dei processi e, in ambito di valutazione, solo come sistema di supporto per la misurazione dei miglioramenti. Questo tipo di uso ha avuto fortune alterne. È troppo facile confondere il modello con una definizione dei processi e cercare di seguirlo, anziché usarlo come mappa che identifica le carenze nei processi esistenti che potrebbero necessitare di un intervento. Il blocco predefinito fondamentale di CMMI è un'area di processo che definisce obiettivi e diverse attività spesso usate per soddisfarli. Un esempio di area di processo è Process and Product Quality Assurance. Un'altra area è Configuration Management. È importante comprendere che un'area di processo non è un processo. Un singolo processo può attraversare più aree di processo e una singola area di processo può coinvolgere più processi.

Il modello CMMI-DEV è in realtà costituito da due modelli che condividono gli stessi elementi sottostanti. Il primo e più familiare è la rappresentazione scalare, in base alla quale viene eseguito il mapping tra le 22 aree di processo e uno dei cinque livelli di maturità dell'organizzazione. Per la valutazione di un'organizzazione è necessario considerare il livello a cui opera e tale livello costituisce un indicatore della capacità dell'organizzazione di gestire il rischio e, quindi, di tenere fede alle promesse.

Rappresentazione scalare di CMMI

I livelli 4 e 5 vengono spesso definiti livelli di maturità superiori. Vi è spesso una netta differenza tra le organizzazioni con un livello di maturità superiore, che mostrano comportamenti di ottimizzazione e gestione quantitativa, e quelle con un livello di maturità inferiore, che si limitano a una semplice gestione o all'applicazione di processi definiti. Nelle organizzazioni con un livello di maturità superiore sono presenti processi meno variabili e vengono spesso usati indicatori anticipatori come parte di un metodo di gestione statisticamente sostenibile. Di conseguenza, le organizzazioni con un livello di maturità superiore tendono a essere sia più prevedibili che più veloci nella reazione alle nuove informazioni, a condizione che non intervengano altri aspetti burocratici. Mentre le organizzazioni con un basso livello di maturità tendono a compiere sforzi eroici, a quelle con un alto livello di maturità può capitare di seguire i processi in situazioni di stress senza comprendere che una modifica a un processo potrebbe consentire una risposta più appropriata.

Il secondo modello, la rappresentazione continua, delinea la capacità dei processi all'interno di ognuna delle 22 aree di processo singolarmente, consentendo all'organizzazione di adattare il lavoro richiesto per il miglioramento dei processi che offrono il valore aziendale più elevato. Questa rappresentazione è più allineata al modello originale di Crosby. Le valutazioni basate su questo modello danno come risultato profili di capacità anziché un singolo numero. Naturalmente, dato che il livello di maturità organizzativo è quello compreso dalla maggior parte dei manager e dei dirigenti, è possibile mappare i risultati di una valutazione del modello continuo alle cinque fasi.

Rappresentazione continua di CMMI

L'uso del modello scalare come base per un programma di miglioramento dei processi può essere pericoloso, in quanto i responsabili dell'implementazione potrebbero dimenticare che il modello CMMI non è un processo o un modello di flusso di lavoro, bensì fornisce obiettivi per il processo e il flusso di lavoro. Soddisfacendo tali obiettivi è possibile migliorare la maturità dell'organizzazione e aumentare la probabilità che gli eventi si svolgano come pianificato. La principale modalità di errore consiste probabilmente nel porsi come obiettivo il raggiungimento di un livello e quindi creare processi e un'infrastruttura volti semplicemente a superare la valutazione. L'obiettivo di qualsiasi attività di miglioramento dei processi deve essere un miglioramento misurabile, non un numero.

Il modello continuo sembra avere maggiore successo come guida per il miglioramento dei processi e alcune imprese di consulenza scelgono di offrire servizi solo incentrati su tale modello. La differenza più ovvia è che un programma di miglioramento dei processi progettato sulla base del modello continuo non prevede obiettivi artificiali determinati dai livelli di maturità. Il modello continuo può anche essere applicato con maggiore naturalezza al miglioramento dei processi nelle aree in cui è più probabile ottenere un vantaggio economico per l'organizzazione. Coloro che seguono il modello continuo hanno quindi una maggiore probabilità di ricevere commenti positivi da un'iniziativa basata sul modello CMMI. I commenti positivi portano anche con maggiore probabilità allo sviluppo di un ciclo virtuoso di miglioramenti.

Elementi del modello CMMI

Il modello CMMI è diviso in 22 aree di processo, elencate nella tabella seguente:

Acronimo

Area di processo

CAR

Causal Analysis & Resolution

CM

Configuration Management

DAR

Decision Analysis & Resolution

IPM

Integrated Project Management

MA

Measurement & Analysis

OID

Organizational Innovation & Deployment

OPD

Organizational Process Definition

OPF

Organizational Process Focus

OPP

Organizational Process Performance

OT

Organizational Training

PI

Product Integration

PMC

Project Monitoring & Control

PP

Project Planning

PPQA

Process & Product Quality Assurance

QPM

Quantitative Project Management

RD

Requirements Definition

REQM

Requirements Management

RSKM

Risk Management

SAM

Supplier Agreement Management

TS

Technical Solution

VER

Verifica

VAL

Convalida

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

Rappresentazione scalare con aree del processo

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

Rappresentazione continua con aree del processo

Ogni area di processo è costituita da componenti necessari, previsti e informativi. Solo i componenti necessari sono effettivamente richiesti 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, dato che un componente previsto è semplicemente previsto e non necessario, ciò significa che una procedura specifica o generica può essere sostituita da una procedura equivalente. Le procedure previste hanno lo scopo di guidare i responsabili dell'implementazione e della valutazione. Se viene scelta una procedura alternativa, il responsabile dell'implementazione ha il compito di avvisare la persona che esegue la valutazione e di spiegare il motivo per cui è appropriata una procedura alternativa. I componenti informativi forniscono dettagli che aiutano i responsabili dell'implementazione ad avviare un'iniziativa di miglioramento dei processi guidata dal modello CMMI. I componenti informativi includono procedure secondarie di procedure generiche e specifiche e prodotti di lavoro tipici.

È molto importante comprendere che sono necessari solo obiettivi generici e specifici. Tutto il resto viene fornito come guida. Gli esempi di componenti previsti e informativi forniti nella documentazione relativa al modello CMMI sono molto spesso tratti da progetti di integrazione di sistemi di difesa e spaziali su vasta scala. Questi progetti sono gestiti da società che patrocinano e supportano il Software Engineering Institute della Carnegie-Mellon University. Essi potrebbero non riflettere il tipo di progetti intrapresi nell'organizzazione o le più recenti tendenze nel settore, quale la comparsa di metodi di Agile Software Development.

Risorse aggiuntive

Per altre informazioni, vedere le risorse Web seguenti:

Vedere anche

Concetti

MSF for CMMI Process Improvement per Visual Studio ALM