Principi e valori CMMI

Da David J. Anderson. David J. Anderson è l'autore di due libri, “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results” [1] pubblicato nel 2003 e “Kanban: Successful Evolutionary Change for your Technology Business” [2] pubblicato in 2010. È stato membro del team che ha creato il metodo di sviluppo software Agile, sviluppo basato su funzionalità, a Singapore tra il 1997 e il 1999. È autore dei principi di gestione del progetto Agile definiti nella Declaration of Interdependence, 2005. David ha creato MSF for CMMI Process Improvement e congiuntamente ha creato la nota tecnica del Software Engineering Institute, "CMMI o Agile: perché non utilizzarli entrambi!" [3] È vicepresidente del Lean Software & Systems Consortium, http://www.leanssc.org e guida un'azienda internazionale di consulenza e formazione per la gestione, David J. Anderson & Associates Inc., http://www.agilemanagement.net aiutano le aziende tecnologiche a migliorare le proprie prestazioni grazie a migliori criteri di gestione e processi decisionali.

Gennaio 2012

Anderson ritiene che se si guarda alle organizzazioni attraverso la lente di CMMI si ottiene una visione importante per gli amministratori, i progettisti dei processi e per tutte le parti interessate esterne inclusi i clienti, gli investitori, gli enti governativi e i revisori.

Si applica a

gestione del ciclo di vita delle applicazioni; CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

Il modello CMM (Capability Maturity Model) originale è stato pubblicato per la prima volta nel 1991. Si è evoluto in CMMI (Capability Maturity Model Integration) un decennio dopo. CMMI è una famiglia di tre costellazioni (come sono note) e questo articolo fa riferimento nello specifico alla costellazione CMMI for Development (CMMI-DEV). Il CMM è stato compilato per risolvere meglio il dipartimento di difesa Stati Uniti a capire gli errori costosi nei progetti software nei programmi su larga scala di appalti pubblici. Una valutazione basata su CMM è stata utilizzata per determinare l'idoneità per il contratto di governo. Più avanti si è evoluto in uno schema di valutazione definito basato su CMMI.

Il concetto di maturità organizzativa rimane controverso. Ad esempio, come è possibile valutare la maturità di un'organizzazione? Un'organizzazione ha un comportamento veramente diverso da quello degli utenti? Il concetto che un'organizzazione possa essere valutata a un livello di maturità particolare e che questo sia un indicatore di capacità di fornire lavoro affidabile al governo è una questione di dibattito continuo. Tuttavia, continuo a sostenere CMMI e ritengo che se si guarda alle organizzazioni attraverso la lente di CMMI si ottiene una visione importante per gli amministratori, i progettisti dei processi e per tutte le parti interessate esterne inclusi i clienti, gli investitori, gli enti governativi e i revisori.

Significato di maturità organizzativa

La maturità in CMMI è destinata a implicare un approccio e la capacità di valutare e gestire il rischio e il giudizio utilizzato nel prendere decisioni. Il termine "maturità" viene attualmente utilizzato nel suo significato comune riferito agli individui. Ad esempio, gli assicuratori possono dirci che è più probabile che i maschi di 18 anni abbiano un incidente in automobile che le donne di 55 anni. Il maschio di 18 anni potrebbe mostrare scarsa capacità di giudizio quando prende decisioni relative alla gestione di un veicolo ed ha probabilmente esperienza insufficiente nel valutare adeguatamente i rischi previste nel corso di una particolare azione. Ciò può causare incidenti che con un po' di esperienza di potrebbero evitare. Le società di assicurazione sono in grado di valutare in modo particolarmente accurato i rischi perché raccolgono dati statistici ed evidenze correlate.

Un problema con CMMI è la natura peggiorativa percepita del termine "maturità". Si presuppone sempre che più maturità sia preferibile a meno maturità. E bisognerebbe sempre cercare la maggior maturità possibile. Se dovessimo pensare a questo aspetto per singoli termini, non sarebbe sempre valido. Il costo dell'assicurazione di un'automobile di una ditta di assicurazione è minore per le persone più mature; tuttavia, è possibile che un team in gara valuti l'esuberanza dei giovani e la possibilità di rischi. Per il team in gara, gli incidenti sono stradali fanno parte del business. Infatti, i guidatori che non hanno mai avuto un incidente verranno licenziati.

Quello che si vuol dire è che i livelli di maturità devono essere compatibili alle circostanze e al contesto. Di più non è necessariamente meglio, ma poter identificare e valutare la maturità organizzativa consente di definire più facilmente se un'azienda è in grado di gestire il rischio e di esercitare il giudizio appropriato nel prendere decisioni sul prodotto e sul progetto.

È necessaria una forte correlazione tra il livello di maturità e la probabilità di raggiungere il risultato desiderato. Un'organizzazione ad elevata maturità dovrebbe avere una probabilità molto alta di fornire un risultato vicino a quello desiderato. Ciò include il possedere la maturità e la capacità di valutare risultati possibili, probabili e raggiungibili e di definire degli obiettivi di conseguenza. È meno probabile che un'organizzazione di maturità inferiore imposti obiettivi realizzabili e fornisca un risultato che risponda alle aspettative. L'altra faccia della medaglia è che un'organizzazione molto matura potrebbe sviluppare un'avversità ai rischi e dedicarsi solo a obiettivi facilmente realizzabili, mentre un'organizzazione esuberante con un livello di maturità inferiore potrebbe raggiungere prestazioni eccezionali grazie a una combinazione di fortuna e di duro lavoro.

Idee per il modello CMMI.

Il modello CMM originale è stato sviluppato da Watt Humphrey ed è apparso per la prima volta (senza il nome CMM) nel suo libro intitolato Managing the Software Process[4]. È stato ispirato dal movimento di controllo di qualità di produzione del ventesimo secolo e dal lavoro di Joseph Juran, W. Edwards Deming e Philip Crosby. Il termine "modello di maturità" e i cinque livelli in esso contenuti sono stati ispirati dal Manufacturing Maturity Model di Crosby. Tuttavia, CMM deve essere considerata come una vera sintesi di idee. Il termine "funzionalità" è quasi certamente ispirato da Deming.

Deming ha utilizzato il termine "funzionalità" con un significato molto specifico molto più profondo del significato attribuito alla parola dal linguaggio comune. Più precisamente, una "funzionalità" può essere considerata "la filosofia naturale" di un sistema o di un'operazione all'interno di un sistema. Deming ha incoraggiato gli amministratori a "studiare le funzionalità" e ad analizzarle in modo statistico. Ha sviluppato il System of Profound Knowledge[5] (Sistema di conoscenza approfondita) che deve essere utilizzato come framework di scelta per aiutare gli amministratori a intervenire in modo appropriato nella progettazione dei sistemi. Deming è un vero pensatore dei sistemi. In questo caso, la parola "sistema" implica un processo eseguito da persone. Non esiste alcun intento di implicare una tecnologia o qualsiasi automazione.

Deming ha creduto e ha compilato l'evidenza, che ha suggerito che fino al 95% delle prestazioni di un sistema provenga dalla progettazione del sistema e non dalle funzionalità degli utenti che utilizzano il sistema. In altre parole, per creare un miglioramento, si deve concentrare l'attenzione sulla modifica del processo, del sistema in cui le persone lavorano, anziché sul miglioramento delle singole prestazioni. Come risultato, non credeva molto negli obiettivi, nella gestione per obiettivi, nei poster motivazionali o nelle ripercussioni sugli con prestazioni insufficienti.

Pertanto Deming ha fornito a un modello di capacità con il suo sistema di conoscenze approfondite e Crosby ha fornito un modello di maturità. Humphrey ha cercato di sintetizzare questi concetti e di applicarli al campo della progettazione software e il risultato è stato il Capability Maturity Model.

Poiché è stata data molta importanza alla valutazione e al perseguimento dei livelli di maturità da qualificare per i contratti pubblici, la modellazione della funzionalità e l'effetto di Deming sono spariti da gran parte della letteratura relativa a CMM e CMMI. Tuttavia, l'effetto Deming è illustrato dettagliatamente nelle aree di processo definite nei livelli di maturità più alti.

CMMI è stato ideato per essere un framework che favorisce la comparsa delle impostazioni cultura in continuo miglioramento in un'organizzazione ed è sempre destinato a essere un approccio al concetto di sistema. Esiste un chiaro parallelo con il pensiero Lean nelle radici di CMMI.

CMMI è un modello

Il modello CMMI è un modello per comprendere capacità e alla maturità organizzative. Non è uno standard, né una definizione del processo di gestione dei progetti o di sviluppo software. Le procedure generali descritte in questo articolo si riferiscono alla capacità dei processi e non a un dato progetto o prodotto in fase di sviluppo. Ad esempio, nella tabella seguente ci si riferisce alla pianificazione per l'implementazione del processo e non per qualsiasi progetto o consegna del prodotto.

Il modello CMMI è composto da 22 aree di processo, più tre obiettivi generici che tutte le organizzazioni si prevede che perseguano.

I 3 obiettivi generici sono i seguenti:

Le 22 aree di processo sono organizzate in 4 categorie: Progettazione, Gestione dei progetti, Gestione dei processi e Supporto. Ogni area di processo è costituita da uno a tre obiettivi specifici e da tutti e tre gli obiettivi generici. Per ogni obiettivo, sono previste comunemente una serie di procedure affinché l'obiettivo venga raggiunto. All'interno di una procedura possono essere delle procedure secondarie consigliate. Il modello CMMI richiede o rappresenta solo gli obiettivi. Le procedure definite negli obiettivi del modello CMMI sono previste ma non obbligatorie. Se non presenti, devono essere sostituite da una procedura di sostituzione equivalente. Nella tabella seguente viene illustrato il raggruppamento delle aree del processo:

Focalizzazione organizzativa	Area di processo
Progettazione	Sviluppo di requisiti Technical Solution Product Integration Verifica Convalida
Gestione di progetti	Project Planning Project Monitoring & Control Integrated Project Management Supplier Agreement Management Requirements Management Risk Management Quantitative Project Management
Gestione di processi	Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation & Deployment
Supporto	Configuration Management Process and Product Quality Assurance Measurement & Analysis DAR (Decision Analysis & Resolution) CAR (Causal Analysis and Resolution)

Pertanto il principio è semplice: se un'organizzazione può presentare la funzionalità per raggiungere gli obiettivi di ogni area di processo, si può dire che abbia una capacità in tale area di processo particolare.

Le aree di processo vengono raggruppate anche in livelli di maturità, che forniscono un metodo rapido per descrivere la maturità. Sebbene il raggruppamento in livelli delle aree di processo resti una questione controversa da più punti di vista, il mio commento sulle organizzazioni nelle ultime due decadi è che la versione corrente 1.3 del modello (considerando che CMMI è effettivamente la versione 2 di CMM) è ampiamente corretta. Organizzazioni caotiche e con una massa maturità tendono a sviluppare funzionalità nelle aree di processo definite nel livello di maturità 2 prima di sviluppare funzionalità in aree di processo definite ai livelli superiori.

Nella tabella seguente viene illustrato il raggruppamento in livelli delle aree del processo.

Livello di maturità	Aree di processo
5	CAR (Causal Analysis & Resolution) Gestione prestazioni organizzative
4	OPP (Organizational Process Performance) QPM (Quantitative Project Management)
3	SR - Sviluppo di requisiti TS (Technical Solution) PI (Product Integration) VER (Verifica) VAL (Convalida) IPM (Integrated Project Management) RSKM (Risk Management) OPF (Organizational Process Focus) OPD (Organizational Process Definition) OT (Organizational Training) DAR (Decision Analysis & Resolution) Process & Product Quality Assurance
2	CM (Configuration Management) MA (Measurement & Analysis) SAM (Supplier Agreement Management) PP (Project Planning) PMC (Project Monitoring & Control) RM (Requirements Management)
1	Non sono presenti aree di processo nel livello di modello 1. Il Livello 1 rappresenta un processo indefinito senza introspezione o la capacità di definire un processo o ripetere un risultato mediante la comprensione del processo che lo ha prodotto. Tecnicamente, in una valutazione CMMI, un'organizzazione che non soddisfa gli obiettivi per le aree di processo nel Livello di modello 2 è ancora Livello di modello 1. Le organizzazioni con processi emergenti verranno quindi viste ancora tecnicamente come modello di Livello 1 anche se il percorso di maturazione dal caso indefinito è stato lungo.

