ANALISI E MESSA IN OPERA IN AMBITO …infocom.uniroma1.it/~robby/Tesi/D'Arduini 2006-07.pdf ·...

SAPIENZA UNIVERSITÀ DI ROMA FACOLTÀ DI INGEGNERIA

TESI DI LAUREA SPECIALISTICA IN

INGEGNERIA DELLE TELECOMUNICAZIONI

ANALISI E MESSA IN OPERA IN AMBITO

AZIENDALE DEL CMMI (CAPABILITY

MATURITY MODEL INTEGRATION):

GESTIONE DELLA CONFIGURAZIONE,

ASSICURAZIONE QUALITÀ DI PROCESSO E

DI PRODOTTO

RELATORE LAUREANDO

CH. MO PROF. ROBERTO CUSANI ROBERTO D’ARDUINI

ANNO ACCADEMICO 2006/2007

Indice

I

INDICE

INDICE............................................................................................................. I

INDICE DELLE TABELLE E DELLE FIGURE..................................... III

INTRODUZIONE ........................................................................................... 1

CAPITOLO I GESTIONE DELLA QUALITÀ ..................................................... 3

I.1 IL CONTESTO ORGANIZZATIVO................................................................................ 3

I.2 STANDARD INTERNAZIONALI (ISO)........................................................................ 6

I.2.1 UNI EN ISO 9001: 2000............................................................................................... 8 I.2.2 UNI CEI ISO/IEC 12207: 2003 .................................................................................. 11 I.2.3 ISO IEC 9126-1: 2000 ................................................................................................ 13

I.3 ALTRI STANDARD (ECSS, MIL-STD-498, AQAP-160)....................................... 15

I.4 MODELLI DI MATURITÀ........................................................................................ 20

I.4.1 I MODELLI CMM......................................................................................................... 20 I.4.2 IL MODELLO CMMI® E LA SUA EVOLUZIONE ............................................................ 22 I.4.3 IL CMMI: OBIETTIVI E VANTAGGI.............................................................................. 24

CAPITOLO II IL CAPABILITY MATURITY MODEL INTEGRATION

(CMMI) .......................................................................................................... 30

II.1 I COMPONENTI DEL MODELLO ............................................................................... 31

II.1.1 LE AREE DI PROCESSO................................................................................................ 31 II.1.2 OBIETTIVI GENERICI ................................................................................................... 37 II.1.3 PRATICHE GENERICHE ................................................................................................ 37 II.1.4 OBIETTIVI SPECIFICI ................................................................................................... 38 II.1.5 PRATICHE SPECIFICHE ................................................................................................ 39 II.1.6 TYPICAL WORK PRODUCT ........................................................................................... 39 II.1.7 SOTTOPRATICHE ......................................................................................................... 39

II.2 I LIVELLI DI CAPABILITY ....................................................................................... 40

II.3 I LIVELLI DI MATURITY ......................................................................................... 43

II.4 LE DUE RAPPRESENTAZIONI .................................................................................. 47

Indice

II

II.4.1 LA RAPPRESENTAZIONE SCALARE .............................................................................. 47 II.4.2 LA RAPPRESENTAZIONE CONTINUA............................................................................ 49 II.4.3 DIFFERENZE TRA LE DUE RAPPRESENTAZIONI............................................................ 51

II.5 QUADRO CONCLUSIVO PER LA REGISTRAZIONE AZIENDALE.................................. 53

CAPITOLO III L’APPROCCIO AZIENDALE AL CMMI................................. 56

III.1 OBIETTIVI AZIENDALI ........................................................................................... 56

III.2 ORGANIZZAZIONE DEL GRUPPO DI LAVORO .......................................................... 57

III.3 FASI DEL PROGETTO E DELLA SUA MESSA IN OPERA.............................................. 58

III.4 QUADRO D’INSIEME: LE RELAZIONI TRA LE AREE DI PROCESSO ........................... 62

CAPITOLO IV GESTIONE DELLA CONFIGURAZIONE (CM) ....................... 73

IV.1 DESCRIZIONE DELL’AREA DI PROCESSO ............................................................... 73

IV.2 ASSESSMENT DELLA GESTIONE DELLA CONFIGURAZIONE.................................... 74

IV.3 ANALISI DEI DATI RACCOLTI................................................................................. 83

CAPITOLO V ASSICURAZIONE QUALITÀ DI PROCESSO E DI PRODOTTO

(PPQA) ........................................................................................................... 85

V.1 DESCRIZIONE DELL’AREA DI PROCESSO ............................................................... 85

V.2 VALUTAZIONI SULL’ASSICURAZIONE QUALITÀ DI PROCESSO E DI PRODOTTO

(PPQA) ............................................................................................................................ 86

CAPITOLO VI PROGETTAZIONE DEL NUOVO SISTEMA PROCEDURALE ... 88

VI.1 QUADRO D’INSIEME: IL NUOVO SISTEMA PROCEDURALE ...................................... 88

VI.2 SCHEDA PROGETTO............................................................................................... 90

VI.3 PROCEDURA: GESTIONE DELLA CONFIGURAZIONE ............................................... 99

VI.3.1 DESCRIZIONE DELLA PROCEDURA.......................................................................... 99 VI.3.2 MAPPING DELLE PRATICHE SPECIFICHE CON LA PROCEDURA.............................. 100

VI.4 SISTEMA DI GESTIONE PER LA QUALITÀ ............................................................. 108

CONCLUSIONI .......................................................................................... 110

APPENDICE A............................................................................................ 112

APPENDICE B ............................................................................................ 129

APPENDICE C............................................................................................ 130

APPENDICE D............................................................................................ 140

BIBLIOGRAFIA......................................................................................... 148

Indice delle Tabelle e delle Figure

III

INDICE DELLE TABELLE E

DELLE FIGURE

FIGURA I.1 – LE TRE DIMENSIONI CRITICHE DI UN'AZIENDA ...................................................... 6

FIGURA I.2 – STORIA DEI CMM ............................................................................................. 24

TABELLA I.3 – RIASSUNTO DEI RISULTATI DI PERFORMANCE DEL CMMI................................. 28

FIGURA I.4 – PERFORMANCE DI PRODUTTIVITÀ E DI QUALITÀ DEL SOFTWARE PER LA LOCKHEED

MARTIN ................................................................................................................................. 29

FIGURA II.1 – STRUTTURA GENERALE DEL MODELLO CMMI................................................... 31

TABELLA II.2 – AREE DI PROCESSO DELLA CATEGORIA PROCESS MANAGEMENT ..................... 33

TABELLA II.3 – AREE DI PROCESSO DELLA CATEGORIA PROJECT MANAGEMENT ..................... 34

TABELLA II.4 – AREE DI PROCESSO DELLA CATEGORIA ENGINEERING .................................... 35

TABELLA II.5 – AREE DI PROCESSO DELLA CATEGORIA SUPPORT ........................................... 36

TABELLA II.6 – OBIETTIVI GENERICI CON LE RELATIVE PRATICHE GENERICHE......................... 38

FIGURA II.7 – CAPABILITY PROFILE ....................................................................................... 41

FIGURA II.8 – STRUTTURA DELLA RAPPRESENTAZIONE SCALARE .............................................. 48

FIGURA II.9 – AREE DI PROCESSO NELLA RAPPRESENTAZIONE SCALARE .................................. 48

TABELLA II.10 – AREE DI PROCESSO PER ML ........................................................................ 49

FIGURA II.11 – STRUTTURA DELLA RAPPRESENTAZIONE CONTINUA ......................................... 50

FIGURA II.12 – AREE DI PROCESSO NELLA RAPPRESENTAZIONE CONTINUA .............................. 50

TABELLA II.13 – COMPARAZIONE TRA RAPPRESENTAZIONE CONTINUA E SCALARE ................... 51

FIGURA II.14 – PRATICHE GENERICHE ED OBIETTIVI GENERICI ............................................... 52

FIGURA II.15 – TARGET PROFILE........................................................................................... 55

FIGURA III.1 – SUDDIVISIONE PER AFFINITÀ DELLE AREE DI PROCESSO SELEZIONATE ............. 58

FIGURA III.2 – IL MODELLO IDEAL: IL CICLO DEL MIGLIORAMENTO CONTINUATIVO............... 59

FIGURA III.3 – LE RELAZIONI TRA LE AREE DI PROCESSO........................................................ 62

FIGURA IV.1 – STIMA IN % DELLE SOTTOPRATICHE SODDISFATTE PER L’AREA GESTIONE DELLA

CONFIGURAZIONE.................................................................................................................. 84

Indice delle Tabelle e delle Figure

IV

FIGURA VI.1 – LE RELAZIONI TRA LE AREE DI PROCESSO E LE PROCEDURE ............................ 89

FIGURA VI.2 – SCHEDA PROGETTO ....................................................................................... 98

FIGURA VI.3 – ALBERATURA DEL SISTEMA DI GESTIONE PER LA QUALITÀ ............................. 108

FIGURA VI.4 – STIMA IN % DELLE SOTTOPRATICHE SODDISFATTE PER L’AREA GESTIONE DELLA

CONFIGURAZIONE PRIMA DEL NUOVO SISTEMA PROCEDURALE .............................................. 111

FIGURA VI.5 – STIMA IN % DELLE SOTTOPRATICHE SODDISFATTE PER LE AREE GESTIONE DELLA

CONFIGURAZIONE E ASSICURAZIONE QUALITÀ DI PROCESSO E DI PRODOTTO DOPO L’ADOZIONE

DEL NUOVO SISTEMA PROCEDURALE ..................................................................................... 111

Introduzione

1

INTRODUZIONE

Ora più che mai, le società sentono l'esigenza di proporre prodotti qualitativamente

più performanti e più a buon mercato.

Per raggiungere questi obiettivi si ha quindi la necessità di incentrare la propria

politica aziendale sulla qualità.

Infatti, per creare prodotti di qualità è necessario per l’azienda possedere una

qualità nell’organizzazione, che porta benefici anche in termini di efficienza e flessibilità.

L’approccio alla qualità adottato dalle imprese coinvolge perciò l’intera

organizzazione e presuppone la predisposizione di elementi interagenti quali, ad esempio,

le attività, i processi, le responsabilità, le mansioni, il cui insieme rappresenta il “mezzo”

per raggiungere gli obiettivi di qualità.

Attualmente sono presenti vari modelli, standard, metodologie e linee guida che

possono valorizzare il proprio modo di lavorare.

Tra tutti hanno assunto e assumono rilevanza le norme internazionali ISO ed i

modelli di maturità.

Mentre le norme ISO si limitano ad essere dei modelli di conformità, in cui i

processi sono, o non sono, aderenti agli standard, i modelli di maturità definiscono un

percorso di costante miglioramento della qualità dei processi di un’organizzazione.

Il CMMI® (Capability Maturity Model® Integration) è un modello di maturità che

fornisce strumenti utili per il miglioramento della qualità aziendale.

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 o servizi.

Il lavoro di tesi, svolto in CHORUS S.r.l. di Roma, ha l’obiettivo di descrivere il

percorso che l’azienda ha intrapreso per analizzare e mettere in opera i dettami di questo

moderno modello di maturità, allo scopo di industrializzare e perfezionare la gestione dei

propri processi aziendali e di istituzionalizzare il miglioramento continuo.

Nel primo capitolo si introduce il tema della gestione della qualità in una società di

software e servizi di informatica, con particolare riferimento agli standard internazionali

Introduzione

2

(ISO) ed ai modelli di maturità (CMM e CMMI); è riportato inoltre un recente studio dei

vantaggi derivanti dall’adozione del modello CMMI.

Nel secondo capitolo si approfondisce lo studio del modello CMMI, descrivendone

i componenti di base, definendo i livelli di capability e di maturity, e le due possibili

rappresentazioni del modello.

Nel terzo capitolo si delineano gli obiettivi e le fasi del progetto di

implementazione del CMMI in ambito aziendale.

Nel quarto e quinto capitolo si trattano singolarmente le aree di processo “Gestione

della Configurazione” e “Assicurazione Qualità di Processo e di Prodotto”, illustrandone le

caratteristiche e riportando l’analisi ed i risultati dell’assessment di alcuni progetti

aziendali, con riferimento alle pratiche del modello CMMI.

Nel sesto capitolo si descrive il nuovo Sistema Procedurale, derivante dall’adozione

delle pratiche del modello CMMI.

Infine nell’ultima sezione sono riportate le conclusioni di questo lavoro di tesi.

Capitolo I Gestione Della Qualità

3

CAPITOLO I GESTIONE DELLA

QUALITÀ

La gestione della qualità è divenuta un punto chiave per garantire l’efficienza di

tutte le attività svolte da aziende ed organizzazioni.

Infatti, essa incide direttamente sui costi aziendali che, secondo alcune stime,

possono arrivare al 30% dei ricavi dell’organizzazione, qualora ci sia un’insufficienza

qualitativa nei processi, nei prodotti, nella gestione delle relazioni fra le unità interne, con i

clienti e coi fornitori, nei meccanismi manageriali, e nella gestione delle risorse umane,

tecniche e del patrimonio.

Un aspetto emerso solo negli ultimi anni è la consapevolezza della criticità del

fattore umano: la qualità è fondata sulle persone e sull’organizzazione, e richiede una

rivoluzione manageriale ed organizzativa piuttosto che una profonda trasformazione

tecnologica.

Gli strumenti principali per migliorare in modo sistematico la qualità nei processi

sono i programmi di miglioramento della qualità, la certificazione di qualità, ed i

programmi di accertamento e miglioramento della maturità del ciclo produttivo.

I.1 Il contesto organizzativo

Lo sviluppo di prodotti può avvenire nell’ambito di tre modelli di organizzazione a

volte coesistenti:

– l’organizzazione gerarchica,

– l’organizzazione per processi,

– l’organizzazione mista (gerarchica nella struttura organizzativa e per

processi nello sviluppo del prodotto).

L’organizzazione gerarchica, molto diffusa, ha consentito di raggiungere elevati

livelli di efficienza della singole funzioni introducendo però forti rigidità; appare poco


4

efficace a rispondere rapidamente ed in modo flessibile alle sollecitazioni di un contesto in

continua evoluzione e fortemente competitivo.

L’organizzazione per processi ha dimostrato di essere la più idonea ad affrontare

la competizione:

- per le caratteristiche di flessibilità,

- per la capacità di perseguire gli obiettivi,

- per l’ottimale utilizzo delle risorse,

- per la semplificazione del confronto con la concorrenza,

- per la semplificazione che introduce nell’integrazione di realtà aziendali

diverse.

Ad oggi poche aziende adottano in modo integrale questo tipo di organizzazione,

perché la migrazione dall’organizzazione gerarchica ad una per processi comporta un

cambiamento di ruoli a cui l’ambiente aziendale si adatta con difficoltà.

Più agevole è l’adozione di un’organizzazione mista che, pur recependo numerosi

vantaggi dell’organizzazione per processi, conserva la struttura gerarchica attenuando la

difficoltà di adattamento.

Il contesto industriale evolve continuamente sia tecnologicamente che

strutturalmente, divenendo più flessibile e più efficiente.

Questa situazione richiede un atteggiamento mentale e metodologie di lavoro

orientati al miglioramento continuo, che richiede appunto un metodo organizzativo

adatto, che faccia propri tali orientamenti e ne faciliti l’attuazione.

Ciò si realizza identificando un sistema di processi, che rappresenti le attività

aziendali (principalmente quelle legate al ciclo di vita dei prodotti), e gestendo le

interazioni tra i processi stessi.

Il CMMI focalizza l’attenzione proprio sul concetto di processo.

Un processo è costituito da 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.


5

Più precisamente, un processo è definito come un insieme organizzato di attività e

di decisioni, finalizzato alla creazione di output, richiesti da clienti, a partire da input

definiti e che, insieme a controlli e risorse, ne costituiscono gli elementi fondamentali.

Ogni volta che viene intrapreso un nuovo progetto, conviene avere a disposizione

una procedura che guidi il processo di stesura del project plan, e che fornisca esempi da

cui trarre informazioni, invece di procedere alla sua composizione e scrittura ex-novo ogni

volta.

I processi devono descrivere gli elementi fondamentali di un’attività, insieme alle

condizioni al contorno e quelle iniziali da rispettare, ma non fornisce indicazioni sulle

modalità di realizzazione, e questo comporta una grande flessibilità, che si può utilizzare

per nuovi esperimenti e modifiche.

La descrizione di un processo deve prevedere:

- Le attività del processo

- Chi le svolge

- Quando (in che condizioni)

- Come (con quali strumenti)

- Gli input e le condizioni di attivazione

- Gli output e le condizioni di completamento

- Le misure e gli indicatori di performance.

Nel nostro caso, un processo è definito ad alto livello e ad esso sono associate delle

procedure, che 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 adattare le proprie risorse e costruisce una direzione per migliorare

i propri prodotti e servizi: i processi costituiscono proprio l'elemento di unione tra persone

e tecnologie.

La Figura I.1 mostra le tre dimensioni su cui tipicamente si focalizzano le

organizzazioni: persone, procedure e metodi, ed infine tool ed apparecchiature.


6

Figura I.1 – Le tre dimensioni critiche di un'azienda

Da sottolineare il fatto che l’approccio per processi non costituisce l’unica

alternativa valida per una gestione aziendale ottima, ma sta di fatto che ne è elemento

portante, se supportato da training, da un budget adeguato, da personale con skill

opportuni, da giusti strumenti, e da impegno da parte del management.

I.2 Standard Internazionali (ISO)

In Italia e nell’Unione Europea esistono due tipologie di standard per il controllo di

qualità nei processi di produzione:

• Regole tecniche, emesse da uno stato attraverso delle leggi e/o dei regolamenti,

in base a direttive europee; il loro rispetto è obbligatorio (cogente);

• Norme tecniche consensuali, elaborate e pubblicate da enti di normazione

riconosciuti, la cui applicazione non è obbligatoria ma volontaria.

Esse possono avere valore:

- Italiano: in tal caso ci si riferisce a norme UNI (Ente Nazionale Italiano di

Unificazione) e CEI (Comitato Elettrotecnico Italiano);

- Europeo: sono le norme EN (European Standard);

- Internazionale: le norme sono denominate ISO (International Organization

for Standardization) e IEC (International Electrotechnical Commission).


7

Il fondamento degli standard per la qualità è costituito dalla famiglia di norme ISO

900X, emesse a partire dagli anni ’80.

Sono norme di tipo consensuale che, nel loro insieme, forniscono le regole

manageriali/organizzative e di processo che le organizzazioni operanti in qualsiasi settore

(produzione o servizi) dovrebbero seguire per rendere razionali, efficienti, efficaci ed

affidabili le attività del loro ciclo produttivo e lavorativo, e il loro modo di interagire con i

clienti.

La famiglia di standard internazionali ISO 900X è la base di riferimento per il

processo di attribuzione di un certificato di qualità alle imprese che vogliano aderire in

modo sistematico alle raccomandazioni e alle prescrizioni degli standard.

Tale certificato è rilasciato da enti indipendenti che non solo assegnano il certificato

dopo una fase preliminare di osservazione dell’azienda, ma verificano anche, con azioni di

monitoraggio, la continuità nel rispetto delle norme.

Gli obiettivi principali delle norme ISO 900X sono due:

• Obiettivo tecnico – organizzativo: consiste nel fornire un insieme di regole

concettuali per migliorare e razionalizzare i processi di produzione;

• Obiettivo di marketing: consiste nel creare nei clienti una fiducia nei confronti

delle organizzazioni che dimostrano di applicare bene queste regole.

Le norme base della famiglia ISO 900X sono la ISO 9000, la ISO 9001, la ISO

9004, e la ISO 90003.

La UNI EN ISO 9000: 2000 “Sistemi di gestione per la qualità – Fondamenti e

terminologia”, oltre a contenere i concetti fondamentali su cui si basano i sistemi di

gestione per la qualità, prevede che i processi lavorativi di un’organizzazione vengano

descritti in documenti specifici, che sono:

- Manuale della qualità;

- Piano della Qualità;

- Piano di Progetto;

- Piano di Gestione della Configurazione.


8

I.2.1 UNI EN ISO 9001: 2000

La UNI EN ISO 9001: 2000 “Sistemi di gestione per la qualità – Requisiti” è la

norma più rilevante tra quelle della famiglia ISO 900X, e si rivolge alla funzione di

assicurazione della qualità.

Un sistema di gestione per la qualità è l’insieme dei controlli, delle attività e delle

risorse che un’organizzazione definisce al fine di ottenere in modo affidabile e ripetibile

prodotti e servizi conformi a specifiche fornite da un cliente, al minor costo possibile e nei

tempi stabiliti.

L’assicurazione della qualità è l’insieme delle attività pianificate e

sistematicamente attuate in un’organizzazione per dimostrare (ai potenziali clienti o al

proprio management) la capacità di fornire un prodotto conforme ai requisiti.

La ISO 9001 definisce i requisiti base di un modello di assicurazione della qualità

valido per tutte le organizzazioni, e può essere utilizzata per uso interno, per scopi

contrattuali e di certificazione.

I requisiti definiti dalla norma ISO 9001 riguardano non solo i principali processi

del ciclo produttivo vero e proprio (i cosiddetti processi primari del ciclo), ma anche i

processi manageriali, organizzativi, di controllo e di supporto a quelli primari, di marketing

e di interfaccia con il cliente, secondo il presupposto che un ciclo produttivo è tanto più

affidabile quanto più è controllato e documentato, e le attività svolte sono consolidate ed

istituzionalizzate nell’ambiente lavorativo, e vicine ai requisiti-utente.

I requisiti ISO 9001 sono ad un livello di astrazione piuttosto alto, in quanto pensati

per essere applicabili da qualsiasi organizzazione, indipendentemente dal settore in cui

opera.

Perciò, la ISO 9001 non entra nel merito di “come” vanno svolte, dal punto di vista

tecnico, le attività previste dai vari processi lavorativi, ma definisce, per ogni processo

preso in considerazione, quegli accorgimenti di natura manageriale/organizzativa che

hanno maggiore influenza sul risultato finale del processo.

Le aree di processo cui sono rivolti i requisiti ISO 9001 sono poche: erano 20 nella

versione 1994 della norma, ma sono solo 5 nella versione 2000.

Esse sono:

- Quality Management System;

- Management Responsibility;


9

- Resource Management;

- Product Realization;

- Measurement, Analysis & Improvement.

Questo numero ridotto di processi cui si rivolge la norma è dovuto all’intento di

focalizzare l’attenzione solo su quei processi a reale valore aggiunto per una

organizzazione, e in particolare su quelli per i quali i potenziali clienti possono avere una

diretta percezione.

Tra gli elementi base della norma si evidenziano in particolare:

• “Ritagliabilità” (tailoring), ovvero la possibilità per le organizzazioni di

personalizzare i requisiti di base in funzione di specifici obiettivi;

• Maggiore facilità d’uso del modello, in modo da estendere la possibilità di

valutazione del grado di applicazione dei requisiti della norma oltre gli addetti

ai lavori;

• Minore enfasi sulla documentazione dei processi;

• Introduzione di elementi di valutazione del Sistema di Gestione per la Qualità

legata a risultati di efficacia oltre che di efficienza;

• Allargamento delle linee aziendali interessate al Sistema di Gestione per la

Qualità, con particolare riferimento a chi gestisce gli aspetti finanziari,

manageriali, amministrativi, commerciali, di relazione con la clientela,

l’impatto sull’ambiente, etc;

• Specifici punti del modello dedicati alla rilevazione e gestione della

“soddisfazione del cliente”;

• Necessità per le organizzazioni di definire obiettivi misurabili di miglioramento,

valutabili dagli auditor;

• Importanza data alle risorse umane (e alla formazione) come fattore primario di

miglioramento.

Le organizzazioni possono richiedere (su base volontaria) ad organismi

specializzati, di rilasciare loro (dopo aver compiuto delle verifiche) una certificazione di

conformità del loro Sistema di Gestione per la Qualità rispetto ai requisiti ISO 9001.

Con il termine “certificazione” si intende l’atto formale con il quale un organismo

accreditato a livello nazionale od internazionale dichiara che un determinato prodotto,


10

processo, servizio o sistema qualità è conforme a quanto prescritto da una normativa ad

esso applicabile.

L’accreditamento di un certificatore è definito come il riconoscimento formale,

rilasciato ad un laboratorio di prova o ad un organismo di auditing, della idoneità ad

effettuare determinati tipi di verifiche.

Va sottolineato che l’accreditamento è una scelta volontaria.

In Italia la maggior parte degli organismi di certificazione (>150) è accreditata dal

SINCERT (Sistema Nazionale per l’accreditamento degli organismi di certificazione),

creato nel 1991 da UNI, CEI, CNR, ENEA, Ministero dell’Industria.

Sul sito web del SINCERT (www.sincert.it) si può verificare se una data Società è

in possesso di una certificazione, la sua estensione, e validità temporale.

In Italia molti organismi che effettuano certificazioni nel settore ISO 9001 sono

riuniti nella federazione CISQ (Certificazione Italiana Sistemi Qualità, www.cisq.com); a

livello europeo l’Ente di riferimento per gli organismi di certificazione è lo IQNET

(www.iqnet-certification.com), che raggruppa enti che operano in 150 nazioni (incluso il

CISQ).

Questi organismi aderiscono poi allo IAF (International Accreditation Forum,

www.iaf.nu), ed allo EA (European Accreditation, www.european-accreditation.org).

Il rilascio della certificazione ISO 9001 avviene a seguito di un certo numero di

visite ispettive, nelle quali vengono esaminati gli elementi di valutazione previsti dal

metodo di verifica adottato (ad esempio il metodo CSQ/ITQS per il settore ICT).

In Italia, al 28/2/2006, risultano certificati rispetto alla norma ISO 9001 i Sistemi di

Gestione per la Qualità (SGQ) di oltre 76.400 organizzazioni (Fonte SINCERT), di cui

circa 2800 del settore ICT (Information Communication Technology), in cui operano 25

organismi di certificazione accreditati dal SINCERT.

La UNI EN ISO 9004: 2000 “Sistemi di gestione per la qualità – Linee guida per il

miglioramento delle prestazioni”, fornisce delle linee guida complementari ai requisiti

della ISO 9001 per migliorare l’efficacia e l’efficienza di un Sistema di Gestione per la

Qualità e le prestazioni dell’organizzazione.

E’ una norma applicabile ai processi di un’organizzazione indipendentemente dal

tipo e dalla dimensione della stessa, e dai prodotti forniti (settore in cui opera, compresi i

servizi).


11

La ISO 9004 non è però una norma utilizzabile per ottenere certificazioni.

La norma UNI CEI ISO/IEC 90003: 2005 “Ingegneria del software e di sistema –

Guida per l’applicazione della ISO 9001: 2000 al software per elaboratore” è costruita

come precisazione puntuale ai requisiti della ISO 9001 nel settore dell’ICT, ma non è una

norma utilizzabile come riferimento diretto per ottenere certificazioni del Sistema di

Gestione per la Qualità di una organizzazione che opera nel settore ICT.

Questa norma fornisce indicazioni riguardo ai processi di acquisizione, fornitura,

sviluppo, gestione operativa e manutenzione del software.

E’ indipendente dalla tecnologia, dai modelli del ciclo di vita, dai processi di

sviluppo, dalla sequenza delle attività e dalla struttura organizzativa utilizzata da una

organizzazione, ed è utilizzabile per prodotti sviluppati ad hoc, prodotti COTS

(Commercial Off The Shelf), e software inserito in prodotti hardware.

In conclusione, gli standard della serie ISO 900X forniscono una serie di

indicazioni generali su come dovrebbe essere organizzata un’azienda che centra il proprio

successo sulla garanzia di qualità dei beni e servizi offerti ai propri clienti.

Essi non suggeriscono però una pratica per il miglioramento dei processi, ma

semplicemente indicano la soglia di accettazione o di rifiuto della qualità.

I.2.2 UNI CEI ISO/IEC 12207: 2003

La norma definisce uno schema di riferimento comune per i processi relativi al

ciclo di vita del software, utilizzando una ben definita terminologia, che può essere presa a

riferimento dall’industria del software.

La norma include i processi, le attività ed i compiti che devono essere svolti durante

l’acquisizione di sistemi software, di prodotti software a sé stanti, di servizi software e

durante la fornitura, lo sviluppo, la gestione operativa e la manutenzione di prodotti

software.

Il termine software include anche il software denominato firmware.

La norma fornisce anche un modello di processo che può essere utilizzato per la

definizione, il controllo ed il miglioramento dei processi relativi al ciclo di vita del

software.


12

E’ applicabile alle attività di acquisizione di sistemi, prodotti e servizi software, alle

forniture, allo sviluppo, alla gestione operativa ed alla manutenzione dei prodotti software,

al firmware, sia sviluppato internamente che esternamente ad una organizzazione.

Vengono, inoltre, inclusi quegli aspetti relativi alla definizione di sistema, necessari

per definire il contesto dei prodotti e dei servizi software.

Questa norma internazionale descrive l’architettura dei processi del ciclo di vita del

software, ma non specifica i dettagli in merito a come sviluppare o eseguire le attività o i

compiti inclusi nel processo; essa inoltre non prescrive uno specifico modello di ciclo di

vita o un metodo di sviluppo del software.

La norma raggruppa le attività che possono essere svolte lungo il ciclo di vita del

software in cinque processi primari, otto processi di supporto e quattro processi

organizzativi.

Ciascun processo del ciclo di vita è diviso in un insieme di attività, e ciascuna

attività è a sua volta suddivisa in una serie di compiti.

I processi primari del ciclo di vita sono cinque e riguardano i soggetti principali che

sono coinvolti nel ciclo di vita del software.

Un soggetto principale è colui che inizia o svolge lo sviluppo, la gestione operativa

o la manutenzione di un prodotto software.

Questi soggetti principali sono gli acquirenti, i fornitori, gli sviluppatori, gli

operatori ed i manutentori dei prodotti software.

I processi primari sono:

1) Processo di Acquisizione;

2) Processo di Fornitura;

3) Processo di Sviluppo;

4) Processo di Gestione Operativa;

5) Processo di Manutenzione.

I processi di supporto del ciclo di vita sono otto.

Un processo di supporto sostiene un altro processo come parte integrante con uno

scopo differente e contribuisce ad assicurare il successo e la qualità del progetto software.

Un processo di supporto è utilizzato e svolto, come necessario, da un altro processo.


13

I processi di supporto sono:

1) Processo di Documentazione;

2) Processo di Gestione della Configurazione;

3) Processo di Assicurazione Qualità;

4) Processo di Verifica;

5) Processo di Validazione;

6) Processo del Riesame Congiunto;

7) Processo di Verifica Ispettiva;

8) Processo di Risoluzione dei Problemi.

I processi organizzativi del ciclo di vita sono quattro.

Sono applicati da una organizzazione allo scopo di definire e sviluppare una

struttura base costituita da processi collegati del ciclo di vita e da personale, allo scopo di

migliorare continuamente la struttura stessa ed i processi.

Questi processi sono di solito sviluppati fuori dell’ambito di specifici progetti o

contratti; comunque, le esperienze accumulate da tali contratti e progetti contribuiscono al

miglioramento dell’organizzazione.

I processi organizzativi sono:

1) Processo di Gestione;

2) Processo di Infrastruttura;

3) Processo di Miglioramento;

4) Processo di Formazione.

I.2.3 ISO IEC 9126-1: 2000

La norma ISO/IEC 9126 “Software engineering – Product quality” contiene il

modello di riferimento per definire le caratteristiche di qualità del software e le metriche

per la valutazione della qualità che il software possiede.

Si può utilizzare per definire i requisiti qualitativi del software, e per definire le

misure che vanno rilevate per valutare la qualità di un software.

Quanto definito dalla 9126 è applicabile a qualsiasi tipo di software (personale o

COTS).


14

Non sono previste certificazioni di qualità del prodotto software rispetto a questa

norma.

La norma si compone di queste parti:

1) Il modello delle caratteristiche e sottocaratteristiche di qualità del software

(ISO/IEC 9126-1 Software Engineering. Product Quality - Part 1: Quality

model, 2001);

2) Le metriche per la misura della qualità esterna (ISO/IEC TR 9126-2, 2003);

3) Le metriche per la misura della qualità interna (ISO/IEC TR 9126-3, 2003);

4) Le metriche per la misura della qualità in uso (ISO/IEC TR 9126-4, 2004).

La parte per noi di maggior interesse è la 9126-1.

Essa definisce un modello a quattro livelli:

• Tre “punti di vista” sulla qualità del software (esterno, interno ed in uso) che

qualsiasi progetto di sviluppo deve prendere in considerazione e soddisfare;

• I principali attributi (definiti come requisiti qualitativi) che qualificano un

software, secondo i 3 punti di vista;

• Per ogni attributo, le sottocaratteristiche (requisiti quantitativi, misurabili) che

la rappresentano, e che dovranno essere misurate per valutare il livello di

qualità effettivamente raggiunto nel software;

• Le metriche per effettuare le misure.

Di particolare rilievo sono le sei caratteristiche che rappresentano la qualità

esterna ed interna di un prodotto software:

- Funzionalità: capacità di fornire servizi tali da soddisfare, in determinate

condizioni, requisiti funzionali espliciti o impliciti;

- Affidabilità: capacità di mantenere le prestazioni stabilite nelle condizioni e nei

tempi fissati;

- Usabilità: capacità di essere compreso, appreso, usato con soddisfazione dal

cliente in determinate condizioni d’uso;

- Efficienza: rapporto fra prestazioni e quantità di risorse utilizzate, in condizioni

definite di funzionamento;

- Manutenibilità: capacità di essere modificato con un impegno contenuto;

- Portabilità: facilità con cui un software può essere trasferito da un sistema

operativo ad un altro.


15

La qualità in uso è rappresentata da 4 caratteristiche, che rappresentano il punto di

vista dell’utente sul software.

Essa rappresenta la capacità del software di supportare specifici utenti a

raggiungere determinati obiettivi, con efficacia, produttività, soddisfazione e sicurezza

personale, in determinati contesti d’uso.

Le quattro caratteristiche sono:

- Efficacia, la capacità di supportare un utente nel raggiungere i suoi obiettivi

con accuratezza e completezza in un dato contesto.

- Produttività, la capacità di supportare un utente nello spendere l’appropriata

quantità di risorse in relazione all’efficacia dei risultati da raggiungere.

- Soddisfazione, la capacità di soddisfare un utente in un dato contesto d’uso.

- Sicurezza, la capacità di raggiungere accettabili livelli di rischio per le persone,

l’ambiente di utilizzo, le attività dell’utilizzatore, in un dato contesto d’uso.

Per quanto riguarda l’applicabilità della norma, possiamo dire che il modello 9126

può essere utilizzato per definire i requisiti di ogni tipo di software (incluso il firmware), o

COTS.

La valutazione della qualità secondo la 9126 è possibile in ogni momento del ciclo

di vita, dall’acquisizione, allo sviluppo (progettazione, codifica), alla manutenzione.

Destinatari sono quindi tutti gli attori del ciclo di vita del software, utenti,

sviluppatori, gestori ed addetti alla manutenzione, manager, auditor, ognuno secondo le

proprie esigenze.

I.3 Altri standard (ECSS, MIL-STD-498, AQAP-160)

ECSS

La standardizzazione è uno strumento importante per ridurre i costi e migliorare la

qualità e comunicazione durante la preparazione e l’esecuzione dei programmi

internazionali.

Nel passato le Agenzie Spaziali in Europa ed i loro maggiori contraenti hanno

sviluppato individualmente degli standard, e li hanno applicati ai loro progetti.

L’ECSS (European Cooperation for Space Standardization) rappresenta un

impegno congiunto dell’ESA (European Space Agency), delle Agenzie Spaziali Nazionali


16

e dell’industria Europea per sviluppare, mantenere ed applicare degli standard comuni a

tutti i progetti spaziali Europei.

L’obiettivo del Sistema di Standardizzazione ECSS è quello di minimizzare il costo

del ciclo di vita, migliorando allo stesso tempo la qualità, l’integrità funzionale e la

compatibilità di tutti gli elementi di un progetto, applicando standard comuni per

l’hardware, il software, le informazioni e le attività nei progetti.

Gli standard ECSS coprono le seguenti categorie di requisiti per progetti ed

applicazioni spaziali:

• Requisiti di gestione del progetto;

• Requisiti per attività di progettazione, sviluppo, produzione e verifica, applicate

a sistemi spaziali e alle loro parti costituenti;

• Requisiti e metodi di assicurazione della qualità del prodotto;

• Requisiti di interfaccia, per informazioni relative a sistemi spaziali ed attività,

trasmessi tra le varie organizzazioni.

Gli Standard ECSS includono specifiche, linee guida, manuali, guide e procedure.

In generale, tutti i documenti emessi dall’ECSS sono denominati standard.

Questi standard devono essere “tailorizzabili” per progetti differenti e si applicano a

tutte le fasi ed attività dall’inizio alla fine di un progetto, inclusa l’analisi e la dismissione

di una missione.

Gli obiettivi generali degli standard ECSS sono:

Ottenere programmi spaziali in Europa che siano ottimizzati dal punto di vista

dei costi;

Promuovere un miglioramento della qualità, sicurezza e protezione ambientale;

Promuovere una comunicazione chiara e non ambigua tra tutte le parti

interessate;

Organizzare e gestire lo sviluppo di un unico insieme di standard, comuni e

coerenti, per la comunità spaziale Europea, evitando così duplicazioni non

necessarie;

Raggiungere un riconoscimento formale di Standard Europeo (EN), per una

parte selezionata degli standard, dal CEN (European Committee for

Standardization), dal CENELEC (European Committee for Electrotechnical

Standardization), e dall’ETSI (European Telecommunication Standard


17

Institute), aumentando in questo modo la competitività a livello internazionale

dell’industria spaziale Europea;

Raggiungere un riconoscimento formale di Standard ISO, per una parte

selezionata degli standard, dall’International Organization for Standardization.

La policy dell’ECSS è quella di:

♦ Promuovere il miglioramento continuo di tecniche e metodi, ed evitare lavoro

non necessario;

♦ Incorporare sistematicamente nel sistema ECSS l’esperienza proveniente dai

progetti passati e da altre appropriate sorgenti;

♦ Aumentare l’efficienza industriale e la competitività limitando la varietà di

prodotti e processi;

♦ Incorporare, dove possibile, gli standard applicati dai membri partecipanti, e di

non creare duplicati degli standard internazionali.

Infine, gli standard ECSS devono:

- Rispondere ad una necessità chiaramente espressa dalla comunità spaziale,

tenendo in dovuto conto lo stato dell’arte;

- Essere facili da utilizzare, ed in particolare devono essere completi quanto

basta, concisi, consistenti, accurati e non ambigui;

- Essere comprensibili per persone qualificate, e strutturati in modo da facilitare

la “tailorizzazione” per progetti specifici;

- Contenere requisiti di cui beneficia l’intera comunità, e che non diano un

vantaggio esclusivo a nessuna organizzazione individuale;

- Essere scritti e strutturati in modo tale da facilitare il trasferimento verso il

CEN, CENELEC, ETSI e ISO.

MIL–STD–498

Il MIL–STD–498 è uno standard militare, approvato per l’utilizzo da parte di tutti i

Dipartimenti e tutte le Agenzie del Dipartimento della Difesa degli Stati Uniti d’America.

Esso scaturisce dalla fusione di due precedenti standard, e definisce una serie di

attività e di documentazione per lo sviluppo di sistemi di difesa e sistemi di informazione

automatizzati.


18

Più precisamente, lo scopo di questo standard è quello di stabilire dei requisiti

uniformi per lo sviluppo e la documentazione software.

Il MIL–STD–498 può essere applicato in ogni fase del ciclo di vita del sistema; non

è stato creato inoltre per specificare o scoraggiare l’uso di un particolare metodo di

sviluppo del software.

Questo standard implementa i processi di sviluppo e di documentazione della

ISO/IEC 12207, e include tutte le attività che riguardano lo sviluppo del software, dove

con “sviluppo del software” qui si intende nuovo sviluppo, modifica, riuso,

reingegnerizzazione, manutenzione, e tutte le altre attività che riguardano i prodotti

software.

Lo sviluppatore software deve stabilire un processo di sviluppo software

consistente con i requisiti contenuti nel contratto.

Il processo deve includere le seguenti attività principali, che si possono

sovrapporre, possono essere applicate iterativamente, possono essere applicate in modo

diverso a differenti elementi del software, e non necessitano di essere applicati nell’ordine

in cui compaiono nella lista.

Inoltre il processo di sviluppo del software deve essere descritto nel Piano di

Sviluppo del Software.

Le attività principali sono:

• Pianificazione del progetto e monitoraggio;

• Stabilire un ambiente di sviluppo software;

• Analisi dei requisiti di sistema;

• Design del sistema;

• Analisi dei requisiti del software;

• Design del software;

• Implementazione del software e test delle unità;

• Integrazione delle unità e test;

• Test di qualificazione di CSCI (Computer Software Configuration Item);

• Integrazione e test di CSCI/HWCI (Hardware Configuration Item);

• Test di qualificazione del sistema;

• Preparazione per l’uso del software;

• Preparazione per la transizione del software;


19

• Processi integrali:

- Gestione della configurazione software;

- Valutazione del prodotto software;

- Assicurazione di qualità del software;

- Azioni correttive;

- Revisioni tecniche e di gestione;

- Altre attività.

AQAP 160

L’AQAP 160 (Edizione 1) “NATO Integrated Quality Requirements for Software

Throughout the Life Cycle” è una pubblicazione della North Atlantic Treaty Organization,

e contiene i requisiti per un sistema di gestione della qualità del software attraverso il ciclo

di vita.

Con “software” si intende incluso anche il firmware.

Questa pubblicazione stabilisce anche una struttura comune per i processi del ciclo

di vita del software, con una terminologia ben definita, che può essere presa come

riferimento dall’industria.

L’AQAP 160 è strutturata in modo tale da poter essere “tailorizzata” per una

determinata organizzazione, progetto o applicazione all’interno del progetto.

Quando “tailorizzata”, questa pubblicazione specifica i requisiti per gestire la

qualità dei processi del ciclo di vita del software, e dei risultanti prodotti e servizi.

Essa è stata concepita soprattutto per essere applicata quando si è in presenza di un

contratto tra due parti, ma può essere anche utilizzata internamente ad un’organizzazione

per la fornitura (e relativa acquisizione, sviluppo, produzione, operazione e manutenzione)

del software integrato (embedded) in un sistema e/o servizio software.

Il modello dell’AQAP 160 Edizione 1 è composto da:

• Requisiti correlati al processo: un insieme di requisiti per i processi primari e di

supporto basati sulla ISO/IEC 12207, integrati con quei requisiti della ISO

9001: 2000 non esplicitamente coperti dalla 12207.

• Requisiti del sistema di qualità: requisiti organizzativi imposti al fornitore,

basati sulla ISO 9001: 2000, e correlati ai processi primari e di supporto;


20

• Requisiti specifici della NATO, dovuti al fatto che l’acquisizione avviene in un

contesto NATO.

I.4 Modelli di Maturità

Nel paragrafo I.2 abbiamo visto come gli standard della famiglia ISO 900X non

forniscano una pratica per il miglioramento dei processi, ma indicano semplicemente una

soglia di accettazione o di rifiuto della qualità.

I modelli di maturità costituiscono invece un approccio differente alla gestione

della qualità: essi servono a valutare l’appartenenza di un’azienda o di un’organizzazione

produttiva ad una delle configurazioni previste dal modello stesso, allo scopo di trarne

informazioni utili per avviare processi di miglioramento.

Un modello di maturità è un insieme strutturato di elementi, che descrive le

caratteristiche di processi efficaci (in base all’esperienza delle organizzazioni che hanno

predisposto il modello).

Fornisce:

- Un punto di partenza e degli stati “obiettivo”;

- L’esperienza della comunità che lo ha prodotto;

- Un linguaggio comune ed una visione condivisa;

- Un metodo per determinare le priorità;

- Un modo per definire il significato di “miglioramento” per l’organizzazione.

Può essere utilizzato per confrontare organizzazioni diverse.

Tra i modelli più articolati, applicabili all’industria del software e dei servizi,

abbiamo il Capability Maturity Model (CMM).

I.4.1 I modelli CMM

CMM sta per Capability Maturity Model, ed è un modello di riferimento costituito

da pratiche (practices) consolidate in una disciplina specifica, utilizzato per stabilire la

capacità di una organizzazione o gruppo di operare in quella disciplina.

Esistono vari CMM, che differiscono per:

- Disciplina (software, sistemi, acquisizione, etc.)

- Struttura


21

- Come viene definita la Maturity (percorso di miglioramento del processo)

- Come viene definita la Capability (istituzionalizzazione)

“Capability Maturity Model®” e CMM® sono utilizzati dal SEI (Software

Engineering Institute) per denotare una classe particolare di modelli di maturità.

Negli anni ’30, W. Stewhart iniziò a lavorare sul miglioramento dei processi con i

suoi principi di controllo statistico della qualità.

Questi principi furono poi raffinati da altre persone, tra cui un certo Humphrey, che

li estesero ed iniziarono ad applicarli al software.

Humphrey scrisse un libro, che fornisce una descrizione dei principi di base su cui

sono basati molti dei CMM.

Il SEI ha preso la premessa su cui si fonda la gestione di un processo, “la qualità di

un sistema o prodotto è altamente influenzata dalla qualità del processo utilizzato per

svilupparlo e mantenerlo”, ed ha definito i CMM che realizzano questa premessa, a cui è

riconosciuta un’importanza particolare a livello internazionale.

I CMM si focalizzano sul miglioramento dei processi in un’organizzazione.

Essi contengono gli elementi essenziali che rendono i processi efficaci per una o

più discipline, e descrivono un percorso evolutivo di miglioramento da processi immaturi

fino a processi maturi, efficaci, qualitativamente migliori.

Dal 1991, sono stati sviluppati dei CMM per una miriade di discipline; alcuni dei

più utilizzati includono modelli per l’ingegneria dei sistemi, ingegneria del software,

acquisizione software, gestione della forza-lavoro e sviluppo, ed infine lo sviluppo

integrato di prodotti e processi (IPPD, Integrated Process and Product Development).

Benché questi modelli siano stati utili per molte organizzazioni, l’uso di modelli

differenti è risultato problematico, a causa di differenti strutture, formati, termini e modi di

misurare la maturità.

Inoltre l’uso in contemporanea di modelli diversi causa confusione, e diventa

complessa e costosa l’integrazione di più di un modello in un unico programma coordinato

di miglioramento.

Il progetto di Integrazione dei CMM (CMMI) è nato proprio per risolvere il

problema dell’uso di tanti CMM diversi, ed è partito da tre modelli CMM, scelti per la loro

diffusione nell’ingegneria del software e dei sistemi, e anche per i loro approcci differenti

al miglioramento dei processi all’interno di un’organizzazione.


22

Questi modelli sono:

• Il Capability Maturity Model for Software (SW-CMM) v2.0 draft C;

• Il Systems Engineering Capability Model (SECM);

• L’Integrated Product Development Capability Maturity Model (IPD-CMM)

v0.98.

Da qui il team del CMMI ha creato un insieme di modelli integrati, che possono

essere adottati sia da coloro che utilizzano correntemente i modelli sorgente, che da coloro

che sono nuovi al concetto di CMM.

Quindi, il CMMI è il risultato dell’evoluzione del SW-CMM, del SECM, e

dell’IPD-CMM.

I.4.2 Il modello CMMI® e la sua evoluzione

Il modello CMMI (Capability Maturity Model Integration) su cui si basa tutto

questo lavoro di tesi e di stage in ambito aziendale è quello denominato “CMMI for

Development”, perché è il successore designato dei tre modelli CMM (Capability Maturity

Model) da cui è scaturito: il Software CMM, l’IPD-CMM e il SECM, che sono stati ritirati.

Per applicare ad aree di interesse molteplici la struttura ottenuta dall’evoluzione dei

CMM, le best practice vengono raggruppate in “costellazioni”.

Una costellazione è un insieme di componenti del CMMI che sono progettati per

soddisfare le necessità di una specifica area di interesse.

Una costellazione può produrre uno o più modelli CMMI correlati, insieme ai

relativi materiali di training ed appraisal (processo di autovalutazione obiettiva).

Recentemente, l’architettura del CMMI è stata migliorata per permettere il supporto

di costellazioni multiple e la condivisione di best practice tra le costellazioni e i modelli

che le compongono.

E sono iniziati i lavori per altre due nuove costellazioni: una per i servizi (“CMMI

for Services”) e l’altra per l’acquisizione (”CMMI for Acquisition”), e la loro uscita è

prevista per il 2007.

Tutti i modelli CMMI disponibili prima del 2006 ora sono considerati parte della

costellazione del “CMMI for Development”.


23

La costellazione del “CMMI for Development” consiste di due modelli: “CMMI for

Development + IPPD” (Integrated Process and Product Development), e “CMMI for

Development” (senza IPPD).

Il “CMMI for Development” è un modello di riferimento che copre le attività di

sviluppo e manutenzione applicate sia ai prodotti che ai servizi.

Organizzazioni appartenenti a molte categorie, compresa l’aerospaziale, bancaria,

hardware, software, difesa, manifatturiera automobilistica, e telecomunicazioni, utilizza il

“CMMI for Development”.

Infatti i modelli della costellazione del “CMMI for Development” contengono

pratiche che coprono la gestione del progetto, la gestione del processo, l’ingegneria di

sistema, l’ingegneria dell’hardware, l’ingegneria del software, ed altri processi di supporto

utilizzati per lo sviluppo e la manutenzione.

Il CMMI ha attraversato un esteso processo di revisione: si è partiti dalla versione

0.2, utilizzata per attività pilota, per poi passare rapidamente alla versione 1.0 e 1.02.

La versione 1.1 del CMMI è stata quella di maggior diffusione ed uso, e noi,

insieme al nostro gruppo di lavoro, abbiamo iniziato l’attività di studio e implementazione

del processo di miglioramento aziendale basandoci proprio su questa versione, in quanto la

versione successiva, la 1.2, è uscita alla fine di agosto 2006, ed è rappresentata dal “CMMI

for Development”.

Da notare che le revisioni e le edizioni del CMMI si fondano sul feedback ottenuto

dagli utenti e da tutta la comunità CMMI che lo utilizza.

Con la versione 1.2 nasce il concetto di costellazione; inoltre, rispetto alla versione

1.1, sono stati fatti i seguenti cambiamenti:

• Sono stati eliminati i concetti di pratica avanzata e di caratteristiche comuni;

• Sono stati aggiunti esempi di hardware;

• Tutte le definizioni sono state consolidate nel glossario;

• Sono state eliminate le aree di processo IPPD, ora incluse nelle altre aree;

• E’ stata eliminato il Supplier Sourcing (acquisizione di prodotti e servizi);

• Sono state aggiunte delle spiegazioni su come le aree di processo supportano le

pratiche generiche.


24

Figura I.2 – Storia dei CMM

I.4.3 Il CMMI: obiettivi e vantaggi

Il CMMI® (Capability Maturity Model® Integration) è un valido strumento per la

definizione, la valutazione ed il miglioramento continuativo dei processi e delle pratiche di

ingegneria di sistema (SE - System Engineering), di ingegneria del software (SWE –

Software Engineering) e di sviluppo integrato di prodotti e processi (IPPD – Integrated

Process and Product Development).

Il CMMI® consiste in un’insieme di best practice per l’acquisizione, lo sviluppo,

l’integrazione e la manutenzione di prodotti e servizi.

Un prodotto può essere rappresentato da un cellulare, un’automobile, un pacchetto

software, un aeroplano, etc., mentre un servizio da un corso di formazione per utenti finali,

dal supporto tecnico on-demand, dal tutoring sui servizi internet di trading online, etc.

Il progetto di sviluppo del CMMI® ha visto coinvolte, a livello internazionale,

numerose aziende, organizzazioni ed esperti del settore provenienti dal mondo industriale,

dei servizi e della ricerca.

Il progetto è stato diretto dal SEI (Software Engineering Institute).


25

Il SEI è un istituto federale di ricerca e sviluppo della Carnegie Mellon University

(Pittsburgh, USA).

Nato nel 1984, il SEI è sponsorizzato dal DoD (US Department of Defense)

attraverso il OUSD – AT&L (Office of the Under Secretary of Defense for Acquisition,

Technology, and Logistics).

Le relazioni tra lo standard ISO 9001:2000 ed il CMMI® sono oggetto di una serie

di studi ed implementazioni che sottolineano la convergenza e la sinergia dei due approcci

e la possibilità di utilizzare CMMI® come driver per sostenere l’implementazione della

normativa ISO 9001:2000, in particolare il miglioramento continuativo come richiesto

dallo standard ISO 9004.

Il CMMI inoltre:

- E’ coerente con l’approccio Total Quality Management (TQM) perché stimola

le Aziende al miglioramento continuo dei processi;

- Identifica punti di forza e di debolezza dei processi e misura l’efficacia delle

azioni correttive;

- Supporta la valutazione degli investimenti necessari per il miglioramento dei

processi;

- Assiste il conseguimento ed il mantenimento delle certificazioni ISO attraverso

il controllo continuo dei processi;

- Individua 5 livelli di maturity di categorie di processi, e 6 livelli di capability

nei singoli processi.

Il CMMI è nato con lo scopo di realizzare degli obiettivi ben precisi, e cioè:

• Aiutare le aziende a definire i propri obiettivi in termini di:

- Tempi

- Costi

- Qualità;

• Aumentare la prevedibilità nel raggiungimento degli obiettivi;

• Aumentare la qualità dei prodotti, mediante la riduzione del numero dei difetti

residui;

• Ridurre tempi e costi dei progetti:

- Diminuendo la necessità di ricorrere alla rilavorazione

- Aumentando la produttività dei processi;


26

• Gestire e migliorare i prodotti/servizi delle Aziende fornendo a tal fine le linee

guida per l’integrazione dei processi correlati;

• Identificare stadi evolutivi nel percorso di miglioramento utilizzabili per fornire

uno standard di benchmark tra Aziende.

Sono stati effettuati svariati studi nell’arco degli ultimi dieci anni, per analizzare

dettagliatamente i vantaggi che l’adozione del CMMI da parte di molte aziende ha

comportato.

L’ultimo studio disponibile (Performance Results of CMMI-Based Process

Improvement) è stato pubblicato dal SEI ad agosto 2006, ed è quello a cui faremo

riferimento, [8].

Esso presenta l’evidenza quantitativa dei risultati ottenuti da 35 organizzazioni che

hanno deciso di adottare un sistema di miglioramento dei processi basato sul CMMI.

Queste organizzazioni hanno applicato il CMMI a varie discipline dell’ingegneria,

tra cui l’ingegneria del software e l’ingegneria dei sistemi, e infatti i risultati presentati

provengono da industrie appartenenti a settori differenti (telecomunicazioni, finanza,

produzione, difesa).

Tutte le organizzazioni a cui ci si riferisce nel report attribuiscono esplicitamente i

loro progressi all’adozione del CMMI.

Tra di esse troviamo: Accenture, General Motors, IBM Application Management

Services, JPMorgan, Lockheed Martin Corporation, Motorola Global Software Group,

Raytheon Corporation, Reuters, The Boeing Company, ed altre.

I risultati delle prestazioni sono catalogati e riassunti utilizzando sei parametri:

costi, tempi (schedule), produttività, qualità, soddisfazione del cliente, e ROI (Return On

Investment).

Queste categorie includono una grande varietà di misure, ognuna di esse selezionata

dalle organizzazioni che hanno partecipato allo studio, per rilevare e dimostrare i

miglioramenti ottenuti in aree di importanza strategica per i propri specifici obiettivi di

business.

La categoria dei costi comprende misure effettuate sulle variazioni nei costi dei

prodotti finali o intermedi, sulle variazioni nei costi dei processi impiegati per la

produzione, e anche un aumento nella predicibilità dei costi sostenuti, con altre misure di

variazione.


27

Sono state rilevate delle riduzioni nei costi della qualità, costi di rilavorazione, costi

fissi, ed un aumento nell’accuracy di stima del budget.

Per quanto riguarda i tempi (schedule), vengono riportati i miglioramenti nella

previsione dello schedule, nell’accuracy delle stime, e le riduzioni dei tempi necessari a

svolgere il lavoro, dei giorni di scostamento dal piano, e del numero di giorni di ritardo.

La categoria della produttività comprende varie misure basate sulla quantità di

lavoro effettuato in un fissato periodo di tempo, come per esempio il numero di linee di

codice per ora di lavoro, e numero di release all’anno.

Il miglioramento nella qualità del prodotto è misurato frequentemente mediante le

diminuzioni nel numero di difetti.

Ancora una volta, le misure specifiche variano molto, secondo gli obiettivi di

business e altre necessità di rilevazione delle organizzazioni prese in considerazione in

questo studio.

La soddisfazione del cliente comprende in genere i cambiamenti basati sulle

rilevazioni dei clienti stessi.

Alcune organizzazioni raccolgono, analizzano ed utilizzano regolarmente misure

quantitative sulla soddisfazione del cliente, ma ad oggi sono disponibili ancora pochi

risultati che possano essere espressi come variazione nel tempo.

Il ROI (Return On Investment) può essere espresso in molti modi, e i risultati a cui

si fa riferimento in questa sede sono riportati in forma di rapporto costi-benefici nel tempo;

come per tutte le altre categorie, i costi ed i benefici a cui ci si riferisce variano a seconda

del tipo di organizzazione che ha fornito i dati.

Tutti i risultati sono riassunti dalla Tabella I.3, e sono espressi in termini di

cambiamenti su intervalli di tempo variabili:


28

Categoria di Performance Miglioramento

medio

Numero di

Data Points

Miglioramento

minimo

Miglioramento

massimo

COSTI 34% 29 3% 87%

TEMPI (Schedule) 50% 22 2% 95%

PRODUTTIVITA’ 61% 20 11% 329%

QUALITA’ 48% 34 2% 132%

SODDISFAZIONE DEL

CLIENTE 14% 7 -4% 55%

ROI (Return on Investment) 4.0 : 1 22 1.7 : 1 27.7 : 1

Tabella I.3 – Riassunto dei risultati di performance del CMMI

Questi risultati forniscono un’ampia e valida prova della validità del CMMI come

modello base del miglioramento dei processi, anche se essi non rappresentano una garanzia

di successo.

Va sottolineato che sono stati rilevati dei miglioramenti in tutte le sei categorie di

performance, e che in genere un’evoluzione positiva per un parametro costituisce un

fattore di miglioramento degli altri parametri.

La Figura I.4 mostra la variazione della produttività e della qualità del software,

ottenuta nell’arco di 11 anni dalla Lockheed Martin mediante l’applicazione del modello

CMMI come strumento di miglioramento dei processi aziendali: il risultato è un aumento

notevole della produttività e una diminuzione del tasso di errore.


29

Figura I.4 – Performance di produttività e di qualità del software per la Lockheed Martin

Capitolo II Il Capability Maturity Model Integration (CMMI)

30

CAPITOLO II IL CAPABILITY

MATURITY MODEL

INTEGRATION (CMMI)

Il CMMI (Capability Maturity Model® Integration) fornisce uno strumento per

creare un punto di integrazione attraverso un modello trascendente dalle discipline.

Come già detto nei paragrafi I.4.1, I.4.2, I.4.3, il CMMI focalizza l’attenzione sul

concetto di processo, in quanto la qualità di un prodotto è determinata principalmente dalla

qualità dei processi di sviluppo, produzione e manutenzione.

Passiamo ora ad analizzare nel dettaglio le parole che compongono l’acronimo

CMMI:

• 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;

• 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'Azienda, ivi inclusa la capacità della stessa di migliorarlo, ottimizzarlo o

comunque modificarlo in risposta a necessità che si presentano;

• Model: insieme di descrizioni di processi da adattare alle diverse realtà aziendali,

quindi fornisce modelli che aiutino le aziende nello sviluppo dei propri servizi e

prodotti;

• Integration: una struttura predisposta all’integrazione di più discipline, quindi

fornisce un modello integrato rispetto a quelli precedenti (CMM).


31

II.1 I componenti del modello

Di seguito viene riportata la struttura generale del modello CMMI® , illustrando le

relazioni tra le varie componenti del modello:

Figura II.1 – Struttura generale del modello CMMI

Nei successivi sottoparagrafi si analizzeranno in dettaglio i vari componenti del

modello.

II.1.1 Le Aree di Processo

L’elemento più importante del modello è l’area di processo che è definita come un

gruppo di procedure o di attività eseguite collettivamente per il raggiungimento di una

serie di obiettivi predefiniti: ogni area di processo ha degli obiettivi (Goal) che devono

essere soddisfatti.

Gli obiettivi delle aree di processo si suddividono in obiettivi specifici e in obiettivi

generici: per raggiungere tali obiettivi devono essere svolte delle attività, di cui alcune

relative agli obiettivi specifici (pratiche specifiche) altre relative agli obiettivi generici

(pratiche generiche).


32

Le pratiche generiche in particolare sono un indicatore del livello di

istituzionalizzazione del processo e sono associate ai livelli di capability (vedere paragrafo

II.2).

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, o analizzato statisticamente, etc.

Le pratiche specifiche invece riguardano le attività che devono essere implementate

per una data area di processo e sono specifiche del dominio dell’area di processo.

Di seguito vengono riportate le 22 aree di processo in ordine alfabetico:

• Causal Analysis and Resolution (CAR)

• Configuration Management (CM)

• Decision Analysis and Resolution (DAR)

• Integrated Project Management +IPPD (IPM+IPPD)

• Measurement and Analysis (MA)

• Organizational Innovation and Deployment (OID)

• Organizational Process Definition +IPPD (OPD+IPPD)

• Organizational Process Focus (OPF)

• Organizational Process Performance (OPP)

• Organizational Training (OT)

• Product Integration (PI)

• Project Monitoring and Control (PMC)

• Project Planning (PP)

• Process and Product Quality Assurance (PPQA)

• Quantitative Project Management (QPM)

• Requirements Development (RD)

• Requirements Management (REQM)

• Risk Management (RSKM)

• Supplier Agreement Management (SAM)

• Technical Solution (TS)

• Validation (VAL)

• Verification (VER)


33

Le aree di processo possono essere raggruppate in quattro categorie: Process

Management, Project Management, Engineering e Support.

Process Management

La categoria Process Management contiene le aree di processo riguardanti le

attività inerenti il progetto che hanno lo scopo di definire, pianificare, sviluppare,

implementare, monitorare, controllare, misurare e migliorare i processi.

Le aree di processo della categoria Process Management sono le seguenti:

Categoria Area di Processo Descrizione

Organizational

Process Focus (OPF)

Identificazione, pianificazione, coordinamento e

implementazione del miglioramento.

Organizational

Process Definition

+IPPD (OPD+IPPD)

Sviluppo e mantenimento del set di standard

aziendali di processo e di prodotto.

Organizational

Training (OT)

Identificazione delle necessità di formazione e di

sviluppo/rilascio della formazione.

Organizational

Process Performance

(OPP)

Determinazione degli obiettivi quantitativi per la

qualità e per le performance dei vari processi

implementati dagli obiettivi di business.

Process Management

Organizational

Innovation and

Deployment (OID)

Selezione ed implementazione di miglioramenti

incrementali ed innovativi, per generare benefici,

gestendo l’inversione in modo quantitativo.

Tabella II.2 – Aree di Processo della categoria Process Management

Project Management

La categoria Project Management contiene le aree di processo riguardanti le attività

di gestione del progetto che hanno lo scopo di pianificare, monitorare e controllare il

progetto.

Le aree di processo della categoria Project Management sono le seguenti:


34


Project Planning

(PP)

Definizione e mantenimento di un piano di progetto,

coinvolgendo gli stakeholder adeguati, ed ottenendo

il commitment per le attività da svolgere.

Project Monitoring

and Control (PMC)

Controllo del progresso rispetto al piano, prendendo

dove necessario azioni correttive e preventive.

Supplier Agreement

Management

(SAM)

Selezione e gestione efficace dei sub-fornitori

definendo un contratto tra le parti che consenta una

pianificazione e un monitoraggio delle attività e delle

performance del sub-fornitore. Revisioni e test di

accettazione svolti d’accordo ai requisiti contrattuali.

Integrated Project

Management

+IPPD

(IPM+IPPD)

Definizione e selezione di un processo per ogni

singolo progetto che sia adattato (tailored) dallo

standard dell’organizzazione (vedere Organizational

Process Definition +IPPD). Tale processo, definito

specificatamente per un progetto, garantisce una

visione integrata per quei gruppi di progetti con forte

connotazione di integrazione tra le varie discipline.

Risk Management

(RSKM)

Approccio continuativo alla gestione dei rischi

associati al progetto attraverso una identificazione dei

parametri e delle tassonomie di rischio.

Project

Management

Quantitative Project

Management

(QPM)

Applicazione di tecniche quantitative e statistiche per

gestire la performance e la qualità di prodotto

Tabella II.3 – Aree di Processo della categoria Project Management

Engineering

La categoria Engineering contiene le aree di processo riguardanti le attività di

sviluppo e manutenzione che sono distribuite in discipline tecniche.

Le aree di processo dell’Engineering sono applicate allo sviluppo di qualsiasi

prodotto o servizio nella fase di sviluppo (per es. prodotti software e hardware, servizi, o

processi).


35

Inoltre le aree di processo dell’Engineering forniscono il fondamento tecnico

dell’IPPD che è basato su un approccio con sistemi tecnici robusti, comprendente lo

sviluppo nel contesto delle fasi della vita del prodotto.

Le aree di processo della categoria Engineering sono le seguenti:


Requirements

Development (RD)

Identificazione delle necessità del cliente e

traduzione in requisiti di prodotto con una soluzione

concettuale di alto livello per ciascuna disciplina

coinvolta e la evoluzione di una architettura

funzionale preliminare.

Requirements

Management

(REQM)

Gestione dei requisiti con un costante allineamento ai

piani di progetto attraverso una efficace gestione dei

cambi e la rintracciabilità dei requisiti dal cliente sino

al prodotto finale.

Technical Solution

(TS)

Sviluppo dei componenti e dati tecnici associati per

la successiva integrazione attraverso la valutazione di

soluzioni alternative (vedere Decision Analysis and

Resolution).

Product Integration

(PI)

Implementazione della migliore strategia per

l’integrazione dei componenti.

Verification (VER) Controllo della conformità con i requisiti specificati

per ciascun prodotto intermedio selezionato.

Engineering

Validation (VAL)

Controllare la validità del prodotto, dei prodotti

intermedi e dei processi rispetto alla necessità del

cliente.

Tabella II.4 – Aree di Processo della categoria Engineering

Support

La categoria Support contiene le aree di processo riguardanti le attività che

supportano lo sviluppo e la manutenzione del prodotto.


36

Le aree di processo della categoria Support indirizzano i processi che sono usati nel

contesto per eseguire altri processi.

Per esempio l’area di processo Assicurazione Qualità di Processo e di Prodotto

(PPQA) può essere usata con tutte le aree di processo per fornire una valutazione oggettiva

dei processi e dei work product descritti in tutte le aree di processo.

Le aree di processo della categoria Support sono le seguenti:


Configuration

Management (CM)

Supporto a tutte le aree di processo nel definire e

mantenere l’integrità dei prodotti (prodotti intermedi

acquisiti o sviluppati internamente) e dei tools.

Process and

Product Quality

Assurance (PPQA)

Supporto a tutte le aree di processo per la obiettiva

valutazione dei processi, dei prodotti e dei prodotti

intermedi rispetto agli standard e alle procedure

applicabili.

Measurement and

Analysis (MA)

Supporto a tutte le aree di processo nel guidare i

progetti e l’organizzazione nell’allineare le necessità

e gli obiettivi di misurazione con l’approccio alla

misurazione al fine di usare i risultati delle

misurazioni per aspetti informativi o prendere

appropriate azioni correttive.

Decision Analysis

and Resolution

(DAR)

Supporto a tutte le aree di processo nello strutturare

un processo di decision making per garantire che le

possibili alternative siano confrontabili e la più

adeguata selezionata.

Support

Causal Analysis

and Resolution

(CAR)

Analisi progettuale delle cause comuni di variazione

inerenti ai processi al fine di rimuoverle e definire la

base conoscitiva per migliorare continuativamente gli

standard processuali dell’organizzazione.

Tabella II.5 – Aree di Processo della categoria Support


37

Nei seguenti sottoparagrafi si analizzeranno più in dettaglio i vari componenti di

un’area di processo.

II.1.2 Obiettivi generici

Gli obiettivi generici sono chiamati “generici” poiché lo stesso obiettivo deve

essere applicato a tutte le aree di processo.

Un obiettivo generico descrive le caratteristiche che devono essere presenti per

istituzionalizzare i processi che implementano un’area di processo.

Un obiettivo generico è un componente del modello che è richiesto ed usato nelle

valutazioni per determinare se un’area di processo viene soddisfatta.

II.1.3 Pratiche generiche

Le pratiche generiche come gli obiettivi generici sono applicate a tutte le aree di

processo.

Una pratica generica è la descrizione di un'attività che è ritenuta importante nel

realizzare l'obiettivo generico ad essa associato.

Per esempio, una pratica generica per l'obiettivo generico “Istituzionalizzare un

processo gestito” è “Provvedere adeguatamente alle risorse per l’esecuzione del processo,

per lo sviluppo dei Work Product (vedere Paragrafo II.1.6) e per la fornitura dei servizi del

processo”.

Di seguito è riportata la Tabella II.6 con gli obiettivi generici e le pratiche

generiche che saranno comuni a tutte le aree di processo.


38

GP 1.1 Effettuare le Pratiche Specifiche

GP 2.1 Stabilire una Politica di Organizzazione

GP 2.2 Pianificare il Processo

GP 2.3 Provvedere alle Risorse

GP 2.4 Assegnare le Responsabilità

GP 2.5 Formare il Personale

GP 2.6 Gestire la Configurazione

GP 2.7 Identificare e Coinvolgere i Relevant Stakeholder

GP 2.8 Monitorare e Controllare il Processo

GP 2.9 Valutare oggettivamente l'Aderenza

GP 2.10 Revisionare lo Stato con una Gestione di Livello più Alto

GP 3.1 Stabilire un Processo Definito

GP 3.2 Collezionare le Informazioni di Miglioramento

GP 4.1 Stabilire gli Obiettivi Quantitativi per il Processo

GP 4.2 Stabilizzare la Prestazione dei Sottoprocessi

GP 5.1 Assicurare un Miglioramento continuo del Processo

GP 5.2 Correggere le Cause Generatrici di Problemi

GG 5 Istituzionalizzare un Processo Ottimizzato

GG 3 Istituzionalizzare un Processo Definito

GG 1 Realizzare gli Obiettivi Specifici

GG 2 Istituzionalizzare un Processo Gestito

GG 4 Istituzionalizzare un Processo Quantitativamente Gestito

Tabella II.6 – Obiettivi generici con le relative pratiche generiche

II.1.4 Obiettivi specifici

Un obiettivo specifico descrive le caratteristiche uniche che devono essere presenti

per soddisfare l’area di processo.

Un obiettivo è un componente del modello che è richiesto ed usato nelle valutazioni

per determinare se un’area di processo viene soddisfatta.

Per esempio, un obiettivo specifico dell’area di processo Gestione della

Configurazione (Configuration Management) è “Stabilire e mantenere l’integrità delle

baseline”.


39

II.1.5 Pratiche specifiche

Una pratica specifica è la descrizione di un’attività che è ritenuta importante nel

realizzare l’obiettivo specifico ad essa associato.

Le pratiche specifiche descrivono quindi le attività che si ritengono indispensabili

per il raggiungimento degli obiettivi specifici di un’area di processo.

Per esempio, una pratica specifica dell’area di processo Monitoraggio e Controllo

del Progetto (Project Monitoring and Control) è “Monitorare i Parametri della

Pianificazione del Progetto”.

II.1.6 Typical work product

I Typical Work Product suddividono l’output di una pratica specifica in una lista di

risultati mirati da ottenere.

Quest’ultimi sono denominati typical work product perché spesso ci sono altri work

product che sono adatti ed efficaci per la pratica specifica, ma che non sono elencati.

Per esempio, un typical work product per la pratica specifica “Monitorare i

Parametri della Pianificazione del Progetto” nell’area di processo Monitoraggio e

Controllo del Progetto è “Registrazione di deviazioni significative rispetto al piano”.

II.1.7 Sottopratiche

Una sottopratica è una descrizione dettagliata che fornisce le linee guida per

l'interpretazione e per l’implementazione della pratica specifica o generica.

Le sottopratiche possono essere espresse come delle norme da seguire, ma

attualmente hanno solo lo scopo di fornire le idee che possono essere utili per migliorare il

processo.

Per esempio, una sottopratica per la pratica specifica “Effettuare Azioni Correttive”

nell’area di processo Monitoraggio e Controllo del progetto è “Determinare e documentare

le azioni necessarie e appropriate per indirizzarsi verso i problemi identificati”.


40

II.2 I livelli di capability

Nel modello CMMI si usano i livelli per descrivere un percorso di evoluzione

raccomandato per un’organizzazione che voglia migliorare i processi che usa per

sviluppare e mantenere i propri prodotti e servizi.

Il CMMI supporta due percorsi di miglioramento, uno per incrementare i processi

corrispondenti ad una determinata area di processo (o aree di processo) scelta

dall’organizzazione, l’altro è per migliorare un insieme di processi rivolgendosi via via ad

aree di processo successive.

Questi due percorsi, che corrispondono alle due rappresentazioni possibili di questo

modello (descritte dettagliatamente nel paragrafo II.4), sono associati ai due tipi di livelli

possibili.

In entrambi i casi il concetto di livello è lo stesso.

Il CMMI fornisce per ciascuna area di processo dei livelli di evoluzione chiamati

Livelli di Capability.

Un livello di capability (Capability Level - CL) consiste in un obiettivo generico e

nelle sue relative pratiche generiche, che possono migliorare i processi dell’organizzazione

associati all’area considerata.

Un livello di capability è quindi un insieme di pratiche che descrivono l’evoluzione

graduale delle attività dell’area di processo.

Ciascun livello serve da fondamento per il livello successivo di miglioramento del

processo, pertanto i livelli sono incrementali: il livello più alto include le caratteristiche di

quelli più in basso.

Ciascuna area prevede 6 livelli di capability (da 0 a 5) che vengono conseguiti

mettendo in atto attività sempre più evolute:

0. Incomplete

1. Performed

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Ogni processo è valutato secondo il proprio capability level.


41

Un’organizzazione, probabilmente, avrà aree di processo diverse stimate a

differenti livelli di capability.

Il risultato di questa stima può essere riferito con il nome di Capability Profile,

come si vede nella Figura II.7.

Figura II.7 – Capability Profile

Livello 0: Incomplete

Un processo è incompleto, quando non è stato eseguito oppure è stato eseguito solo

parzialmente. Uno o più obiettivi specifici dell’area di processo non sono stati soddisfatti, e

non esistono obiettivi generici per questo livello in quanto non c’è ragione di

istituzionalizzare un processo parzialmente eseguito.

Livello 1: Performed

Perché un’area di processo sia al 1° livello di capability bisogna mettere in pratica

le attività di base richieste per iniziare a lavorare su quella determinata area.

Un processo eseguito è tale, quando soddisfa gli obiettivi specifici dell’area di

processo.

Questo livello supporta e permette le attività necessarie per produrre i work

product.


42

Benché il processo eseguito abbia per risultato dei miglioramenti importanti, questi

potrebbero essere persi nel tempo se non vengono istituzionalizzati.

L’istituzionalizzazione (ovvero la soddisfazione delle pratiche generiche dei livelli

di capability dal 2 al 5) aiuta ad assicurare che i miglioramenti siano mantenuti.

Livello 2: Managed

Un processo gestito è un processo eseguito che ha le infrastrutture di base per

essere supportato.

E’ organizzato ed eseguito in accordo ad alcune regole; impiega persone

competenti che abbiano adeguate conoscenze per produrre dei risultati controllati;

coinvolge gli stakeholder più importanti (ovvero i portatori di interessi del progetto); è

monitorato, controllato e revisionato.

Questo livello aiuta ad assicurare che le pratiche esistenti siano mantenute nel

tempo.

Livello 3: Defined

Un processo definito è un processo gestito che è stato adattato in accordo con le

linee guida di tailoring dei processi standard dell’organizzazione.

Contribuisce ai work product, alle misure, ed ad altre informazioni di

miglioramento.

La differenza principale tra il livello 2 ed il livello 3 è il campo di applicazione

degli standard, le descrizioni del processo e le procedure.

Nel livello 2 questi punti possono essere un po’ diversi in ciascuna istanza specifica

del processo.

Nel livello 3, invece, queste caratteristiche sono più rilevanti e vengono tailorizzate

dall’insieme dei processi standard dell’azienda per adattarle ad un particolare progetto od

unità organizzativa.

Un’altra differenza è che al livello 3 i processi sono tipicamente descritti in maniera

più rigorosa rispetto al livello 2.

Il processo definito, infatti, afferma chiaramente lo scopo, gli input, i criteri di

entrata, le attività, i ruoli, le misure, gli step di verifica, gli output ed i criteri di uscita.


43

Il livello 3 quindi gestisce i processi in maniera preventiva attraverso la

comprensione delle relazioni tra le attività di processo, delle misure dettagliate, dei work

product e dei servizi.

Livello 4: Quantitatively Managed

In questo caso il processo è un processo definito che è controllato usando tecniche

quantitative o statistiche.

Gli obiettivi quantitativi per la qualità ed il processo sono stabiliti ed usati come

criteri di gestione dei processi stessi.

La performance del processo e della qualità è intesa in termini statistici e viene

gestita attraverso tutta la vita del processo.

Livello 5: Optimizing

In questo caso si ha un livello che è quello del livello di capability precedente che è

stato però migliorato sulla base di una comprensione delle più comuni cause di variazione

del processo.

Il punto focale a questo livello è un miglioramento continuo del range di

esecuzione del processo attraverso miglioramenti innovativi ed incrementali.

In aggiunta, il fatto che i livelli di capability dal 2 al 5 utilizzino gli stessi termini

degli obiettivi generici dal 2 al 5 è intenzionale, perché ognuno di questi obiettivi, con le

relative pratiche, riflette il significato del livello di capability in termini di obiettivi e

pratiche che si possono implementare.

II.3 I livelli di maturity

I livelli di maturity (Maturity Level - ML) consistono in relative pratiche specifiche

e generiche, per un predefinito insieme di aree di processo, che miglioreranno la

rappresentazione totale dell’azienda.

Il livello di maturity dell’organizzazione fornisce una strada per prevedere una

rappresentazione di una data disciplina o insieme di discipline.

Ciascun livello matura un importante sottoinsieme di processi preparandolo a

muoversi per il livello successivo.


44

I maturity level sono misurati dal raggiungimento di obiettivi generici e specifici

associati a ciascun predefinito insieme di aree di processo.

Le aree di processo possono anche essere raggruppate nei 5 livelli di maturity, che

vengono conseguiti portando sottoinsiemi crescenti di aree di processo allo stesso livello di

capability.

In questo modo le aziende vengono guidate lungo un percorso ottimale di crescita

della capability, che rivolge l’attenzione dapprima ai processi della categoria Process

Management, poi a quelli della categoria Engineering, fino a quelli di controllo statistico

della progettazione e di miglioramento continuo dei processi.

Un livello di maturity è una tappa ben definita lungo il percorso evolutivo della

maturity dell’azienda.

I 5 livelli utilizzati per descrivere la strada consigliata per una organizzazione che

voglia migliorare i processi di sviluppo e manutenzione di prodotti e servizi, sono:

1. Initial

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Da notare che i capability level e i maturity level usano gli stessi termini per

definire i livelli dal 2 al 5, questo perché i due livelli sono complementari.

Quelli di maturity sono usati per caratterizzare il miglioramento

dell’organizzazione relativo ad un insieme di aree di processo, quelli di capability

caratterizzano il miglioramento organizzativo relativo ad una singola area di processo.

Livello 1: Initial

Rappresenta processi con risultati non prevedibili.

I processi di produzione sono instabili e disorganizzati; implicitamente definiti di

volta in volta da chi li realizza; il flusso delle attività è caotico.

Il successo in questo caso è affidato solo alla competenze delle persone che

lavorano nell’azienda e non all’uso comprovato di processi.

A questo livello anche se si producono prodotti e servizi che funzionano, spesso si

superano i budget e non si raggiungono pienamente gli scopi preposti.


45

Livello 2: Managed

A questo livello i progetti devono assicurare che i processi siano pianificati e gestiti

in accordo a delle regole stabilite.

I progetti usano persone competenti che hanno una conoscenza adeguata per

produrre output controllati; coinvolgono gli stakeholder più importanti; sono monitorati,

controllati e revisionati.

Questo livello aiuta ad assicurare che le pratiche siano mantenute nel tempo.

I progetti saranno rappresentati e gestiti in accordo ai piani documentati ed agli

impegni stabiliti con gli stakeholder e revisionati se necessario.

Livello 3: Defined

A questo livello i processi sono ben caratterizzati e compresi, e sono descritti in

standard, procedure, tool e metodi.

L’insieme di processi standard, che sono la base del livello di maturity 3, sono

stabiliti e migliorati nel tempo.

I progetti stabiliscono i loro processi definiti tailorizzando l’insieme dei processi

standard dell’organizzazione, in accordo alle linea guida del tailoring.

La differenza principale tra il livello 2 ed il livello 3 è il campo di applicazione

degli standard, le descrizioni del processo e le procedure.

Nel livello 2 questi punti possono essere un po’ diversi in ciascuna istanza specifica

del processo.

Nel livello 3, invece, queste caratteristiche sono più rilevanti e vengono tailorizzate

dall’insieme dei processi standard dell’azienda per adattarle ad un particolare progetto od

unità organizzativa.

Un’altra differenza è che al livello 3 i processi sono tipicamente descritti in maniera

più rigorosa rispetto al livello 2.

Il processo definito afferma chiaramente lo scopo, gli input, i criteri di entrata, le

attività, i ruoli, le misure, gli step di verifica, gli output ed i criteri di uscita.

Il livello 3 quindi gestisce i processi in maniera preventiva attraverso la

comprensione delle relazioni tra le attività di processo, delle misure dettagliate, dei work

product e dei servizi.


46

A questo livello l’organizzazione deve inoltre maturare le aree di processo del

livello 2.

Livello 4: Quantitatively Managed

In questo caso l’organizzazione ed i progetti stabiliscono gli obiettivi quantitativi,

per la rappresentazione della qualità e dei processi, e li usano come criteri di gestione.

Gli obiettivi sono basati sulle necessità del cliente, degli utenti, dell’organizzazione

e dell’implementazione del processo.

La rappresentazione del processo e della qualità è intesa nei termini statistici ed è

gestita attraverso la vita dei processi.

La differenza maggiore tra il livello 3 ed il 4 sta nella capacità di prevedere

l’esecuzione dei processi.

Al livello 4 l’esecuzione dei processi è controllata attraverso tecniche statistiche e

quantitative ed è prevedibile quantitativamente.

Al livello 3, invece, i processi sono solamente prevedibili qualitativamente.

Livello 5: Optimizing

A questo livello l’azienda migliora continuamente i suoi processi, basati su una

comprensione quantitativa delle più comuni cause di variazione del processo.

Questo maturity level si focalizza su un continuo miglioramento dell’esecuzione del

processo attraverso processi innovativi e miglioramenti tecnologici.

La differenza maggiore tra il livello 4 ed il 5 è il tipo di variazione del processo

indicata.

Al livello 4 l’azienda è impegnata a tenere sotto controllo le cause straordinarie di

variazione del processo e a fornire una previsione statistica dei risultati.

Al livello 5, invece, l’azienda si occupa di tenere sotto controllo le cause più

comuni di variazione del processo, per migliorare l’esecuzione del processo e per

raggiungere gli obiettivi di miglioramento del processo.


47

II.4 Le due rappresentazioni

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'azienda 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.

II.4.1 La rappresentazione scalare

La rappresentazione scalare (staged representation) utilizza i maturity level e

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,

ovvero come una serie di fasi (stage) che sono appunto i maturity level.

Ognuno di questi livelli contiene un set di aree di processo che indicano dove

focalizzarsi per migliorare il processo aziendale.

Ogni area di processo è descritta in termini di pratiche che contribuiscono a

raggiungere gli obiettivi.

Le pratiche descrivono l'infrastruttura e le attività che concorrono all'effettiva

implementazione ed istituzionalizzazione delle aree di processo.

I progressi sono misurati in raggiungimento degli obiettivi di ogni area di processo

presenti in un particolare maturity level come si può vedere dalla Figura II.8.


48

Figura II.8 – Struttura della rappresentazione scalare

La Figura II.9 mostra come le aree di processo sono usate nella rappresentazione

scalare, ovvero raggruppate per maturity level.

Figura II.9 – Aree di Processo nella rappresentazione scalare

All'interno della Tabella II.10 sono presentate le aree di processo con il relativo

maturity level.


49

Nome Acronimo ML

Configuration Management CM 2

Measurement and Analysis MA 2

Process and Product Quality Assurance PPQA 2

Project Monitoring and Control PMC 2

Project Planning PP 2

Requirements Management REQM 2

Supplier Agreement Management SAM 2

Decision Analysis and Resolution DAR 3

Integrated Project Management +IPPD IPM +IPPD 3

Organizational Process Definition +IPPD OPD +IPPD 3

Organizational Process Focus OPF 3

Organizational Training OT 3

Product Integration PI 3

Requirements Development RD 3

Risk Management RSKM 3

Technical Solution TS 3

Validation VAL 3

Verification VER 3

Organizational Process Performance OPP 4

Quantitative Project Management QPM 4

Causal Analysis and Resolution CAR 5

Organizational Innovation and Deployment OID 5

Tabella II.10 – Aree di Processo per ML

II.4.2 La rappresentazione continua

La rappresentazione continua utilizza i capability level e non fornisce una direzione

obbligatoria nella definizione delle modalità con cui affrontare il processo.

Come la rappresentazione scalare, la rappresentazione continua è formata da aree di

processo che contengono delle pratiche che, al contrario della rappresentazione scalare,

sono organizzate in modo da sostenere lo sviluppo di una singola area di processo.

Le pratiche generiche sono raggruppate in capability level.

Ogni area di processo è istituzionalizzata implementando le sue pratiche generiche.

I capability level, quindi, si applicano al raggiungimento del miglioramento del

processo nelle singole aree come mostrato in Figura II.11, e questa rappresentazione si


50

occupa di selezionare una particolare area di processo per migliorarla e raggiungere il

capability level desiderato.

Figura II.11 – Struttura della rappresentazione continua

La Figura II.12 mostra come le aree di processo sono usate nella rappresentazione

continua.

Figura II.12 – Aree di Processo nella rappresentazione continua


51

II.4.3 Differenze tra le due rappresentazioni

La scelta tra le due rappresentazioni è libera, ma è interesse dell’azienda riuscire a

capire quale delle due rappresentazioni conviene maggiormente adottare.

La Tabella II.13 riassume le differenze tra la rappresentazione continua e la

rappresentazione scalare.

Rappresentazione Continua Rappresentazione Scalare

L’azienda seleziona le aree di processo e i livelli di capability basati sui propri obiettivi di miglioramento del processo.

L’azienda seleziona le aree di processo basate sui maturity level.

I progessi sono misurati usando i capability level, che:

• Misurano l’istituzionalizzazione (maturity) di un particolare processo nell’azienda.

• Vanno da 0 a 5.

I progressi sono misurati usando i maturity level, che:

• Misurano l’istituzionalizzazione (maturity) di un insieme di processi nell’azienda.

• Vanno da 1 a 5.

I profili dei capability level sono usati per raggiungere e tracciare l’esecuzione del miglioramento dei processi.

I maturity level sono usati per raggiungere e tracciare l’esecuzione del miglioramento dei processi.

L’Equivalent Staging (equivalente scalare) permette ad un’organizzazione di utilizzare l’approccio continuo al miglioramento del processo, per derivare un livello di maturity come parte di un appraisal (autovalutazione).

Non c’è necessità di un meccanismo di equivalenza per tornare all’approccio continuo.

Tabella II.13 – Comparazione tra rappresentazione continua e scalare

Dopo avere visto, per ogni singola rappresentazione, come sono usate le aree di

processo, possiamo illustrare anche come sono usate le pratiche generiche (Generic

Practice - GP) e gli obiettivi generici (Generic Goal - GG).

Come dimostra la figura seguente, tutti i GG e le GP sono usate nella

rappresentazione continua, ed il capability level che si vuole raggiungere per il


52

miglioramento determinerà quali GG e GP saranno applicati all’area di processo

selezionata.

Nella rappresentazione scalare, invece, come si evince sempre dalla Figura II.14,

sono usati solo i GG 2 e 3, infatti sono evidenziati solo questi ultimi e le loro relative GP.

Figura II.14 – Pratiche generiche ed obiettivi generici

I GG 4 e 5 e le pratiche relative non sono usati perché non tutti i processi

raggiungeranno lo stato di processo definito.

Questo perché soltanto alcuni processi e sottoprocessi diverranno “Quantitatively

Managed” e “Optimizing”, ovvero quelli individuati dalle aree di processo ai livelli 4 e 5

di maturity.

Ci sono tre fattori che influenzano la decisione di adottare una rappresentazione

piuttosto che l’altra, e sono: business, cultura aziendale e legacy.

Per il primo fattore (business) si può dire che in un’azienda in cui si ha una

conoscenza matura dei propri obiettivi di business, è probabile che vi sia un tracciamento

forte tra processi aziendali e relativi obiettivi di commercio, in questo caso l’azienda

potrebbe scegliere la rappresentazione continua.


53

Mentre se l’azienda decide di migliorare i propri processi attraverso l’intera

organizzazione, potrebbe servire la rappresentazione scalare, in quanto la aiuterà a

selezionare i processi critici per metterli a fuoco e migliorarli.

Per quanto riguarda il fattore della cultura aziendale, questa si riferisce al fatto che

se un’azienda ha poca esperienza nel miglioramento dei processi, potrebbe adottare la

rappresentazione scalare, in quanto le fornirebbe il consiglio utile supplementare

sull’ordine in cui i cambiamenti dovrebbero accadere.

Infine, se un'organizzazione ha esperienza di un altro modello che ha una

rappresentazione scalare, quindi parliamo del fattore legacy, può essere saggio continuare

con questa rappresentazione nell’uso del modello CMMI, in particolare se ha investito le

risorse ed i processi.

Lo stesso vale per la rappresentazione continua.

In ogni caso, a prescindere dai tre fattori, la scelta è totalmente libera, anche perchè

le due rappresentazioni sono destinate ad offrire essenzialmente i risultati equivalenti.

Di conseguenza, un'Azienda può trovare utilità in entrambe le rappresentazioni e

spesso può definire un programma di miglioramento che usi i principi sia della

rappresentazione scalare che continua.

II.5 Quadro conclusivo per la registrazione aziendale

Legando tutto il discorso sui livelli, possiamo dire che il concetto di “maturity” si

riferisce all’intera Azienda, e il concetto di “capability” alla singola area di processo.

Detto questo, riassumiamo di seguito le condizioni richieste per ottenere la

registrazione di maturity aziendale del modello CMMI:

• Per raggiungere il livello di maturity 2, tutte le aree di processo assegnate a

quel maturity level devono raggiungere il livello di capability 2 (entrambe le

rappresentazioni) o superiore (solo rappresentazione continua);

• Per raggiungere il livello di maturity 3, tutte le aree di processo assegnate ai

maturity level 2 e 3 devono raggiungere il livello di capability 3 (entrambe

le rappresentazioni) o superiore (solo rappresentazione continua);


maturity level 2, 3 e 4 devono raggiungere il livello di capability 3

(entrambe le rappresentazioni) o superiore (solo rappresentazione continua);


54


maturity level 2, 3, 4 e 5 devono raggiungere il livello di capability 3

(entrambe le rappresentazioni) o superiore (solo rappresentazione continua).

Quindi i capability level 4 e 5 non sono obbligatori per il raggiungimento delle

corrispondenti maturity, però alcune aziende potrebbero voler alzare il proprio capability

level di alcune aree di processo, pur non essendo necessario per il raggiungimento della

registrazione di una determinata maturity.

Allora quello che si fa è tracciare per le aziende registrate non solo la maturity

raggiunta, ma anche il capability profile (visto nel paragrafo II.2), che darà la stima delle

aree di processo che si troveranno a differenti e maggiori livelli di capability.

Questo aspetto del modello CMMI però, riguarda solamente le aziende che usano la

rappresentazione continua, in quanto la rappresentazione scalare richiede degli step

obbligatori che portano ad un determinato livello di maturity e non è quindi possibile in

questo caso un livello intermedio, ovvero registrare aree di processo a livelli di capability

diversi da quelli raggiunti per la registrazione.

Inoltre, come detto nel paragrafo II.4.3, i GG di livello più alto (4 e 5),

corrispondenti ai relativi capability level (4 e 5), sono usati solo nella rappresentazione

continua, poiché se si volesse alzare il capability level di alcune aree di processo sopra il 3,

ciò non sarebbe possibile per le aziende che usano la rappresentazione scalare.

La Figura II.15 mostra una sintesi dei profili raggiungibili (Target Profile) per i

maturity level (ML) dal 2 al 5, in cui ciascuna area annerita nelle colonne del capability

level (CL) rappresenta un profilo che è equivalente al livello di maturity.


55

Nome Acronimo ML CL1 CL2 CL3 CL4 CL5

Requirements Management REQM 2

Project Planning PP 2

Project Monitoring and Control PMC 2

Supplier Agreement Management SAM 2

Measurement and Analysis MA 2

Process and Product Quality Assurance PPQA 2

Configuration Management CM 2

Target Profile 2

Requirements Development RD 3

Technical Solution TS 3

Product Integration PI 3

Verification VER 3

Validation VAL 3 Target Profile 3

Organizational Process Focus OPF 3

Organizational Process Definition +IPPD OPD +IPPD 3

Organizational Training OT 3

Integrated Project Management +IPPD IPM +IPPD 3

Risk Management RSKM 3

Decision Analysis and Resolution DAR 3

Organizational Process Performance OPP 4

Quantitative Project Management QPM 4

Target Profile 4

Organizational Innovation and Deployment OID 5

Causal Analysis and Resolution CAR 5

Target Profile 5

Figura II.15 – Target Profile

Capitolo III L’Approccio Aziendale Al CMMI

56

CAPITOLO III L’APPROCCIO

AZIENDALE AL CMMI

III.1 Obiettivi aziendali

La CHORUS S.r.l. è un’azienda che opera nel campo dell’ingegneria del software e

si occupa di “Progettazione, sviluppo, installazione e manutenzione di prodotti software e

prestazione dei relativi servizi professionali”.

Opera cioè in un contesto industriale che evolve continuamente, sia

tecnologicamente che strutturalmente, divenendo più flessibile e più efficiente.

Per l’azienda assume particolare importanza il poter assicurare la qualità dei

prodotti e servizi offerti ai propri clienti, attraverso le certificazioni di qualità della serie

ISO 900X.

D’altra parte le certificazioni di qualità non suggeriscono nessuna pratica per il

miglioramento dei processi, ma indicano soltanto una soglia di accettazione o di rifiuto

della qualità.

Per competere con successo in questo tipo di mercato si deve puntare ad una

dinamicità crescente, ed assumere un atteggiamento mentale e metodologie di lavoro

orientati al miglioramento continuo.

Solo in questo modo si potrà veramente emergere e migliorare il proprio business.

L’adozione, da parte dell’azienda, di un modello di maturità come il CMMI

permette di apprendere progressivamente le pratiche più progredite dell’ingegneria del

processo software.

Questa evoluzione si articola sui cinque livelli di maturità già descritti nel paragrafo

II.3: Initial, Managed, Defined, Quantitatively Managed, Optimizing.

Sebbene l’azienda possegga una certificazione di qualità ISO 9001, da molti

considerata equivalente al terzo livello di maturità del CMMI, l’analisi effettuata

inizialmente la attesta ad un livello di maturità sensibilmente inferiore.


57

Questo è un’ulteriore dimostrazione del fatto che le certificazioni di qualità sono

spesso fatti formali e laterali, che non rispecchiano le reali pratiche aziendali e che entrano

solo marginalmente nei processi primari.

La CHORUS S.r.l. si è posta l’obiettivo di raggiungere il terzo livello di maturità

indicato dal modello CMMI entro giugno 2008.

Per fare ciò ha sviluppato ed avviato un progetto di implementazione del modello

CMMI che coinvolge l’azienda stessa a tutti i livelli, e si avvale del mentoring della

Business Strategy SaS, che è uno dei due SEI partner presenti in Italia.

III.2 Organizzazione del gruppo di lavoro

Il gruppo di lavoro a cui l’azienda ha affidato il progetto di implementazione del

CMMI è stato composto da quattro stagisti e da alcuni tutor aziendali.

Il progetto è stato interamente coordinato e supervisionato dal Responsabile della

Qualità dell’azienda, persona con esperienza trentennale nel campo dell’informatica e dei

sistemi per la qualità (è auditor certificato delle norme ISO 9001, BS 7799 e ISO 12207).

Inoltre i tutor che l’azienda ha messo a disposizione del progetto ricoprono

incarichi manageriali e hanno ricevuto un training qualificato sul modello CMMI,

seguendo corsi di formazione del SEI.

Dopo una prima fase di studio del modello, ci siamo trovati di fronte alla scelta

della strada da percorrere per giungere all’implementazione del modello CMMI.

Come precedentemente illustrato, esistono due possibili rappresentazioni del

modello CMMI: la continua e la scalare.

La scelta è ricaduta sulla rappresentazione continua poiché permette la massima

flessibilità nella scelta delle aree di processo su cui concentrare l’attenzione dell’azienda,

al fine di soddisfare i propri obiettivi di business.

In questa fase del progetto di implementazione è stato così deciso di lavorare per la

messa in opera delle best practice soltanto di alcune aree di processo.

Per ottenere una registrazione SEI si dovranno comunque prendere in

considerazione tutte quelle aree di processo previste dal livello di maturity che si vuole

raggiungere.

Sono state ritenute strategiche le seguenti aree di processo: Configuration

Management (CM), Measurement and Analysis (MA), Process and Product Quality


58

Assurance (PPQA), Project Monitoring and Control (PMC), Project Planning (PP),

Requirements Development (RD), Requirements Management (REQM), Risk Management

(RSKM), Technical Solution (TS), Validation (VAL) e Verification (VER).

Per velocizzare il progetto di implementazione del CMMI, è parso opportuno che

ognuno di noi stagisti si occupasse di alcune aree di processo in particolare.

È stata così effettuata una suddivisione per affinità di aree di processo, come risulta

dalla Figura III.1, di seguito riportata.

Figura III.1 – Suddivisione per affinità delle Aree di Processo selezionate

Durante ogni fase del progetto di implementazione del CMMI, ognuno di noi

stagisti si è occupato prevalentemente delle aree di processo che gli sono state assegnate.

III.3 Fasi del progetto e della sua messa in opera

Il progetto di implementazione CMMI in CHORUS S.r.l. è stato impostato secondo

il modello IDEALSM ovvero il ciclo di vita per il miglioramento continuativo sviluppato

dal Software Engineering Institute (SEI).

L’esecuzione ciclica di una serie di attività consente l’implementazione di un

programma di miglioramento.

Esse sono:

• Initiating – Identificazione degli obiettivi di business dell’azienda e

sensibilizzazione dell’alta direzione sui costi e benefici di un programma di

miglioramento;

• Diagnosing - Valutazione delle pratiche sulla base del modello di riferimento

CMMI;

• Establishing – Pianificazione del miglioramento;

Project Planning

Project Monitoring and Control

Requirements Development

Requirements Management

Configuration Management

Process and Product Quality Assurance

Technical Solution

Verification

Validation


59

• Acting – Implementazione delle pratiche di miglioramento, attraverso

esperienze pilota (a livello progetto o area);

• Learning – Acquisizione del miglioramento come pratica aziendale e

validazione della sua efficacia dal punto di vista dei risultati economici e degli

obiettivi di business.

Il modello IDEAL (vedi Figura III.2 ) non è solo una istanziazione del più famoso

ciclo PDCA (Plan-Do-Check-Act), ma include una filosofia di lavoro, ben evidenziata

dalla “L” finale, ovverosia catturare opportunamente l’esperienza in database (quantitativi

e qualitativi).

Figura III.2 – Il modello IDEAL: il ciclo del miglioramento continuativo

Di seguito sono riportate nel dettaglio le attività che riguardano ogni fase del

modello IDEAL.

INITIATING – Fase di avviamento

Dopo aver identificato gli obiettivi di business dell’azienda, il gruppo di lavoro ha

compreso gli effettivi vantaggi che deriveranno dall’implementazione del modello CMMI

ed ha ricevuto il sostegno dell’Alta Direzione nel progetto.


60

Sono state valutate le risorse e stimati i tempi di realizzazione.

In questa fase noi stagisti abbiamo acquisito le nozioni base del modello CMMI,

attraverso lo studio e l’analisi del materiale di training ufficiale del SEI.

DIAGNOSING – Fase di valutazione

Durante questa fase è stato effettuato un assessment (valutazione) di alcuni progetti

aziendali a fronte dei requisiti imposti dalle aree di processo selezionate per

l’implementazione del CMMI in azienda.

È stato possibile utilizzare le pratiche e le sottopratiche del modello CMMI per

costruire alcune tabelle che sono state le linee guida per la valutazione dei progetti.

I risultati delle attività di assessment vengono riportati in dettaglio nei capitoli 4 e 5

per le aree di processo da me analizzate.

L’analisi dei dati raccolti nell’assessment ha portato ad evidenziare i punti di forza

e le aree di debolezza dell’attuale Sistema Procedurale (ovvero l’insieme delle procedure

che regolano i progetti aziendali), tenendo sempre presente l’obiettivo del raggiungimento

del terzo livello di maturità.

Ognuno di noi stagisti, curando le aree di processo assegnategli, ha prodotto una

serie di annotazioni circa le integrazioni e le modifiche da effettuare sul Sistema

Procedurale per l’adozione del modello CMMI.

Queste raccomandazioni sono state utilizzate nella fase successiva per la

definizione di un piano di miglioramento.

ESTABLISHING – Fase di definizione

Il rapporto di valutazione risultante dalla fase precedente ha consentito di definire la

priorità degli interventi, e quindi, di pianificare le azioni di miglioramento.

A seguito di alcune riunioni con il Responsabile della Qualità dell’azienda, si è

deciso di intraprendere la strada della progettazione di un nuovo Sistema Procedurale che

prendesse spunto da quello attuale, ma a cui non rimanesse obbligatoriamente legato.

Sono state così identificate nuove procedure e definiti i loro domini di applicazione.

Le nuove procedure affiancheranno il personale dell’azienda nello svolgimento

delle attività lavorative con l’obiettivo di trasferirvi le conoscenze delle best practice del

CMMI e consolidare l’adozione del modello.


61

Questo tipo di apprendimento è chiamato Training on the Job; oltre ad essere un

efficace metodo di formazione per il personale, che è guidato passo per passo in tutte le

attività, è anche utile all’azienda poiché abbatte i costi legati alla formazione del personale.

La progettazione del nuovo Sistema Procedurale è stata affidata a noi stagisti.

Nel piano delle attività di progettazione sono state previste periodiche revisioni del

lavoro da parte del Responsabile della Qualità.

ACTING – Fase di implementazione

In questa fase è avvenuta la progettazione del nuovo Sistema Procedurale.

Sono state formulate e scritte le nuove procedure aziendali che permetteranno di

implementare il terzo livello di maturità del CMMI.

Di sicuro è stata una delle fasi più importanti ed innovative del progetto.

Ognuno di noi stagisti si è interessato alle attività legate alle aree di processo

assegnategli e le procedure risultanti sono riportate nel capitolo 6 di questa tesi.

Il nostro stage in azienda si è concluso dopo aver prodotto le nuove procedure.

Questo perché i tempi aziendali per l’adozione di un modello come il CMMI sono

relativamente lunghi.

Il progetto di implementazione del CMMI andrà comunque avanti e proseguirà

secondo l’iter stabilito.

Inizialmente si sceglieranno alcuni progetti pilota in cui adottare il nuovo Sistema

Procedurale ed, in base alle indicazioni raccolte, si effettueranno eventuali revisioni delle

procedure.

Dopo aver effettuato – anche più di una volta – il processo di test e rifinitura, e

dopo la definitiva approvazione da parte dell’Alta Direzione dell’azienda, il nuovo Sistema

Procedurale diventerà applicabile per tutti i progetti aziendali.

LEARNING – Fase di apprendimento

Come già detto in precedenza, il modello CMMI aiuta a valutare e a dare il giusto

peso ad errori e successi sperimentati nel corso delle fasi precedenti e a, eventualmente,

rivedere le scelte organizzative.

In questa fase si farà proprio questo.


62

III.4 Quadro d’insieme: le relazioni tra le Aree di Processo

Nel quadro d’insieme riportato in Figura III.3 sono riportate le aree di processo

selezionate dall’azienda.

Esse sono rappresentate dai cerchi colorati e contraddistinte dal loro acronimo.

Le relazioni che intercorrono tra loro sono messe in evidenza dalle frecce (entranti,

uscenti o bidirezionali).

VALVAL

RSKMRSKM

REQMREQM

PMCPMC

TSTS

PPPP

VERVER

RDRD

MACMPPQA MAMACMCMPPQAPPQA

Figura III.3 – Le relazioni tra le Aree di Processo

Per ricavare tale quadro d’insieme siamo partiti dal ciclo di vita del prodotto

attualmente adottato in CHORUS S.r.l. , perciò le relazioni tra le aree di processo sono

scaturite da questo particolare contesto lavorativo.

Nel seguito viene riportata una breve descrizione per ognuna delle aree di processo

presente in Figura III.3.


63

CONFIGURATION MANAGEMENT (CM)

Lo scopo dell’area di processo Gestione della Configurazione (CM) è di stabilire e

mantenere l'integrità dei work product attraverso l'identificazione e il controllo dei

componenti da inserire sotto gestione della configurazione, e le verifiche (audits) di

configurazione.

L’area di processo di Gestione della Configurazione (CM) si occupa in particolare

di quanto segue:

• identificare gli item di configurazione (entità minima, all’interno della

configurazione di un sistema, che può essere univocamente identificata e

rintracciata in fasi prestabilite dello sviluppo del prodotto);

• controllare i cambiamenti agli item di configurazione;

• descrivere le regole su come creare e rilasciare le baseline a partire dagli item di

configurazione gestiti dal sistema di gestione della configurazione;

• mantenere l'integrità delle baseline;

• fornire accuratamente lo stato e la configurazione aggiornata dei dati ai

sviluppatori, agli utenti finali e ai clienti.

Le disposizioni su come condurre la gestione della configurazione devono essere

stabilite negli accordi cliente-fornitore.

La Gestione della Configurazione (CM) ha collegamenti con tutte le aree di

processo.

In particolar modo è in relazione con l’area di processo di Pianificazione del

Progetto (PP), per le informazioni riguardo i piani di sviluppo e sulle strutture di

ripartizione del lavoro, che possono essere utili per determinare gli item di configurazione,

e con l’area di processo di Monitoraggio e Controllo del Progetto (PMC) per le

informazioni riguardo le analisi di prestazioni e le azioni correttive.

MEASUREMENT AND ANALYSIS (MA)

Lo scopo dell’area di processo Misura ed Analisi (MA) è sviluppare e sostenere una

capacità di misurazione utile per supportare le informazioni gestionali.

L’area di processo di Misura ed Analisi (MA) si occupa in particolare di quanto

segue:


64

• specificare gli obiettivi di misura ed analisi adatti agli obiettivi e alle

informazioni necessarie identificate;

• specificare le misure, le tecniche di analisi e i meccanismi per la raccolta dei

dati;

• eseguire la raccolta, l’archiviazione e l'analisi dei dati ;

• fornire risultati obiettivi che possono essere usati per prendere decisioni e per

intraprendere azioni correttive appropriate.

L'integrazione delle attività di Misura ed Analisi (MA) sui processi del progetto

supporta quanto segue:

• pianificazione e stima degli obiettivi;

• tracciamento delle prestazioni attuali attraverso piani e obiettivi stabiliti;

• identificazione e risoluzione dei problemi relativi ai processi;

• fornire una base per incorporare le misure in processi aggiuntivi in futuro.

La Misura ed Analisi è oggetto delle seguenti relazioni:

• con l’area di processo Pianificazione del Progetto (PP) per le informazioni

riguardanti la stima degli attributi del progetto e delle altre informazioni di

pianificazione necessarie;

• con l’area di processo Monitoraggio e Controllo del Progetto (PMC) per le

informazioni riguardanti il monitoraggio delle informazioni necessarie sulle

prestazioni del progetto;

• con l’area di processo Gestione della Configurazione (CM) per le informazioni

riguardanti la gestione delle misure sui work product;

• con l’area di processo Sviluppo dei Requisiti (RD) per le informazioni

riguardanti i requisiti del cliente e le informazioni necessarie collegate;

• con l’area di processo Gestione dei Requisiti (REQM) per le informazioni

riguardanti la tracciabilità dei requisiti in gestione e le informazioni necessarie

collegate.

PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)

Lo scopo dell’area di processo Assicurazione Qualità di Processo e di Prodotto

(PPQA) è di fornire al personale ed all'amministrazione una comprensione obiettiva dei

processi e dei work product ad essi associati.


65

L’area di processo di Assicurazione Qualità di Processo e di Prodotto (PPQA) si

occupa in particolare di quanto segue:

• valutare obiettivamente i processi eseguiti, i work product ed i servizi,

attraverso le descrizioni, le procedure e gli standard da applicare ai processi;

• identificare e documentare i problemi di Non conformità;

• fornire risposte al personale ed ai responsabili di progetto sui risultati delle

attività di assicurazione della qualità;

• accertare che i problemi di Non Conformità siano tracciati.

Lavora in stretto contatto con l’area di processo di Pianificazione del Progetto (PP),

per le informazioni riguardanti l'identificazione dei processi e dei work product associati

che saranno valutati oggettivamente, e con l’area di processo Verifica (VER), per le

informazioni riguardanti il soddisfacimento dei requisiti specifici.

PROJECT PLANNING (PP)

Lo scopo dell’area di processo Pianificazione del Progetto (PP) è stabilire e

mantenere i piani che definiscono le attività di progetto.

Quest’area di processo comprende:

• lo sviluppo del piano di progetto;

• l’opportuna interazione con gli stakeholder;

• ottenere il commitment per il piano;

• il mantenimento del piano.

La pianificazione inizia dai requisiti, che definiscono il prodotto ed il progetto.

L’input per la stesura del piano proviene dunque dalle aree di processo della

Gestione e Sviluppo dei Requisiti (REQM e RD), che costituiscono anche la base per una

ripianificazione.

Poi, la pianificazione prevede un’attività di stima e valutazione dei work product e

task, e qui interviene l’area di processo della Soluzione Tecnica (TS), da cui deriva la

trasformazione dei requisiti nella soluzione tecnica adottata per l’esecuzione del progetto, e

da cui la pianificazione non può prescindere.

La pianificazione prosegue con la determinazione delle risorse necessarie, la

negoziazione dei commitment, la redazione di uno schedule, ed un’attenta identificazione

ed analisi dei rischi di progetto (RSKM).


66

Può essere necessaria un’iterazione di queste attività, per arrivare ad un piano di

progetto definitivo.

Questo ultimo costituisce la base per l’esecuzione ed il controllo delle attività di

progetto.

Di solito il piano necessita di varie revisioni, man mano che il progetto va avanti,

per tener conto di eventuali cambiamenti di requisiti, di stime imprecise, e di azioni

correttive.

Da qui si evidenzia una forte relazione con l’area di processo del Monitoraggio e

Controllo del Progetto (PMC).

PROJECT MONITORING AND CONTROL (PMC)

Lo scopo dell’area di processo Monitoraggio e Controllo del Progetto (PMC) è

quello di fornire una visione chiara dell’avanzamento del progetto, per ottenerne la

comprensione, in modo da poter intraprendere le opportune azioni correttive, nel caso in

cui si evidenziassero deviazioni significative dal piano.

Una deviazione è significativa se, nel caso in cui fosse lasciata inalterata,

impedirebbe il raggiungimento degli obiettivi di progetto.

Un piano di progetto ben documentato costituisce la base per monitorare le varie

attività, per valutarne e comunicarne lo stato, e per prendere azioni correttive.

L’avanzamento del progetto è determinato prima di tutto confrontando le

caratteristiche attuali di work product e task, l’effort, i costi e i tempi, con quelli stimati

presenti nel piano, in corrispondenza di determinate milestone.

Il piano di progetto deve specificare a che livello va monitorato il progetto, la

frequenza delle revisioni sullo stato di avanzamento, e le misure da utilizzare.

Da qui dunque la relazione del PMC con l’area di processo della Pianificazione del

Progetto (PP).

Quando lo stato del progetto devia in modo significativo da quello atteso, devono

essere prese le opportune azioni correttive, che possono richiedere una ripianificazione: ciò

comporta una revisione del piano originario, la definizione di nuovi accordi e/o obiettivi,

oppure l’inserimento nel piano di progetto di attività addizionali di mitigazione.


67

Siccome le azioni correttive scaturiscono sempre da attività di verifica e di

validazione del prodotto, le aree di processo di Verifica (VER) e di Validazione (VAL)

forniscono un input al PMC.

Inoltre le attività di mitigazione sono proprie dell’area di processo Gestione del

Rischio (RSKM), con cui il PMC è in stretta relazione.

REQUIREMENT DEVELOPMENT (RD)

Lo scopo dell’area di processo Sviluppo dei Requisiti (RD) è di produrre ed

analizzare i requisiti del cliente, del prodotto e dei componenti del prodotto.

Si parla quindi di una fase che si trova a monte, ovvero all’inizio del progetto,

quando bisogna capire cosa vuole il cliente, tirandone fuori dei requisiti e sviluppando

quelle specifiche che saranno utilizzate nel corso del progetto per arrivare alla

realizzazione del prodotto e dei componenti del prodotto.

Questa area di processo quindi, identificherà le necessità del cliente e li tradurrà in

requisiti di prodotto che saranno poi analizzati per produrre delle soluzioni concettuali di

più alto livello; provvederà a fornire i requisiti all’area di processo Soluzione Tecnica (TS),

che li convertirà nell’architettura di prodotto, nel disegno del componente di prodotto e nel

componente di prodotto stesso.

Allo stesso modo, l’area di processo Soluzione Tecnica (TS), provvederà ad inviare

all’area di processo Sviluppo dei Requisiti (RD) delle soluzioni alternative per produrre dei

nuovi requisiti o per farvi delle modifiche nel caso in cui quelli ricevuti non siano adeguati

o non siano realizzabili.

A questo punto, i componenti di prodotto generati, saranno combinati insieme,

quindi dovranno essere verificate le varie interfacce identificate dopo le combinazioni dei

componenti, per assicurare che incontrino i requisiti di interfaccia forniti appunto dall’area

di processo Sviluppo dei Requisiti (RD).

Quindi ci sarà anche una relazione unidirezionale verso le aree di processo Verifica

(VER) e Validazione (VAL), perché ci sarà la verifica delle interfacce e dei requisiti, e la

validazione dei prodotti, componenti di prodotto, work product e processi.

Quindi l’area di processo Sviluppo dei Requisiti (RD) dovrà fornire alle medesime

le specifiche trovate.


68

Sarà poi nuovamente compito dell’area di processo Soluzione Tecnica (TS) trovare

delle soluzioni alternative nel caso di esiti negativi delle aree di processo Verifica (VER) e

Validazione (VAL) e comunicarle alle aree relative, compresa l’area di processo Sviluppo

dei Requisiti (RD).

L’area di processo in esame avrà inoltre relazioni continue con le aree di processo:

• Gestione dei Requisiti (REQM), che provvederà a gestire i requisiti

sviluppati durante il progetto;

• Pianificazione del Progetto (PP), che farà una pianificazione del piano

anche in base ai requisiti sviluppati;

• Gestione del Rischio (RSKM) perché, nello sviluppare i requisiti, si

dovrà tenere conto anche del rischio che si potrebbe incontrare nel

progetto sviluppando le specifiche desiderate.

REQUIREMENT MANAGEMENT (REQM)

Questa area di processo deve controllare i requisiti dei prodotti e dei componenti

del prodotto del progetto, ed identificare eventuali inconsistenze fra requisiti, piani di

progetto e work product.

L’area di processo Gestione dei Requisiti (REQM) controlla la gestione di tutte le

specifiche ricevute o generate dal progetto, comprese sia quelle tecniche che non tecniche.

Quindi ci possiamo trovare in due casi, nel primo può succedere che le specifiche

arrivino già del cliente, in questo caso non occorre sviluppare i requisiti, ma serve solo

comprenderli con il cliente e gestirli (in questo caso si utilizza solo l’area di processo

Gestione dei Requisiti (REQM)).

Nel secondo caso, invece, il cliente non fornisce direttamente i requisiti ma solo le

sue necessità ed aspettative, quindi bisogna prima sviluppare i requisiti e poi in un secondo

momento gestirli (si utilizza sia l’area di processo Sviluppo dei Requisiti (RD) che

Gestione dei Requisiti (REQM)).

Quindi, come già detto, questa area di processo gestisce sia requisiti ricevuti che

vengono dal cliente, sia requisiti sviluppati direttamente dal progetto, motivo per cui avrà

relazioni continue con l’area di processo Sviluppo dei Requisiti (RD) durante tutto il

progetto.


69

I requisiti gestiti saranno successivamente forniti all’area di processo Soluzione

Tecnica (TS), che dovrà produrre i prodotti o trovare soluzioni alternative nel caso di

requisiti inadeguati, quindi ci saranno continue relazioni con l’area di processo Gestione

dei Requisiti (REQM).

L’area di processo in esame gestirà i requisiti durante tutto il progetto anche per

assicurare che i cambiamenti si riflettano sui relativi piani, e perciò avrà connessioni anche

con l’area di processo Pianificazione del Progetto (PP).

L’area di processo Gestione dei Requisiti (REQM) dovrà avere delle relazioni

anche con le aree di processo Verifica (VER) e Validazione (VAL), per verificare e

convalidare i requisiti (quindi ci sarà una relazione unidirezionale verso le medesime per

fornire appunto i requisiti); e con l’area di processo Soluzione Tecnica (TS), che

provvederà a trovare delle soluzioni alternative ed a comunicarle all’area di processo in

esame nel caso di esiti negativi da parte delle aree di processo Verifica (VER) e/o

Validazione (VAL).

L’area di processo Gestione dei Requisiti (REQM) darà dunque vita ad una

sequenza di eventi e sarà fondamentale per controllare e disciplinare le aree di processo

con le quali avrà relazioni.

RISK MANAGEMENT (RSKM)

Lo scopo di questa area di processo è quello di identificare potenziali problemi

prima che essi si verifichino, in modo tale da pianificare ed attuare attività di gestione del

rischio quando necessario, per mitigare così gli impatti negativi sul raggiungimento degli

obiettivi di progetto.

L’area di processo Gestione del Rischio (RSKM) è un processo continuo, e deve

focalizzarsi sui problemi che potrebbero mettere in pericolo il raggiungimento di obiettivi

critici.

Una gestione del rischio efficace comprende un’identificazione precoce ed

aggressiva dei rischi, mediante l’intervento degli stakeholder, tra cui deve instaurarsi un

rapporto per una libera e aperta discussione riguardante i rischi.

La gestione dei rischi deve considerare sorgenti di rischio sia interne che esterne

per costi, schedule e performance, insieme ad altri rischi.


70

Un’identificazione precoce è essenziale, perché risulta sempre più semplice, meno

costoso, e meno invasivo effettuare cambiamenti e correggere l’effort di lavoro durante le

prime fasi di progetto, piuttosto che durante le ultime.

La gestione dei rischi può essere suddivisa in tre parti:

• la definizione di una strategia di gestione del rischio

• l’identificazione ed analisi dei rischi

• la gestione dei rischi identificati, inclusa l’implementazione di piani di

mitigazione del rischio quando necessario.

Inizialmente un’organizzazione può focalizzare l’attenzione sulla semplice

identificazione dei rischi, per acquisire una consapevolezza elementare, di base, e poter

reagire nel caso in cui un rischio si verifichi.

Questa fase iniziale è descritta nelle aree di processo del PP e PMC.

L’area di processo Gestione del Rischio (RSKM), invece, costituisce un’evoluzione

rispetto all’identificazione preliminare di base appena descritta, e indica cosa fare per

pianificare, anticipare, e mitigare in modo sistematico i rischi, per minimizzarne a priori

l’impatto sul progetto.

Per quanto appena detto, è evidente la forte relazione che esiste tra l’area di

processo RSKM e le aree di processo di Sviluppo e Gestione dei Requisiti (RD e REQM)

per la fase iniziale, e con le aree di processo Pianificazione, Monitoraggio e Controllo del

Progetto (PP e PMC) lungo tutta la durata del progetto stesso.

TECHNICAL SOLUTION (TS)

L’obiettivo di questa area di processo è quello di progettare, sviluppare ed

implementare soluzioni in base a dei requisiti.

L’area di processo Soluzione Tecnica (TS) è applicabile ad ogni livello

dell’architettura di un prodotto e ad ogni prodotto, componente di prodotto o processo

correlato al ciclo di vita del prodotto.

In tutta l’area di processo, il significato dei termini “prodotto” e “componente di

prodotto” si estende anche ai servizi ed ai loro componenti.

L’area di processo Soluzione Tecnica (TS) si concentra su quel che segue:

• valutazione e selezione delle soluzioni che potenzialmente soddisfano un

definito insieme di requisiti;


71

• sviluppo dettagliato dei progetti delle soluzioni selezionate;

• implementazione dei progetti in prodotti o componenti.

Dopo aver ricevuto i requisiti dall’area di processo di Sviluppo dei Requisiti (RD),

questi vengono trasformati nell’architettura di prodotto, nei progetti di componente ed,

infine, nel prodotto stesso.

Attraverso le relazioni con le aree di processo di Verifica (VER) e Validazione

(VAL), viene assicurato che i work product soddisfino i requisiti e che i prodotti

funzionino correttamente.

Tutte le attività di questa area di processo sono pianificate, controllate e monitorate

dalle aree di processo di Pianificazione del Progetto (PP) e di Monitoraggio e Controllo del

Progetto (PMC).

VALIDATION (VAL)

L’obiettivo di questa area di processo è quello di dimostrare che un prodotto (o un

componente di prodotto) sia valido per l’utilizzo per cui è stato progettato quando viene

inserito nell’ambiente di lavoro.

L’area di processo Validazione (VAL) dimostra che un prodotto, nei casi previsti,

adempirà al suo utilizzo progettato; di contro, l’area di processo Verifica (VER) si occupa

di vedere se un work product soddisfa completamente i requisiti specificati.

In altre parole l’area di processo Verifica (VER) si assicura che “tu l’abbia costruito

correttamente”, mentre l’area di processo Validazione (VAL) si assicura che “tu abbia

costruito la cosa giusta”.

Le attività dell’area di processo Validazione (VAL) utilizzano un approccio simile

a quello dell’area di processo Verifica (VER) (ad es. test, analisi, ispezioni, dimostrazioni

o simulazioni).

Spesso gli utenti finali o altri stakeholder vengono coinvolti nelle attività dell’area

di processo Validazione (VAL).

Sia le attività dell’area di processo Verifica (VER) che quelle dell’area di processo

Validazione (VAL) spesso si svolgono simultaneamente e possono utilizzare lo stesso

ambiente.


72

Quest’area di processo lavora in stretto contatto con le aree di processo della

categoria di Engineering (TS, RD, REQM e VER), ma anche con le aree di processo di

Pianificazione e Gestione del Progetto (PP e PMC).

VERIFICATION (VER)

L’obiettivo di questa area di processo è quello di assicurare che i work product

selezionati rispettino i requisiti per loro specificati.

L’area di processo della Verifica (VER) include le seguenti attività: la preparazione

alla verifica, l’esecuzione della verifica e l’identificazione delle azioni correttive.

L’area di processo Verifica (VER) comprende la verifica del prodotto e dei work

product intermedi in base a tutti i requisiti selezionati, compresi quelli del consumatore, di

prodotto e di componente di prodotto.

In tutta l’area di processo, il significato dei termini “prodotto” e “componente di

prodotto” si estende anche ai servizi ed ai loro componenti.

L’area di processo Verifica (VER) è un processo che si svolge in maniera

incrementale durante tutte le fasi del ciclo di vita del prodotto, a partire dalla verifica dei

requisiti, passando per la verifica dei work product in lavorazione, per culminare nella

verifica del prodotto finito.

Come l’area di processo Validazione (VAL), questa area di processo lavora in

stretto contatto con le aree di processo della categoria di Engineering (TS, RD, REQM e

VAL), ma anche con le aree di processo di Pianificazione e Gestione del Progetto (PP e

PMC).

Capitolo IV Gestione della Configurazione (CM)

73

CAPITOLO IV GESTIONE DELLA

CONFIGURAZIONE (CM)

Le aree di processo di cui mi sono occupato nei mesi in azienda sono “Gestione

della Configurazione” (CM) e “Assicurazione Qualità di Processo e di Prodotto” (PPQA).

Queste due aree di processo appartengono entrambe alla Categoria Support e

svolgono una funzione di supervisione su tutte le aree di processo delle altre categorie

(Process Management, Project Management, Engineering), con la prima in riferimento

alla configurazione dei vari elementi del progetto, e la seconda in riferimento

all’assicurazione della qualità dell’intero processo produttivo e del prodotto finale.

In questo capitolo tratterò l’area di processo “Gestione della Configurazione” (CM)

e nel successivo l’area di processo “Assicurazione Qualità di Processo e di Prodotto”

(PPQA).

IV.1 Descrizione dell’Area di Processo

Lo scopo dell’area di processo Gestione della Configurazione (CM) è di stabilire e

mantenere l'integrità dei work product attraverso l'identificazione e il controllo dei

componenti da inserire sotto gestione della configurazione, e le verifiche (audits) di

configurazione.

La presente area di processo definisce dunque le modalità di gestione e le relative

responsabilità, assegnate dalla Società, per controllare e tenere traccia di tutti gli oggetti

significativi che compongono una particolare versione di un componente di prodotto o di

un prodotto inserito o meno all’interno di un Sistema, allo scopo di garantirne nel tempo la

riproducibilità, la rintracciabilità e l’integrità (entrambi requisiti indispensabili per poter

assicurare che eventuali attività di aggiornamento e/o manutenzione future possano

avvenire in modo controllato).


74

L’area di processo Gestione della Configurazione (CM) si applica a: prodotti

software, documenti richiesti per supportare un determinato prodotto, prodotti di sicurezza,

prodotti di engineering, prodotti di qualità, prodotti di configurazione e prodotti hardware.

L’area di processo di Gestione della Configurazione (CM) si occupa in particolare

di quanto segue:

• identificare gli item di configurazione (entità minima, all’interno della

configurazione di un sistema, che può essere univocamente identificata e

rintracciata in fasi prestabilite dello sviluppo del prodotto);

• stabilire un Sistema di Gestione della Configurazione (SGC)

• descrivere le regole su come creare e rilasciare le baseline a partire dagli item di

configurazione gestiti dal Sistema di Gestione della Configurazione;

• mantenere l'integrità delle baseline;

• tracciare le richieste di cambiamento agli item di configurazione

• controllare i cambiamenti agli item di configurazione;

• fornire accuratamente lo stato e la configurazione aggiornata dei dati ai

sviluppatori, agli utenti finali e ai clienti;

• effettuare le verifiche di configurazione (audits).

Le disposizioni su come condurre la gestione della configurazione devono essere

stabilite negli accordi cliente-fornitore.

L’area di processo Gestione della Configurazione (CM) ha collegamenti con tutte le

aree di processo.

In particolar modo è in relazione con l’area di processo di Pianificazione del

Progetto (PP), per le informazioni riguardo i piani di sviluppo e sulle strutture di

ripartizione del lavoro, che possono essere utili per determinare gli item di configurazione,

e con l’area di processo di Monitoraggio e Controllo del Progetto (PMC) per le

informazioni riguardo le analisi di prestazioni e le azioni correttive.

IV.2 Assessment della Gestione della Configurazione

L’assessment del lavoro in azienda, come scritto nel paragrafo III.3, è stata

effettuata tramite tabelle, create da noi stagisti, che sono state compilate mediante colloqui

ed interviste ad alcuni Project Manager.


75

Ogni tabella rappresenta una pratica specifica dell’area di processo.

Nelle righe delle tabelle sono riportati i typical work product e le sottopratiche

della pratica specifica corrispondente.

Le colonne sono formate dai seguenti campi:

1. Stato: indica semplicemente se la sottopratica è soddisfatta (S), non soddisfatta

(NS) o parzialmente soddisfatta (PS);

2. Evidenza oggettiva: indica, nel caso di esito positivo del primo campo, con che

cosa (soprattutto documenti) si è dato prova dell’effettuazione della

sottopratica, od eventuali appunti;

3. Note: questo campo contiene informazioni relative al sistema procedurale (PG

sta per Procedura Gestionale) attualmente in uso nell’azienda per soddisfare le

sottopratiche; per le procedure sono anche indicati nel dettaglio i paragrafi ed il

relativo livello di completezza.

Tramite le interviste abbiamo provveduto a riempire tutte le tabelle di ogni area di

processo che ci è stata assegnata.

I typical work product sono scritti solo a titolo informativo in quanto il CMMI li

prevede, ma i campi non sono stati riempiti perché in realtà sono solo quelli tipici richiesti

(ma ve ne potrebbero essere degli altri) e non era necessario verificarli ma solo seguirli per

comprendere meglio le sottopratiche.

Inoltre i typical work product sono automaticamente soddisfatti dal

soddisfacimento delle sottopratiche relative.

Per ogni tabella, in alto sulla sinistra, è stato riportato il progetto di riferimento sul

quale è stato effettuato l’assessment.

Di seguito sono riportate tutte le tabelle prodotte per l’area di processo Gestione

della Configurazione (CM).


76


77


78


79


80


81


82


83

IV.3 Analisi dei dati raccolti

L’analisi dei dati effettuata dopo l’assessment è stata realizzata alla luce dei dati

raccolti durante le interviste fatte per il riempimento delle tabelle sopra riportate.

Per quanto riguarda l’area di processo Gestione della Configurazione (CM), ci

siamo resi conto, con il Responsabile della Qualità, che il vecchio sistema procedurale

dell’azienda non soddisfava a pieno le sottopratiche del modello CMMI.

Infatti la procedura attualmente in uso per la Gestione della Configurazione (CM)

non focalizza tutti i punti richiesti dal CMMI.

La procedura del vecchio sistema procedurale di cui mi hanno dato evidenza i

Project Manager, per questa area di processo, è Procedura Gestionale “Gestione della

Configurazione” (PG.08A).

Questa procedura non analizza nel dettaglio tutte le sottopratiche dell’area di

processo Gestione della Configurazione (CM) e come si è visto nel paragrafo precedente

mostra numerose lacune.

A questo punto quello che si è pensato di fare è stato, in accordo con il

Responsabile della Qualità, creare ex-novo una procedura (Procedura CM.01 – Gestione

della Configurazione) che rispettasse punto per punto tutte le sottopratiche richieste dal

modello CMMI.

Di conseguenza, ho creato per la nuova procedura anche dei nuovi template, ovvero

quei documenti che bisognerà compilare, per ogni progetto, seguendo le linee guida delle

relative procedure.

Il fatto che numerose sottopratiche siano parzialmente soddisfatte, come si vede

dalle tabelle, non implica che l’area di processo si trovi ad un buon livello di capability del

CMMI, infatti, per questa area si può stimare il livello 0 di capability.

Questo perché, come spiegato nel paragrafo II.2, se non sono completamente

soddisfatte tutte le pratiche specifiche di un’area ci si trova al livello 0 di capability.

Dopo l’analisi dei dati la situazione che si presenta per le 38 sottopratiche di questa

area di processo è la seguente (Figura IV.1):


84

Figura IV.1 – Stima in % delle Sottopratiche soddisfatte per l’area Gestione della Configurazione

Capitolo V Assicurazione Qualità di Processo e di Prodotto (PPQA)

85

CAPITOLO V ASSICURAZIONE

QUALITÀ DI PROCESSO E DI

PRODOTTO (PPQA)

V.1 Descrizione dell’Area di Processo

Lo scopo dell’area di processo Assicurazione Qualità di Processo e di Prodotto

(PPQA) è di fornire al personale ed all'amministrazione una comprensione obiettiva dei

processi e dei work product ad essi associati.

L’area di processo di Assicurazione Qualità di Processo e di Prodotto (PPQA) si

occupa in particolare di quanto segue:

• valutare obiettivamente i processi eseguiti, i work product ed i servizi,

attraverso le descrizioni, le procedure e gli standard da applicare ai processi;

• identificare e documentare i problemi di Non conformità;

• accertare che i problemi di Non Conformità siano tracciati;

• comunicare e garantire la risoluzione delle Non Conformità;

• fornire risposte al personale ed ai responsabili di progetto sui risultati delle

attività di assicurazione della qualità;

• creare un archivio.

Lavora in stretto contatto con l’area di processo di Pianificazione del Progetto (PP),

per le informazioni riguardanti l'identificazione dei processi e dei work product associati

che saranno valutati oggettivamente, e con l’area di processo Verifica (VER), per le

informazioni riguardanti il soddisfacimento dei requisiti specifici.


86

In particolare le sottopratiche nell’area di processo di Assicurazione Qualità di

Processo e di Prodotto (PPQA) assicurano che i processi pianificati siano effettivamente

implementati, mentre le sottopratiche nell’area di processo Verifica (VER) assicurano che i

requisiti specificati siano soddisfatti.

Queste due aree di processo possono occasionalmente richiamare lo stesso work

product ma da differenti prospettive.

L'obiettività nell’eseguire le valutazioni richieste dall’area di processo

Assicurazione Qualità di Processo e Prodotto (PPQA) è critica per il successo del progetto.

L’obiettività è ottenuta sia tramite l’indipendenza del Responsabile della Qualità

dell’azienda dai dirigenti dell’azienda stessa, sia tramite continue verifiche sull’effettiva

applicazione delle procedure aziendali effettuate dal Responsabile della Qualità.

V.2 Valutazioni sull’Assicurazione Qualità di Processo e di Prodotto

(PPQA)

Per questa area di processo non è stato possibile eseguire un vero e proprio

assessment a causa della natura di questa area di processo.

Infatti il compito principale dell’area di processo Assicurazione Qualità di Processo

e di Prodotto (PPQA) è assicurarsi che tutti i processi siano eseguiti coerentemente al

modello CMMI e che quindi i relativi prodotti siano stati ottenuti correttamente: se ciò

risulta vero allora i prodotti ottenuti dovranno necessariamente risultare conformi alle

specifiche.

Facendo un esempio è compito dell’area di processo Verifica (VER) verificare che i

prodotti finali rispettino i requisiti per loro specificati, e per controllare ciò vengono

eseguite verifiche sul prodotto, che daranno come esito l’identificazione e successiva

messa in opera di eventuali azioni correttive sul prodotto stesso: tutto questo però, viene

fatto in pratica scrivendo una o più procedure aziendali che descrivono come implementare

tutti gli aspetti dell’area di processo Verifica (VER).

Ma è compito dell’area di processo Assicurazione Qualità di Processo e di Prodotto

(PPQA) controllare e valutare se le verifiche, l’identificazione delle azioni correttive e la

realizzazione di queste azioni correttive, siano state effettuate dal personale dell’azienda in

maniera conforme alle procedure aziendali definite: per essere ancora più precisi, se si

prevede l’emissione di un particolare documento, nel caso venga rivelata una non


87

conformità, in cui si inserisce l’azione correttiva da intraprendere, compito della PPQA è

quello di controllare se questo documento è stato emesso e se è conforme allo standard

definito nelle procedure aziendali che mettono in pratica l’area di processo VER.

I controlli e le valutazioni richieste dall’area di processo PPQA vengono eseguite

dal Responsabile della Qualità che come detto in precedenza deve essere una figura

aziendale indipendente dai vertici dell’azienda.

Questi controlli e valutazioni previsti dal PPQA, oltre a dover garantire la

risoluzione delle non conformità, hanno però bisogno di essere tracciati e necessitano di un

vero e proprio “Sistema di Gestione per la Qualità” che avrà tra le funzioni più importanti

quella di archiviare i documenti prodotti e di contenere le procedure aziendali e i template

dei vari tipi di documenti in vigore.

Si è quindi proceduto ad aggiornare il vecchio Sistema di Gestione per la Qualità

per renderlo conforme al modello CMMI.

Capitolo VI Progettazione del Nuovo Sistema Procedurale

88

CAPITOLO VI PROGETTAZIONE

DEL NUOVO SISTEMA

PROCEDURALE

In questo capitolo analizzeremo la fase in cui abbiamo dato vita ad un nuovo

sistema procedurale.

Le nuove procedure sono state create sulla base di quelle vecchie, nel caso in cui

queste ultime rispecchiassero in parte le esigenze del CMMI, e da zero, nel caso in cui è

stato necessario un riassetto totale della procedura.

In generale, i primi tre capitoli e l’ultimo sono presenti in tutte le procedure e

template relativi.

VI.1 Quadro d’insieme: il nuovo sistema procedurale

Le procedure sono state aggiornate sulla base dei dati analizzati dopo la fase

dell’assessment e sulla base del modello CMMI, ottenendo quindi le relazioni con ogni

area di processo.

Dopo l’analisi sono state prese le decisioni che hanno portato a creare delle

procedure ex-novo, o a rielaborare semplicemente le esistenti o a lasciarle invariate.

Per quanto riguarda le aree di processo a me assegnate, la conseguenza dell’analisi

effettuata sui dati è stata quella di creare una procedura ex-novo con i relativi template

(CM.01 – Gestione della Configurazione), per quanto riguarda l’area di processo Gestione

della Configurazione (CM), e aggiornare il vecchio Sistema di Gestione per la Qualità, per

quanto riguarda l’area di processo Assicurazione Qualità di Processo e di Prodotto

(PPQA).

La procedura “CM.01 – Gestione della Configurazione” e il nuovo “Sistema di

Gestione per la Qualità” saranno descritti rispettivamente nei paragrafi VI.3 e VI.4.


89

Nella Figura VI.1 sono riportate le aree di processo assegnate a noi stagisti e le

relative procedurali gestionali associate.

Dalla figura si evincono anche le sovrapposizioni tra le procedure, che nascono in

quanto più aree avranno pratiche e sottopratiche sviluppate da procedure di altre aree di

processo, e procedure che svilupperanno punti di aree di processo non strettamente

collegate; questo succede perché le procedure useranno più punti del modello CMMI per

implementare i processi e di conseguenza potranno usare più aree di processo.

Come conseguenza di ciò, questa fase è stata realizzata da noi stagisti collaborando

tutti insieme, per riuscire a capire quali sottopratiche dovessero essere sviluppate nelle

procedure assegnate agli altri colleghi piuttosto che nelle procedure assegnate a noi e

viceversa.

VALVAL

RS KM

RS KM

REQM

REQM

PMCPMC

Procedura S viluppo e Ges tione dei Requis iti

Proc edura Ges tione Offerte e Ordini di Vendita

Procedura Pianificazione e Ges tione Progetti

Procedura Ges tione Ris c hi

TSTS

PPPP

VERVER

RDRD

Procedura Progettazione S viluppo e Implementazione

Procedura Verifica e Validazione

MAMACMCM Procedura Metric he

Proc edura Ges tione della Configurazione

PPQAPPQAS is tema di Ges tione per la Qualità

Figura VI.1 – Le relazioni tra le Aree di Processo e le Procedure


90

VI.2 Scheda progetto

La scheda progetto è una scheda che è stata creata per mappare i processi del ciclo

di vita del software (norma 12207) con le aree di processo del modello CMMI, con un

rapporto 1:1 tra processo e pratica specifica.

Nell’azienda in cui abbiamo effettuato lo stage si sviluppa software, ed è per questo

motivo che è stato effettuato un mapping tra CMMI e norma 12207.

Associare il CMMI al lavoro di tutti i giorni in un’azienda, è una fase molto

importante e che richiede molta cura.

Nel nostro caso sono state trovare le relazioni tra pratiche specifiche di ogni area di

processo e processi della norma 12207, in modo da applicare a quella che è la norma

portante dell’azienda, il modello CMMI.

L’azienda seguirà la scheda per ogni progetto dall’inizio alla fine del lavoro, per

creare automaticamente un percorso da seguire per portare a termine ogni fase di ogni

attività, seguendo le linee guida delle procedure relative alle pratiche specifiche mappate

con la scheda.

Nella Figura VI.2 è riportata la scheda progetto realizzata dall’azienda, con

evidenziate le aree di processo a me assegnate.

Da notare come la norma 12207 si mappa bene con il modello CMMI.

Processi del Ciclo di Vita (norma ISO/IEC 12207)

Attività dei Processi Aree di

Processo (CMMI)

Pratiche Specifiche (CMMI)

1.1

Obtain an Understanding of Requirements Requirements

Management

1.2 Obtain Commitment to Requirements

1.1 Elicit Needs

1.2 Develop the Customer Requirements

3.1

Establish Operational Concept and Scenarios

5.1 Vendita

(Processo Primario)

Avvio


3.2 Establish a Definition of Required


91

Functionality

3.3 Analyze Requirements

3.4

Analyze Requirements to Achieve Balance

3.5 Validate Requirements

Supplier Agreement

Management 1.1

Determine Acquisition Type

Avvio

Preparazione della risposta

Contratto

Non Applicabile per il CMMI

N.A. N.A.



3.4


Risk Management TUTTE

Technical Solution 2.4

Perform Make, Buy, or Reuse Analyses

Organizational Process

Definition + IPPD

TUTTE

1.1 Estimate the Scope of the Project

1.2

Establish Estimate of Work product and Task Attribute

1.4 Determine Estimates of Effort and Cost

2.1 Establish the Budget and Schedule

2.2 Identify Project Risks

2.3 Plan for Data Management

2.4 Plan for Project Resources

5.2 Fornitura (Processo Primario)

Pianificazione

Project Planning

2.5 Plan for Needed Knowledge


92

and Skills

2.6 Plan for Project Resources

Measurement and Analysis TUTTE

1.1 Monitor Project Planning Parameters

1.2 Monitor Commitments

1.3 Monitor Project Risks

1.4 Monitor Data Management

Esecuzione e controlli

1.5 Monitor Stakeholder Involvement

1.6 Conduct Progress Reviews

Project Monitoring and

Control

1.7 Conduct Milestone Reviews

3.1 Review Plans that Affect the Project

3.2

Reconcile Work and Resource Levels

Riesami e valutazioni

Project Planning

3.3 Obtain Plan Commitment

Consegna e completamento

Non trovata sulla versione

1.2 del Manuale

CMMI

1.3 Define Project Lifecycle Project

Planning 2.7 Establish the

Project Plan Attuazione del processo Organizational

Process Definition +

IPPD

1.1 Establish Standard Processes

3.1

Establish Operational Concept and Scenarios



5.3 Sviluppo (Processo Primario)

Analisi dei requisiti del sistema

Requirements Management 1.1

Obtain an Understanding of Requirements


93

Preparazione della richiesta di offerta 1.2 Select

Suppliers

Preparazione del contratto e suo aggiornamento 1.3

Establish Supplier Agreement

2.1 Execute the Supplier Agreement

2.2

Monitor Selected Supplier Processes

Monitoraggio del fornitore

2.3

Evaluate Selected Supplier Work Products

2.4 Accept the Acquired Product Accettazione e completamento

Supplier Agreement

Management

2.5 Transitino Product

1.1

Develop Alternative Solutions and Selection Criteria

Technical Solution

1.2 Select Product-Component Solutions

1.4

Maintain Bidirectional Traceability of Requirements


1.5

Identify Inconsistencies between Project Work and Requirements


Progettazione architetturale del sistema


3.4


1.3 Manage Requirements Changes

1.4

Maintain Bidirectional Traceability of Requirements

Analisi dei requisiti del software


1.5 Identify Inconsistencies between Project Work


94

and Requirements

2.1

Establish Product and Product Component Requirements

2.2

Allocate Product Component Requirements

2.3 Identify Interface Requirements

3.2

Establish a Definition of Required Functionality


3.4 Analyze Requirements to Achieve Balance


3.5 Validate Requirements

2.1

Design the Product or Product Component

2.2 Establish a Technical Data Package

2.3 Design Interfaces Using Criteria

Technical Solution

3.2

Develop Product Support Documentation

Progettazione architetturale del software /

Progettazione di dettaglio del software

Verification 1.3

Establish Verification Procedures and Criteria

3.1 Implement the Design

Technical Solution

3.2

Develop Product Support Documentation

1.3

Establish Verification Procedures and Criteria

3.1 Perform Verification

Codifica e prova del software

Verification

3.2 Analyze Verification


95

Results

1.1 Determine Integration Sequenze

1.2

Establish the Product Integration Environment

1.3

Establish Product Integration Procedures and Criteria

2.1

Review Interface Descriptions for Completeness

Integrazione del software / Integrazione del sistema

Product Integration

2.2 Manage Interfaces

1.1 Select Products for Validation

1.2 Establish the Validation Environment

1.3

Establish Validation Procedures and Criteria

2.1 Perform Validation

Validation

2.2 Analyze Validation Results

3.1

Confirm Readiness of Product Components for Integration

3.2 Assemble Product Components

Prova di qualificazione del software / Prove di qualificazione

del sistema

3.3

Evaluate Assembled Product Components

Installazione del software

Product Integration

3.4

Package and Deliver the Product or Product Component

Assistenza delle attività di accettazione del software


1.2 del Manuale


96

CMMI

Attuazione del processo Prove durante la gestione

operativa Gestione operativa del sistema

5.4

Gestione Operativa (Processo Primario)

Supporto agli utenti

Trattata nei processi di :

Sviluppo, Risoluzione

dei Problemi, Manutenzione

Attuazione del processo Analisi dei problemi e delle

modifiche Esecuzione delle modifiche

Riesame / Accettazione delle attività di manutenzione

Migrazione

5.5 Manutenzione

(Processo Primario)

Dismissione del software


1.2 del Manuale

CMMI

Attuazione del processo Configuration Management 1.1

Identify Configuration Items


Definition + IPPD

1.1 Establish Standard Processes

Progettazione e sviluppo Process and

Product Quality

Assurance

TUTTE

Produzione 1.2

Establish a Configuration Management System

6.1 Documentazio- ne (Processo di Supporto)

Manutenzione

Attuazione del processo Identificazione della

configurazione Controllo della configurazione Registrazione dello stato della

configurazione Valutazione della configurazione

6.2

Gestione della Configurazione

(Processo di Supporto)

Gestione dei rilasci e delle consegne

Configuration Management

TUTTE

Attuazione del processo

Assicurazione del prodotto

Assicurazione del processo 6.3

Assicurazione Qualità


Assicurazione del sistema qualità

Process and Product Quality

Assurance

TUTTE

6.4 Verifica Attuazione del processo Verification TUTTE


97

(Processo di Supporto) Verifica

Attuazione del processo 6.5

Validazione (Processo di

Supporto) Validazione Validation TUTTE


Riesame della gestione del progetto

6.6

Riesame Congiunto


Riesame tecnico

Quantitative Project

Management / Integrated

Project Management

+ IPPD / Project

Monitoring and Control

TUTTE - per PMC: SP 1.6,

1.7, 2.1,

2.2, 2.3

Attuazione del processo 6.7

Verifica Ispettiva

(Processo di Supporto) Verifica ispettiva

Verification TUTTE


6.8

Risoluzione dei Problemi (Processo di

Supporto) Risoluzione del problema

Causal Analysis and Resolution /

Decision Analysis and Resolution

TUTTE

Requirements Development 2.1

Establish Product and Product Component Requirements

1.2 Obtain Commitment to Requirements

Avvio e definizione dello scopo


1.3 Manage Requirements Changes

1.1

Establish the Project's Defined Process

1.2

Use Organizational Process Assets for Planning Project Activities

1.3 Establish the Project's Work Environment

1.4 Integrate Plans

7.1 Gestione (Processo

Organizzativo)

Pianificazione

Integrated Project

Management + IPPD

1.5

Manage the Project Using the Integrated Plans


98

1.6

Contribute to the Organizational Process Assets

1.1

Establish the Project's Defined Process

2.1 Manage Stakeholder Involvement

Esecuzione e controllo

Causal Analysis and Resolution

TUTTE

Riesame e valutazione

Chiusura del processo Verification TUTTE


Definizione dell' infrastruttura


Definition + IPPD

1.6 Establish Work Environment Standards 7.2

Infrastruttura (Processo

Organizzativo) Manutenzione dell' infrastruttura Configuration

Management TUTTE

Definizione del processo

Valutazione del processo

7.3 Miglioramento

(Processo Organizzativo)

Miglioramento del processo

Organizational Process Focus

/ Organizational Innovation and Deployment /


Performance / Measurement and Analysis

TUTTE


Sviluppo del materiale di formazione 7.4

Formazione (Processo

Organizzativo) Realizzazione del piano di formazione

Organizational Training TUTTE

Figura VI.2 – Scheda Progetto


99

VI.3 Procedura: Gestione della Configurazione

VI.3.1 Descrizione della procedura

Questa procedura (CM.01 – Gestione della Configurazione) è riportata nella

Appendice A ed è stata scritta seguendo passo per passo il manuale del modello CMMI per

l’area di processo Gestione della Configurazione (CM).

I paragrafi del documento redatto sono stati divisi per pratiche specifiche e per

relative sottopratiche.

Per ogni punto è stata data una breve descrizione delle azioni da compiere per

soddisfare alla sottopratica.

Lo scopo è dunque quello di definire le modalità di gestione e le relative

responsabilità, assegnate dalla Società, per controllare e tenere traccia di tutti gli oggetti

significativi (item di configurazione) che compongono una particolare versione di un

componente di prodotto o di un prodotto inserito o meno all’interno di un Sistema, allo

scopo di garantirne nel tempo la riproducibilità, la rintracciabilità e l’integrità.

Il responsabile del progetto, nominato dal Direttore Tecnico, dovrà applicare la

presente procedura, che fornisce le indicazioni di massima da seguire, e redigere il “Piano

di Gestione della Configurazione (PGC)” del progetto che contiene le istruzioni operative

collegate alla presente procedura.

Altri documenti molto importanti sono:

• il “Giornale di Configurazione (GDC)” del progetto, che contiene la lista di

tutti gli item di configurazione (CI) e ne traccia per ognuno le richieste di

cambiamento e le modifiche apportate;

• il “Configuration Item Data List (CIDL)” che viene redatto per ogni baseline

(consegna intermedia del prodotto al cliente durante la fase di sviluppo), e

contiene la lista di tutti gli item di configurazione che fanno parte della baseline

con la descrizione per ognuno della evoluzione che ha subito.

I template del Piano di Gestione della Configurazione (PGC), del Giornale di

Configurazione (GDC) e del Configuration Item Data List (CIDL) sono riportati

rispettivamente nell’Appendice B, C, D.


100

VI.3.2 Mapping delle pratiche specifiche con la procedura

In questo paragrafo sono riportate le tabelle della fase dell’assessment però

aggiornate al nuovo sistema procedurale ed ai nuovi template.

Nelle tabelle sono date le corrispondenze tra sottopratiche, procedure gestionali e

template che saranno seguiti dall’azienda per aderire al modello CMMI.

I typical work product sono scritti solo a titolo informativo in quanto il CMMI li

prevede, ma i campi non sono stati riempiti perché in realtà sono solo quelli tipici richiesti

ma ve ne potrebbero essere degli altri, quindi non serviva verificarli ma solo seguirli per

comprendere meglio le sottopratiche.

Inoltre i typical work product sono automaticamente soddisfatti dal

soddisfacimento delle sottopratiche relative.


101


102


103


104


105


106


107


108

VI.4 Sistema di Gestione per la Qualità

Come già detto, è stato necessario aggiornare il vecchio Sistema di Gestione per la

Qualità, in riferimento all’area di processo Assicurazione Qualità di Processo e di Prodotto

(PPQA).

La struttura del nuovo “Sistema di Gestione per la Qualità” è rappresentata in

Figura VI.3 mostrandone l’alberatura fino al 3° livello.

Figura VI.3 – Alberatura del Sistema di Gestione per la Qualità

Come si nota dalla Figura VI.3, il Sistema di Gestione per la Qualità si divide in

due sottosezioni denominate Registrazioni e Struttura Documentale.

Nella sottosezione Registrazioni le cartelle più importanti sono:

• Visite Ispettive che contiene i documenti che testimoniano l’avvenuto controllo

su come vengono applicate le procedure o sulla regolarità dei vari documenti

prodotti;

• Azioni Correttive e Preventive che contiene le azioni correttive da intraprendere

nel caso in cui vengano rilevate delle non conformità;


109

• Riesami che contiene i documenti emessi dopo che siano state effettuate le

azioni correttive necessarie e la successiva verifica che la non conformità sia

stata superata.

Nella sottosezione Struttura Documentale le cartelle più importanti sono:

• Procedure che contiene tutte le procedure CM scritte per implementare il

modello CMMI (più eventuali altre procedure aziendali);

• Modelli che contiene tutti i template definiti per i vari documenti;

• Norme Cogenti che contiene le norme che devono essere applicate all’interno

dell’azienda (ad es. le norme ISO 9001 se l’azienda possiede la certificazione

ISO 9001);

• Manuale che contiene il “Manuale della Qualità” dell’azienda che ha lo scopo

di enunciare la politica per la Qualità dell’azienda stessa.

La gestione del Sistema di Gestione per la Qualità, i controlli e le valutazioni

necessarie vengono eseguite dal Responsabile della Qualità che come detto in precedenza

deve essere una figura aziendale indipendente dai vertici dell’azienda.

Conclusioni

110

CONCLUSIONI

Il nostro risultato è stato quello di essere riusciti ad ottenere un metodo

efficace, affidabile, snello, e poco dispendioso dal punto di vista temporale, che permetta a

tutto il personale aziendale, che lavora ad uno specifico progetto, di seguire ed applicare,

senza possibilità di confusione o errore, i principi del modello CMMI.

Questo metodo permetterà anche di soddisfare ogni singola sottopratica di ogni

singola area di processo, senza la necessità di fare formazione o training specifico.

L’azienda seguirà la scheda progetto (paragrafo VI.2) dall’inizio fino alla chiusura

di ogni progetto, per creare automaticamente un percorso da seguire che porti a termine

ogni fase di ogni attività, seguendo le linee guida delle procedure relative alle pratiche

specifiche mappate con la scheda progetto.

Tutto questo farà crescere e maturare dal punto di vista professionale il personale

ed ogni membro dello staff di progetto.

In conclusione presento (riutilizzando dati trovati in altri punti della tesi) per le aree

di processo a me assegnate, quella che era la situazione aziendale da cui siamo partiti e

quella a cui siamo arrivati, ovvero prima e dopo la creazione del nuovo sistema

procedurale.

Prima del nuovo sistema procedurale:

Dall’analisi effettuata sull’assessment la situazione, per l’area di processo Gestione

della Configurazione (CM), si presentava così: livello di capability 0 del CMMI e

percentuale di Sottopratiche soddisfatte dell’8%.

Su un totale di 38 sottopratiche la situazione era la seguente :

Conclusioni

111

Figura VI.4 – Stima in % delle Sottopratiche soddisfatte per l’area Gestione della Configurazione prima

del nuovo sistema procedurale

Per l’area di processo Assicurazione Qualità di Processo e di Prodotto (PPQA),

poiché non esistevano procedure che implementassero le varie aree di processo del

modello CMMI, la situazione si presentava così: livello di capability 0 del CMMI.

Dopo il nuovo sistema procedurale:

La situazione, per entrambe le aree, dopo l’adozione da parte dell’azienda del

nuovo sistema procedurale, si presenta così: livello di capability 3 del CMMI e percentuale

di Sottopratiche soddisfatte del 100%.

Figura VI.5 – Stima in % delle Sottopratiche soddisfatte per le aree Gestione della Configurazione e

Assicurazione Qualità di Processo e di Prodotto dopo l’adozione del nuovo sistema procedurale

Grazie al lavoro svolto in azienda la situazione è notevolmente migliorata, tutte le

sottopratiche delle pratiche specifiche risulteranno soddisfatte per le aree di processo

analizzate; di conseguenza abbiamo portato il livello di capability delle aree da 0 a 3, e

nello stesso tempo si sono create le basi per i livelli superiori.

Appendice A

112

APPENDICE A

Appendice A

113

Appendice A

114

Appendice A

115

Appendice A

116

Appendice A

117

Appendice A

118

Appendice A

119

Appendice A

120

Appendice A

121

Appendice A

122

Appendice A

123

Appendice A

124

Appendice A

125

Appendice A

126

Appendice A

127

Appendice A

128

Appendice B

129

APPENDICE B

Appendice C

130

APPENDICE C

Appendice C

131

Appendice C

132

Appendice C

133

Appendice C

134

Appendice C

135

Appendice C

136

Appendice C

137

Appendice C

138

Appendice C

139

Appendice D

140

APPENDICE D

Appendice D

141

Appendice D

142

Appendice D

143

Appendice D

144

Appendice D

145

Appendice D

146

Appendice D

147

Bibliografia

148

BIBLIOGRAFIA

[1] Software Engineering Institute (SEI). CMMI Web Site.

http://www.sei.cmu.edu/cmmi/cmmi.html

[2] CMMI Product Team. CMMI® for Development, Version 1.2. Pittsburgh, PA:

Software Engineering Institute, Carnegie Mellon University, Agosto 2006.

http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html

[3] CMMI Product Team. CMMISM for Systems Engineering/Software

Engineering/Integrated Product and Process Development/Supplier Sourcing,

Version 1.1 Continuous Representation. Pittsburgh, PA: Software Engineering

Institute, Carnegie Mellon University, Marzo 2002.


[4] G. Magnani. Il CMMI® (Capability Maturity Model Integration) - La valutazione

ed il miglioramento continuativo dei processi di integrazione di sistema.

[5] E. Viola. CMMI – Capability Maturity Model Integration. Roma, 25 maggio 2005.

http://www.isacaroma.it/html/ArchivioEventi-050525.html

[6] V. Tozzetti. Adozione del CMMI. Roma, 25 maggio 2005.

http://www.isacaroma.it/html/ArchivioEventi-050525.html

[7] M. Minzoni. CMMI - Ottimizzare il processo per migliorare il prodotto. MokaByte

n. 90, Novembre 2004.

http://www.mokabyte.it/2004/11/cmmi.htm

[8] D. L. Gibson, D. R. Goldenson, K. Kost. Performance Results of CMMI-Based

Process Improvement. Pittsburgh, PA: Software Engineering Institute, Carnegie

Mellon University, Agosto 2006.


[9] Software Engineering Institute (SEI). The IDEAL Model.

http://www.sei.cmu.edu/ideal/ideal.html

[10] M. Bolognani. Gestione delle società di software. Napoli: Edizioni Scientifiche

Italiane, 2003.

Bibliografia

149

[11] International Organization for Standardization. ISO 9000: Quality management

systems – Fundamentals and vocabulary. 2000.


systems – Requirements. 2000.


systems — Guidelines for performance improvements. 2000.

[14] International Organization for Standardization and International Electrotechnical

Commission. ISO/IEC 90003: Software engineering – Guidelines for the

application of ISO 9001:2000 to computer software. 2004.

[15] International Organization for Standardization and International Electrotechnical

Commission. ISO/IEC TR 12207 Information Technology – Software Life Cycle

Processes. 2003.

[16] International Organization for Standardization, International Electrotechnical

Commission. ISO/IEC 9126-1: Software engineering – Product quality – Part 1:

Quality model. 2001.

[17] North Atlantic Treaty Organization. AQAP-160 (Edition 1): NATO Integrated

Quality Requirements for Software throughout the Life Cycle. 2001.

[18] Department of Defence of United States of America. MIL-STD-498: Software

Development and Documentation. 1994.

[19] European Cooperation for Space Standardization (ECSS). ECSS-P-00A:

Standardization policy. 2000.

ANALISI E MESSA IN OPERA IN AMBITO …infocom.uniroma1.it/~robby/Tesi/D'Arduini 2006-07.pdf ·...

Documents

Transcript of ANALISI E MESSA IN OPERA IN AMBITO …infocom.uniroma1.it/~robby/Tesi/D'Arduini 2006-07.pdf ·...