QUALITA' ONLINE !

Qualità On Line n ° 3, Novembre 2007

Powered by
Visita il sito di ELITEC GROUP

Maturity Models: modelli esclusivi o integrabili?

Luigi Buglione, Quality & Process Specialist – Atos Origin Italia Spa, Coordinatore Gdl “CMMI E Altri Modelli Di Maturità” – Aicqci

Questo articolo è disponibile come file pdf stampabile (download).

ABSTRACT
Per un reale e profondo miglioramento continuo dei processi aziendali, è possibile porre in essere un uso congiunto di modelli di maturità sia "orizzontali" (come CMMI o SPICE) che "verticali" (come il TMMi per il testing o P3M3 per il Project Management).

1. Introduzione
Il proliferare di una pletora di modelli di maturità (maturity models – MM) nel corso degli ultimi anni (laddove il CMMI è sicuramente quello più conosciuto ai più) ha portato a coniare il termine “MM-mania”1, ad indicare in qualche modo non solo l’uso, ma anche il presunto abuso di questa formula (ovverosia ordinare i processi relativi ad un dato dominio applicativo secondo un livello di maturità crescente nell’adozione di tali pratiche) e della relativa “etichetta” (MM) a tal punto da poter annoverare periodicamente diversi nuovi MM, ora riferibili anche a prodotti (ad esempio, l’Open Source Maturity Model), non solo a processi. Basta effettuare una semplice ricerca sul web per potersene rendere conto da soli.
Alcune domande che potrebbero sorgere in coloro che vogliono (o vorrebbero) avvicinarsi all’uso di tali modelli sono ad esempio: quale modello scegliere? È possibile (o consigliabile) usarne solo uno o più di uno? Sono modelli esclusivi o integrabili? Last but not least, quanto costa usare questi modelli? Che ROI genera implementare un’iniziativa di miglioramento di processo del genere?
L’obiettivo di questo articolo è quello di illustrare l’attuale situazione fornendo, se possibile, alcune indicazioni per integrare tra di loro diversi MM e discutendo degli impatti economici (sul COQ dell’organizzazione) quanto quelli legati alle competenze delle risorse umane deputate a lavorare, a diversi livelli di conoscenza e profondità, con tali modelli.

2. Motivazioni iniziali per l’uso di MM
Partiamo allora dalla domanda iniziale, ovverosia: perché utilizzare un MM? Al fine di ottimizzarne l’uso, è bene ripercorrere brevemente la genesi di tale approccio, ricordando che nasce non in ambito software, ma prettamente organizzativo. La formulazione iniziale è infatti di uno dei guru del TQM, Philip Crosby, che alla fine degli anni ’70 propose una Organizational Maturity Quality Grid che, attraverso una serie di criteri misurabili, valutava con una scala Likert (livelli da 1 a 5) la maturità di un’organizzazione, disegnando un “profilo” (quello che oggi con il CMMI nella rappresentazione continuous è dato dai risultati degli appraisal delle singole Process Areas) [CROS79].
L’idea fu presto mutuata per il settore software da un gruppo di ricercatori IBM capitanati da Ron Radice a metà degli anni ’80 [RADI85], successivamente recepita dal SEI per valutare i fornitori ICT del DoD [SEI87] e nel 1991 tradotta e raffinata nuovamente per valutare gli sviluppi software, in quello che è divenuto il Sw-CMM v1.0 [SEI91], e poi nel 1993 con la versione 1.1 [SEI93], quella ben conosciuta ed adottata da migliaia di aziende nel mondo. Di qui tutti gli sviluppi successivi fino alla più recente evoluzione (CMMI v1.2 [SEI06a]), per i quali si rimanda, per chi fosse interessato, a [BUGL03, Cap.5].
Due possibili schemi sono stati formulati nel corso del tempo: staged e continuous. Usare lo schema di rappresentazione “staged” (a scalare) di un MM permette ad un’organizzazione di poter conoscere a che punto del cammino verso una migliore capacità produttiva essa si posiziona in un dato momento. Il risultato finale sarà quindi un Maturity Level (ML) compreso tra 1 e 5, laddove l’entità valutata è l’organizzazione nel suo complesso. Questo è lo schema iniziale mutuato da Crosby. Il vincolo con questo tipo di schema è però quello di dover valutare strettamente gruppi di processi per livelli e secondo una progressione standard. Ad esempio, volendo sapere se l’organizzazione raggiunge il ML2, andranno valutati i processi previsti dal modello all’interno di tale livello, e non altri; qualora vengano visionati anche altri processi in modo puntuale (es: CAR, processo di livello 5), questi non aggiungeranno però valore al risultato dell’appraisal teso a verificare la compatibilità delle pratiche del solo livello 2 [BUGL06c].
Usare invece la rappresentazione “continuous” di un MM permette di effettuare una valutazione diretta del Capability Level (CL) dei singoli processi di un’organizzazione, non necessariamente seguendo la progressione per ML proposta dal modello. Per aggregazione (“equivalent staging”), qualora vengano valutati tutti i processi di un dato livello, è possibile comunque ottenere il corrispondente ML, e quindi il rating dell’organizzazione, come per la rappresentazione “staged”.

 Le assunzioni fondamentali per effettuare un benchmark esterno di processo sono quindi date da:

  • Stabilire il set dei processi ritenuti comuni per quel dato dominio (modello di processi) e relative pratiche;
  • Stabilire la progressione tipica che si suppone debba esserci ai diversi stadi di maturità per tale modello (ripartizione dei processi per ML; ad es: la pianificazione del progetto è un processo da eseguirsi prima o dopo dell’analisi statistica dei dati storici?);
  • Stabilire dei criteri di valutazione che rispettino ed esprimano in modo fedele il reale livello di maturità dell’organizzazione nella percezione comune delle persone.

Una precisazione utile per il prosieguo della discussione è che per MM deve intendersi l’insieme di diverse componenti:

  • Modello di processi;
  • Suddivisione dei processi per livelli di crescente maturità e per gruppi tematicamente omogenei (nel caso del  CMMI sono 4: project, process, engineering, support);
  • Criteri di valutazione del modello di processi (nel caso di CMMI, i requisiti sono espressi in ARC [SEI06b].

Ne consegue che il beneficio derivante dall’adozione di un MM può essere visto da diversi punti di vista:

  • Interno: si conoscono i gap da colmare, da cui derivare una “tabella di marcia” verso il continuous improvement del proprio sistema di processi, non necessariamente esauribile con i processi inclusi nello scopo del SGQ/QMS aziendale, ma anche considerando quelli che rappresentano i punti (formalmente) “mancanti” nella mappa strategica dei processi aziendali2, come nella logica di una balanced scorecard3. Sapere che gli input allo staffing di un progetto debbano essere migliorati anche a fronte di una revisione del processo di people management, ad esempio, non rientra completamente nello scopo della clausola 6 della ISO 9001:2000 (es: processo di mentoring o di MBO), ma contribuisce in modo diretto e “pesante” ai risultati dei processi produttivi nello scopo “stretto” certificativo.
  • Esterno: si crea un linguaggio comune nella comunità di riferimento, con una fiducia nei risultati di appraisal ottenuti e condivisi. Sapere che una data organizzazione è stata riconosciuta conforme ad esempio al ML2 del CMMI indica quindi un ottimo livello di adozione delle pratiche basilari a livello di progetto, ma non necessariamente lo stesso si potrà affermare per quelle pratiche riferibili ai livelli di maturità superiori (per grandi linee: ML3 contiene processi di natura organizzativa, ML4 uso di approcci quantitativi per il controllo e monitoraggio delle attività, ML5 infine approcci volti al continuous improvement). Anche se poi i distinguo da poter fare sono comunque molti e di indubbio interesse, sono fuori dello scopo della presente discussione.

3. Usi esclusivi di MM
Osservando la storia e l’evoluzione dei MM, è possibile notare come (ovviamente) i primi ad essere prodotti siano stati MM con un modello di processi sufficientemente ampio da ricomprendere buona parte dei processi della supply chain di un dato settore, modelli che possiamo definire “orizzontali”. Alcuni esempi possono essere quindi il Sw-CMM, SPICE (ISO 15504)4, Trillium [BELL94], FAA iCMM [FAA01] e CMMI, che ricomprendono processi relativi (temporalmente parlando) alla fase di deployment di un progetto software, non includendo (ad eccezione di SPICE, ad esempio) i processi relativi al tender (o bid che dir si voglia).
Di contro, è possibile classificare come “verticali” quei MM che approfondiscono uno specifico processo o gruppo di processi incluso in un modello orizzontale. Alcuni esempi possono essere il TMMi (Test Maturity Model Integration)5 o P3M3 per il Project Management [OGC06].

immagine

Relativamente ai modelli “orizzontali”, il fatto di essere sufficientemente “comprensivi” in termini contenutistici e di essere stati i primi modelli a proporre tale paradigma ha portato come si può ben immaginare ad un loro uso “esclusivo”. Tornando indietro nel tempo di qualche anno, non esisteva l’esigenza da un lato di integrarli con altri modelli, vista l’esiguità del numero di modelli proposti, né d’altro canto se ravvedeva l’opportunità, essendo l’obiettivo principale di molte compagnie quello di un riconoscimento esterno per motivazioni di business più che per un effettivo miglioramento di natura tecnica.
Riepilogando, un’organizzazione che voglia adottare un MM “orizzontale” effettuerà una fase di scouting tra i diversi modelli concorrenti per un dato dominio applicativo e relativa analisi SWOT (Strenghts, Weaknesses, Opportunities, Threats) al fine di selezionare quello che offra, in prospettiva, il miglior rapporto costi-benefici. Ad esempio, meglio CMMI o SPICE? SPICE o AutomotiveSPICE [AUTO07]? CMMI o FAA iCMM?

Ma cosa succede nel caso in cui un’organizzazione sia maggiormente interessata all’uso di MM per un reale miglioramento in ottica “interna”?

4. Criteri per possibili integrazioni di MM
È possibile evidenziare diverse possibilità, legate ai possibili obiettivi informativi di un’organizzazione. Nel seguito si riportano due ipotesi, a titolo esemplificativo.

  1. Obiettivo: Ampliare lo scopo del set di processi del MM “orizzontale”, mantenendo lo stesso livello di “profondità” nelle descrizioni.
    1. Modalità operativa: Inserire nuovi processi ad-hoc, eventualmente “prelevati” da altri MM, mantenendo l’architettura e criteri di rating del modello principale. 
      1. Un esempio: in CMMI non è previsto un processo di riuso a sé stante, diversamente dalla ISO 15504 (processo ORG.6). Nel mapping effettuato dal SQI, gli unici riferimenti alle pratiche di riuso vengono effettuate in relazione al PP (Project Planning), SG1 (Establish Estimates) e con un giudizio pari a “slight” (leggero), poi in diverse GP sempre dello stesso processo. Analizzando il contenuto delle BP di ORG.6 si ravvedono invece elementi che impattano tanto sui processi organizzativi (es: librerie del riuso) quanto di informativa e comunicazione ai potenziali utenti (che potrebbe essere mappata con la GP2.7 di TS – Technical Solution). Ma se l’organizzazione volesse invece mantenere l’integrità del processo ORG.6 in aggiunta al modello di processi CMMI, i passi da seguire sarebbero i seguenti:
        1. Posizionamento in un gruppo di processi CMMI (es: Process Management)
        2. Posizionamento del processo in uno dei 5 livelli di maturità (es: ML3)
        3. Scrittura delle sezioni “Elaboration” per ciascuna GP del processo di riuso
    2. Modalità operativa: Recuperare elementi dell’architettura da altri MM, per ottenere un proprio modello “target”.
      1. Un esempio: si consideri AutomotiveSPICE, il MM pensato per il settore automobilistico mutuato dallo standard ISO 15504 (aka SPICE). AutomotiveSPICE propone – come il modello di processi originario in SPICE – un obiettivo unico (purpose) per ciascun processo a cui legare tutte le BP (Base Practice, l’equivalente delle SP di CMMI), invece di poterle suddividere in due o più SG (Specific Goal) specifici, dettagliando maggiormente l’obiettivo “padre” di quel processo.
  2. Obiettivo: Ampliare lo scopo del set di processi del MM “orizzontale”, approfondendo il livello di “profondità” per taluni processi o gruppi di processi.
    1. Modalità operativa: Incrociare il modello “orizzontale” con uno o più modelli “verticali”, irrobustendo le pratiche desiderate nel modello “principale”. Le azioni principali sono:
        • Mapping bi-fronte tra i vari MM in esame, sia termini di pratiche che di architettura per cogliere al meglio le differenze e le complementarietà in essere;
        • Inserimento degli elementi risultati “additivi” dal modello “verticale” a quello “orizzontale”. Secondo il livello di granularità, le nuove pratiche potranno essere delle SP o delle sub-practice all’interno di una SP esistente. Gli altri elementi, equiparabili alle vecchie Common Feature (CF) potranno riferirsi alle sezioni “Elaboration” delle singole GP di quella data Process Area;
      1. Un esempio: si supponga di voler irrobustire le pratiche CMMI di project management fino al ML3 introducendo nuovi elementi o viste rispetto a quanto già esistente, identificando come modello verticale P3M3 [OGC06]. Tale modello, che copre un campo più ampio del solo Project Management (le tre “P” stanno per “portfolio, programme & project”), è composto da 32 processi, ciascuno espresso con 6 elementi (l’equivalente delle Common Feature nel CMMi): Functional Achievement / Process Goal (FA); Approach (AP); Deployment (DE); Review (RE); Perception (PE); Performance Measures (ME). La seguente tabella fornisce una mappatura con le CF del CMMi.

CMMI v1.1 CF

CMMI v1.x GP

P3M3

CO – Committment to Perform

2.1

FA – Funct.Achiev. / Process Goal

AB – Ability to Perform

2.2; 2.3; 2.4; 2.5; 3.1

AP – Approach

DI – Direct Implementation

2.6; 2.7; 2.8; 3.2

DE – Deployment; ME – Perf.Meas.

VE - Verification

2.9; 2.10

RE – Review; PE – Perception

Tab. 1 – Common Feature: CMMI vs P3M3


P3M3

CMMI v1.x GP

FA – Functional Achievement / Process Goal

2.1; 2.3; 2.4

AP – Approach

2.2

DE – Deployment

2.6

RE – Review

2.9; 2.10

PE – Perception

2.7

ME – Performance Measures

2.8

 Tab. 2 – Common Feature: P3M3 vs CMMI
In termini di processi, P3M3 prevede i seguenti 32 processi, suddivisi sempre in 5 ML:


ML1

ML2

ML3

ML4

ML5

1.1 Project Definition

2.1Business Case Develop.

3.1 Benefits mgmt

4.1 Mgmt Metrics

5.1 Proactive problem mgt

1.2 Progr. Mgmt awareness

2.2 Programme Organization

3.2 Transition mgmt

4.2 Quality Mgmt

5.2 Tech. management

2.3 Progr. Definition

3.3 Information mgmt

4.3 Organiz. Cultural grow

5.3 Cont. process impr.

2.4 Prj. Establishment

3.4 Organiz. Focus

4.4 Capacity Mgmt

2.5 Prj. Plan, Monit & Control

3.5 Process Definition

2.6 Stakeholder mgt & comm

3.6 Training, skill…

2.7 Req. Management

3.7 Integr. Mgt & Rep

2.8 Risk Management

3.8 Lifecycle control

2.9 Config. Management

3.9 Intergroup coord

2.10 Programme Plan & Contr

3.10 Quality Assur.

2.11 Mgmt suppl & ext.parties

3.11 COE deployment

3.12 Org. portfolio

Tab. 3 – I processi di P3M3 v1.0  per livello di maturità


Ad esempio l’equivalente delle due PA in CMMI relative a pianificazione (PP) e monitoraggio & controllo (PMC) nel ML2 sono mappabili con il processo 2.5 (Project Planning, Monitoring & Control), ma l’informazione interessante per un architetto CMMI potrebbe essere quella di irrobustire i processi del gruppo di Project Management con le informazioni legate agli aspetti di Programma e Portfolio (tipicamente organizzativi e quindi riconducibili ad un livello 3 CMMI). Ancora, il confronto su diversi posizionamenti in termini di livelli di maturità per pratiche analoghe (in diversi casi P3M3 anticipa alcuni aspetti rispetto al posizionamento nella versione staged del CMMI) potrebbe portare a modificare i propri processi, inserendo talune pratiche precedentemente non previste poiché non direttamente riferibili alla mappatura tra i processi del proprio QMS e l’unico modello “orizzontale” di riferimento (es: CMMI). Ancora, la crescita culturale del personale (processo 4.3 P3M3) è vista come processo a sé stante e non solo come pratica nell’ambito di un processo CMMI (GP2.5), quindi con diverse implicazioni a livello organizzativo. E via dicendo, le possibili considerazioni potranno essere diverse, muovendo dagli obiettivi informativi dell’organizzazione.
A questo punto il modello target sarà quello su cui poter effettuare i nuovi appraisal di classe B/C, volti ad un miglioramento continuo ancora più mirato e focalizzato, secondo i desiderata dell’organizzazione.

5. Dai MM verso il PMS
Quanto finora discusso non può però prescindere dal contesto più allargato del sistema dei processi aziendali. Parlare di SGQ/QMS può risultare limitativo, poiché sotto tale etichetta si ricomprendono formalmente solo i processi direttamente riferibili ai requisiti della ISO 9001:2000. Per tale motivo, si preferisce riferirsi ad una visione “allargata” del QMS ridenominandolo PMS (Process Management System), comprendente l’interezza dei processi di un’organizzazione.
In un processo di miglioramento continuo che prevede la modifica dei processi aziendali affinché questi siano “misurati” in un’ottica evolutiva, di crescente maturità sia in termini definitori che implementativi, un fattore da considerare è sicuramente la necessaria gradualità nell’introduzione dei nuovi elementi, al fine di minimizzare le resistenze al cambiamento.
Come discusso in apertura di articolo, un MM è dato dall’insieme di più elementi, tra cui le regole di valutazione dei processi. Essendo il processo di audit in termini economici una delle voci imputabili – per il suo costo – nel calcolo del COQ (Cost Of Quality) [JAGA05], è fondamentale per una corretta strategia di integrazione delle diverse modalità di audit/appraisal sulle stesse entità , al fine di evitare inutili duplicazioni, laddove possibile.

Non può esistere una regola generale valida per ogni realtà, ovviamente. Ma alcuni suggerimenti improntati al buon senso, si. Ad esempio, tra due situazioni di partenza A (audit secondo i criteri della UNI ISO 19011:2003 [UNI03a]) e B (criteri ARC [SEI06b] con il modello SCAMPI [SEI06c] Classe B) entrambi applicabili a progetti di sviluppo e manutenzione software per un’azienda appartenente ai settori EA 33/35, diverse possibilità:

  1. due audit separati effettuati in parallelo à costi doppi, risultati che possono essere usati per azioni correttive/migliorative ma con difficoltà e maggior tempo necessario per riconciliare i due schemi di partenza verso una comune azione di miglioramento sui temi trattati da ambedue gli schemi (ISO e CMMI);
  2. da un certo momento si decide che tutti i processi (non solo quelli inclusi nel MM) verranno valutati con la regola più dettagliata tra le due à i costi risulteranno più alti del solo audit secondo i criteri della ISO 19011, essendo i criteri ARC maggiormente comprensivi e dettagliati, ma comunque più bassi che non nel caso precedente (doppi audit);
  3. è possibile anche una soluzione intermedia, ovverosia l’uso dell’architettura del modello di rating del MM ma con un set ridotto/customizzato di criteri di valutazione (le GP di CMMI), sempre nel rispetto dei criteri previsti nel sistema A [BUGL06b]. Tale Il sistema “misto” potrà quindi essere usato come elemento di transizione verso la seconda soluzione:
    • per tutti i processi del PMS, in modo massivo oppure
    • per alcuni processi, mantenendo per altri la soluzione intermedia.
    I vantaggi si traducono in una migliore e più approfondita conoscenza del proprio modo di lavoro, con un maggior ritorno di produttività attraverso cicli più brevi per la re-ingegnerizzazione dei processi.

6. Impatti sulla competenza delle risorse umane
Ovviamente scelte organizzative volte alla realizzazione di quanto discusso non possono essere realizzate con il solo apporto dei process owner e degli enti deputati ad effettuare gli audit. Nella “lista della spesa” per tale investimento (non costo) è necessario difatti pensare ad un intervento volto, più che alla formazione, al raggiungimento di una reale e vissuta consapevolezza (awareness) di cosa il PMS esprima, con e senza il contributo attivo di ogni risorsa dell’organizzazione.
Sebbene tale aspetto dovrebbe essere già vissuto da ogni azienda che vanti la certificazione ISO 9001:2000, spesso tale consapevolezza non emerge da un’analisi sul campo. Alcuni segnali di alto livello possono già emergere dalla lettura della mappa dei processi aziendali (quella che la BSC chiama mappa strategica), opportunamente incrociata con i piani formativi (almeno degli ultimi 2 anni, con riferimento alla formazione “tecnica” e non “istituzionale”) e con l’indicazione delle misure tipicamente adottate per il monitoraggio & controllo dei processi.
Aggiornare periodicamente le competenze e gli skill del personale di un’organizzazione rimane quindi un elemento centrale per ogni organizzazione, indipendentemente dall’uso di un MM. Per quelle aziende che poi intendano usare un meccanismo come quello dei MM per conseguire un effettivo ed efficace miglioramento della propria capacità organizzativa e produttiva, tale aspetto diventa ancor di più fondamentale, non per il mero ossequio a criteri valutativi (es: CMMI GP2.5), ma perché l’unico modo - quantomeno – per un sustain delle proprie performance nel breve/medio periodo. Una evidenza indiretta del ridotto numero di personale con conoscenze di MM e temi collegati al deployment dei singoli processi inclusi in tali modelli è rinvenibile dai rapporti periodici sulla numerosità di aziende riconosciute conformi ad audit ufficiali. Nel caso del CMMI, dall’ultimo rapporto del SEI [SEI06d] risulta che le aziende che si sono sottoposte con risultato positivo ad un appraisal SCAMPI Classe A sono ad oggi non più di 10, contro i 598 degli USA, i 158 della Cina, i 39 del Brasile, i 65 della Francia,  i 56 della Corea e via dicendo. Ovviamente debbono poi sommarsi tutte quelle aziende che non arrivano al momento certificativo ma che comunque usano CMMI (o altri MM) per supportare il proprio miglioramento di processo. Ma in ogni caso, è ragionevole presupporre una proporzionalità – seppur non aritmetica – tra i due livelli (solo uso interno; riconoscimento certificativo).
Che profilo/ruolo in un’azienda dovrebbe/potrebbe essere deputato a conoscere i MM e il corpus di conoscenza collegato? Un project manager, un QA assistant o un Ingegnere del Software?  Sia recenti studi italiani come ICT-Job [ANAS] come anche modelli di competenze stranieri sono particolarmente interessati a seguire tutte le evoluzioni tecnologiche, aggiornando le relative famiglie professionali, purtroppo a detrimento dei gruppi legati maggiormente agli aspetti organizzativi nell’ICT [BUGL03b]. Questo è sicuramente il punto di attenzione da cui dover partire per aggiornare in modo realistico e profittevole la lista dei “jobs & roles” nelle proprie organizzazioni, al fine di poter seguire (o anticipare, possibilmente), e non inseguire affannosamente il miglioramento.

7. Conclusioni & Prospettive
Modelli di maturità (MM) come il CMMI o SPICE rappresentano per un’organizzazione ICT un possibile “alleato” e non un concorrente [BUGL06a] rispetto alla ISO 9001:2000. Tali modelli possono fornire un aiuto nel pianificare al meglio le azioni tese al miglioramento del proprio PMS, inteso come il sistema complessivo dei processi di un’azienda, ricomprendendosi anche quei processi non riferiti strettamente allo scopo certificativo ISO 9001:2000 (es: ufficio viaggi, contabilità, …).
In particolare sono almeno due gli aspetti positivi che possono trarsi dai MM. Innanzitutto è possibile verificare l’opportunità di ibridare più modelli tra loro, tipicamente un modello “orizzontale” (contenente i processi tipici della suppy chain per un dato dominio applicativo) con uno o più modelli “verticali” (contenenti una visione più dettagliata per singoli gruppi tematici di processi: es: project management, test, misurazione, …). Ciò può offrire vantaggi in termini di ridefinizione e miglioramento dei propri processi, irrobustendoli con i giusti elementi, a costi di analisi alquanto ridotti, essendo la quasi totalità dei MM accessibile sul web, e con un buon livello di confidenza nella qualità di tali input documentali, essendo standard condivisi da comunità di interesse.
In secondo luogo, gli schemi di valutazione continuous proposti dai MM – anche se adottati in modo personalizzato – possono rappresentare un passaggio “evolutivo” dai criteri della ISO 19011:2003 verso una visione più approfondita del “come” vengono espressi ed eseguiti i processi del PMS di un’azienda. Il bilanciamento tra il livello di profondità degli audit e la granularità dei risultati ottenuti, input per le relative azioni correttive/migliorative, rappresenta uno dei obiettivi per il conseguimento di un miglioramento complessivo, anche in termini economico-finanziari, nel medio periodo.
Presupposto imprescindibile per poter realizzare quanto descritto rimane sempre la componente umana e la competenza che può esprimere. Viviamo in un mondo che maneggia molti dati ma poche informazioni, dove il termine “knowledge” è impropriamente usato ed abusato, ma non realmente vissuto. Si parla di “knowledge management” e di KMS per intendere semplici repository documentali, ma non è di uso frequente ad oggi misurare il Capitale Umano (Human Capital) o altri aspetti intangibili per conoscere il reale valore della propria azienda. Quello che si auspica è che gli aspetti organizzativi (e quindi le relative competenze) siano progressivamente aggiornati e valutati alla stregua degli skill di natura tecnica. Solo il giusto bilanciamento tra le due famiglie professionali può e potrà garantire un miglioramento costante ed armonico di un’azienda.
E partire dalla conoscenza ed uso di un MM può rappresentare un primo passo teso a creare consapevolezza verso questo obiettivo.

8. Bibliografia

[ANAS]

Anasin-Federcomin, ICT-Job, URL: http://www.ict-job.it

[AUTO07]

SPICE User Group, Automotive SPICE. Process Reference Model (PRM) version 4.3, May 2007, URL: www.automotivespice.com

[BELL94]

Bell Canada, TRILLIUM : Model for Telecom Product Development & Support Process Capability, Release 3.0, December 1994, Internet Edition, URL: http://nas.cl.uh.edu/mckay/rbse/trillium.pdf

[BUGL03a]

Buglione  L., Misurare il Software. Quantità, qualità, standard e miglioramento di processo nell’Information & Communication TEchnology, FrancoAngeli, 2003, ISBN 88-464-4634-8, URL: http://www.geocities.com/lbu_measure/libri/mis.htm

[BUGL03b]

Buglione L., SQA: competenza e addestramento nello SWEBOK, Atti del XXI Convegno Nazionale AICQ "Qualità oggi: cosa cambia, contributi per capire", Roma 10 Novembre 2003

[BUGL06a]

Buglione L., Modelli di Software Process Improvement e ISO 9001:2000: possibili alleati o concorrenti?, De Qualitate, Nuovo Studio Tecna, Maggio 2006, Anno XV, N° 5, pp. 67-72

[BUGL06b]

Buglione L. & Cislaghi M., Valutare i processi nelle Organizzazioni ICT: Oltre la ISO 19011?, Qualità, n.4/2006, Luglio/Agosto 2006, pp.4-8

[BUGL06c]

Buglione L. & Abran A., Introducing Root-Cause Analysis and Orthogonal Defect Classification at Lower CMMI Maturity Levels, Proceedings of MENSURA 2006, Cadiz (Spain), November 6-8, 2006, ISBN 978-84-9828-101-9, pp. 29-40, URL: http://gsyc.es/~herraiz/MENSURA2006/articles/ircaodclcml.pdf

[COPE03]

Copeland L., The Maturity Maturity Model (M3). Guidelines for Improving the Maturity Process, StickyMinds, September 2003, URL: http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&ObjectId=6653

[CROS79]

Crosby P.B., Quality is free, McGraw-Hill, 1979, ISBN 0-451-62585-4

[FAA01]

Ibrahim L. et al., The Federal Aviation Administration Integrated Capability Maturity Model (FAA iCMM), Version 2.0, September 2001, URL: http://www.faa.gov/about/office_org/headquarters_offices/aio/documents/media/FAA-iCMMv2.pdf

[JAGA05]

Jagannathan S.R., Bhattacharya S., Matawie K., Value Based Quality Engineering, TickIT International, 1Q05, January 2005, pp.3-9, URL: http://www.tickit.org/international.htm

[OGC06]

OGC, P3M3: Portfolio,Programme & Project Management Maturity Model, Version 1.0, February 2006, Office of Government Commerce, URL: http://www.ogc.gov.uk/documents/p3m3.pdf

[RADI85]

Radice R.A., Harding J.T., Munnis P.E. & Phillips R.W., A Programming Process Architecture, IBM Systems Journal, IBM Corp., Vol. 24, No. 2, 1995, pp. 79-90, URL: http://www.research.ibm.com/journal/sj/382/radice.pdf

[SEI87]

Humphrey W. & Sweet W., A Method for Assessing the Software Engineering Capability of Contractors, Technical Report, CMU/SEI-87-TR-023, Software Engineering Institute (SEI), 1987

[SEI91]

Paulk  M.C., Curtis B., Chrissis M.B. et al., Capability Maturity Model for Software, Version 1.0, Software Engineering Institute, CMU/SEI-91-TR-24, August 1991

[SEI93]

Paulk M.C., Weber C.V., Garcia S.M.,  Chrissis M.B. & Bush M., Key Practices of the Capability Maturity Model Version 1.1, Software Engineering Institute/Carnegie Mellon University, CMU/SEI-93-TR-025, February 1993, URL: http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr25.93.pdf

[SEI06a]

CMMI Product Team, CMMI for Software Engineering, Version 1.2, CMMI-DEV v1.2, CMU/SEI-2006-TR-008, Technical Report, Software Engineering Institute, August 2006, URL: http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html

[SEI06b]

SEI, Appraisal Requirements forCMMI, Version 1.2 (ARC, V1.2), Software Engineering Institute, Technical Report, CMU/SEI-2006-TR-011, August 2006, URL: http://www.sei.cmu.edu/publications/documents/06.reports/06tr011.html

[SEI06c]

SEI, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), version 1.2: Method Definition Document, Software Engineering Institute, Handbook, CMU/SEI-2006-HB-002, August 2006, URL: http://www.sei.cmu.edu/publications/documents/06.reports/06hb002.html

[SEI06d]

SEI, Process Maturity Profile - CMMI v1.1 SCAMPI v1.1 Class A Appraisal Results: 2006 Mid-Year Update, Presentation, Software Engineering Institute, September 2006

[SEMQ06]

---, SEMQ website, URL: http://www.geocities.com/lbu_measure/spi/spi.htm#p6 (last access: 2006/05/24)

[UNI00]

UNI EN ISO 9001:2000, Sistemi di Gestione per la Qualità. Requisiti, Dicembre 2000

[UNI03a]

UNI EN ISO 19011:2003, Linee guida per gli audit dei sistemi di gestione per la qualità e/o di gestione ambientale, 2003

[UNI03b]

UNI 11097:2003, Linee Gestione per la qualità - Indicatori e quadri di gestione della qualità - Linee guida generali, 2003

[UNI05]

UNI EN ISO 9000:2005, Sistemi di Gestione per la Qualità. Fondamenti e Terminologia, Dicembre 2005

 


1Per una versione aggiornata della lista di Copeland [COPE03], con URL: http://www.geocities.com/lbu_measure/spi/spi.htm#p6
2Cfr. ISO 9001:2000 [UNI00, §4.1, lett.c], in ossequio al quinto principio di gestione della qualità, l’ approccio sistemico alla gestione » [UNI05, §0.2, lett.c].
3Una norma italiana ad-hoc è la UNI 11097:2003 [UNI03b] che introduce in forma embrionale i concetti della BSC alla sola politica della qualità.
4www.isospice.com
5http://www.tmmifoundation.org/

 

A cura della redazione della Rivista "Qualità" di AICQ
Direttore Responsabile:Giovanni Mattana
Redazione: Linda Nobile
Realizzazione tecnica a cura di Eli-net S.r.l. società di ELITEC GROUP
Redazione tecnica:Alberto Bobbo, Enrico Ladogana, Marco Bolzoni