Nella tabella seguente viene presentata una panoramica in termini di disposizione dell'oggetto o scopo di ciascuna area del processo:

Area di processo	Scopo
CAR (Causal Analysis and Resolution)	Analizzare la causa principale dei problemi di processo eccezionali (speciali variazioni del motivo, per utilizzare W. il termine di Edwards Deming) e suggerire e implementare le modifiche di processo per impedire una ricorrenza. L'attenzione è diretta a un comportamento anomalo di processi quantitativamente compresi e stabili. I risultati di ogni giorno probabilmente verranno considerate parte della gestione dei rischi (RSKM) piuttosto che dell'AUTOMOBILE.
CM (Configuration Management)	Oltre al controllo della versione del codice sorgente, questa area di processo copre tutta l'amministrazione relativa agli ambienti di sistema, le configurazioni dei componenti, le piattaforme, il middleware, applicazioni e la documentazione. Possibilità di compilare e distribuire correttamente il codice in esecuzione fa parte di questa area di processo.
DAR (Decision Analysis & Resolution)	Per tutte le decisioni importanti in un progetto o nello sviluppo del prodotto, mostrare che è stato preso in considerazione un set di alternative o di opzioni e che gli elementi contestuali sono stati utilizzati per valutare l'idoneità delle diverse opzioni. Registrare la decisione e i motivi per la scelta.
IPM (Integrated Project Management)	Questo secondo livello di gestione dei progetti all'interno del modello CMMI implica che un'organizzazione sia in grado di gestire contemporaneamente più progetti potenzialmente dipendenti. Per ottenere questo risultato, l'organizzazione utilizza un ufficio di gestione programma o di portafoglio.
MA (Measurement and Analysis)	Raccogliere i dati sulle prestazioni del processo, del progetto e del prodotto. Producono metrica e indicatori sotto forma di rapporti basati su dati.
OPD (Organizational Process Definition)	L'organizzazione deve avere una o più definizioni di processo definite in un contesto. In un contesto verrà descritto un profilo del rischio. Ciascun progetto può essere valutato in base ai rischi e una definizione di processo selezionata dal catalogo organizzativo e quindi adattatala in modo appropriato.
OPF (Organizational Process Focus)	L'organizzazione deve credere che la definizione del processo definisce e influisce sulle capacità e che il miglioramento delle capacità avviene principalmente attraverso il miglioramento dei processi. Di conseguenza, l'organizzazione gestisce attivamente le definizioni di processo e le controlla (utilizzando l'area di processo PPQA) per garantire che queste definizioni vengono eseguite.
Gestione prestazioni organizzative	Quest'area del processo include il concetto di una conoscenza statistica della qualità dei risultati di un processo rispetto alla sua capacità prevista. Possono essere valutate le modifiche al processo destinate a migliorare la funzionalità ed è possibile considerare il modello sottostante per il processo se i risultati osservati non riflettono quelli previsti dal modello di processo sottostante quando è stata eseguita una modifica alla definizione del processo. L'organizzazione gestisce le proprie prestazioni tramite i processi per soddisfare le esigenze aziendali.
OPP (Organizational Process Performance)	Quest'area del processo include il concetto di confronto delle prestazioni, spesso definita "benchmarking". OPP creati i modelli di processo dai dati di base per consentire il confronto. Ciò fornisce a un'organizzazione la possibilità di rispondere a domande quali "quale dei tre team di prodotto dovremmo scegliere per [questo progetto specifico]?"
Organizational Training	La capacità individuale in procedure specifiche è importante per le prestazioni del processo e la capacità del sistema. Un sistema che funziona bene con forti prestazioni avrà una forte possibilità di formazione per ridurre la variabilità nella funzionalità a livello di procedura locale.
Product Integration	Possibilità di integrare più componenti per formare un prodotto completo e gestire gli elementi necessari per permetterlo.
Project Monitoring and Control	Raccogliere dati sui progetti correnti, confrontare i piani, le proiezioni e le simulazioni e eseguire le azioni appropriate in base ai dati.
Project Planning	Pianificare progetti basati sulle stime, su simulazioni e sull'analisi dei requisiti.
Process and Product Quality Assurance	Principalmente una funzione di controllo di conformità del processo. Destinato a dimostrare che il sistema funziona come previsto. Consente di evitare possibili errori di gestione nella modifica del processo per la risoluzione di un problema quando effettivamente il processo corrente non è seguito come previsto.
Quantitative Project Management	Questo è il terzo e più alto livello di gestione del progetti all'interno del modello CMMI. Implica che metodi quantitativi statisticamente affidabili siano utilizzati per pianificare, monitorare e gestire i progetti.
Sviluppo di requisiti	Esiste un processo definito e ripetibile per sollecitare, negoziare, analizzare e documentare le richieste.
Requirements Management	I requisiti vengono rilevati durante il ciclo di vita del progetto e è idealmente, completi, tracciabilità fra una configurazione inviato e la richiesta originale di requisito.
Risk Management	Sebbene l'intero modello CMMI può essere considerato un framework per la gestione dei rischi, quest'area di processo viene indirizzata in modo specifico al "rischio basato sugli eventi" o alla probabilità e all'impatto delle variazioni specifiche del motivo delle sorprese di ogni giorno. Quest'area del processo richiede riduzione dei rischi, attenuazione, pianificazione delle emergenze, gestione dei problemi e risoluzione.
Supplier Agreement Management	Possibilità di gestire i fornitori esterni, di definire i contratti, gestire il contratto e di eseguire la distribuzione del prodotto o servizio desiderato.
Technical Solution	Tutte le competenze necessarie relative all'architettura del software, alla progettazione e alla codifica.
Convalida	Test di accettazione dei requisiti dell'utente.
Verifica	Test su una progettazione (da soluzione tecnica). Assicurarsi che il prodotto viene compilato come previsto, progettato e assemblato in modo da soddisfare le necessità e il lavoro degli utenti nel relativo ambiente.

Per ogni area di processo, può essere valutato un livello di funzionalità. Quattro livelli di funzionalità sono definiti nella v1.3 di CMMI:

0. Incompleto

1. Eseguito

2. Gestito

3. definito

Se ogni obiettivo specifico viene soddisfatto e vengono soddisfatti alcuni degli obiettivi generici, la capacità per un'area di processo specifica verrà valutata almeno al livello 1, ovvero eseguita. Il livello 1 di funzionalità implica che i membri del team sanno bene cosa stanno facendo. Tuttavia, è probabile che la procedura specifica non visualizzi stabilità in caso di analisi statistica. Le procedure vengono seguite ma manca ancora coerenza. Il livello 2 di funzionalità implica che il team conosca il funzionamento di qualcosa e dispone delle competenze necessarie per prevedere la prestazione di una procedura e per evidenziare un controllo statistico. È probabile che esistano procedure di formazione o di lavoro in collaborazione per produrre una maggiore coerenza tra i membri del team. Il livello 3 di funzionalità implica una padronanza della competenza e una capacità di sviluppare tecniche nuove e migliori per raggiungere l'obiettivo. La funzionalità di Livello 3 implica che qualsiasi analisi statistica richiederebbe la ridefinizione di una linea di base dopo ogni modifica esplicita nella tecnica o nella procedura sottostante.

Il modello CMMI in poche parole

Pertanto il modello CMMI fondamentalmente dichiara che le organizzazioni nuove e immature, inizialmente, svilupperanno capacità in procedure per gestire le configurazioni e il controllo del codice sorgente, raccogliendo dati sui progetti e sul lavoro che stanno eseguendo, pianificando progetti, tenendo traccia dei requisiti, monitorando lo stato di avanzamento del progetto e intraprendendo azioni basate sul confronto dei dati effettivi rispetto a un piano. Questa è l'essenza del livello di maturità 2.

Mentre le funzionalità del livello 2 di maturità 2 si mettono a posto, l'organizzazione e i suoi dipendenti spostano la loro attenzione altrove, quindi inizia a emergere la funzionalità di definizione dei requisiti, l'architettura e la progettazione, i processi di integrazione e definizione in modo che possano essere ripetuti. Con lo stabilizzarsi delle cose, emerge una comprensione di come lo stile delle impostazioni e della gestione influenzi le prestazioni cultura e la necessità di fornire ulteriori miglioramenti delle prestazioni. Man mano che le cose diventano più stabili e si acquisisce familiarità con i problemi quotidiani, quali il monitoraggio del progetto e della pianificazione, rimane il tempo per considerare la gestione dei rischi e analizzare alternative e opzioni prima di prendere decisioni. È possibile che emerga un coordinamento di più progetti dipendenti e un migliore controllo delle risorse condivise. Forse emergeranno un programma di formazione, uno schema di suggerimenti, una combinazione di esercitazioni per aspiranti master o semplicemente forme ritualizzate di lavoro in collaborazione per migliorare le funzionalità e aumentare il livello globale di prestazioni. Se necessario, potrebbe emergere una funzione di controllo interno o di controllo di qualità di processo. Questa è l'essenza del livello di maturità 3.

Quando un'organizzazione opera a un saldo livello di maturità 3, tutto funziona come un orologio. L'organizzazione produce nei propri stabilimenti e ha un'immagine affidabile e credibile. Un alto livello di attendibilità emerge nelle relazioni con i clienti. I manager iniziano a porre domande quali "dove investire per un ulteriore miglioramento?" e "quale team produce le miglior prestazioni economiche"? I manager iniziano a sviluppare informazioni dettagliate più avanzate in funzionalità e prestazioni e si rendono conto che possono utilizzare analisi di simulazione e statistiche per migliorare la qualità del prodotto, la consegna al cliente nonché la soddisfazione. Le decisioni del management ora sono interamente obiettive e difendibili con dati statistici. Questa è l'essenza di un'organizzazione con livello di maturità 4. Per la maggior parte degli amministratori senior, il livello di maturità 4 rappresenta lo stato ideale. Tutto funziona liscio e dispongono di dati sulle prestazioni comparati e sono in grado di consegnare rispetto alle promesse con un alto livello di precisione. La prestazione economica è notevolmente migliorata e la prestazione dell'organizzazione è estremamente prevedibile.

I comportamenti del livello di maturità 5 emergono spesso molto prima che un'organizzazione in realtà raggiunga il Livello 5. L'analisi della causa radice è vista spesso nelle organizzazioni a livello di maturità 3. Il livello 5 prevede che l'analisi della causa radice sia eseguita utilizzando dati quantitativi e che sia sostenibile a livello statistico. La comparsa di un processo formalizzato per l'innovazione del processo e la distribuzione dei miglioramenti può inoltre verificarsi prima che l'organizzazione possa effettivamente essere considerata al livello di maturità 5. Al livello 5, il miglioramento del processo è stato istituzionalizzato e inculcato nelle impostazioni cultura dell'organizzazione. La cultura consiste nello sfidare sempre status quo e ricercare la migliore funzionalità, il miglioramento della qualità del prodotto e delle prestazioni economiche.

Valutazioni CMMI

Una valutazione di maturità CMMI viene stabilità da una valutazione. Esiste un processo standard per le valutazioni. Si chiama SCAMPI e significa Standard CMMI Appraisal Method for Process Improvement. Questo processo è stato introdotto per rendere ripetibili alcune fasi del processo e per aumentare l'attendibilità del relativo risultato. I tre livelli di rigore nelle valutazioni vengono indicati come Classe A, B e C, dove la classe A è la più rigida. Le valutazioni di classe A sono necessarie per una valutazione a livello di modello accettabile per il record pubblico o per i requisiti del dipartimento di difesa degli Stati Uniti.

Tutte le classificazioni di classe A e la maggior parte di quelle di Classe B vengono condotte dai responsabili della valutazione CMMI che sono autorizzati del Software Engineering Institute a condurre le valutazioni. Questi consulenti hanno seguito un programma di formazione specifico prima di ottenere l'autorizzazione. Alcuni responsabili della valutazione hanno seguito una formazione supplementare e sono definiti come "High Maturity Lead Appraisers" CMMI. Le organizzazioni che ricercano una valutazione al livello 4 o 5 del modello devono lavorare con un responsabile della valutazione con un livello di maturità alto.

Le valutazioni ricercano la prova che le procedure sono state condotte in modo da realizzare gli obiettivi tra le aree di processo di CMMI. In un'organizzazione che gestisce un portafoglio di progetti e dotata forse di diverse business unit, viene utilizzata una formula complessa per determinare il numero di progetti in un dato ambito che devono essere valutati. L'obiettivo è di garantire una copertura adeguata di un set di progetti campione che dimostrano che l'organizzazione ha una capacità istituzionalizzata all'interno di ogni area di processo richiesta. Il Responsabile della valutazione determinerà i progetti da valutare sulla base di questa formula.

All'interno di ogni progetto che viene valutato, è necessario raccogliere prove a dimostrazione che le procedure, richieste per mostrare sufficiente capacità nell'area del processo, sono state completate. Per ogni procedura, il responsabile della valutazione cerca l'evidenza ultima e tangibile, nota come elementi e spesso viene trovata nell'evidenza dei documenti, ad esempio nei piani, nel codice sorgente, nelle progettazioni e nei documenti dell'architettura. Inoltre, ricercano affermazioni. Un'affermazione è in genere un'evidenza di una diceria, ad esempio dei membri dello staff che discutono su come condurre una procedura, come gli aneddoti che descrivono la presenza alla riunione di pianificazione. Le affermazioni vengono raccolte intervistando il personale interessati ai progetti valutati. Le affermazioni possono aumentare l'evidenza dei documenti o confutarla, portando il responsabile della valutazione a farsi domande sulla validità della documentazione.

Le valutazioni CMMI non sono necessarie affinché il modello CMMI sia utile. CMMI aiuta le organizzazioni di sviluppo software a comprendere la propria capacità e maturità e a confrontarle con le aspettative dei clienti e di altre parti interessate esterne. Grazie a una conoscenza approssimativa di dove un'organizzazione esegue il mapping nel modello CMMI viene fornito un metodo di valutazione della possibile risposta in una situazione di stress e della capacità di consegna rispetto alle aspettative. Le organizzazioni di cui è stata osservata l'esecuzione di attività con un livello di maturità più alto, senza avere una base solida di maturità più bassi possono spesso avere comportamenti imprevedibili. Ciò si verifica mentre i comportamenti di maturità elevata sono presente e questo è lodevole, queste procedure di maturità di alto livello non sono affidabili in quando non sono compilate su una base solida.

Le valutazioni CMMI vengono spesso utilizzate come modalità di convalida di un'iniziativa di miglioramento di processo a livello di organizzazione. Ciò crea una pressione per il "superamento del test". L'attenzione si rivolge alla dimostrazione che ogni procedura all'interno dell'area del processo viene seguita e alla dimostrazione con le prove. Questo può fuorviare da ciò che è effettivamente importante, ovvero mostrare che la capacità è all'altezza delle aspettative del cliente e migliorare tale capacità attraverso azioni di gestione esplicite. La particolare attenzione al "superamento del test" ha spesso prodotto effetti collaterali e malfunzionamento significativi nelle organizzazioni. Di conseguenza, il modello CMMI ha sviluppato molti detrattori nel settore aziendale. È un peccato in quanto credo fermamente nella validità del modello CMMI e nella sua capacità di offrire spunti interessanti ai responsabili nell'organizzazione, spunti che dovrebbero portare a migliorare le capacità, le prestazioni e la soddisfazione del cliente.

[1] Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

[2] Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

[3] Glazer, Hillel e Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum, CMMI or Agile: Why not embrace both!, Software Engineering Institute, novembre 2008

[4] Humphrey, Watts S., Managing the Software Process, Addison Wesley Professional, 1989

[5] Deming, W. Edwards, The New Economics for Industry, Government, Education, 2nd Edition, The MIT Press, 2000