Introduzione
Ora più che mai, le società sentono l'esigenza di proporre prodotti più performanti e più a buon mercato. Sebbene lo sviluppo software non sia il motore di business per la maggior parte delle aziende, il software stesso è diventato uno strumento di distinzione strategica e competitiva per molti settori. In quanto tale, aziende manufatturiere, istituzioni finanziare, amministrazioni pubbliche (per menzionare alcuni settori, tra privati e pubblici, che ad oggi si rivelano essere grandi utenti software), come i classisici produttori software, evidenziano sempre più la loro dipendenza nella capacità di gestire lo sviluppo di software ad alto livello qualitativo ed in grado di integrarsi con i loro prodotti o portfolio di servizi.
Attualmente sono presenti vari modelli, standards, metodologie e linee guida che possono valorizzare il proprio modo di lavorare. Tuttavia, la maggior parte degli approcci disponibili si concentrano su una specifica area di business e non offrono un approccio sistematico e completo al problema. Per esempio sono disponibili vari maturity models (modelli di valutazione dell'efficacia del processo) come il Software Engineering Institute's (SEI's) Capability Maturity Model® for Software (SW-CMM®), che si focalizza nel migliorare il software, ed il Electronic Industries Alliance's (EIA's) Systems Engineering Capability Model (SECM), orientato nelle attività di ingegneria dei sistemi. Focalizzando i propri sforzi per migliorare una singola area di business, questi modelli hanno perpetuato la mancanza di un punto di integrazione.
IL CMMI (Capability Maturity Model® Integration) fornisce uno strumento per creare un punto di integrazione attraverso un modello trascendente dalle discipline. Consiste di un'insieme di best practice, focalizzate a migliorare i processi aziendali, per l'acquisizione, lo sviluppo, l'integrazione e la manutenzione di prodotti e servizi.

Cos'è un processo
Un processo è definito come una serie di step che portano alla soluzione di un problema. Per essere efficaci, questi step devono essere definiti in modo non ambiguo - che siano quindi, facilmente comprensibili e semplici da eseguire da chiunque utilizzi il processo. L'obiettivo è dunque ridurre il lavoro superfluo. Perché ricreare la ruota ogni volta che iniziamo un nuovo progetto? Se ci viene richiesto di presentare un project plan, perchè non avere una procedura che delinei come scriverne uno, assieme ad un esempio cui trarre informazioni? Non è certamente più semplice di riscriverlo e sudare sangue ogni volta?
Lo stesso esempio vale per la stima delle giornate per un programmatore. Quante volte vi è capitato di sentirvi preoccupati per una stima o per mantenere lo sviluppo entro i tempi definiti. Non sarebbe meglio avere un processo che vi supporti nella stima delle giornate?
I processi sono come le ricette. Una ricetta dice gli ingredienti, come mixare gli ingredienti, la temperatura da usare e per quanto tempo cuocere il tutto. Allo stesso modo, non ci insegna come tagliare a fette, sbattere, tritare, etc.. Inoltre lasciano spazio per nuovi esperimenti e modifiche.
Nel nostro caso, un processo è definito ad alto livello e ad esso sono associate delle procedure a sostegno del proceso. Le procedure sono descritte con un livello di dettaglio maggiore.
L'utilizzo di processi permette di adeguare il proprio modo di fare business, fornisce la possibilità di adeguare le proprie risorse e costruisce una direzione per migliorare i propri prodotti: risulta l'elemento di unione tra persone e tecnologie (vedi la Figura 1)

Figura 1 - le tre dimensioni critiche di un'azienda

Quindi il processo è l'unica risposta valida? No, il processo è parte della risposta. Il processo quando supportato da training, da un adeguato budget, da personale skillato, da strumenti giusti, e da impegno da parte del management, costituisce l'elemtno portate per la corretta gistione delle attività aziendali.
Per valutare la qualità di un processo, sono stati definit tre attributi qualitativi fondamentali:

1. Capability: è l'insieme dei risultati che un processo consente di conseguire. Esprime le potenzialità del processo e permette di effettuare stime attendibili sulla possibilità di raggiungere i risultati di un progetto, sia per il committente che per il produttore.
2. Performance: è una misura dei risultati effettivi ottenuti nell'applicazione del processo. Una valutazione a consuntivo, un indice, dei risultati che sono stati raggiunti.
3. Maturity: è una misura dell'efficacia del processo e della estensione e precisione con cui le fasi e le attività dello stesso sono esplicitamente definite, gestite, misurate e controllate. Rappresenta una valutazione del livello di padronanza e controllo del processo da parte dell'organizzazione, ivi inclusa la capacità dell'organizzazione di migliorarlo, ottimizzarlo,… o comunque modificarlo in risposta a necessità che si presentano.

CMMI Overview
Il primo Capability Maturitity Model (CMM v1.0) fu definito dal Software Engineering Institute e chiaramente indirizzato a definire un livello di maturity del processo di sviluppo software. Dopo la sua adozione ed utilizzo in vari domini, furono definite delle varianti per altre discipline come l'ingegneria di sistema, la gestione del personale, lo sviluppo di prodotti integrati, ed altre ancora. Sebbene molte organizzazioni li trovarono interessanti ed utili, il loro utilizzo fu ridotto a causa di problemi di sovrapposizione, inconsistenza ed integrazione tra modelli diversi.
Il progetto CMM Integration fu costituito per riorganizzare il problema di avere troppi modelli non interconnessi tra loro e permettere in futuro l'integrazione di nuove discipline. La mission iniziale era di combinare questi tre modelli:

1. Capability Maturity Model for Software (SW-CMM);
2. Systems Engineering Capability Model (SECM);
3. Integrated Product Development Capability Maturity Model (IPD-CMM).
   

La federazione di questi modelli in un singolo framework ha così permesso di integrare linguaggi diversi e ridurre lo sforzo necessario per perfezionare l'intero processo aziendale in tutte le discipline che lo compongono.

Un modello, due rappresentazioni
Filosoficamente ci sono due approcci differenti al processo di miglioramento. Uno focalizzato sull'organizzazione, come entità univoca, ed in grado di fornire una road map di passi successivi rivolti a migliorare la capacità aziendale di capire e controllare il processo. Questo approccio sta alla base della rappresentazione scalare. L'altro approccio possibile, la rappresentazione continua, si focalizza sul processo singolo, lasciando all' organizzazione la possibilità di definire su quali processi applicare il modello.
L'utilizzo dello standard CMMI ci pone davanti ad una scelta: utilizzare la rappresentazione continua o scalare.
Prima di passare a vedere in dettaglio le due rappresentazioni possibili, dobbiamo definire alcuni concetti:

Maturity Level - è una misura dell'estensione e dell'efficacia dell'intero processo aziendale. Sono definiti 5 livelli di maturità, ognuno con livelli di difficoltà e richieste diverse.

Capability Level - indica il livello di istitituzionalizzazione del processo: la capacità dell'azienda di eseguire, controllare, e miglorare le performance di un processo. Sono definiti 6 livelli di capability.

Process Areas (PAs) - Un'area di processo è definita come un gruppo procedure o attività eseguite collettivamente per ottenere un obiettivo specifico e comune. Come per esempio la gestione dei requisiti a Livello 2, sviluppo dei requisiti a Livello 3 ed una gestione misurabile dei progetti a Livello 4.

Goals - Ogni area di processo ha degli obiettivi (Goal) che devono essere soddisfatti. Dato che gli obiettivi sono definiti ad alto livello, sono associati ad una serie di procedure.Vi sono obiettivi specifici e e generici:
1 - Specific goals (SG): sono applicati ad una singola area di processo e descrivono l'unica caratteristica che deve essere implementata per soddisfare gli obiettivi per l'area di processo.
2- Generic goals (GG): obiettivi comuni a più aree di processo; sono un indicatore del livello di istituzionalizzazione del processo. Il grado di istituzionalizzazione di un processo corrisponde al livello di controllo che l'organizzazione è in grado di attuare sul processo stesso: individuale, oppure derivante da standard progettuali o dell'organizzazione, analizzato statisticamente, etc.

Procedure - sono attività che devono essere eseguite per raggiungere uno specifico obiettivo. Vi sono due tipi di procedure:
1. Specific practices (SP): relative ad uno specifico obiettivo o goals;
2. Generic practices (GP): associate ad un obiettivo generico, applicato a tutte le aree di processo; possono migliorare le performance ed il controllo di ogni processo. Per esempio, nella PA Project Planning, una delle procedure è scrivere un piano di progetto. Un'altra è stimare il numero di persone richiesto e derivarne una schedulazione.

La rappresentazione scalare
La rappresentazione scalare (staged representation), fornisce una road map predefinita stabilita sulla base di un comprovato raggruppamento e ordinamento di processi. Il termine "staged" deriva dal modo con cui il modello descrive questa road map come una serie di "fasi (stages)" che sono chiamate "maturity levels". Ogni maturity level contiene un set di aree di processo che indicano dove focalizzarsi per migliorare il processo aziendale. Ogni area di processo è descritta in termini di procedure che contribuiscono a raggiungere gli obiettivi. Le procedure descrivono l'infrastruttura e le attività che contribuiscono all'effettiva implementazione ed istituzionalizzazione delle aree di processo. I progressi sono misurati in raggiungimento degli obiettivi di ogni area di processo presente in un particolare maturity level.

Figura 2 - la rappresentazione scalare

Le procedure generiche sono raggruppate per Common Features - un concetto unico alla rappresentazione scalare. Questi componenti non sono mai valutati, sono solo un modo di presentare le procedure generiche in aree di processo.
Maturity level. Il CMMI secondo la rappresentazione scalare, descrive cinque livelli distinti di maturità. Il raggiungimento di un dato livello è sostanziato dal raggiungimento del livello immediatamente precedente:

Figura 3 - Maturity Levels

Lo standard CMMI fa riferimento a 25 aree di processo, ripetute in entrambe le rappresenrazioni.
Nella rappresentazione continua, le aree di processo sono raggruppate per categoria: Process Management, Project Management, Engineering, e Support. Nella rappresentazione scalare le aree di processo sono raggruppate per maturity levels da 2 a 5. All'interno della Tabella 1 sono presentate le aree di processo raggruppate per categoria ed evidenziato il relativo maturity level.

Tabella 1 - Aree di processo per categoria

Il grado di qualità complessiva di un'azienda è strettamente correlato al numero di aree chiave che ricevono un trattamento soddisfacente (all'interno di quella azienda).
Sono stati definiti 5 maturity level, utilizzati per descrivere la strada evolutiva consigliata per una organizzazione che voglia migliorare i processi di sviluppo e manutenzione di prodotti e servizi.

1. Livello 1 (Iniziale) - rappresenta un processo con risultati non prevedibili. Il processo di produzione è instabile e disorganizzato, implicitamente definito di volta in volta da chi lo realizza, il flusso delle attività è caotico.
2. Livello 2 (Ripetibile) - rappresenta un processo caratterizzato da performance di progetto ripetibili. Il processo è pianificato, realizzato, monitorato, e controllato rispetto ad obiettivi di business predefiniti;
3. Livello 3 (Definito) - rappresenta un processo caratterizzato da un progetto di progresso all'interno dell'azienda. Il processo è fondato su ben definite metodologie, tecniche e tecnologie, sia per ciò che riguarda gli aspetti gestionali che per ciò che riguarda gli aspetti operativi; esiste un unico modello di riferimento per l'organizzazione, la gestione e la realizzazione di progetti;
4. Livello 4 (Gestito) - Il processo viene controllato usando tecniche quantitative e statistiche. Gli obiettivi di business dell'organizzazione sono controllati attraverso una loro comprensione in termini statistici;
5. Livello 5 (Ottimizzato) - E' istituzionalizzata una politica di gestione della qualità, ovvero l'uso di metodi quantitativi, fondati su dati e misure ottenute per feedbacks dai processi realizzati, per il miglioramento del processo stesso, anche attraverso l'introduzione controllata di nuove metodologie, tecniche e tecnologie.

La rappresentazione continua
La rappresentazione continua non fornisce una direzione obbligatoria nella definzione delle modalità con cui affrontare il processo.
Come la rappresentazione scalare, la rappresentazione continua è formata da aree di processo che contengono delle procedure che, al contrario della rappresentazione scalare, sono organizzate in modo da sostenere lo sviluppo di una singola area di processo. La maggior parte delle procedure sono generiche e applicate a tutte le aree di processo. Le procedure generiche sono raggruppate in capability levels (CLs), ognuno dei quali ha una definizione che è pressoche equivalente alla definzione di maturity level nella rappresentazione scalare. Ogni area di processo è istutizionalizzata implementando le procedure generiche nella relativa area di processo.

Figura 4 - la rappresentazione continua

Nella rappresentazione continua, gli obiettivi (goals) non sono esplicitamente definiti, dando quindi maggior enfasi alle procedure stesse. Ogni processo è valutato secondo il proprio capability level. Un' organizzazione, probabilmente, avrà aree di processo diverse stimate a differenti capability levels. Il risultato di questa stima, può essere riferito con il nome di capability profile, come si vede in Figura 5.

Figura 5 - Capability Level profile

Questo istogramma può essere anche utilizzato per definire un target per le attività di process-improvement all'interno dell'azienda. Dato che questo grafico mostra il capability profile attuale e che si vuole raggiungere, può essere utilizzato per misurare i progressi nell' attività di process-improvement.
In teoria la scelta della rappresentazione è incondizionata, anche se in realtà incrementare il livello di capability di un particolare processo richiede che altri processi abbiano un determinato livello di capability. Per questo, la rappresentazione continua permette un minor numero di opzioni nella road map di ottimizzazione del processo. Stiamo parlando di due rappresentazioni - due diverse visioni dello stesso contenuto. Le regole per convertire una rappresentazione nell' altra sono state definite. Così, la scelta non preclude l'utilizzo di una o dell'altra, nel momento in cui decidiamo di cambiare strada.
La Tabella 2 riassume le differenze tra la rappresentazione continua e la rappresentazione scalare.

Tabella 2 - Comparazione tra rappresentazione scalare e continua

Conclusioni
Concludendo si può dire che il principio ispiratore è lo stesso sotteso dall'allenamento negli sport: "non si può migliorare ciò che non è ripetuto" (l'allenamento consiste appunto nel ripetere e migliorare). Nel livello 2, l'obbiettivo è creare un environment ripetibile togliendo le cause che possono impedirlo:

• una pianificazione che non può essere rispettata,
• specifiche che cambiano.
  

Naturalmente non tutte le performance saranno buone. Nel livello 3, raggiunta la stabilità che rende ripetibili i processi si identificano i migliori. Nel livello 4 si cerca di eliminare le cause che impediscono di raggiungere gli obiettivi, misurando quantitativamente le prestazioni perchè ogni istanza si avvicini al modello. Nel livello 5 si migliorano di continuo anche i modelli.

Bibliografia
[1] dott. Giuseppe Magnani ,"Il CMMI® (Capability Maturity Model Integration) - La valutazione ed il miglioramento continuativo dei processi di integrazione di sistema"
[2] Walker Royce, "CMM vs. CMMI: From Conventional to Modern Software Management", The Rational Edge, 2002
[3] Margaret K. Kulpa and Kent A. Johnson , "Interpreting the CMMI: A Process Improvement Approach", Auerbach Publications © 2003
[4] "CMMI Main Page", Carnagie Mellon Software Engineering Institute, http://www.sei.cmu.edu/cmmi/cmmi.html
[5] "Lucidi del Corso di Ingegneria del Software", Università degli Studi del Sannio - Facoltà di Ingegneria
[6] Mary Beth Chrissis, Mike Konrad, Sandy Shrum, "CMMI®: Guidelines for Process Integration and Product Improvement", Addison-Wesley Pub Co; 1st edition (February 24, 2003)