Il Capability Maturity Model Integration (CMMI) è un “programma” di formazione e valutazione per il miglioramento a livello di processo gestito dal CMMI Institute.

Bisogna prima introdurre il concetto di maturità dei processi. Questa nozione è abbastanza intuitiva. La probabilità di portare a termine un progetto dipende dalla maturità del progetto e la maturità dipende dal grado di controllo che si ha sulle azioni che si vanno a svolgere per realizzare il progetto.

Si ha quindi che:

• il progetto è immaturo quando le azioni legate allo sviluppo non sono ben definite o ben controllate e quindi i dev hanno troppa libertà che rischia di degenerare in una sorta di anarchia nel controllo del processo di sviluppo, alzando la probabilità di fallimento;
• il progetto è maturo quando le attività svolte sono ben definite, chiare a tutti i partecipanti e ben controllate. Si ha quindi un modo per osservare quanto si sta svolgendo e verificare che sia come pianificato, alzando le probabilità di successo e riducendo quelle di fallimento.

Risulta quindi essenziale ragionare sulla maturità del processo.

La maturità del processo è definita tramite un insieme di livelli di maturità con associate metriche per gestire i processi, questo è detto Capability Maturity Model (CMM). In altri termini il modello CMM è una collezione dettagliata di best practices che aiutano le organizzazioni a migliorare e governare tutti gli aspetti relativi al processo di sviluppo, dalla gestione dei rischi al testing, dal design al project management, etc…

Un processo migliore porta ad un prodotto migliore.

La sotria dei CMMs parte dagli anni 90 e porta alla versione del 2018 che andremo ad analizzare.

Analizziamo quindi nel dettaglio il modello:

All’interno del diagramma (che rappresenta letteralmente un documento) notiamo:

• process area, che racchiude al suo interno una collezione di pratiche organizzate secondo obiettivi e riguarda un certa area del processo. Nel CMMI abbiamo 22 diverse process area, tra cui configuration management, project planning, risk management, … Nel diagramma si ha lo studio di una generica process area

• ciascuna process area ha:

  • un purpose statement, che descrive lo scopo finale della process area stessa
  • un introductory notes, con delle note introduttive che descrivono i principali concetti della process area
  • un related process area, se utile, con la lista delle altre process area corelate a quella corrente

• le process area si dividono in due tipologie di obiettivi:

  1. specific goals, ovvero gli obiettivi specifici della singola process area in questione. Questi obiettivi caratterizzano la process area
  2. generic goals, ovvero gli obiettivi comuni a tutte le process area. Questi obiettivi rappresentano quanto la process area sia ben integrata e definita nel contesto del processo ma questi criteri sono generali.

• all’interno di ogni specific goals (per questo la freccia tratteggiata) abbiamo una serie di specific practices, ovvero quelle azioni che, se svolte, permettono di raggiungere quell’obiettivo specifico e, a loro volta, tali pratiche sono organizzate in:

  • example work product, ovvero elenchi di esempi di prodotti che possono essere generati attraverso l’adempimento delle pratiche
  • subpractices, ovvero pratiche di “grana più fine”

• all’interno di ogni generic goals (per questo la freccia tratteggiata) abbiamo una serie di generic practices, comuni a tutti, con le pratiche che devono essere svolte per gestire positivamente una qalsiasi process area e, a loro volta, tali pratiche sono organizzate in:

  • generic practices elaborations, ovvero ulteriori informazioni di dettaglio per la singola pratica
  • subpractices, ovvero pratiche di “grana più fine”

  Tra i principali generic goals (GG) abbiamo:

  • GG1: raggiungere i specific goals, tramite l’esecuzione delle specific practices
  • GG2: “ufficializzare” un managed process, tramite training del personale, pianificazione del processo, controllo dei work product ecc…
  • GG3: “ufficializzare” un defined process, tramite la definizione rigoroa del progetto e la raccolta di esperienze legate al processo.

Per capire quanto un processo software è organizzato secondo questo standard bisogna “mappare” quali goals e quali pratiche si stanno perseguendo e seguendo e usare CMMI non solo come “ispirazione” ma come vero e proprio standard per definire le azioni da svolgere nonchè per confrontare il nostro operato e studiarlo qualitativamente. Lo studio qualitativo mi permette di stabilire la maturità dei progetti, secondo un certo livello di compliance, detto CMMI level. Tale qualità che può essere certificata da enti certificatori appositi (si ha anche una repository pubblica con i livelli di compliance di diversi progetti di organizzazioni famose).

Studiamo a fondo questi livelli di maturità e la loro codifica.

Si hanno due linee di sviluppo / miglioramento: