ANALISI E MESSA IN OPERA IN AMBITO AZIENDALE DEL CMMI

SAPIENZA
UNIVERSITÀ DI ROMA
FACOLTÀ DI INGEGNERIA
TESI DI LAUREA SPECIALISTICA IN
INGEGNERIA ELETTRONICA
ANALISI E MESSA IN OPERA
IN AMBITO AZIENDALE DEL CMMI
(CAPABILITY MATURITY MODEL INTEGRATION):
PIANIFICAZIONE, MONITORAGGIO
E CONTROLLO DEL PROGETTO
RELATORE
LAUREANDA
CH.MO PROF. ROBERTO CUSANI
LUANA LIBERATORE
MATRICOLA 779312
ANNO ACCADEMICO 2005/2006
Indice
INDICE
INTRODUZIONE ............................................................................................... 1
1.
2.
GESTIONE DELLA QUALITA’ .............................................................. 3
1.1
IL CONTESTO ORGANIZZATIVO .....................................................................................3
1.2
STANDARD INTERNAZIONALI (ISO).............................................................................6
1.2.1
UNI EN ISO 9001: 2000 ....................................................................................7
1.2.2
UNI CEI ISO/IEC 12207: 2003 .......................................................................11
1.2.3
ISO IEC 9126-1: 2000......................................................................................13
1.3
ALTRI STANDARD (ECSS, MIL-STD-498, AQAP-160) ...........................................15
1.4
MODELLI DI MATURITÀ .............................................................................................19
1.4.1
I MODELLI CMM ...............................................................................................20
1.4.2
IL MODELLO CMMI® E LA SUA EVOLUZIONE....................................................21
1.4.3
IL CMMI: OBIETTIVI E VANTAGGI .....................................................................23
IL CAPABILITY MATURITY MODEL® INTEGRATION............... 28
2.1
I COMPONENTI DEL MODELLO ....................................................................................28
2.1.1
LE AREE DI PROCESSO ........................................................................................29
2.1.2
OBIETTIVI GENERICI ..........................................................................................35
2.1.3
PRATICHE GENERICHE .......................................................................................35
2.1.4
OBIETTIVI SPECIFICI...........................................................................................35
2.1.5
PRATICHE SPECIFICHE ........................................................................................35
2.1.6
TYPICAL WORK PRODUCT .................................................................................36
2.1.7
SOTTOPRATICHE ................................................................................................36
2.2
I LIVELLI DI CAPABILITY ............................................................................................36
2.3
I LIVELLI DI MATURITY ..............................................................................................40
2.4
LE DUE RAPPRESENTAZIONI .......................................................................................43
2.4.1
LA RAPPRESENTAZIONE SCALARE ......................................................................43
2.4.2
LA RAPPRESENTAZIONE CONTINUA ....................................................................46
2.4.3
DIFFERENZE TRA LE DUE RAPPRESENTAZIONI ....................................................47
I
Indice
2.5
3.
4.
5.
6.
APPROCCIO AZIENDALE AL CMMI ................................................ 53
3.1
OBIETTIVI AZIENDALI ................................................................................................53
3.2
ORGANIZZAZIONE DEL GRUPPO DI LAVORO ...............................................................54
3.3
FASI DEL PROGETTO E DELLA SUA MESSA IN OPERA ...................................................55
3.4
QUADRO D’INSIEME: LE RELAZIONI TRA LE AREE DI PROCESSO ................................58
PIANIFICAZIONE DEL PROGETTO.................................................. 68
4.1
DESCRIZIONE .............................................................................................................68
4.2
ASSESSMENT .............................................................................................................70
4.3
ANALISI DEI DATI RACCOLTI ......................................................................................86
MONITORAGGIO E CONTROLLO DEL PROGETTO ................... 88
5.1
ASPETTI FONDAMENTALI ...........................................................................................88
5.2
FASE DI ASSESSMENT ................................................................................................89
5.3
RISULTATI DELL’ANALISI ........................................................................................101
PROGETTAZIONE DEL NUOVO SISTEMA PROCEDURALE ... 103
6.1
QUADRO D’INSIEME: IL NUOVO SISTEMA PROCEDURALE .........................................103
6.2
PROCEDURA DI PIANIFICAZIONE E GESTIONE PROGETTI ..........................................105
6.2.1
DESCRIZIONE ...................................................................................................105
6.2.2
MAPPING DELLE PRATICHE CMMI CON LA PROCEDURA .................................106
6.3
7.
QUADRO CONCLUSIVO PER LA REGISTRAZIONE AZIENDALE .......................................50
SCHEDA PROGETTO .................................................................................................132
CONCLUSIONI ...................................................................................... 134
APPENDICI..................................................................................................... 136
APPENDICE A: PROCEDURA “PIANIFICAZIONE E GESTIONE PROGETTI”..........................136
APPENDICE B: TEMPLATE PMP (PROJECT MANAGEMENT PLAN) ..............................162
APPENDICE C: TEMPLATE PPR (PERIODICAL PROGRESS REPORT) .............................164
BIBLIOGRAFIA............................................................................................. 167
II
Introduzione
INTRODUZIONE
Attualmente esistono vari modelli, standard, metodologie e linee guida che servono a
valorizzare il modo di lavorare. Tra tutti assumono rilevanza le norme internazionali ISO ed i
modelli di maturità.
Mentre le norme ISO sono dei modelli che indicano se i processi aziendali risultano o
meno conformi agli standard, i modelli di maturità definiscono un percorso di costante
miglioramento della qualità dei processi di una organizzazione, evidenziandone anche il
livello.
Il CMMI® (Capability Maturity Model® Integration) è un modello di maturità
sviluppato dal SEI (Software Engineering Institute), che consiste di un insieme di best
practices indirizzate a migliorare i processi aziendali per l’acquisizione, lo sviluppo,
l’integrazione e la manutenzione di prodotti o servizi.
Il mio lavoro di tesi si è svolto nell’ambito di uno stage presso la CHORUS s.r.l. di
Roma, e si è inserito nella fase iniziale del percorso che l’azienda ha intrapreso per analizzare
e mettere in opera i dettami di questo moderno modello, allo scopo di perfezionare la gestione
dei propri processi aziendali, e di raggiungere il livello 3 di maturità del CMMI, previsto per
giugno 2007. Il motivo di questa decisione aziendale è che il CMMI sta divenendo un must in
ambito industriale, e viene richiesto il raggiungimento del livello 3 come requisito
indispensabile per partecipare ai bandi di gara, specialmente per quanto riguarda i
Dipartimenti della Difesa delle nazioni NATO.
Il CMMI fornisce delle indicazioni di massima molto generiche riguardanti ogni Area
di Processo, perché esso si riferisce a tipologie diverse di organizzazione, e quindi le modalità
di implementazione del modello sono lasciate all’azienda. Questo è stato il punto di partenza
del mio lavoro: cercare e trovare la maniera più semplice ed efficace per adattare ed applicare
il CMMI al particolare contesto lavorativo della CHORUS.
Ho approfondito lo studio del modello CMMI, dei suoi componenti di base, dei livelli
di capability e maturity e delle due possibili rappresentazioni del modello.
Nel periodo di stage presso l’azienda mi sono occupata personalmente di due tra le
Aree di Processo che la CHORUS ha deciso di sviluppare e migliorare: la “Pianificazione del
Progetto”, e il “Monitoraggio e Controllo del Progetto”, insieme alla Gestione dei Rischi.
1
Introduzione
Ho inizialmente svolto una fase di assessment della situazione aziendale rispetto alle
Aree suddette, effettuando delle interviste e dei colloqui con alcuni Projet Manager, seguendo
dei progetto di riferimento, ed ho riportato i risultati in una forma semplice e schematica,
utilizzando delle tabelle.
Dopo l’analisi attenta dei risultati, e in seguito a delle riunioni con il gruppo di lavoro
CMMI, è emersa la necessità di modificare in modo radicale il sistema procedurale
dell’azienda, e di svilupparne uno nuovo, che fosse pienamente rispondente ai requisiti del
modello.
Io ho ideato e redatto personalmente una nuova procedura, “Pianificazione e Gestione
Progetti”, che riporta in maniera chiara la tracciabilità con le pratiche del modello.
Il risultato di tutto il lavoro è stato il raggiungimento di un obiettivo importante, quello
del training on the job: un sistema semplice, efficace, poco costoso dal punto di vista di
impiego di risorse, per assicurare all’azienda l’aderenza al modello senza fare formazione
specifica al personale, ma creando uno strumento per assicurarsi che tutti applichino le
pratiche CMMI senza alcun errore, pur non avendo una conoscenza approfondita a riguardo.
Questo strumento è rappresentato dalla Scheda Progetto. Ogni nuovo progetto ne dovrà
prevedere una, che sarà adattata, modellata (tailorizzata) volta per volta ai singoli progetti, a
seconda delle varie esigenze del cliente e delle caratteristiche del prodotto o servizio
comissionato.
2
Gestione della Qualità
GESTIONE DELLA QUALITA’
1.
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à e la certificazione di qualità, ed i programmi di
accertamento e miglioramento della maturità del ciclo produttivo.
1.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 delle singole funzioni introducendo però forti rigidità; appare poco 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
3
Gestione della Qualità
–
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.
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
4
Gestione della Qualità
•
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 1 mostra le tre dimensioni su cui tipicamente si focalizzano le
organizzazioni: persone, procedure e metodi, ed infine tool ed apparecchiature.
Procedure e metodi
che definiscono le
relazioni tra i task
PROCESSO
Persone con
skill, training
Tool ed
apparecchiature
e motivazione
Figura 1.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.
5
Gestione della Qualità
1.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) 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).
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.
6
Gestione della Qualità
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
1.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
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.
7
Gestione della Qualità
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;
-
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 quelli a reale valore aggiunto per una organizzazione, in particolare su
quei processi di cui 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 per la Gestione della 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.
8
Gestione della Qualità
Figura 1.2 – Un Sistema di Gestione per la Qualità secondo la ISO 9001
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,
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.iqnetcertification.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).
9
Gestione della Qualità
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). 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 (Information
Communication Technology), 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à.
10
Gestione della Qualità
1.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 la parte software contenuta nel 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.
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,
alla parte software contenuta nel firmware, sia sviluppata 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.
11
Gestione della Qualità
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. 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.
12
Gestione della Qualità
Figura 1.3 – I processi della ISO 12207.
1.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.
13
Gestione della Qualità
Quanto definito dalla 9126 è applicabile a qualsiasi tipo di software (Custom o
COTS).
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 91261 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 utiizzate, 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.
14
Gestione della Qualità
La qualità in uso è rappresentata da 4 caratteristiche, che rappresentano il punto di
vista dell’utente sul software. 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, Custom, COTS, incluso il
"firmware". 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.
1.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 Stadardization) rappresenta un impegno
congiunto dell’ESA (European Space Agency), delle Agenzie Spaziali Nazionali 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
15
Gestione della Qualità
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 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;
16
Gestione della Qualità
•
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.
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, reingegnerrizzazione,
manutenzione, e tutte le altre attività che riguardano i prodotti software.
17
Gestione della Qualità
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;
•
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 anche la porzione software del firmware.
18
Gestione della Qualità
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 immerso (embedded) in un sistema e/o un 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;
•
Requisiti specifici della NATO, dovuti al fatto che l’acquisizione avviene in un
contesto NATO.
1.4 Modelli di Maturità
Nel paragrafo 1.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:
19
Gestione della Qualità
–
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 Malcolm Bridge National Quality Award (MBA), ed il Capability Maturity Model (CMM).
1.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
•
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
20
Gestione della Qualità
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. 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’IPDCMM.
1.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
21
Gestione della Qualità
specifica area di interesse. Una costellazione può produrre uno o più modelli CMMI correlati,
insieme ai relativi materiali di training ed appraisal (processo di autovalutazone 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”.
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, manufatturiera
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;
22
Gestione della Qualità
•
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.
STORIA DEI CMM
CMM for Software
Systems Engineering
v1.1 (1993)
CMM v1.1 (1995)
INCOSE SECAM
(1996)
Integrated Product
Software CMM
EIA 731 SECM
Development CMM
v2, draft C (1997)
(1998)
(1997)
v1.02 (2000)
v1.1 (2002)
CMMI for
CMMI for
CMMI for
Acquisition
Development
Services
Figura 1.4 – Storia dei CMM.
1.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
23
Gestione della Qualità
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 ondemand, 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,
www.sei.cmu.edu). 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 Defence 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
24
Gestione della Qualità
•
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 ri-lavorazione
-
Aumentando la produttività dei processi
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 (Software Enginnering Institute) ad agosto 2006, ed
è quello a cui faremo riferimento (www.sei.cmu.edu/cmmi/results.html). 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 di performance 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. Sono
25
Gestione della Qualità
state rilevate delle riduzioni nei costi della qualità, costi di rilavorazone, 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 seguente tabella, e sono espressi in termini di
cambiamenti su intervalli di tempo variabili:
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%
4.0 : 1
22
1.7 : 1
27.7 : 1
ROI (Return on
Investment)
Tabella 1: Riassunto dei risultati di performance del CMMI.
26
Gestione della Qualità
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
miglioramenti degli altri parametri.
La seguente figura 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.
TASSO DI
TASSO DI ERRORE
PRODUTTIVITA’
Figura 1.5: Performance di produttività e di qualità del software per la Lockheed Martin.
27
Il Capability Maturity Model Integration
2.
Il CAPABILITY MATURITY MODEL®
INTEGRATION
Il CMMI (Capability Maturity Model® Integration) è un modello che fornisce uno
strumento per creare un punto d’integrazione tra varie discipline. Come già detto, 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.
Possiamo analizzare nel dettaglio le parole che compongono l’acronimo CMMI:
•
Capability: si riferisce all’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 dell’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 ovvero modificarlo, in risposta a necessità che si
presentano.
•
Model: insieme di descrizioni di processi da adattare alle diverse realtà aziendali;
fornisce quindi modelli che aiutino le aziende nello sviluppo dei propri servizi e
prodotti.
•
Integration: si riferisce all’integrazione di più discipline, e al fatto che il CMMI
costituisce un modello integrato rispetto a quelli precedenti (CMM).
2.1 I componenti del modello
Di seguito viene riportata la struttura generale del modello CMMI, illustrandone le
relazioni tra i vari componenti:
28
Il Capability Maturity Model Integration
Figura 2.1 - Struttura generale del modello CMMI.
2.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 ed in obiettivi
generici: per raggiungere tali obiettivi devono essere svolte delle attività, di cui alcune relative
agli obiettivi specifici (e allora si parla di pratiche specifiche), altre relative agli obiettivi
generici (pratiche generiche).
Le pratiche generiche (generic practices) in particolare sono un indicatore del livello
di istituzionalizzazione del processo e sono associate ai livelli di capability (vedere paragrafo
2.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.
29
Il Capability Maturity Model Integration
Le pratiche specifiche invece riguardano le attività che devono essere implementate
per una specifica area di processo e sono specifiche del dominio dell’area di processo.
Nell’ultima versione del CMMI (la 1.2), le aree di processo sono in totale 22; nella
versione precedente invece erano 25. Sono riportate di seguito, 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)
Le aree di processo possono essere raggruppate in quattro categorie: Process
Management, Project Management, Engineering e Support.
30
Il Capability Maturity Model Integration
Process Management
La categoria Process Management comprende le aree di processo riguardanti le
attività di 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:
Categoria
Area di
Processo
Organizational
Process Focus (OPF)
Organizational
Process Definition
+IPPD (OPD+IPPD)
Process
Management
Descrizione
Identificazione, pianificazione, coordinamento e
implementazione del miglioramento.
Sviluppo e mantenimento del set di standard
aziendali di processo e di prodotto.
Organizational
Identificazione delle necessità di formazione e di
Training (OT)
sviluppo/rilascio della formazione.
Organizational
Determinazione degli obiettivi quantitativi per la
Process Performance
qualità e per le performance dei vari processi
(OPP)
implementati dagli obiettivi di business.
Organizational
Selezione ed implementazione di miglioramenti
Innovation and
incrementali ed innovativi, per generare benefici,
Deployment (OID)
gestendo l’inversione in modo quantitativo.
Figura 2.2 - Aree di processo della categoria Process Management.
31
Il Capability Maturity Model Integration
Project Management
La categoria Project Management comprende le aree di processo riguardanti le attività
di gestione del progetto che hanno lo scopo di pianificare, monitorare e controllare il progetto
stesso. Le aree di processo della categoria Project Management sono quelle della tabella
seguente.
Categoria
Area di Processo
Project Planning
(PP)
Project Monitoring
and Control (PMC)
Descrizione
Definizione e mantenimento di un piano di progetto,
coinvolgendo gli stakeholder adeguati, ed ottenendo
il commitment per le attività da svolgere.
Controllo del progresso del progetto rispetto al
piano, prendendo ove necessario azioni correttive e
preventive.
Selezione e gestione efficace dei sub-fornitori
Supplier Agreement
Management
(SAM)
mediante la definizione di un contratto tra le parti che
consenta una pianificazione ed un monitoraggio delle
attività e delle performance del sub-fornitore.
Revisioni e test di accettazione svolti in accordo con i
requisiti contrattuali.
Project
Definizione e selezione di un processo per ogni
Management
Integrated Project
Management
+IPPD
(IPM+IPPD)
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)
Quantitative Project
Management
(QPM)
Approccio continuativo alla gestione dei rischi
associati al progetto attraverso una identificazione dei
parametri e delle classificazioni dei rischi.
Applicazione di tecniche quantitative e statistiche per
gestire la performance e la qualità di un prodotto.
Figura 2.3 - Aree di processo della categoria Project Management.
32
Il Capability Maturity Model Integration
Engineering
La categoria Engineering comprende 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 alla realizzazione di qualsiasi
prodotto o servizio nella fase di sviluppo (per esempio prodotti software e hardware, servizi,
processi). Inoltre le aree di processo dell’Engineering forniscono il fondamento tecnico
dell’IPPD. Le aree di processo della categoria Engineering sono le seguenti:
Categoria
Area di Processo
Descrizione
Identificazione delle necessità del cliente e
Requirements
Development (RD)
relativa traduzione in requisiti di prodotto, con
una soluzione concettuale di alto livello per
ciascuna disciplina coinvolta, e sviluppo di
una architettura funzionale preliminare.
Gestione dei requisiti con un costante
Requirements
Management (REQM)
allineamento ai piani di progetto attraverso
un’efficace
gestione
delle
modifiche
e
rintracciabilità dei requisiti, dal cliente sino al
prodotto finale.
Sviluppo dei componenti e dati tecnici
Engineering
associati
per
Technical Solution (TS) attraverso
la
la
successiva
valutazione
integrazione
di
soluzioni
alternative (vedere Decision Analysis and
Resolution).
Product Integration (PI)
Implementazione della migliore strategia per
l’integrazione dei componenti.
Controllo della conformità con i requisiti
Verification (VER)
specificati per ciascun prodotto intermedio
selezionato.
Controllo della validità del prodotto, dei
Validation (VAL)
prodotti intermedi e dei processi rispetto alla
necessità del cliente.
Figura 2.4 - Aree di processo della categoria Engineering.
33
Il Capability Maturity Model Integration
Support
La categoria Support comprende le Aree di processo riguardanti le attività che
supportano lo sviluppo e la manutenzione del prodotto.
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.
Le aree di processo della categoria Support sono le seguenti:
Categoria
Area di Processo
Configuration
Management (CM)
Process and
Product Quality
Assurance (PPQA)
Descrizione
Supporto a tutte le aree di processo nel definire e
mantenere l’integrità dei prodotti (prodotti intermedi
acquisiti o sviluppati internamente) e dei tool.
Supporto a tutte le aree di processo per l’obiettiva
valutazione dei processi, dei prodotti e dei prodotti
intermedi rispetto agli standard ed alle procedure
applicabili.
Supporto a tutte le aree di processo per guidare i
progetti e l’organizzazione nell’allineamento delle
Support
Measurement and
necessità e degli obiettivi di misurazione con
Analysis (MA)
l’approccio alla misurazione, questo al fine di usare i
risultati delle misurazioni per aspetti informativi o
prendere appropriate azioni correttive.
Decision Analysis
and
Resolution
(DAR)
Causal
and
(CAR)
Supporto a tutte le aree di processo nello strutturare
un processo di “decision making” per garantire che le
possibili
alternative siano
confrontabili
e
per
garantire la più adeguata selezione tra queste ultime.
Analysis
Resolution
Analisi progettuale delle cause comuni di variazione
inerenti ai processi al fine di rimuoverle e definire la
base conoscitiva per migliorare continuativamente gli
standard di processo dell’organizzazione.
Figura 2.5 - Aree di processo della categoria Support.
34
Il Capability Maturity Model Integration
Ora passiamo alla descrizione dettagliata dei vari componenti di un’area di processo.
2.1.2 Obiettivi generici
Questi obiettivi sono detti “generici” poiché lo stesso obiettivo deve essere applicato
genericamente ed indistintamente a tutte le aree di processo. Un obiettivo generico descrive le
caratteristiche
che
devono
essere
presenti
per
istituzionalizzare
i
processi
che
implementeranno un’area di processo. Un obiettivo generico è un componente del modello,
che viene richiesto ed utilizzato nelle valutazioni, per determinare se un’area di processo
soddisfa i requisiti del CMMI.
2.1.3 Pratiche generiche
Le pratiche generiche sono associate agli obiettivi generici e, come questi ultimi, 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 e per la fornitura dei servizi del processo”.
2.1.4 Obiettivi specifici
Un obiettivo specifico descrive le caratteristiche uniche che devono essere presenti per
soddisfare una specifica area di processo. Un obiettivo è un componente del modello, che è
richiesto ed usato nelle valutazioni per determinare se un’area di processo soddisfa i requisiti
del CMMI.
Per esempio, un obiettivo specifico dell’area di processo “Gestione della
Configurazione” (CM) è “Stabilire e mantenere l’integrità delle baseline”.
2.1.5 Pratiche specifiche
Le pratiche specifiche sono associate ad una specifica area di processo. Una pratica
specifica è la descrizione di un’attività che è ritenuta importante nel realizzare l’obiettivo
35
Il Capability Maturity Model Integration
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” (PMC) è “Monitorare i parametri della pianificazione del progetto”.
2.1.6 Typical Work Product
I Typical Work Product costituiscono l’output di una pratica specifica, e cioè dei
risultati attesi dopo l’attuazione della pratica. Sono denominati typical perché spesso esistono
altri work product possibili, ma che non sono elencati. Ad 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”.
2.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 considerate come norme da seguire, ma di fatto hanno l’unico scopo di fornire
indicazioni utili per migliorare il processo. Per esempio, un 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”.
2.2 I livelli di capability
Nel modello CMMI si usano dei livelli per descrivere un percorso di evoluzione
raccomandato per un’organizzazione che voglia migliorare i processi utilizzati per sviluppare
e mantenere i propri prodotti e servizi.
Il
CMMI
supporta
due
percorsi
di
miglioramento,
uno
per
migliorare
progressivamente i processi corrispondenti ad una o più aree di processo scelte
dall’organizzazione, l’altro permette alle organizzazioni di migliorare un insieme di processi
correlati occupandosi gradualmente di insiemi di aree di processo successive.
36
Il Capability Maturity Model Integration
Questi due percorsi di miglioramento, che corrispondono alle due rappresentazioni
possibili di questo modello (che vedremo successivamente) vengono associati ai due tipi di
livelli possibili: i livelli di capability e i livelli di maturity. In entrambi i casi il concetto di
livello è lo stesso. Infatti i livelli caratterizzano l’evoluzione da uno stato mal definito verso
uno in cui si utilizzano informazioni quantitative per determinare e gestire i miglioramenti
necessari per raggiungere gli obiettivi di business di un’organizzazione.
Per arrivare ad un particolare livello, un’organizzazione deve raggiungere tutti gli
opportuni obiettivi dell’area di processo o dell’insieme di aree di processo selezionate per
ottenere il miglioramento voluto, indipendentemente dal fatto che si tratti di un livello di
capability o di maturity: in sostanza, sia i livelli di capability che di maturity forniscono un
modo per misurare quanto efficientemente un’organizzazione può migliorare i propri processi,
e quanto effettivamente li migliora, anche se l’approccio al miglioramento rimane differente
per i due tipi di livello.
Il CMMI fornisce per ciascuna area di processo dei 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 i connotati di quelli più in basso.
Ciascuna area di processo prevede 6 livelli di capability (da 0 a 5), che vengono
conseguiti mettendo in atto attività via via più evolute:
0. Incomplete
1. Performed
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
Ogni
area
di
processo
è
valutata
secondo
il
proprio
capability
level.
Un’organizzazione, probabilmente, avrà aree di processo diverse stimate a differenti livelli di
37
Il Capability Maturity Model Integration
capability. Il risultato di questa stima può essere riferito con il nome di Capability Profile,
come si vede nella figura seguente.
Livelli di capability
5
4
3
2
1
0
Area 1
Area 2
Area 3
Area 4
Aree di processo
Figura 2.6 - 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” (performed) è tale quando soddisfa gli obiettivi specifici
dell’area di processo. Questo livello supporta e permette le attività necessarie per produrre i
prodotti di lavoro (work product).
Benché il processo “eseguito” abbia per risultato dei miglioramenti importanti, questi
potrebbero essere persi nel tempo se non vengono istituzionalizzati. L’istituzionalizzazione
38
Il Capability Maturity Model Integration
(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” (managed) è un processo “eseguito” (livello di capability 1) che
ha le infrastrutture di base per essere supportato. Viene organizzato ed eseguito secondo
alcune regole; impiega persone competenti che abbiano adeguate conoscenze per produrre dei
risultati controllati; coinvolge gli stakeholder relativi (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” (defined) è un processo “gestito” (livello di capability 2) 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 del processo.
La differenza principale tra il livello 2 ed il livello 3 è il campo di applicazione degli
standard, delle descrizioni del processo e delle procedure. Nel livello 2 questi punti possono
essere un po’ diversi in ogni specifica istanza del processo (e.g., in un particolare progetto).
Nel livello 3, invece, gli standard, le descrizioni del processo e le procedure 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 di capability 3 i processi sono tipicamente descritti
in modo più rigoroso rispetto al livello 2. Un 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. Il livello 3 quindi gestisce i processi in maniera preventiva,
utilizzando una comprensione delle relazioni tra le attività di processo e misure dettagliate sul
processo, sui suoi work product, e sui suoi servizi.
Livello 4: Quantitatively Managed
In questo caso il processo è un processo “definito” (livello di capability 3) che viene
controllato utilizzando tecniche statistiche, o altre tecniche quantitative.
39
Il Capability Maturity Model Integration
Vengono stabiliti obiettivi quantitativi per la performance di qualità e di processo, ed
utilizzati come criteri di gestione del processo stesso. 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,
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.
2.3 I livelli di maturity
Un livello di maturity (Maturity Level - ML) consiste in un’insieme di pratiche
specifiche e generiche correlate, per un predefinito insieme di aree di processo, che
miglioreranno la performance globale dell’azienda. Il livello di maturity dell’organizzazione
fornisce una strada per prevedere la performance in una data disciplina o insieme di
discipline.
Ciascun livello di maturity sviluppa e completa un importante sottoinsieme di
processi, preparandolo ad avanzare verso il livello di maturity successivo. I livelli di maturity
vengono misurati mediante il raggiungimento degli obiettivi generici e specifici associati ad
ogni predefinito insieme di aree di processo.
Le aree di processo possono anche essere raggruppate secondo i 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 di management, poi a quelli di
ingegneria, fino a quelli di controllo statistico della progettazione e di miglioramento continuo
dei processi.
40
Il Capability Maturity Model Integration
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 un’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 livelli di capability e i livelli di maturity utilizzano intenzionalmente
gli stessi termini per definire i livelli dal 2 al 5, perché i concetti di capability e maturity sono
complementari. I livelli di maturity sono utilizzati per caratterizzare il miglioramento
dell’organizzazione relativo ad un insieme di aree di processo, e quelli di capability
caratterizzano il miglioramento 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 alle 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 supera il budget e non si rispetta il programma
(schedule).
Livello 2: Managed
A questo livello i progetti dell’organizzazione hanno l’assicurazione che i processi
siano pianificati e gestiti secondo regole stabilite. I progetti impiegano persone competenti
che hanno risorse adeguate per produrre output controllati; coinvolgono gli stakeholder; sono
monitorati, controllati e revisionati.
Questo livello di maturity aiuta ad assicurare che le pratiche esistenti siano mantenute
nel tempo. I progetti saranno eseguiti e gestiti secondo i piani documentati e gli impegni
stabiliti con gli stakeholder.
41
Il Capability Maturity Model Integration
Livello 3: Defined
A questo livello si ottiene una buona comprensione e caratterizzazione dei processi,
che sono descritti mediante standard, procedure, tool e metodi. L’insieme di processi
standard, che costituisce la base del livello di maturity 3, viene stabilito e migliorato nel
tempo.
I progetti stabiliscono i loro processi definiti tailorizzando l’insieme dei processi
standard dell’organizzazione, in accordo con le linee guida del tailoring.
La differenza principale tra il livello 2 ed il livello 3 di maturity è il campo di
applicazione degli standard, delle descrizioni del processo e delle procedure. Nel livello 2
questi punti possono essere un po’ diversi in ogni specifica istanza del processo (e.g., in un
particolare progetto). Nel livello 3, invece, gli standard, le descrizioni del processo e le
procedure 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 modo più
rigoroso 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, utilizzando una
comprensione delle relazioni tra le attività di processo e misure dettagliate sul processo, sui
suoi work product, e sui suoi servizi.
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 obiettivi quantitativi per la
performance della qualità e dei processi e li utilizzano come criteri di gestione. Gli obiettivi
quantitativi sono basati sulle necessità del cliente, degli utenti finali, dell’organizzazione e di
chi implementa il processo. La performance del processo e della qualità è intesa in termini
statistici ed è gestita lungo tutta la vita dei processi.
La differenza maggiore tra il livello di maturity 3 e 4 sta nella capacità di prevedere la
performance del processo. Al livello 4 di maturity, la performance dei processi è controllata
attraverso tecniche statistiche, ed altre tecniche quantitative, ed è quantitativamente
prevedibile. Al livello 3, invece, i processi sono prevedibili solo qualitativamente.
42
Il Capability Maturity Model Integration
Livello 5: Optimizing
A questo livello l’azienda migliora i suoi processi in maniera continua, e questi sono
basati su una comprensione quantitativa delle più comuni cause di variazione di un processo.
Questo livello di maturity si focalizza su un continuo miglioramento della performance 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 di maturity 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 migliorarne la performance e per raggiungere gli obiettivi
quantitativi di miglioramento.
2.4 Le due rappresentazioni
Il CMMI prevede 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 comprendere e controllare il
processo. Questo approccio sta alla base della rappresentazione scalare. L'altro approccio
possibile, la rappresentazione continua, si focalizza sul processo singolo, lasciando
all'Organizzazione la possibilità di definire su quali processi applicare il modello.
L'utilizzo dello standard CMMI ci pone davanti ad una scelta: utilizzare la
rappresentazione continua o scalare.
2.4.1 La rappresentazione scalare
La rappresentazione scalare (staged representation) utilizza i livelli di maturity 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 livelli di maturity. Ognuno
di questi livelli comprende un insieme di aree di processo che indicano dove focalizzarsi per
migliorare il processo aziendale. Quindi le aree di processo nella rappresentazione scalare
sono raggruppate per livelli di maturity, che indicano dunque quali sono le aree di processo da
implementare per raggiungere ciascun livello. Ogni area di processo è descritta in termini di
pratiche che contribuiscono a raggiungere gli obiettivi. Le pratiche descrivono l'infrastruttura
43
Il Capability Maturity Model Integration
e le attività che concorrono all'effettiva implementazione ed istituzionalizzazione delle aree di
processo. I progressi sono misurati in termini di raggiungimento degli obiettivi di ogni area di
processo presente in un particolare livello di maturity.
Figura 2.7 - Struttura della rappresentazione scalare.
La figura seguente mostra come sono raggruppate le aree di processo nella
rappresentazione scalare, ovvero per livello di maturity.
Maturity Level 5
Maturity Level 4
Maturity Level 3
Maturity Level 2
CM
PPQA
MA
SAM
PMC
PP
REQM
= Aree di processo selezionate per raggiungere il livello di maturità 3.
Figura 2.8 - Aree di processo nella rappresentazione scalare.
44
Il Capability Maturity Model Integration
Per esempio, al livello 2 di maturity, esiste un insieme di aree di processo che
un’organizzazione deve utilizzare per guidare il proprio processo di miglioramento, fino a
raggiungere tutti gli obiettivi di tutte queste aree di processo. Una volta che il livello 2 di
maturity sia stato raggiunto in questo modo, l’organizzazione focalizzerà la sua attenzione
sulle aree di processo del livello 3, e così via.
Nella tabella seguente sono presentate le aree di processo con il relativo livello di
maturity.
Nome
Acronimo
Maturity
Level
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
Figura 2.9 - Aree di processo per maturity level.
45
Il Capability Maturity Model Integration
2.4.2 La rappresentazione continua
La rappresentazione continua utilizza i livelli di capability 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. Una volta che
l’organizzazione ha selezionato una o più aree di processo, deve anche decidere quanto vuole
sviluppare i processi associati a queste aree.
Le pratiche generiche sono raggruppate in livelli di capability. Ogni area di processo è
istituzionalizzata implementando le sue pratiche generiche.
I livelli di capability, quindi, si applicano al raggiungimento del miglioramento del
processo nelle singole aree, e questa rappresentazione si occupa appunto di selezionare una
particolare area di processo per migliorarla e raggiungerne il livello di capability desiderato.
Figura 2.10 - Struttura della rappresentazione continua.
46
Il Capability Maturity Model Integration
La figura seguente mostra come le aree di processo vengono utilizzate nella
rappresentazione continua.
Livelli di capability
5
4
3
2
1
0
Area 1
Area 2
Area 3
Area 4
Aree di processo
Figura 2.11 - Aree di processo nella rappresentazione continua.
2.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 seguente riassume le differenze tra la rappresentazione continua e la
rappresentazione scalare.
47
Il Capability Maturity Model Integration
Rappresentazione Continua
Rappresentazione Scalare
L’azienda seleziona le aree di L’azienda seleziona le aree di
processo e i livelli di capability processo basate sui maturity
basati sui propri obiettivi di level.
miglioramento del processo.
I progessi sono misurati I progressi sono misurati
usando i capability level, che:
usando i maturity level, che:
•
•
Misurano
l’istituzionalizzazione
(maturity)
di
un
particolare
processo
nell’azienda.
Vanno da 0 a 5.
I profili dei capability level
sono usati per raggiungere e
tracciare l’esecuzione del
miglioramento dei processi.
•
•
Misurano
l’istituzionalizzazione
(maturity) di un insieme
di processi nell’azienda.
Vanno da 1 a 5.
I maturity level sono usati per
raggiungere
e
tracciare
l’esecuzione
del
miglioramento dei processi.
L’Equivalent
Staging Non c’è necessità di un
(equivalente scalare) permette meccanismo di equivalenza per
ad
un’organizzazione
di tornare all’approccio continuo.
utilizzare l’approccio continuo
al miglioramento del processo,
per derivare un livello di
maturity come parte di un
appraisal (autovalutazione).
Figura 2.12 - Comparazione tra rappresentazione continua e scalare.
Dopo aver visto, per ogni singola rappresentazione, come sono utilizzate le aree di
processo, illustriamo anche come sono impiegate le pratiche generiche (Generic Practice GP) e gli obiettivi generici (Generic Goal - GG).
Come dimostra la figura seguente, nella rappresentazione continua sono utilizzati tutti
i GG e le GP, ed il livello di capability che si vuole raggiungere per il miglioramento
determinerà quali GG e GP saranno applicati all’area di processo selezionata dall’azienda.
Nella rappresentazione scalare, invece, come si evince sempre dalla figura, sono usati solo i
GG 2 e 3, infatti sono evidenziati solo questi ultimi e le loro relative GP.
48
Il Capability Maturity Model Integration
GG 1
GG 2
GG 3
GG 4
GG 5
GP 1.1
GP 2.1
GP 3.1
GP 4.1
GP 5.1
GP 2.2
GP 3.2
GP 4.2
GP 5.2
GP 2.3
GP 2.4
GP 2.5
GP 2.6
GP 2.7
GP 2.8
GP 2.9
GP usate nella rappresentazione scalare
GP 2.10
Figura 2.13 - Pratiche Generiche ed Obiettivi Generici.
I GG 4 e 5, e le relative pratiche generiche, non sono usati, perché non tutti i processi
supereranno lo stato di processo “definito”. Infatti soltanto alcuni processi e sottoprocessi
diverranno “Quantitatively Managed” e “Optimizing”, ovvero quelli individuati dalle aree di
processo ai livelli 4 e 5 di maturity.
Inoltre, se per esempio un’organizzazione ha raggiunto il livello 2 di maturity, per
arrivare al livello 3 dovrà riprendere in considerazione le aree di processo del livello 2 e
applicarvi l’obiettivo generico 3 e tutte le sue pratiche generiche.
Ci sono tre fattori che influenzano la decisione di adottare una rappresentazione
piuttosto che l’altra, e sono: business, cultura e legacy (eredità).
Per il primo fattore (business), si può dire che in un’azienda in cui si ha una
conoscenza consolidata 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. Mentre se l’azienda decide di migliorare i propri
49
Il Capability Maturity Model Integration
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, perché le fornirebbe le linee guida per riconoscere l’ordine in cui i
cambiamenti dovrebbero accadere.
Infine, se un'organizzazione ha già esperienza nell’adozione di un altro modello (per
esempio un CMM) che utilizza 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 risorse e 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 risultati equivalenti. Di
conseguenza, un'Azienda può trovare utilità in entrambe le rappresentazioni, e definire un
programma di miglioramento che utilizzi i principi sia della rappresentazione scalare che
continua.
2.5 Quadro conclusivo per la registrazione aziendale
Riassumendo il discorso sui livelli, possiamo dire che il concetto di “maturity” si
riferisce all’intera Organizzazione, non alla singola area di processo (per la quale è definito il
concetto di “capability”).
Quindi, a questo punto, possiamo schematizzare le condizioni richieste per il
raggiungimento della registrazione di maturity aziendale del modello CMMI:
•
Per raggiungere il livello di maturity 2, tutte le aree di processo assegnate a
quel livello di maturity 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
livelli di maturity 2 e 3 devono raggiungere il livello di capability 3 (entrambe
le rappresentazioni) o superiore (solo rappresentazione continua);
50
Il Capability Maturity Model Integration
•
Per raggiungere il livello di maturity 4, tutte le aree di processo assegnate ai
livelli di maturity 2, 3 e 4 devono raggiungere il livello di capability 3
(entrambe le rappresentazioni) o superiore (solo rappresentazione continua);
•
Per raggiungere il livello di maturity 5, tutte le aree di processo assegnate ai
livelli di maturity 2, 3, 4 e 5 devono raggiungere il livello di capability 3
(entrambe le rappresentazioni) o superiore (solo rappresentazione continua).
Quindi i livelli di capability 4 e 5 non sono obbligatori per il raggiungimento delle
corrispondenti maturity, però alcune aziende potrebbero voler alzare il livello di capability 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 2.2), che darà la
stima delle aree di processo che si troveranno a differenti livelli di capability.
Questo aspetto del modello CMMI però, riguarda solamente le aziende che utilizzano
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 2.4.3, i GG di
più alto livello (4 e 5), corrispondenti ai relativi livelli di capability (4 e 5), sono usati solo
nella rappresentazione continua, quindi volendo aumentare e portare il livello di capability di
alcune aree di processo oltre il 3, non sarebbe neanche possibile per le aziende che adottano la
rappresentazione scalare.
La figura seguente mostra una sintesi dei profili raggiungibili (Target Profile) per i
maturity level (ML) dal 2 al 5; ogni area annerita nelle colonne del capability level (CL)
rappresenta un profilo che è equivalente al livello di maturity.
51
Il Capability Maturity Model Integration
Nome
Acronimo
ML
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
Assurance
PPQA
2
Configuration Management
CM
2
Requirements Development
RD
3
Technical Solution
TS
3
Product Integration
PI
3
Verification
VER
3
Validation
VAL
3
Organizational Process Focus
OPF
3
Organizational
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
Performance
OPP
4
Quantitative Project Management
QPM
4
Organizational Innovation and
Deployment
OID
5
Causal Analysis and Resolution
CAR
5
Product Quality
Process
Process
CL1
CL2
CL3
CL4
CL5
Target
Profile 2
Target
Profile 3
Target
Profile 4
Target
Profile 5
Figura 2.14 - Target Profile.
52
Approccio aziendale al CMMI
3.
APPROCCIO AZIENDALE AL CMMI
3.1 Obiettivi aziendali
La CHORUS S.p.A. è 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
dei servizi offerti ai propri clienti, attraverso le certificazioni di qualità della serie ISO 9000.
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
precedente capitolo: 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. Questa è un’ulteriore dimostrazione
del fatto che le certificazioni di qualità sono spesso qualcosa di formale e laterale, che non
rispecchiano le reali pratiche aziendali e che entrano solo marginalmente nei processi primari.
La CHORUS S.p.A. si è posta l’obiettivo di raggiungere il terzo livello di maturità
indicato dal modello CMMI entro giugno 2007. 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.
53
Approccio aziendale al CMMI
3.2 Organizzazione del gruppo di lavoro
L’azienda ha affidato il progetto di implementazione del CMMI ad un gruppo di
lavoro appositamente costituito, composto da quattro stagisti (tra cui io) 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: quella continua e quella 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
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, in quattro gruppi di Aree, come
risulta dalla figura di seguito riportata.
54
Approccio aziendale al CMMI
Project Planning
Requirements
Development
Project Monitoring
Requirements
and Control
Management
Configuration
Management
Technical Solution
Verification
Process and Product
Quality Assurance
Validation
Figura 3.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, ma
lavorando contemporaneamente all’integrazione e alla correlazione con tutte le altre Aree.
3.3 Fasi del progetto e della sua messa in opera
Il progetto di implementazione CMMI in CHORUS S.p.A. è 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. Queste attività vengono suddivise in fasi, che 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;
•
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.
55
Approccio aziendale al CMMI
Il modello IDEAL non è solo una instanziazione del più famoso ciclo PDCA (PlanDo-Check-Act), ma include una filosofia di lavoro, ben evidenziata dalla “L” finale, ovverosia
catturare opportunamente l’esperienza in database (quantitativi e qualitativi).
Figura 3.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. 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 abbiamo 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.
56
Approccio aziendale al CMMI
È 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
successivi 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 maturity.
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. Questo tipo di apprendimento è chiamato Training on the
Job; oltre ad essere un efficace metodo di formazione per il personale, che è guidato passo
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
57
Approccio aziendale al CMMI
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 7 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 e, 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 dare il giusto peso a
errori e successi sperimentati nel corso delle fasi precedenti e, eventualmente, a rivedere le
scelte organizzative. In questa fase si farà proprio questo.
3.4 Quadro d’insieme: le relazioni tra le Aree di Processo
Nel quadro d’insieme riportato in figura 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).
58
Approccio aziendale al CMMI
REQM
RD
RSKM
PP
TS
VER
PMC
VAL
PPQA
CM
MA
Figura 3.3 - Le relazioni tra le Aree di Processo.
Questo quadro d’insieme è il frutto di un lungo periodo di riflessione, confronto e
lavoro di gruppo in azienda. Per ricavare tale quadro d’insieme siamo partiti dal ciclo di vita
del prodotto attualmente adottato in CHORUS S.p.A., perciò le relazioni evidenziate tra le
Aree di Processo sono proprie di questo particolare contesto lavorativo.
Nel seguito viene riportata una breve descrizione per ognuna delle Aree di Processo
presente in Figura 3.3.
CONFIGURATION MANAGEMENT (CM)
Lo scopo della 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.
L’Area di processo di Gestione della Configurazione si occupa in particolare di quanto
segue:
59
Approccio aziendale al CMMI
•
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 di creazione e rilascio delle baseline a partire dagli Item di
configurazione
•
Mantenere l'integrità delle baseline
•
Fornire dati accurati sullo stato e la configurazione corrente agli sviluppatori, agli
utenti finali e ai clienti.
Le disposizioni su come condurre la gestione della configurazione devono essere stabilite
negli accordi cliente-fornitore.
MEASUREMENT AND ANALYSIS (MA)
Lo scopo di questa Area di Processo è sviluppare e sostenere una capacità di
misurazione utilizzata per supportare le necessità di informazioni gestionali.
L’area di processo di Misura ed Analisi si occupa in particolare di quanto segue:
•
Specificare gli obiettivi di misura ed analisi in modo tale che siano allineati con le
necessità identificate di informazioni e con gli obiettivi
•
Specificare le misure, le tecniche di analisi e i meccanismi per la raccolta e
gestione dei dati
•
Eseguire la raccolta, l’archiviazione e l'analisi dei dati
•
Fornire risultati oggettivi che possono essere usati per prendere decisioni e per
intraprendere azioni correttive appropriate
L'integrazione delle attività di Misura ed Analisi nei processi di progetto supporta
quanto segue:
•
Pianificazione e stima degli obiettivi
•
Tracciamento delle prestazioni reali rispetto a quelle pianificate
•
Identificazione e risoluzione dei problemi correlati ai processi
•
Fornire una base per incorporare le misure in processi aggiuntivi in futuro
60
Approccio aziendale al CMMI
PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)
Lo scopo dell’Assicurazione della 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 della Qualità di Processo e di Prodotto si occupa
in particolare di quanto segue:
•
Valutare obiettivamente i processi eseguiti, i work product e i servizi, secondo le
descrizioni dei processi, le procedure e gli standard applicabili
•
Identificare e documentare i problemi di non conformità
•
Fornire un feedback al personale ed ai responsabili di progetto sui risultati delle
attività di assicurazione della qualità
•
Assicurare che ci si occupi dei problemi di non conformità
PROJECT PLANNING (PP)
Lo scopo della Pianificazione del Progetto è stabilire e mantenere i piani che
definiscono le attività di progetto. Questa 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 Technical Solution (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). Può essere necessaria una
iterazione di queste attività, per arrivare ad un piano di progetto definitivo. Quest’ultimo
costituisce la base per l’esecuzione ed il controllo delle attività di progetto.
61
Approccio aziendale al CMMI
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 del Monitoraggio e Controllo del Progetto è 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 evidenzino deviazioni
significative dal piano. Una deviazione è significativa se, nel caso in cui venisse lasciata
inalterata, impedisse 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 viene 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. 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 della Gestione del Rischio (RSKM), con cui il
PMC è in stretta relazione.
REQUIREMENTS DEVELOPMENT (RD)
Lo scopo dell’area di processo di Sviluppo dei Requisiti è quello di produrre ed
analizzare tre tipi di requisiti: del cliente, del prodotto, e dei componenti di prodotto.
62
Approccio aziendale al CMMI
Considerati nella loro totalità, questi requisiti si occupano delle necessità degli
stakeholder (ovvero gli individui che sono attivamente coinvolti nel progetto e la cui
soddisfazione influenza il successo del progetto stesso), considerando tutte le fasi del ciclo di
vita del prodotto, e le varie caratteristiche del prodotto stesso (e.g. safety e manutenibilità). I
requisiti devono tener conto anche dei vincoli causati dalla scelta di una particolare soluzione
tecnica (per es. l’uso di componenti off-the-shelf).
I cambiamenti ai requisiti, se ve ne sono, devono essere documentati mediante
richieste di cambiamento provenienti dal cliente o dagli utenti, oppure devono assumere la
forma di nuovi requisiti scaturiti dal processo di sviluppo dei requisiti.
I requisiti costituiscono la base di ogni attività di progetto. Lo sviluppo dei requisiti
comprende le seguenti attività:
•
Esplicitazione, analisi, validazione e comunicazione delle necessità, aspettative
e vincoli provenienti dal cliente, allo scopo di ottenere i requisiti del cliente,
che costituiscono la comprensione di cosa soddisferà gli stakeholder, cioè di
quali caratteristiche dovrà avere il prodotto finale;
•
Sviluppo dei requisiti del ciclo di vita del prodotto;
•
Definizione esatta dei requisiti del cliente;
•
Definizione dei requisiti iniziali del prodotto, consistenti con i requisiti del
cliente.
Quindi, una volta ottenuti i requisiti del cliente, essi vengono ulteriormente raffinati e
trasformati in requisiti del prodotto e dei componenti di prodotto, utilizzando anche le
soluzioni tecniche che si è deciso di adottare. I termini “prodotto” e “componente di prodotto”
sono utilizzati in tutte le aree di processo, e per questo il loro significato comprende anche i
servizi, e i loro componenti.
REQUIREMENTS MANAGEMENT (REQM)
Lo scopo della Gestione dei Requisiti è quello di gestire i requisiti dei prodotti di
progetto e dei componenti di prodotto, e di identificare le eventuali inconsistenze tra questi
requisiti, i piani di progetto e i work product. Controlla la gestione di tutte le specifiche
ricevute o generate dal progetto, comprese sia quelle tecniche che non tecniche.
Si possono presentare due casi:
63
Approccio aziendale al CMMI
•
Le specifiche arrivano dal cliente; in questo caso non occorre sviluppare i
requisiti, ma serve solo comprenderli parlando con il cliente e gestirli (si
utilizza solo l’area Gestione dei Requisiti).
•
Nel secondo caso, invece, il cliente non fornisce direttamente i requisiti ma
solo le sue necessità ed aspettative; qui bisogna prima sviluppare i requisiti, e
poi in un secondo momento gestirli (si utilizza sia l’area Sviluppo dei
Requisiti che l’area Gestione dei Requisiti).
Quindi questa area di processo gestisce sia requisiti ricevuti, che provengono dal
cliente, che requisiti sviluppati direttamente dall’azienda che svolge il progetto.
Si definiscono cinque attività principali:
-
ottenere la comprensione dei requisiti con il cliente
-
ottenere l’impegno (commitment) in base ai requisiti
-
gestire eventuali cambiamenti
-
mantenere la tracciabilità dei requisiti
-
identificare le eventuali inconsistenze tra i requisiti ed i lavori di progetto
Nel caso in cui un progetto riceve i requisiti dal cliente, questi sono rivisti insieme dai
cliente e dai fornitori che lavorano al progetto, per risolvere possibili problemi ed impedire
incomprensioni prima che i requisiti siano incorporati nei programmi del progetto.
Una volta raggiunto l'accordo si ottiene l’impegno per il progetto, si controllano i
cambiamenti ai requisiti mentre si evolvono, e si identificano tutte le contraddizioni che si
presentano fra i piani, i prodotti di lavoro ed i requisiti.
Nel caso in cui, invece, i requisiti non arrivano dal cliente, ma si hanno a disposizione
solo i fabbisogni degli stakeholder, prima della gestione dei requisiti bisogna applicare l’area
di processo dello Sviluppo dei Requisiti.
Bisogna opportunamente documentare i requisiti, i cambiamenti e la motivazione
delle decisioni prese in merito, e mantenere la tracciabilità bidirezionale fra i requisiti
sorgente e tutti i requisiti di prodotto e componenti di prodotto che da essi derivano.
RISK MANAGEMENT (RSKM)
Lo scopo di quest’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.
64
Approccio aziendale al CMMI
La gestione del rischio è 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. 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 della Gestione dei Rischi (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 il RSKM e le aree
di processo di Sviluppo e Gestione dei Requisiti (RD e REQM) per la fase iniziale, e con le
aree di 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.
La Soluzione Tecnica è 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.
65
Approccio aziendale al CMMI
L’area di processo si concentra su quel che segue:
•
Valutazione e selezione delle soluzioni che potenzialmente soddisfano un definito
insieme di requisiti;
•
Sviluppo dettagliato dei progetti delle soluzioni selezionate (dettagliato nel senso
che contiene tutte le informazioni necessarie per produrre, codificare o
implementare il progetto in un prodotto o un componente);
•
Implementazione dei progetti in prodotti o componenti.
Le pratiche specifiche della Soluzione Tecnica si applicano non solo al prodotti o ai
componenti di prodotto ma anche ai processi correlati al ciclo di vita del prodotto.
VALIDATION (VAL)
L’obiettivo di questa area di processo è quello di dimostrare che un prodotto (o un
componente di prodotto) adempia al suo utilizzo progettato quando viene posto nell’ambiente
previsto.
Le attività della Validazione possono essere applicate a tutti gli aspetti del prodotto.
La Validazione dimostra che un prodotto, nei casi previsti, adempirà al suo utilizzo
progettato; di contro, la Verifica si occupa di vedere se un work product soddisfa
completamente i requisiti specificati. In altre parole la Verifica si assicura che “tu l’abbia
costruito correttamente”, mentre la Validazione si assicura che “tu abbia costruito la cosa
giusta”, cioè deve controllare che non solo funzioni, ma che faccia esattamente quello per cui
è stato progettato. Le attività di Validazione utilizzano un approccio simile a quello della
Verifica (ad es.: test, analisi, ispezioni, dimostrazioni o simulazioni). Spesso gli utenti finali o
altri stakeholder vengono coinvolti nelle attività di Validazione. Sia le attività di Verifica che
quelle di Validazione spesso si svolgono simultaneamente e possono utilizzare lo stesso
ambiente.
VERIFICATION (VER)
L’obiettivo di questa area di processo è quello di assicurare che i work product
(qualsiasi prodotto di una fase lavorativa) selezionati rispettino i requisiti per loro specificati.
L’area di processo della Verifica include le seguenti attività: la preparazione alla
verifica, l’esecuzione della verifica e l’identificazione delle azioni correttive.
66
Approccio aziendale al CMMI
La Verifica 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.
La Verifica è 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
67
Pianificazione del Progetto
PIANIFICAZIONE DEL PROGETTO
4.
La Pianificazione del Progetto è la prima Area di Processo di cui mi sono occupata
personalmente durante il periodo di stage presso la CHORUS. Per affinità di argomenti e per
completezza, mi sono occupata anche della Gestione dei Rischi, attività indispensabile da
considerare proprio in fase di pianificazione, e del Monitoraggio e Controllo del Progetto, che
comprende un insieme di attività fondamentali per assicurarsi che gli obiettivi prefissati in
fase di pianificazione vengano alla fine raggiunti.
4.1 Descrizione
Lo scopo della Pianificazione del Progetto è stabilire e mantenere i piani che
definiscono le attività di progetto. Questa 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 Technical Solution (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). Può essere necessaria una
iterazione di queste attività, per arrivare ad un piano di progetto definitivo. Quest’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
68
Pianificazione del Progetto
qui si evidenzia una forte relazione con l’area di processo del Monitoraggio e Controllo del
Progetto (PMC).
Vediamo ora un po’ più in dettaglio quali sono le attività da implementare per una
corretta pianificazione di un progetto secondo il CMMI.
Il macroprocesso di Pianificazione inizia con una fase di stima e valutazione di ogni
singolo aspetto coinvolto nella pianificazione di un progetto, a partire dai parametri. Con
questo termine si intendono tutte le informazioni necessarie per una corretta pianificazione,
organizzazione, composizione dello staff, coordinamento, direzione, e definizione del budget.
Queste stime costituiscono la base di ogni piano di progetto. I fattori che di solito vengono
presi in considerazione durante la stima dei parametri includono:
•
I
requisiti
di
progetto,
inclusi
i
requisiti
del
prodotto,
quelli
imposti
dall’organizzazione, dal cliente, e altri requisiti che influiscono sul progetto;
•
Campo di applicazione del progetto e sua struttura, mediante la definizione di una
WBS (Work Breakdown Structure) ad alto livello;
•
Caratteristiche di task e work product;
•
Approccio tecnico;
•
Il modello scelto per il ciclo di vita del progetto;
•
Programma temporale (schedule);
•
Modelli o dati storici per convertire le caratteristiche di task e work product in ore di
lavoro e costi;
•
Metodologia utilizzata (modelli, dati o algoritmi) per individuare le necessità di
materiali, competenze, ore di lavoro e costi.
La fase successiva a quella di valutazione consiste nella pianificazione vera e propria,
cioè nello sviluppo del piano di progetto. Quest’ultimo è un documento formale, che deve
considerare tutte le fasi del ciclo di vita del progetto, e una volta approvato serve a gestire e
controllare l’esecuzione del progetto. E’ basato sui requisiti e sulle stime e valutazioni
effettuate. In concreto, bisogna:
•
Stabilire il budget e definire il programma temporale (schedule);
•
Identificare e analizzare i rischi di progetto;
•
Stabilire un piano per la gestione dei dati di progetto;
•
Definire un piano per reperire tutte le risorse necessarie (personale ed
apparecchiature);
69
Pianificazione del Progetto
•
Determinare un piano per le competenze e le conoscenze richieste;
•
Pianificare il coinvolgimento degli stakeholder durante tutte le fasi del progetto;
•
Sviluppare il piano complessivo di progetto.
L’ultima fase è quella che rende effettivo ed applicabile il piano, e consiste
nell’ottenere il commitment (cioè l’impegno) all’esecuzione del piano da parte di tutti gli
stakeholder responsabili del supporto e della realizzazione del progetto. Questa fase viene
anche detta di kick-off, e segna la partenza vera e propria dei lavori. Per ottenere il
commitment, si passa attraverso:
•
La revisione di tutti i piani che influenzano il progetto;
•
La verifica che ci sia la copertura delle attività con le risorse a disposizione;
•
La revisione dei requisiti e dello schedule;
•
La rinegoziazione di budget e impegni interni ed esterni.
4.2 Assessment
Con il termine Assessment si indica la rilevazione dello stato attuale di una o più
attività aziendali. La prima fase del nostro lavoro in azienda e stata proprio l’assessment della
CHORUS: ogni stagista si è occupato della situazione aziendale riguardante le aree di
processo assegnategli, allo scopo di ottenere una visione chiara delle condizioni di partenza
della CHORUS per il percorso di implementazione del CMMI e per il raggiungimento del
livello 3 di maturità.
L’assessment è stato effettuato mediante riunioni, colloqui individuali ed interviste ad
alcuni Project Manager. Queste interviste avevano lo scopo di verificare, per ogni pratica
specifica dell’area di processo in questione, se ogni singola sottopratica prevista dal modello
CMMI aveva un riscontro diretto in una o più attività aziendali oppure no. Infatti il
raggiungimento del livello 3 di maturità del CMMI prevede che tutte le sottopratiche di tutte
le pratiche specifiche vengano pienamente soddisfatte, cioè previste ed attuate da un’attività
aziendale.
I risultati ottenuti sono stati poi inseriti e schematizzati in tabelle excel. La struttura di
queste tabelle è stata discussa e approvata da tutto il gruppo di lavoro del CMMI, e quindi si è
deciso di adottare uno schema comune di rappresentazione.
70
Pianificazione del Progetto
Ogni tabella rappresenta una singola pratica specifica dell’area di processo. Nelle
righe sono riportati i typical work product e le sottopratiche (subpractices) della pratica
specifica corrispondente. Le colonne sono tre:
•
Stato: mostra lo stato attuale dell’azienda rispetto ad una precisa sottopratica, quindi
indica se la sottopratica è soddisfatta (S), non soddisfatta (NS), o parzialmente
soddisfatta (PS);
•
Evidenza oggettiva: in questa colonna ho riportato la prova formale (se esiste) che
l’azienda mette in atto in maniera continua e standard l’attività indicata dalla
sottopratica in questione. Di solito l’evidenza oggettiva è costituita da documenti, di
cui è riportato il codice;
•
Note: qui ho riportato delle annotazioni utili per una successiva analisi dei dati
raccolti, costituite per lo più da riferimenti alle procedure in uso in CHORUS al
momento dell’assessment, che potessero soddisfare le sottopratiche. PG sta per
Procedura Gestionale, ed è l’acronimo utilizzato da CHORUS per indicare le
procedure aziendali.
Inoltre ogni tabella riporta in alto a sinistra il codice identificativo di un progetto di
riferimento, analizzato per effettuare l’assessment.
Qui di seguito sono riportate le tabelle relative alla fase di assessment per l’Area di
processo della Pianificazione del Progetto.
71
Pianificazione del Progetto
SP 1.1 Valutare la Struttura del Progetto
Telespazio Cosmo Sky-Med TPZPFS004
Stato
1. Descrizioni dei Task
-----
Typical Work
2. Descrizioni del pacchetto di lavoro (work package)
Products
3. WBS - Struttura di Ripartizione del Lavoro
Evidenza Oggettiva
Note
---------
PG.04A - GP par. 4.2
(manca la WBS)
La PG.04A attuale andrà
PMP (Project Management Plan): cap.3 divisa in due: PG.04A - GP
1. Sviluppare una WBS basata sull'architet ura del prodotto PS (CSK-CHO-PFSET-PMP-0001-2.0) Nota: (Gestione Progetto), che
la WBS è del progetto, e non del prodotto genererà il PMP, e la
PG.04A - PR
(Progettazione e
Realizzazione)
2. Identificare i pacchetti di lavoro (work packages) con un
Subpractices dettaglio sufficiente a specificare le stime dei task del
progetto, le responsabilità, e il programma (schedule).
PS
PMP, cap. 3
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.04A - GP
par. 4.2
(da ampliare)
3. Identificare il prodotto o i componenti di prodotto che
saranno acquisiti esternamente.
PMP, cap. 3: "WP Inputs", nella tabella per la
PS
descrizione dei WP
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.04A - GP
par. 4.2
(da ampliare)
4. Identificare i "work products" che saranno riutilizzati
PMP, cap.3: "WP Exclusions & Constraints",
PS nella tabella per la descrizione dei WP
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.04A - GP
par. 4.2
(da ampliare)
72
Pianificazione del Progetto
SP 1.2 Stabilire le Stime delle Caratteristiche dei Work Products e dei Tasks
Telespazio Cosmo Sky- Med TPZPFS004
Stato
1. Approccio tecnico
-----
Evidenza Oggettiva
Note
2. Dimensione e comples ità di task e "work products"
Typical Work
Products 3. Valutazione dei modelli
-----
4. Valutazione delle carat eristiche
-----
1. Determinare l'approccio tecnico per il progetto
SEMP (Software Engineering
Management Plan): esiste un template,
ma è del cliente;
PG.04A - GP
S
ADD cap.2
(CSK-CHO-PFSET-SEMP-0001-1.0)
(CSM-UGS-STD-ADD-0060-1.1)
Subpractices 2. Utilizzare metodi appropriati per determinare le
carat eristiche dei "work products" e dei task che saranno
usati per valutare i requisiti delle risorse
-----
PMP e SEMP (Il SEMP va consegnato
insieme al PMP nella fase di kick-of ) PG.04A - GP
S
(CSK-CHO-PFSET-PMP-0001-2.0) par. 4.4.1 e 4.5
(CSK-CHO-PFSET-SEMP-0001-1.0)
3. Valutare le carat eristiche dei "work products" e dei task NS
PG.04A - GP
par.4.2 (da
ampliare)
73
Pianificazione del Progetto
SP1.3DefinrlCcodiVtaelProgt
TelspazioCmSky-MedTPZFS04 Stao EvidenzaOgtiv Note
TypicalWork PMcap.3 PG.04A-P
1.PianfcrelasidCcloiVta S
Products (CSK-HOPFSET-MP01-2.) par.41
74
Pianificazione del Progetto
SP 1.4 Determinare le Stime di Impegno e Costo
Telespazio Cosmo Sky- Med TPZPFS004
Stato
1. Valutazione del e motivazioni del e decisioni (rationale) S
Typical Work
Products 2. Stime del 'Impegno sul Proget o
3. Stime del Costo del Proget o
Evidenza Ogget iva
Note
JFD (Justification File Document)
(CSM-CHO-UGS-PFS-TNO-0050-2.1)
---------
SAP
(Stato di Avanzamento del Proget o)
Non c'è una PG: manca la
1. Rac ogliere i model i o i dati storici che saran o utiliz ati Non si utiliz ano model i, ma soltanto dati
rac olta di model i e la
per trasformare le carat eristiche dei "work products" e dei PS storici, costituiti dai SAP di proget i
costituzione di una repository
task in stime del e ore di lavoro e del costo.
precedenti
di dati storici strut urata
2. Includere le neces ità di una infrastrut ura di sup orto
Subpractices
S
durante la stima di impegno e costo.
PMP, nel a parte dedicata al 'Hardware PG.04A - GP, par. 4.4
procurement PG.03 (Gestione Offerte),
(CSK-CHO-PFSET-PMP-0001-2.0) par. 4.3
PG.04A - GP, par. 4.4
3. Stimare impegno e costo utiliz ando model i e/o dati
Solo stime empiriche basate su SAP
PG.03 (Gestione Offerte),
PS
storici.
storici
par. 4.3
75
Pianificazione del Progetto
SP 2.1 Stabilire il Budget e il Programma (Schedule)
Telespazio Cosmo Sky-Med TPZPFS004
Stato
1. Programmi (Schedules) di progetto
-----
Evidenza Oggettiva
Note
S
SOW (Statement Of Work), cap. 6.3
"Schedule and Milestones"
(CSM-UGS-STD-SOW-0077-1.1)
PG.03
2. Identificare le assunzioni di programma (schedule)
S
PMP, cap. 3
(Le assunzioni si riferiscono alla durata di
determinate attività)
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.03
PG.04A - GP
3. Identificare i vincoli
S
PMP, cap. 3
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.03
PG.04A - GP
4. Identificare le dipendenze tra i compiti (tasks)
S
PMP, cap.3
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.03
PG.04A - GP
5. Definire il budget e il programma (schedule)
S
SAP per il budget;
PMP per lo schedule
(CSK-CHO-PFSET-PMP-0001-2.0)
PG.03
PG.04A - GP
6. Stabilire i criteri delle azioni correttive
S
RMP (Risk Management Plan)
(CSK-CHO-PFSET-RMP-0001-1.0)
PG.04A - GP
Typical Work 2. Dipendenze di programma (schedule)
Products
-----
3. Budget di progetto
-----
1. Identificare le "milestones" più importanti
Subpractices
76
Pianificazione del Progetto
SP 2.2 Identificare i Rischi di Proget o
Telespazio Cosmo Sky-Med TPZPFS0 4
Stato
1. Rischi dentificati
---
Typical Work
2. Effet i di rischio e probabil tà di oc or enza
Products
3. Priorità di rischio
---
Subpractices
Evidenza Ogget iva
Note
---
1. Identificare i rischi
PG.04A - GP
RMP (Risk Management Plan)
PS
PG "Gestione rischi" (da
(CSK-CHO-PFSET-RMP-0 01-1.0)
creare)
2. Documentare i rischi
PG.04A - GP
RMP
PS
PG "Gestione rischi" (da
(CSK-CHO-PFSET-RMP-0 01-1.0)
creare)
MOM (Minute Of Meeting) di riunioni con
gli stakeholder; PG "Gestione rischi" (da
3. Revisionare e ot enere un'ac ordo con gli stakeholder
PS
sul a completez a e cor et ez a dei rischi documentati
MPR (Monthly Progres Report) creare)
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
4. Revisionare i rischi n modo ap ropriato
PS
MPR PG "Gestione rischi" (da
(CSM-CHO-UGS-PFS-MPR-01 0-1.0) creare)
77
Pianificazione del Progetto
SP 2.3 Piano per la Gestone dei Dati
Telespazio Cosmo Sky-Med TPZPFS004
1. Piano della gestione dei dati
Stato
Evidenza Oggettiva
S
CDMP-Configuration & Data Management
Plan (documento applicabile A33 del SOW)
(CSM-UGS-STD-SOW-0077-1.1)
SOW cap.8; GDC (Giornale Di
Configurazione)
(CSM-UGS-STD-SOW-0077-1.1)
(TPZPFS-GDC-e1.ro.xls)
SOW e PGC (come risposta al SOW)
(CSM-UGS-STD-SOW-0077-1.1)
2. Lista principale dei dati gestiti
S
3. Contenuto dei dati e descrizione del formato
S
4. Liste dei requisiti sui dati per acquirenti e fornitori
S
SOW e PGC
(CSM-UGS-STD-SOW-0077-1.1)
S
SOW (documenti applicabili A38, A39, A40);
PGC
(CSM-UGS-STD-SOW-0077-1.1)
6. Requisiti di sicurezza
S
SOW (documenti applicabili A38, A39, A40);
(CSM-UGS-STD-SOW-0077-1.1)
7. Procedure di sicurezza
S
SOW (documenti applicabili A38, A39, A40);
(CSM-UGS-STD-SOW-0077-1.1)
8. Meccanismo di recupero, riproduzione e distribuzione dei
dati
S
SOW e PGC
(CSM-UGS-STD-SOW-0077-1.1)
9. Programma (schedule) per la raccolta dei dati di progetto
S
SOW e PGC
(CSM-UGS-STD-SOW-0077-1.1)
10. Lista dei dati di progetto da raccogliere
S
SOW e PGC
(CSM-UGS-STD-SOW-0077-1.1)
Typical Work 5. Requisiti di privacy
Products
1. Stabilire i requisiti e le procedure per assicurare la privacy
e la sicurezza dei dati
Subpractices 2. Stabilire un meccanismo per archiviare i dati e per
accedere ai dati archiviati
3. Determinare i dati di progetto che devono essere
identificati, raccolti e distribuiti
S
S
S
Note
Per i requisiti: PG03;
SOW per i requisiti di sicurezza e privacy:
Per le procedure: DPS
vengono dati dal cliente (documenti applicabili:
(Documento Programmatico
A31, A32, A33, A38, A40, ...);
sulla Sicurezza), richiamato
PGC: c'è un richiamo alla PG-08A
dalla legge 196;
(CSM-UGS-STD-SOW-0077-1.1)
PG08A
PG03
SOW : dice come archiviare i dati (documenti
PG15A:"Backup ed
applicabili: A33-CDMP, A34) (CSM-UGSarchiviazione del software"
STD-SOW-0077-1.1)
PG08A
SOW, cap.7 (per il formato dei dati) e cap.8
(indica quali sono i dati);
il PGC dice come gestire i dati (il PGC c'è, ma
deve essere aggiornato)
(CSM-UGS-STD-SOW-0077-1.1)
PG03
PG08A
78
Pianificazione del Progetto
SP 2.4 Piano per le Risorse di Progetto
Telespazio Cosmo Sky-Med TPZPFS004
Stato
Evidenza Oggettiva
1. Pacchetti di lavoro (work packages) delle WBS
S
PMP, cap. 3
(CSK-CHO-PFSET-PMP-0001-2.0)
2. Dizionario dei task delle WBS
S
PMP, cap. 3
(CSK-CHO-PFSET-PMP-0001-2.0)
3. Requisiti di personale basati sulla dimensione e campo di
applicazione del progetto
S
PMP, cap. 2
(CSK-CHO-PFSET-PMP-0001-2.0)
S
"Technical Proposal": è un documento che va
allegato al PMP, e contiene una lista di compon.
HW/SW
(CSK-CHO-PFSET-TP-0001-1.0)
S
PMP, per la definizione del processo (ADD per il
prodotto)
(CSK-CHO-PFSET-PMP-0001-2.0)
S
PMP, cap.3 (C'è un WP dedicato al PM, con
l'indicazione di tut e le attività che deve
svolgere)
(CSK-CHO-PFSET-PMP-0001-2.0)
1. Determinare i requisiti del processo
S
PMP, cap.3 (i requisiti del processo sono intesi
come attività da svolgere nel progetto)
PG04A - GP
(CSK-CHO-PFSET-PMP-0001-2.0)
2. Determinare i requisiti del personale
S
4. Lista delle facilities (applicazioni)/apparecchiature
Typical Work
critiche
Products
5. Definizioni e diagrammi del processo/flusso di lavoro
6. Lista dei requisiti dell'amministrazione del programma
Subpractices
3. Determinare i requisiti di facilities, apparecchiature e
componenti
S
PMP, cap.2
(CSK-CHO-PFSET-PMP-0001-2.0)
Note
PG04A - GP
"Technical Proposal": è un documento che va
allegato al PMP, e contiene una lista di compon.
PG04A - GP
HW/SW
(CSK-CHO-PFSET-TP-0001-1.0)
79
Pianificazione del Progetto
SP 2.5 Piano per le Conoscenze e le Competenze Richieste
Typical Work
Products
Telespazio Cosmo Sky-Med TPZPFS004
Stato
Evidenza Oggettiva
1. Inventario delle neces ità delle competenze (skil )
S
SOW per l'identificazione delle risorse;
"Nota Risorse e Progetti"
2. Piani per la costituzione dello staf e per le nuove
assunzioni
-----
Note
3. Database (i.e., competenze e formazione)
PS
Esiste un file che contiene tut e le
"Schede Di Qualifica del Personale"
(MD4.18A); viene aggiornato
annualmente, ma non c'è un piano per
l'aggiornamento periodico (iniziativa
personale)
1. Identificare le conoscenze e le competenze neces arie per
eseguire il progetto
S
Renzulli: SOW, e "Nota Risorse e
Progetti"
2. Valutare le conoscenze e le competenze disponibili
NS
Non esiste un template, e non c'è
PG04A - GP
un'evidenza oggettiva vera e propria
3. Selezionare i meccanismi per procurarsi le conoscenze e le
competenze necessarie
S
C'è una procedura, "Recruiting", che
Procedura "Recruiting"
viene seguita ed attuata
Subpractices
4. Incorporare i meccanismi selezionati nel piano di progetto NS
Non viene fat o
PG03
PG04A - GP
PG04A - GP
80
Pianificazione del Progetto
SP2.6PianoperilCoinvolgimentodegliStakeholder
Tel spazioCosmoSky-MedTPZPFS0 4 Stao EvidenzaOg et iva Note
PMP,cap.2(questocapitol specifcatuti
ruolie,perogniruol ,leresponsabiltà);
TypicalWork
1.PianoperilcoinvolgimentodeloStakeholder S cap.3(quison indicati tempidi ntervento PG04A-GP
Products
diognistakeholder)
(CSK-CHO-PFSET-PMP-0 01-2.0)
· Fareunalistaditutiglistakeholder
· Motivazioni(rationale)perilcoinvolgimentodeglistakeholder
· Ruolieresponsabiltàdeglistakeholder iguardoalprogeto,atraversolafasedelci lodivitadelprogeto
Esempi · Rap orti raglistakeholder
· Importanzadelostakeholder elativa lsuc es odelprogeto,atraversolafasedelci lodivtadelprogeto
· Risorse(e.g,train g,materiali,tempo,fondi)nec s ariadas icura el'interazionedelostakeholder
· Program azione(schedule)delefasidel'interazionedelostakeholder
81
Pianificazione del Progetto
SP2.7 Stabil re il Piano di Proget o
Tel spazio Cosmo Sky-Med TPZPFS0 4
Typical Work
1. Piano di proget o generale
Products
Stato
Evidenza Ogget iva
Note
PMP; MPR perl'avanzamento delpiano, ed
eventuali scostamenti rispet o al a
S pianif cazioneiniz ale PG04A-GP
(CSK-CHO-PFSET-PMP-0 01-2.0)
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
· Piano Principale Integrato -un piano event-driven che documenti realiz azioni signif cative mediante criteri suc es o/insuc es o sia per il busines che
per gliel menti tecnic del proget o e che leghi ogni realiz azione con un evento chiave del program a.
· Program a (schedule)Principale integrato – un program a dei compit integrato e intercon es o a più livel i, richiesto per completare il avoro
documentato in un Piano Principale Integrato cor elato.
Esempi · Piano di Gestione Ingegneria dei Sistemi– un piano che descrive in det aglio l'impegno tecnico integrato at raverso tut o il proget o.
· Program a (schedule)Principale Ingegneria dei Sistemi – un program a event-based che contenga una rac olta di realiz azioni tecniche chiave,
ognuna con criteri misurabil , e che richieda un completamento con suc es o per ilsuperamento di eventi dentif cati.
· Program a (schedule)Det agliato Ingegneria deiSistemi – un program a det agliato,a dipendenza temporale, task-oriented, che as ocispecif che
date milestones al Program a Principale Ingegneria dei Sistemi.
82
Pianificazione del Progetto
SP3.1RevisonareiPncheIflunzaoilPrgeto
TelspazioCsmSky-MedTPZFS04 Stao EvidenzaOgetiva Note
TypicalWork 1.Registrazonedlrvisondepiancheflunzao MPR
S PG.04A-GP
Products ilproget (CSM-HOUGS-PFMR-01 .)
83
Pianificazione del Progetto
SP3.2 Concil are iLivel idiLavoro e del e Risorse
Tel spazioCosmoSky-MedTPZPFS0 4
Sta o EvidenzaOg et iva Note
1.Metodirevis onatiecor ispondentevalutazionedei
MPR
par metri(per es mpio,strumentimigliorieusodi S
PG.04A-GP
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
componenti m ediat mentedisponib li)
2.Budgetrinegoziati
TypicalWork
Products 3.Program i(schedules) revisonati
MPR,per leore;SAP,per ilcosto
PG.04A-GP
S
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
MPR
PG.04A-GP
S
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
4.Lista deirequistirevisonat
MPR
S
PG.04A-GP
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
5.Ac ordiconlostakeholder inegoziati
MPReMOM
S
PG.04A-GP
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
84
Pianificazione del Progetto
SP 3.3 Ottenere l'Impegno all'Esecuzione del Piano
Typical Work
Products
Telespazio Cosmo Sky-Med TPZPFS004
Stato
1. Richieste documentate per gli impegni
-----
2. Impegni documentati
-----
Evidenza Oggettiva
Note
Impegno (commitment)= Ordine
controfirmato per accettazione
S
SAP e PMP
PG.03
(CSK-CHO-PFSET-PMP-0001-2.0) (supporto
PG.04A - GP
necessario = persone)
2. Documentare tutti gli impegni organizzativi, sia pieni che
provvisori, accertando il livello adatto dei firmatari.
S
SAP e PMP
(CSK-CHO-PFSET-PMP-0001-2.0) Tutte
le commesse sono documentate col SAP, il
PG.03
PMP è usato per questo scopo solo in PG.04A - GP
Telespazio, ma non negli altri progetti; "Note
Conclusive" del Direttore Tecnico
3. Revisionare le commesse interne con l'amministrazione
principale in modo appropriato.
S
SAP, per le revisioni delle commesse; MPR
PG.04A - GP
(CSM-CHO-UGS-PFS-MPR-0110-1.0)
S
SAP per le revisioni; PMP
(CSK-CHO-PFSET-PMP-0001-2.0) SAP,
PG.04A - GP
per monitorare l'andamento delle commesse
PG.06B "Gestione
(interne ed esterne); le review sono fatte come
Acquisti"
da Sistema per la Qualità, cioè ci sono delle
MOM di riunioni
S
PMP,cap.2 (identificazione delle persone) e
cap.3 (identificazione delle attività)
PG.04A - GP
(CSK-CHO-PFSET-PMP-0001-2.0)
1. Identificare il supporto necessario e negoziare gli impegni
con gli stakeholder.
Subpractices
4. Revisionare gli impegni esterni con il management in
modo appropriato.
5. Identificare gli impegni sulle interfacce tra gli elementi del
progetto e degli altri progetti ed unità organizzative, in modo
che possano essere monitorati.
85
Pianificazione del Progetto
4.3 Analisi dei dati raccolti
L’analisi dei dati raccolti costituisce la seconda fase del mio lavoro individuale in
azienda. Mi sono basata sui dati e le informazioni raccolte durante le interviste ed i colloqui
con i Project Manager e con il Responsabile per la Qualità, ed ho analizzato la situazione
della CHORUS dal punto di vista dei requisiti che il CMMI impone di soddisfare, per l’Area
di processo della Pianificazione del Progetto.
Ho constatato che non tutte le sottopratiche (subpractices) relative alle pratiche
specifiche della Pianificazione vengono soddisfatte, ed alcune vengono attuate solamente in
parte, come si può facilmente dedurre dalle tabelle riportate nel paragrafo precedente. Anche
se la situazione complessiva risulta abbastanza buona, è ancora insufficiente per il
raggiungimento del livello 3 di maturità del CMMI. Infatti per questo scopo è necessario che
tutte le sottopratiche vengano attuate, e inoltre che il loro uso sia “istituzionalizzato”, cioè
bisogna che queste attività siano presenti nelle procedure aziendali, che vengano monitorate, e
adattate (tailorizzate) volta per volta ai vari progetti, secondo criteri precisi e stabiliti a priori.
Per la Pianificazione dei progetti, la CHORUS utilizza una Procedura Gestionale, la
PG.04, e possiede un documento per redigere il piano di progetto, che è il PSP (Piano di
Sviluppo del Progetto). Dall’analisi è risultato che sia la procedura che il PSP sono da
ampliare in modo consistente: per esempio, manca la WBS (Work Breakdown Structure), e
anche un dettaglio sufficiente per alcune caratteristiche dei work product. Serve inoltre un
lavoro sull’attività di stima e valutazione iniziale, che costituisce la base della pianificazione:
è emerso che essa ha caratteristiche empiriche, si fonda sull’esperienza personale dei
manager, e non risulta né sistematica né programmata. Il CMMI inoltre richiede già in fase di
pianificazione un’attenta gestione dei rischi associati al progetto, cosa che non è presente
nelle Procedure Gestionali dell’azienda ai livelli richiesti dal modello. L’analisi dei dati ha
evidenziato inoltre che alcune attività vengono eseguite a buoni livelli, e in maniera
pienamente rispondente ai requisiti del CMMI, come per esempio la gestione dei dati di
progetto.
Di seguito viene riportata graficamente la situazione di partenza della CHORUS per
l’implementazione del CMMI, dal punto di vista delle pratiche specifiche dell’Area di
processo della Pianificazione, che risultano soddisfatte, non soddisfatte, o parzialmente
soddisfatte:
86
Pianificazione del Progetto
PRATICHE SPECIFICHE
23,00%
6,000%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
71%
Figura 4.1 – Stima in percentuale delle pratiche specifiche per l’Area di Pianificazione.
87
Monitoraggio e Controllo del Progetto
5.
MONITORAGGIO E CONTROLLO DEL
PROGETTO
Il Monitoraggio e Controllo del Progetto è la seconda Area di processo di cui mi sono
occupata personalmente durante il periodo di stage in azienda. E’ strettamente collegato dal
punto di vista concettuale all’Area di Pianificazione, la quale costituisce il fondamento su cui
si basa tutta la gestione del progetto, dalle prime fasi fino alla sua conclusione e chiusura.
5.1 Aspetti fondamentali
Lo scopo del Monitoraggio e Controllo del Progetto è 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 evidenzino deviazioni
significative dal piano. Una deviazione è significativa se, nel caso in cui venisse lasciata
inalterata, impedisse 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 viene determinato prima di tutto confrontando le
caratteristiche reali 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. 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 della Gestione del Rischio (RSKM), con cui il
PMC è in stretta relazione.
88
Monitoraggio e Controllo del Progetto
Vediamo più in dettaglio come si effettua il monitoraggio di un progetto.
La prima azione da fare consiste nel controllo dei parametri di progetto, che costituiscono gli
indicatori tipici dello stato di avanzamento dei lavori, e comprendono le caratteristiche di
work product e task (come dimensione, complessità, peso, funzione), costi, effort, e tempi. Il
monitoraggio qui vuol dire una misura dei valori reali di questi parametri, il confronto con i
valori stimati, e l’identificazione delle deviazioni significative dal piano; tutto ciò va
registrato e documentato, insieme ad informazioni sul contesto, per poter interpretare
correttamente le misure effettuate.
Ogni elemento delle pratiche specifiche dell’Area di Pianificazione va riportato nel
piano di progetto, che costituisce un punto di riferimento per il monitoraggio, il quale prevede
dunque la gestione ed il controllo di ogni singola attività riportata nel piano: si deve procedere
dunque al monitoraggio dei rischi, del coinvolgimento degli stakeholder nei lavori, della
gestione dei dati, e così via, sempre seguendo il piano di progetto.
Fondamentali risultano le revisioni in fasi prestabilite dell’avanzamento del progetto,
fasi che sono dette milestones. Infine, da sottolineare il fatto che un’azione correttiva nasce
per lo più durante l’attività di controllo del progetto, ed è per questo che quest’Area di
processo deve gestire e prevedere le azioni correttive, mediante un vero e proprio “Piano per
le azioni correttive”.
5.2 Fase di Assessment
Con il termine Assessment si indica la rilevazione dello stato attuale di una o più
attività aziendali. La prima fase del nostro lavoro in azienda e stata proprio l’assessment della
CHORUS: ogni stagista si è occupato della situazione aziendale riguardante le aree di
processo assegnategli, allo scopo di ottenere una visione chiara delle condizioni di partenza
della CHORUS per il percorso di implementazione del CMMI e per il raggiungimento del
livello 3 di maturità.
Come già spiegato nel paragrafo 4.2, l’assessment è stato effettuato mediante riunioni,
colloqui individuali ed interviste ad alcuni Project Manager, per verificare, per ogni pratica
specifica dell’area di processo in questione, se ogni singola sottopratica prevista dal modello
CMMI aveva un riscontro diretto in una o più attività aziendali oppure no.
I risultati ottenuti sono stati poi inseriti e schematizzati in tabelle excel. La struttura di
queste tabelle è stata discussa e approvata da tutto il gruppo di lavoro del CMMI, e quindi si è
deciso di adottare uno schema comune di rappresentazione.
89
Monitoraggio e Controllo del Progetto
Ogni tabella rappresenta una singola pratica specifica dell’area di processo. Nelle
righe sono riportati i typical work product e le sottopratiche (subpractices) della pratica
specifica corrispondente. Le colonne sono tre:
•
Stato: mostra lo stato attuale dell’azienda rispetto ad una precisa sottopratica, quindi
indica se la sottopratica è soddisfatta (S), non soddisfatta (NS), o parzialmente
soddisfatta (PS);
•
Evidenza oggettiva: in questa colonna ho riportato la prova formale (se esiste) che
l’azienda mette in atto in maniera continua e standardizzata l’attività indicata dalla
sottopratica in questione. Di solito l’evidenza oggettiva è costituita da documenti, di
cui è riportato il codice;
•
Note: qui ho riportato delle annotazioni utili per una successiva analisi dei dati
raccolti, costituite per lo più da riferimenti alle procedure in uso in CHORUS al
momento dell’assessment, che potessero soddisfare le sottopratiche. PG sta per
Procedura Gestionale, ed è l’acronimo utilizzato da CHORUS per indicare le
procedure aziendali.
Ho effettuato l’assessment per il Monitoraggio e Controllo del Progetto prendendo in
considerazione due progetti diversi (Telespazio ed ENAV), ed ho riportato in ogni tabella in
alto a sinistra il codice identificativo di uno dei due, scrivendo delle note di riferimento per
l’altro all’interno dei vari campi.
Qui di seguito sono riportate tutte le tabelle relative alla fase di assessment per l’Area
di processo del Monitoraggio e Controllo del Progetto.
90
Monitoraggio e Controllo del Progetto
SP 1.1 Monitorare i Parametri della Pianificazione del Progetto
Progetto Enav - ENVSTN003
Stato
Evidenza Oggettiva
1. Registrazioni della performance di progetto
PS
SAP (Stato di Avanzamento del Progetto):
evidenza a livello economico, ma non a livello
temporale contemporaneamente
2. Registrazione di deviazioni significative rispetto al piano
S
MoM di riunioni; SAP;
MPR (Monthly Progress Report)
1. Monitoraggio dello stato di avanzamento lavori e
scostamenti rispetto alla pianificazione
S
2. Monitoraggio dei costi e dell'impegno previsto
S
Typical Work
Products
3. Monitoraggio delle caratteristiche dei Task e dei work
products
PS
Subpractices
4. Monitoraggio delle risorse approvigionate e impiegate
NS
Note
Sullo stato di avanzamento progetto (SAP) PG04A - GP
vengono riportati i dati relativi agli indicatori di
progetto come costi,impegni,milestone riportati
nel piano evidenziando i valori stimati e quelli PG04A - GP
effettivi dando evidenza di eventuali scostamenti
L'unico attributo dei work package monitorato ad
oggi è il peso rispetto all'intero progetto, dato PG04A - GP
deducibile dal SAP in base all'effort stimato per i
vari task.
Mediante il SAP si monitorizza solo il costo
stimato ed il costo effettivo;
MPR
PG04A - GP
5. Monitoraggio degli skill e delle conoscenze del personale NS (ENAV)
S (Telespazio)
assegnato al progetto
ENAV: Non si fa neanche nel Project Planning,
ad oggi;
PG04A - GP
Per Telespazio: SAP
6. Documentare gli scostamenti significativi nei parametri di
pianificazione del progetto
Si evidenziano dai Progress Report periodici
(mensili per ENAV), compilati dal PM (Project PG04A - GP
Manager); esistono template per i MPR
S
91
Monitoraggio e Controllo del Progetto
SP1.2Monitora egliImpegnidelProget o
ProgetoENAV-ENVSTN0 3
Stao EvidenzaOg et iva Note
TypicalWork
1.Registrazionedel revisonidegli mpegni S MPR(MonthlyProgres Report)
Products
1.Revisonare golarmentegli mpegni(sia nterniche MPR(MonthlyProgres Report)
PG04A-GP
S
esterni)
(com es e sterne=fornitori)
Questaidentifcazionevien ef tuat
Subpractices 2.Identifcaregli mpegnicheno son sta isod isfatioche tramiteMPR,mano èlegat aicosti;
S
PG04A-GP
han ounsignifcativorischiodino es er sod isfati PerTel spazio,èdaconsidera epureil
SAP,insiemealMPR
3.Documentareirsultaidel revisonidegli mpegni S MPR(MonthlyProgres Report) PG04A-GP
92
Monitoraggio e Controllo del Progetto
SP1.3 Monitorare iRischidiProget o
Proget oENAV-ENVSTN0 3
Sta o EvidenzaOg et iva Note
TypicalWork
1.Registrazionidel monitorag iodeirischidiproget o - - Products
PG04A-GP
1.Verif careperiodicamenteipianidirischioinrelazione Verif ca periodica ef et uat tramite
S
PG"GestioneRischi"
al 'at uale sta odelproget oedanaliz are ventualicrit cità
MPR
(da creare)
2.Ef et uareag iornamentisuipianidirischiononap ena ci
PG04A-GP
Ag iornamentodelPianodiGestionedei
Subpractices sonoinformazionidisponib li,perincorpora elemodif che S Rischi(RMP) PG"GestioneRischi"
aisud et ipiani
(da creare)
VienecompilatoilRisk Management
3.Condiv der ecomunicarealpersonalecoinvoltosia
Report(RMR):èundocumento.xls;
internoche adeventualifornitoriocol aboratoriglieventuali S
PG04A-GP
vieneconsegnatoa chiriceveilMPR;
rischiemersi
Per Tel spazio:nonc'èilRMR
93
Monitoraggio e Controllo del Progetto
SP 1.4 Monitorare la Gestione dei Dati
Proget o ENAV-ENVSTN0 3
Typical Work
1. Registrazione del a gestione dei dati
Products
Stato Evidenza Ogget iva
Note
---
1. Revis onare periodicamente le at ività di gestione dei dati
S MPR (anche per Telespazio) PG04A- GP
in base al a loro descrizione nel piano di proget o
2. Identif care documentare problemi signif cativi ed i loro
S MPR (anche per Telespazio) PG04A- GP
impat i
Subpractices
(Per Telespazio: Verbali di Riesame
(del e Verif che Interne per la Qualità);
3. Documentare i risultati del e revis oni del e at ività di
S PAR ,cap.8: riguarda le at ività del a PG04A- GP
gestione dei dati
qualità sul proget o- mod. VRS
(CSM-CHO-UGS-PFS-PAR-0235)
94
Monitoraggio e Controllo del Progetto
SP1.5 Monitora eilCoinvolgimentodegliStakeholder
ProgetoENAV-ENVSTN0 3
Sta o EvidenzaOg et iva Note
TypicalWork
1.Registrazionidelcoinvolgimentodeglistakeholder - - Products
Laverifcavien ef tuat ramitemail
1.Verifcareperiodicamentelostaodelcoinvolgimento NS(Enave
(perTel spazio,ancheMOMdirunioni), PG04A-GP
deglistakeholder
Tel spazio)
mano èperiodicaesi tematica
Subpracti es 2.Identifcare documentareproblemisgnifcativ edilor Alcuniproblemivengon documentainel
S
PG04A-GP
impati
MPR(problemid scostamentodaipani)
3.Documentareirsultaidel revisonidelostaodi NS (Enave
coinvolgimentodeglistakeholder Tel spazio)
PG04A-GP
95
Monitoraggio e Controllo del Progetto
SP 1.6 Effettuare Revisioni sullo Stato di Avanzamento
Progetto ENAV - ENVSTN003
Stato
Evidenza Oggettiva
-----
Servono per tenere gli stakeholders informati;
le verifiche possono non essere specificate
esplicitamente nei piani di progetto (dal
manuale)
S
· MPR (consegnato al cliente, no al personale
che lavora al progetto);
· SAP (ad uso interno della direzione tecnica,
non viene comunicato al cliente, né al personale
che lavora al progetto);
· GANTT (alla direzione tecnica, e al cliente)
PG04A - GP
NS
Metriche del MPR: su nessun progetto ENAV (il
cliente non le richiede).
Per Telespazio: PAR (tutto); c'è solo la
comunicazione dei dati al cliente, ma non la
revisione
(CSM-CHO-UGS-PFS-PAR-0235)
PG04A - GP
S
· MoM di riunioni
Per Telespazio: MPR
(CSM-CHO-UGS-PFS-MPR-0110-1.0)
PG04A - GP
4. Documentare le richieste di cambiamento e i problemi
identificati in ognuno dei work product e processi
S
· possono scaturire da MoM;
· MDSW-VRS (Verbale di Riesame/Verifica).
Per Telespazio: le richieste di cambiamento sono
documentate nel RFD (Request For Deviation),
che viene dal cliente, e a cui si risponde con una
TNO; i problemi sono documentati con il
"Rapporto di Non Conformità" (MD4.17E)
PG04A - GP
5. Documentare i risultati delle revisioni
S
MDSW-VRS (Verbale di Riesame/Verifica)
PG04A - GP
6. A chiusura registrare i report dei cambiamenti ed i
problemi riscontrati
S
PAL (Progress Action List) : documento .xls
PG04A - GP
Typical Work 1. Documentare i risultati delle attività di revisione sul
Products progetto
1. Comunicare regolarmente lo stato delle attività assegnate
e dei "work products" agli stakeholder
2. Revisionare i risultati della raccolta e dell'analisi delle
misure per controllare il progetto
3. Identificare e documentare le problematiche e le
Subpractices deviazioni significative rispetto al piano
Note
96
Monitoraggio e Controllo del Progetto
SP 1.7 Effet uare Revisioni sul e Milestone
Proget o ENAV - ENVSTN003
Stato
Typical Work 1.Risultati documentati del e revisioni ef et uate sul e
Products milestone
-----
1. Effet uare revisioni sui punti cardine del programma
(schedule) di proget o, come il completamento di fasi
selezionate, con gli stakeholder
S
2. Revisionare gli impegni, il piano, lo stato ed i rischi del
S
proget o
Subpractices
Evidenza Ogget iva
Note
MPR (Milestones Critiche)
PG04A - GP
MPR
PG04A - GP
SPR (Software Problem Report) e RID
3. Identificare e documentare problemi significativi ed i loro
PG04A - GP
S
impat i
(per la parte documentale) del MPR
MPR, PAL
4. Documentare i risultati del a revisione, del e eventuali
(Il PAL costituisce un elenco che met e
S
PG04A - GP
at ività e decisioni
insieme RID, SPR e le soluzioni ai
problemi)
5. Tenere trac ia degli items del e azioni di chiusura.
S
MPR
PG04A - GP
97
Monitoraggio e Controllo del Progetto
SP2.1AnalizareiProblemi
ProgetoENAV-ENVSTN0 3 Stao EvidenzaOg etiva Note
· MPR-OpenPoints(ENAV-STL);
TypicalWork 1.Listadeiproblemiche an obisogn diazoni
S · MPR-ListActionItemandStaus PG04A-GP
Products coretive
(CosmoSky)
1.Riunreiproblemiperl'anlis - Subpracti es
2.Analizareiproblemiperdet rminarel'sigenzadi
-azion coretive
98
Monitoraggio e Controllo del Progetto
SP 2.2 Effet uare Azioni Cor et ive
Proget o ENAV - ENVSTN003
Typical Work
1. Piano per le azioni cor et ive
Products
Stato
Evidenza Ogget iva
Note
PAL ( Progres Action List)
PS Per Telespazio: non c'è un piano per le azioni
cor et ive
Compilazione da parte del PM di proget o di una
PG14A "Gestione
nota tecnica o di un verbale di ruinione dove
1. Determinare e documentare le azioni neces arie e
Azioni Cor et ive e
PS vengono evidenziate le azioni.
ap ropriate per indiriz arsi verso i problemi dentificati
Preventive" (da
Per Telespazio: MPR per il piano (azioni neces arie)
ampliare)
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
Subpractices 2. Revisionare e ot enere un ac ordo con gli stakeholder
S
sul e azioni da prendere
3. Concordare i cambiamenti agli mpegni nterni ed esterni S
MoM
PG14A "Gestione
Azioni Cor et ive e
Preventive" (da
ampliare)
PG14A "Gestione
Azioni Cor et ive e
MoM (da cui pos ono scaturire azioni)
Preventive" (da
ampliare)
99
Monitoraggio e Controllo del Progetto
SP 2.3 Gestire Azioni Cor et ive
Proget o ENAV - ENVSTN003
Stato
Typical Work
1. Risultato del e azioni cor et ive
Products
-- -
Evidenza Ogget iva
Control o formale:
· Giornale di Configurazione (GDC)
1. Monitorare le azioni cor et ive per il completamento S · (PAL).
Per Telespazio: MPR
(CSM-CHO-UGS-PFS-MPR-01 0-1.0)
Control o di merito:
Subpractices 2. Analiz are i risultati del e azioni ntraprese al fine di
S · SAP
determinarne l'ef et iva ef icacia
· MPR
3. Determinare e documentare le azioni ap ropriate per
cor eg ere le deviazioni dai risultati pianificati per le azioni S
cor et ive.
SAP e MPR
Note
PG14A, paragrafo "Gestione
Azioni Cor et ive"; L'AQ procede a
verificare la chiusura del e azioni
cor et ive. Documento di
riferimento: "Verifica Azione
Cor et iva"
PG14A, paragrafo 4.4: "Verifica
del 'ef icace at uazione del e azioni
cor et ive"; Documento di
riferimento:"Verifica Azione
Cor et iva"
PG14A, paragrafo 4.4: "Verifica
del 'ef icace at uazione del e azioni
cor et ive"; Documento di
riferimento:"Verifica Azione
Cor et iva"
100
Monitoraggio e Controllo del Progetto
5.3 Risultati dell’analisi
L’analisi dei dati raccolti costituisce la seconda fase del mio lavoro individuale in
azienda. Mi sono basata sui dati e le informazioni raccolte durante le interviste ed i colloqui
con i Project Manager e con il Responsabile per la Qualità, ed ho analizzato la situazione
della CHORUS dal punto di vista dei requisiti che il CMMI impone di soddisfare, per l’Area
di processo di Monitoraggio e Controllo del Progetto.
Ho constatato che non tutte le sottopratiche (subpractices) relative alle pratiche
specifiche del Monitoraggio vengono soddisfatte, ed alcune vengono attuate solamente in
parte, come si può facilmente dedurre dalle tabelle riportate nel paragrafo precedente. Anche
se la situazione complessiva risulta abbastanza buona, è ancora insufficiente per il
raggiungimento del livello 3 di maturità del CMMI. Infatti per questo scopo è necessario che
tutte le sottopratiche vengano attuate, e inoltre che il loro uso sia “istituzionalizzato”, cioè
bisogna che queste attività siano presenti nelle procedure aziendali, che vengano monitorate, e
adattate (tailorizzate) volta per volta ai vari progetti, secondo criteri precisi e stabiliti a priori.
L’azienda si avvale di una Procedura Gestionale, la PG.04, per gestire oltre che
pianificare un progetto. Dall’analisi è emerso che però questa risulta incompleta rispetto ai
requisiti imposti dal modello CMMI, e va dunque ampliata.
L’analisi dei dati ha evidenziato inoltre che alcune attività vengono eseguite a buoni
livelli, e in maniera pienamente rispondente ai requisiti del CMMI, come per esempio il
controllo della gestione dei dati di progetto, le revisioni alle milestone, il monitoraggio di
costi, effort, commitment, e l’identificazione dei problemi che hanno bisogno di azioni
correttive.
Di seguito viene riportata graficamente la situazione di partenza della CHORUS per
l’implementazione del CMMI, dal punto di vista delle pratiche specifiche dell’Area di
processo del Monitoraggio e Controllo del Progetto, che risultano soddisfatte, non soddisfatte,
o parzialmente soddisfatte:
101
Monitoraggio e Controllo del Progetto
PRATICHE SPECIFICHE
5,00%
14,000%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
81%
Figura 5.1 – Stima in percentuale delle pratiche specifiche per l’Area di Monitoraggio e
Controllo del Progetto.
102
Progettazione del nuovo sistema procedurale
6.
PROGETTAZIONE DEL NUOVO SISTEMA
PROCEDURALE
La terza ed ultima fase dello stage in azienda ha riguardato l’ideazione e progettazione
di un nuovo sistema di procedure aziendali, completamente innovativo rispetto a quello
esistente, rivelatosi inadatto ed insufficiente per soddisfare i requisiti del modello CMMI.
6.1 Quadro d’insieme: il nuovo sistema procedurale
Sulla base dei risultati dell’analisi dei dati derivanti dalla fase di assessment, è emerso
con chiarezza che il sistema di Procedure Gestionali dell’azienda non era in grado di coprire
in modo efficace tutti i vincoli del CMMI, e che non sarebbe stato possibile adattare queste
procedure ed integrarle in maniera lineare, agile e completa per ottenere la copertura delle
pratiche del modello. Da qui è nato un lungo e costruttivo dibattito all’interno di tutto il
gruppo di lavoro, che ci ha portato alla decisione di creare ex-novo un sistema di procedure
aziendali. Siamo arrivati all’individuazione del nuovo sistema partendo dalle relazioni tra
tutte le Aree di processo su cui l’azienda ha deciso di agire, relazioni che abbiamo evidenziato
man mano che il nostro lavoro progrediva.
Per quanto riguarda il mio contributo personale, ho provveduto alla progettazione e
stesura dell’intera procedura “Pianificazione e Gestione Progetti”, che abbraccia appieno tutte
e due le Aree di processo di cui mi sono occupata. Per affinità di argomento e per
completezza, ho inglobato nella procedura da me scritta anche tutta la parte
dell’identificazione, analisi e gestione dei rischi. La CHORUS provvederà in un secondo
momento a scorporarla e a farne una procedura a se stante, ma questa è una questione soltanto
formale, e non sostanziale.
Nella figura seguente sono riportate le Aree di Processo di cui noi stagisti ci siamo
occupati, con evidenziate le relazioni emerse tra di esse, e l’indicazione delle nuove procedure
che, come si vede chiaramente, abbracciano e coprono in maniera organica tutte le Aree,
soddisfacendo appieno ai dettami del modello.
103
Progettazione del nuovo sistema procedurale
Abbiamo potuto ideare e realizzare questo nuovo sistema di procedure con la massima
flessibilità e libertà di scelta perché il CMMI fornisce soltanto delle linee guida molto
generiche, e sta all’azienda riuscire ad implementare il modello nella maniera più efficiente, e
meno costosa.
Procedura
Sviluppo e Gest ione
dei Requisit i
Procedura
Gestione
Offerte e
Ordini di Vendita
REQM
Procedura
Gestione
Rischi
RD
RSKM
PP
TS
Procedura
Progettazione
Sviluppo e
Implementazione
VER
VAL
Procedura
Pianificazione e
Gestione
Progett i
PMC
Procedura
Verifica e Validazione
PPQA
Sistema di
Gest ione
per la
Qualità
CM
Procedura
Gestione della
Configurazione
MA
Procedura
Metriche
Figura 6.1 – Il nuovo sistema procedurale.
104
Progettazione del nuovo sistema procedurale
6.2 Procedura di Pianificazione e Gestione Progetti
6.2.1 Descrizione
La procedura di Pianificazione e Gestione Progetti (che si trova nell’Appendice A)
costituisce gran parte del lavoro personale svolto in azienda. Per la sua redazione ho seguito i
dettami del modello CMMI in maniera molto rigorosa, riferendomi in ogni fase al manuale
“CMMI for Development vers. 1.2”, che costituisce il documento ufficiale da applicare.
Il principio fondamentale che ho utilizzato per la composizione della procedura è stato
quello di fornire uno strumento di tracciabilità con le pratiche specifiche e con le relative
sottopratiche che fosse evidente, comprensibile, rapido ed efficace, e che consentisse
all’azienda di ottenere uno strumento per seguire rigorosamente il modello in questione
durante l’intero svolgimento di un progetto, ma anche una prova tangibile ed inconfutabile del
raggiungimento di un determinato livello di capability per l’organo competente per la
registrazione al SEI, cioè la Business Strategy, società partner SEI. Per questo motivo ogni
paragrafo della procedura riporta un riferimento alle pratiche dell’Area di processo accanto al
titolo.
Gli argomenti trattati dalla procedura si possono evincere dal testo della procedura
stessa. Questa inoltre costituisce una guida per la redazione di documenti di progetto
fondamentali, che sono:
•
PMP (Project Management Plan), che contiene il piano dettagliato del progetto
e di ogni suo aspetto, come il programma temporale (schedule), la previsione
di costi, budget, la soluzione tecnica adottata, l’allocazione di risorse, il
coinvolgimento degli stakeholder (coloro che condividono gli interessi nel
progetto), la gestione dei dati, l’identificazione ed analisi dei rischi;
•
PPR (Periodical Progress Report), mediante il quale si effettua tutto il
monitoraggio e controllo sulle attività di progetto, si gestiscono le azioni
correttive, e anche una eventuale ripianificazione se necessaria. E’ lo strumento
chiave per rilevare il reale stato di avanzamento dei lavori, e lo scostamento
della situazione attuale con quella stimata in fase di pianificazione.
L’indice di questi documenti si trova nelle Appendici A e B.
105
Progettazione del nuovo sistema procedurale
6.2.2 Mapping delle pratiche CMMI con la procedura
Una volta effettuato l’assessment della situazione aziendale, e una volta assicurata la
corrispondenza uno a uno tra le varie attività previste dalla procedura e le pratiche specifiche
delle Aree di processo di cui sopra, è risultato indispensabile fornire una prova della
tracciabilità inversa tra la procedura e le pratiche e sottopratiche del CMMI, come verifica
della completezza ed efficienza del lavoro svolto.
Di seguito sono riportate delle tabelle: ogni tabella corrisponde ad una pratica
specifica di un’Area di processo, ed in ognuna di esse sono specificate tutte le sottopratiche
relative. Viene indicata non solo la procedura, ma anche il paragrafo specifico in cui viene
coperta una determinata sottopratica. Le procedure gestionali CHORUS del nuovo sistema
procedurale sono indicate con la sigla CM, seguita da due cifre. La procedura di
“Pianificazione e Gestione Progetti” è la CM.02. Inoltre nelle tabelle si trova un’indicazione
del documento prodotto, che rappresenta l’evidenza oggettiva che l’azienda sta mettendo in
atto i dettami del modello, secondo il nuovo sistema di procedure creato.
E’ da sottolineare che questa doppia tracciabilità è fondamentale, perché costituisce
una doppia prova dell’istituzionalizzazione del modello per quelle Aree di processo che la
CHORUS ha deciso di trattare per arrivare al livello 3 di maturità.
106
Progettazione del nuovo sistema procedurale
SP 1.1 Valutare la Struttura del Progetto
Telespazio Cosmo Sky-Med TPZPFS004
1. Descrizioni dei Task
Typical Work 2. Descrizioni del pacchetto di lavoro (work package)
Products
3. WBS - Strut ura di Ripartizione del Lavoro
Procedura Gestionale
Documento di Output
-----
-----
-----
-----
-----
-----
CM.02
PMP
1. Sviluppare una WBS basata sul 'architet ura del prodotto "Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.1.1.1
2. Identificare i pacchet i di lavoro (work packages) con un
CM.02
PMP
dettaglio suf iciente a specificare le stime dei task del progetto, "Pianificazione e Gestione Progetti"
(Project Management Plan)
le responsabilità, e il programma (schedule).
par. 4.1.1.2
Subpractices
CM.02
3. Identificare il prodotto o i componenti di prodotto che
PMP
"Pianificazione e Gestione Progetti"
saranno acquisiti esternamente.
(Project Management Plan)
par. 4.1.1.3
4. Identificare i "work products" che saranno riutiliz ati
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.1.1.4
107
Progettazione del nuovo sistema procedurale
SP 1.2 Stabilire le Stime delle Caratteristiche dei Work Products e dei Tasks
Telespazio Cosmo Sky- Med TPZPFS004
1. Approccio tecnico
Procedura Gestionale
Documento di Output
-----
-----
2. Dimensione e comples ità di task e "work products"
Typical Work
Products 3. Valutazione dei modelli
-----
-----
-----
-----
4. Valutazione delle carat eristiche
-----
-----
1. Determinare l'approccio tecnico per il progetto
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.1.2.1
Subpractices 2. Utilizzare metodi appropriati per determinare le
CM.02
PMP
carat eristiche dei "work products" e dei task che saranno usati "Pianificazione e Gestione Progetti"
(Project Management Plan)
per valutare i requisiti delle risorse
par. 4.2.2
CM.02
PMP
3. Valutare le carat eristiche dei "work products" e dei task "Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.1.2.3
108
Progettazione del nuovo sistema procedurale
SP1.3DefinrlCcodiVtaelProgt
TelspazioCmSky-MedTPZFS04 ProceduaGstionle DocumentdiOupt
C M .0 2
TypicalWork PM
1.PianfcrelasidCcloiVta "PianfczoeGstinProgeti"
Products (ProjectMangmetPlan)
par.413
109
Progettazione del nuovo sistema procedurale
SP 1.4 Determinare le Stime di Impegno e Costo
Telespazio Cosmo Sky- Med TPZPFS004
1. Valutazione del e motivazioni del e decisioni (rationale)
Typical Work
Products 2. Stime dell'Impegno sul Proget o
3. Stime del Costo del Proget o
Procedura Gestionale
Documento di Output
-----
-----
-----
-----
-----
-----
CM.02
1. Raccogliere i model i o i dati storici che saranno utiliz ati
PMP
per trasformare le carat eristiche dei "work products" e dei task "Pianificazione e Gestione Proget i"
(Project Management Plan)
in stime del e ore di lavoro e del costo.
par. 4.1.4.1
SCM.02
PMP
2. Includere le neces ità di una infrastrut ura di supporto
Subpractices
"Pianificazione e Gestione Proget i"
durante la stima di impegno e costo.
(Project Management Plan)
par. 4.1.4.2
CM.02
PMP
3. Stimare impegno e costo utiliz ando model i e/o dati storici. "Pianificazione e Gestione Proget i"
(Project Management Plan)
par. 4.1.4.3
110
Progettazione del nuovo sistema procedurale
SP 2.1 Stabilire il Budget e il Programma (Schedule)
Telespazio Cosmo Sky-Med TPZPFS004
Procedura Gestionale
Documento di Output
-----
-----
Typical Work 2. Dipendenze di programma (schedule)
Products
-----
-----
3. Budget di progetto
-----
-----
1. Programmi (Schedules) di progetto
1. Identificare le "milestones" più importanti
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.1.1
2. Identificare le assunzioni di programma (schedule)
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.1.2
3. Identificare i vincoli
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.1.3
4. Identificare le dipendenze tra i compiti (tasks)
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.1.4
5. Definire il budget e il programma (schedule)
CM.02
"Pianificazione e Gestione Progetti"
par. 4.2.1.5
6. Stabilire i criteri delle azioni correttive
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.1.6
Subpractices
SAP
(Stato di Avanzamento
Progetto)
e GANTT
111
Progettazione del nuovo sistema procedurale
SP 2.2 Identificare i Rischi di Proget o
Telespazio Cosmo Sky-Med TPZPFS004
1. Rischi identificati
Typical Work
2. Effet i di rischio e probabilità di occor enza
Products
3. Priorità di rischio
Subpractices
Procedura Gestionale
Documento di Output
-----
-----
-----
-----
-----
-----
1. Identificare i rischi
CM.02
RMP
"Pianificazione e Gestione Proget i"
(Risk Management Plan)
par. 4.2.2.1-2-4
2. Documentare i rischi
CM.02
RMP
"Pianificazione e Gestione Proget i"
(Risk Management Plan)
par. 4.2.2.1-4
CM.02
3. Revisionare e ottenere un'ac ordo con gli stakeholder sul a
RMP
"Pianificazione e Gestione Proget i"
completez a e cor et ez a dei rischi documentati
(Risk Management Plan)
par. 4.2.2
4. Revisionare i rischi in modo ap ropriato
CM.02
RMP
"Pianificazione e Gestione Proget i"
(Risk Management Plan)
par. 4.2.2
112
Progettazione del nuovo sistema procedurale
SP 2.3 Piano per la Gestone dei Dati
Telespazio Cosmo Sky-Med TPZPFS004
Procedura Gestionale
Documento di Output
1. Piano della gestione dei dati
-----
-----
2. Lista principale dei dati gestiti
-----
-----
3. Contenuto dei dati e descrizione del formato
-----
-----
4. Liste dei requisiti sui dati per acquirenti e fornitori
-----
-----
Typical Work 5. Requisiti di privacy
Products
6. Requisiti di sicurezza
-----
-----
-----
-----
7. Procedure di sicurezza
-----
-----
8. Meccanismo di recupero, riproduzione e distribuzione dei
dati
-----
-----
9. Programma (schedule) per la raccolta dei dati di progetto
-----
-----
10. Lista dei dati di progetto da raccogliere
-----
-----
1. Stabilire i requisiti e le procedure per assicurare la privacy e
la sicurezza dei dati
CM.01
"Gestione della Configurazione"
par. 4.2
PMP
(Project Management Plan)
2. Stabilire un meccanismo per archiviare i dati e per accedere
Subpractices
ai dati archiviati
CM.01
"Gestione della Configurazione"
par. 4.2
PMP
(Project Management Plan)
3. Determinare i dati di progetto che devono essere identificati,
raccolti e distribuiti
CM.01
"Gestione della Configurazione"
par. 4.2
PMP
(Project Management Plan)
113
Progettazione del nuovo sistema procedurale
SP 2.4 Piano per le Risorse di Progetto
Telespazio Cosmo Sky-Med TPZPFS004
Typical Work
Products
Procedura Gestionale
Documento di Output
1. Pacchetti di lavoro (work packages) delle WBS
-----
-----
2. Dizionario dei task delle WBS
-----
-----
3. Requisiti di personale basati sulla dimensione e campo di
applicazione del progetto
-----
-----
4. Lista delle facilities (applicazioni)/apparecchiature critiche
-----
-----
5. Definizioni e diagrammi del processo/flusso di lavoro
-----
-----
6. Lista dei requisiti dell'amministrazione del programma
-----
-----
1. Determinare i requisiti del processo
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.4.1
Subpractices 2. Determinare i requisiti del personale
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.4.2
3. Determinare i requisiti di facilities, apparecchiature e
componenti
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.4.3
114
Progettazione del nuovo sistema procedurale
SP 2.5 Piano per le Conoscenze e le Competenze Richieste
Telespazio Cosmo Sky-Med TPZPFS004
Procedura Gestionale
Documento di Output
-----
-----
Typical Work
Products 2. Piani per la costituzione dello staf e per le nuove assunzioni
-----
-----
3. Database (i.e., competenze e formazione)
-----
-----
1. Inventario delle necessità delle competenze (skil )
CM.02
1. Identificare le conoscenze e le competenze necessarie per
PMP
"Pianificazione e Gestione Progetti"
eseguire il progetto
(Project Management Plan)
par. 4.2.5.1
2. Valutare le conoscenze e le competenze disponibili
Subpractices
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.5.2
CM.02
3. Selezionare i meccanismi per procurarsi le conoscenze e le
PMP
"Pianificazione e Gestione Progetti"
competenze necessarie
(Project Management Plan)
par. 4.2.5.3
CM.02
PMP
4. Incorporare i meccanismi selezionati nel piano di progetto "Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.2.5.4
115
Progettazione del nuovo sistema procedurale
SP2.6PianoperilCoinvolgimentodegliStakeholder
Tel spazioCosmoSky-MedTPZPFS0 4
ProceduraGestionale DocumentodiOutput
CM.02
PMP
TypicalWork
1.PianoperilcoinvolgimentodeloStakeholder "Pianif cazione GestioneProgeti"
(ProjectManagementPlan)
Products
par.4.26
· Fareunalistaditu tiglistakeholder
· Motivazioni(rationale)perilcoinvolgimentodeglistakeholder
· Ruolie responsabiltàdeglistakeholder iguardoalproget o,atraversolafasedelci lodivitadelprogeto
Esempi · Rap orti raglistakeholder
· Importanzadelostakeholder elativa lsuc es odelproget o,atraversolafasedelci lodivitadelproget o
· Risorse (e.g,train g,materiali,tempo,fondi)neces ariadas icurarel'interazionedelostakeholder
· Program azione(schedule)dele fasidel'interazione del ostakeholder
116
Progettazione del nuovo sistema procedurale
SP 2.7 Stabilire il Piano di Proget o
Telespazio Cosmo Sky-Med TPZPFS004
Typical Work
1. Piano di proget o generale
Products
Procedura Gestionale
Documento di Output
CM.02
PMP
"Pianificazione e Gestione Proget i"
(Project Management Plan)
par. 4.2.7
· Piano Principale Integrato - un piano event-driven che documenti realiz azioni significative mediante criteri suc es o/insuc es o
sia per il busines che per gli elementi tecnici del proget o e che leghi ogni realiz azione con un evento chiave del programma.
· Programma (schedule) Principale integrato – un programma dei compiti integrato e interconnes o a più livel i, richiesto per
completare il lavoro documentato in un Piano Principale Integrato cor elato.
· Piano di Gestione Ingegneria dei Sistemi – un piano che descrive in det aglio l'impegno tecnico integrato attraverso tut o il
Esempi proget o.
· Programma (schedule) Principale Ingegneria dei Sistemi – un programma event-based che contenga una rac olta di realiz azioni
tecniche chiave, ognuna con criteri misurabili, e che richieda un completamento con suc es o per il superamento di eventi
identificati.
· Programma (schedule) Det agliato Ingegneria dei Sistemi – un programma det agliato, a dipendenza temporale, task-oriented, che
associ specifiche date e milestones al Programma Principale Ingegneria dei Sistemi.
117
Progettazione del nuovo sistema procedurale
SP3.1RevisonareiPancheInflu zanoilPrgeto
TelspazioCsmoSky-MedTPZFS04 ProceduaGestionale documentodiOutp
CM.02 MO dirunoiatvedal
TypicalWork 1.Registrazonedlrevisondeipancheiflunzaoil
"Pianfczione GstionePrgti" PM
Products proget
par.431 (ProjectMangemtPlan)
118
Progettazione del nuovo sistema procedurale
SP 3.2 Verifica di Copertura del e Attività con le Risorse
Telespazio Cosmo Sky-Med TPZPFS0 4
Procedura Gestionale
Documento di Output
1. Metodi revisionati e cor ispondente valutazione dei
CM.02
PMP
parametri (per esempio, strumenti migliori e uso di componenti "Pianificazione e Gestione Proget i"
(Project Management Plan)
immediatamente disponibili)
par. 4.3.2.1
2. Budget rinegoziati
CM.02
PMP
"Pianificazione e Gestione Proget i"
(Project Management Plan)
par. 4.3.2.2
Typical Work
Products 3. Programmi (schedules) revisionati
CM.02
PMP
"Pianificazione e Gestione Proget i"
(Project Management Plan)
par. 4.3.2.3
4. Lista dei requisiti revisionata
CM.02
PMP
"Pianificazione e Gestione Proget i"
(Project Management Plan)
par. 4.3.2.4
5. Accordi con lo stakeholder rinegoziati
CM.02
PMP
"Pianificazione e Gestione Proget i"
(Project Management Plan)
par. 4.3.2.5
119
Progettazione del nuovo sistema procedurale
SP 3.3 Ottenere l'Impegno all'Esecuzione del Piano
Typical Work
Products
Telespazio Cosmo Sky-Med TPZPFS004
Procedura Gestionale
Documento di Output
1. Richieste documentate per gli impegni
-----
-----
2. Impegni documentati
-----
-----
CM.02
PMP
1. Identificare il supporto necessario e negoziare gli impegni
"Pianificazione e Gestione Progetti"
(Project Management Plan)
con gli stakeholder.
par. 4.3.3.1
CM.02
2. Documentare tut i gli impegni organizzativi, sia pieni che
PMP
"Pianificazione e Gestione Progetti"
provvisori, accertando il livello adatto dei firmatari.
(Project Management Plan)
par. 4.3.3.2
3. Revisionare le commesse interne con l'amministrazione
principale in modo appropriato.
CM.02
PMP
"Pianificazione e Gestione Progetti"
(Project Management Plan)
par. 4.3.3.3
Subpractices
CM.02
4. Revisionare gli impegni esterni con il management in modo
PMP
"Pianificazione e Gestione Progetti"
appropriato.
(Project Management Plan)
par. 4.3.3.4
5. Identificare gli impegni sulle interfacce tra gli elementi del
CM.02
PMP
progetto e degli altri progetti ed unità organizzative, in modo "Pianificazione e Gestione Progetti"
(Project Management Plan)
che possano essere monitorati.
par. 4.3.3.5
120
Progettazione del nuovo sistema procedurale
Per l’Area di processo del Monitoraggio e Controllo del Progetto, le tabelle con la
mappatura tra le pratiche specifiche e le nuove procedure gestionali sono riportate di seguito:
SP 1.1 Monitorare i Parametri della Pianificazione del Progetto
Progetto Enav - ENVSTN003
Procedura Gestionale
Documento di Output
1. Registrazioni della performance di progetto
-----
-----
2. Registrazione di deviazioni significative rispetto al piano
-----
-----
Typical Work
Products
1. Monitoraggio dello stato di avanzamento lavori e
scostamenti rispetto alla pianificazione
CM.02
PPR
"Pianificazione e Gestione Progetti"
(Periodical Progress Report)
par. 4.4.1.1
2. Monitoraggio dei costi e dell'impegno previsto
CM.02
PPR
"Pianificazione e Gestione Progetti"
(Periodical Progress Report)
par. 4.4.1.2
3. Monitoraggio delle caratteristiche dei Task e dei work
products
CM.02
PPR
"Pianificazione e Gestione Progetti"
(Periodical Progress Report)
par. 4.4.1.3
4. Monitoraggio delle risorse approvigionate e impiegate
CM.02
PPR
"Pianificazione e Gestione Progetti" (Periodical Progress Report)
par. 4.4.1.4
MPR
5. Monitoraggio degli skill e delle conoscenze del personale
assegnato al progetto
CM.02
PPR
"Pianificazione e Gestione Progetti"
(Periodical Progress Report)
par. 4.4.1.5
Subpractices
CM.02
6. Documentare gli scostamenti significativi nei parametri di
PPR
"Pianificazione e Gestione Progetti"
pianificazione del progetto
(Periodical Progress Report)
par. 4.4.1.6
121
Progettazione del nuovo sistema procedurale
SP 1.2 Monitorare gli Impegnidel Proget o
Proget o ENAV-ENVSTN0 3
Typical Work
1. Registrazionedel erevis oni degli mpegni
Products
Procedura Gestionale Documento di Output
---
---
CM.02
PR
1. Revis onareregolarmentegli mpegni (sia interni che
"Pianifcazione Gestione Proget i"
(Periodical Progres Report)
esterni)
par. 4. .2.1
CM.02
Subpractices 2. Identifcare gli mpegni chenon sono sta i sod isfat i o che "Pianifcazione Gestione Proget i" P R
han o un signif cativo rischio di non es eresod isfat i
(Periodical Progres Report)
par. 4. .2.2
CM.02
MOM
3. Documentarei risulta i del e revis onidegli mpegni "Pianifcazione Gestione Proget i" (Minute OfMeeting)
par. 4. .2.3 ag iornate
122
Progettazione del nuovo sistema procedurale
SP 1.3 Monitorare i Rischi di Proget o
Proget o ENAV - ENVSTN0 3
Typical Work
1. Registrazioni del monitorag io dei rischi di proget o
Products
Procedura Gestionale Documento di Output
---
---
CM.02
Aggiornamento del RMP
1. Verif care periodicamente i piani di rischio in relazione
"Pianif cazione e Gestione Proget i"
(Risk Management Plan)
al 'at uale stato del proget o ed analiz are ventuali crit cità
par. 4.4.3.1
2. Ef et uare ag iornamenti sui piani di rischio non ap ena ci CM.02
Aggiornamento del Piano di
Subpractices sono informazioni disponibil , per incorporare le modif che ai "Pianif cazione e Gestione Proget i" Gestione dei Rischi (RMP)
par. 4.4.3.2
sud et i piani
3. Condividere comunicare al personale coinvolto sia interno CM.02
RMP/MOM
che ad eventuali fornitori o col aboratori gli eventuali rischi "Pianif cazione e Gestione Proget i" (di riunioni previste nel RMP
emersi
par. 4.4.3.3
stes o)
123
Progettazione del nuovo sistema procedurale
SP 1.4 Monitorare la Gestione dei Dati
Proget o ENAV - ENVSTN0 3
Typical Work
1. Registrazione del a gestione dei dati
Products
Procedura Gestionale Documento di Output
---
---
CM.02
PR
1. Revis onare periodicamente le at ività di gestione dei dati n
"Pianif cazione e Gestione Proget i"
(Periodical Progres Report)
base al a loro descrizione nel piano di proget o
par. 4.4.4.1
CM.02
2. Identif care documentare problemi signif cativi ed i loro
PR
"Pianif cazione e Gestione Proget i"
Subpractices impat i
(Periodical Progres Report)
par. 4.4.4.2
CM.02
3. Documentare i risultati del e revis oni del e at ività di
PR
"Pianif cazione e Gestione Proget i"
(Periodical Progres Report)
gestione dei dati
par. 4.4.4.3
124
Progettazione del nuovo sistema procedurale
SP 1.5 Monitorare il Coinvolgimento degli Stakeholder
Proget oENAV -ENVSTN0 3
Typical Work
1. Registrazioni del coinvolgimento degli stakeholder
Products
Procedura Gestionale Documento di Output
---
---
CM.02
1. Verif care periodicamente lo stato del coinvolgimento degli
MOM di riunioni periodiche
"Pianif cazione Gestione Proget i"
con gli stakeholder
stakeholder
par. 4.4.5.1
CM.02
2. Identif care documentare problemi signif cativi ed i loro
MOM di riunioni periodiche
Subpractices
"Pianif cazione Gestione Proget i"
impat i
con gli stakeholder
par. 4.4.5.2
CM.02
3. Documentarei risultati del erevis oni del o sta o di
MOM di riunioni periodiche
"Pianif cazione Gestione Proget i"
coinvolgimento degli stakeholder
con gli stakeholder
par. 4.4.5.3
125
Progettazione del nuovo sistema procedurale
SP 1.6 Effettuare Revisioni sullo Stato di Avanzamento
Progetto ENAV - ENVSTN003
Typical Work 1. Documentare i risultati delle attività di revisione sul
Products progetto
Procedura Gestionale
Documento di Output
-----
-----
1. Comunicare regolarmente lo stato delle attività assegnate e
dei "work products" agli stakeholder
PPR
CM.02
(Periodical Progress Report) e
"Pianificazione e Gestione Progetti"
conseguente aggiornamento del
par. 4.4.6.1
GANTT
2. Revisionare i risultati della raccolta e dell'analisi delle
misure per controllare il progetto
PPR
CM.02
(Periodical Progress Report) e
"Pianificazione e Gestione Progetti"
conseguente aggiornamento del
par. 4.4.6.2
GANTT
3. Identificare e documentare le problematiche e le deviazioni
significative rispetto al piano
CM.02
PPR
"Pianificazione e Gestione Progetti" (Periodical Progress Report) e
par. 4.4.6.3
MOM di riunioni periodiche
4. Documentare le richieste di cambiamento e i problemi
identificati in ognuno dei work product e processi
CM.02
"Pianificazione e Gestione Progetti"
par. 4.4.6.4
5. Documentare i risultati delle revisioni
PPR
CM.02
(Periodical Progress Report) e
"Pianificazione e Gestione Progetti"
documenti applicabili
par. 4.4.6.5
richiamati
Subpractices
CM.02
6. A chiusura registrare i report dei cambiamenti ed i problemi
"Pianificazione e Gestione Progetti"
riscontrati
par. 4.4.6.6
PPR
(Periodical Progress Report)
PAL (Progress Action List)
da creare
126
Progettazione del nuovo sistema procedurale
SP 1.7 Effettuare Revisioni sulle Milestone
Progetto ENAV - ENVSTN003
Typical Work 1.Risultati documentati delle revisioni effettuate sulle
Products milestone
Procedura Gestionale
Documento di Output
-----
-----
1. Effettuare revisioni sui punti cardine del programma
(schedule) di progetto, come il completamento di fasi
selezionate, con gli stakeholder
CM.02
PPR
"Pianificazione e Gestione Progetti"
(Periodical Progress Report)
par. 4.4.7.1
2. Revisionare gli impegni, il piano, lo stato ed i rischi del
progetto
CM.02
PPR
"Pianificazione e Gestione Progetti"
(Periodical Progress Report)
par. 4.4.7.2
PPR
(Periodical Progress Report)
CM.02
3. Identificare e documentare problemi significativi ed i loro
SPR
"Pianificazione e Gestione Progetti"
impatti
(Software Problem Report)
par. 4.4.7.3
Subpractices
RID
(Review Item Discrepance)
4. Documentare i risultati della revisione, delle eventuali
attività e decisioni
SPR
CM.02
(Software Problem Report)
"Pianificazione e Gestione Progetti"
RID
par. 4.4.7.4
(Review Item Discrepance)
PAL (Progress Action List)
5. Tenere traccia degli items delle azioni di chiusura.
CM.02
"Pianificazione e Gestione Progetti"
par. 4.4.7.5
PAL
(Progress Action List)
127
Progettazione del nuovo sistema procedurale
SP2.1AnalizareiProblemi
ProgetoENAV-ENVSTN0 3
ProceduraGestionale DocumentodiOutput
CM.02
PAL
TypicalWork
1.Listadeiproblemiche an obisognodiazion coretive "Pianficazione GestioneProgeti"
(Proges ActionList)
Products
par.4 .81
1.Riunreiproblemiperl'an lis
Subpracti es
-- --
2.Analiz areiproblemiperdet rminarel'sigenzadiazion
-- -coretive
128
Progettazione del nuovo sistema procedurale
SP 2.2 Effet uare Azioni Correttive
Proget o ENAV - ENVSTN003
Typical Work
1. Piano per le azioni cor et ive
Products
1. Determinare e documentare le azioni neces arie e
appropriate per indiriz arsi verso i problemi identificati
Procedura Gestionale
Documento di Output
-----
-----
CM.02
PAC
"Pianificazione e Gestione Proget i" (Piano per le Azioni
par. 4.4.9.1
Corret ive)
PAC
CM.02
Subpractices 2. Revisionare e ottenere un accordo con gli stakeholder sul e
(Piano per le Azioni
"Pianificazione e Gestione Proget i"
Corret ive)
azioni da prendere
par. 4.4.9.2
e MOM
PAC
CM.02
(Piano per le Azioni
3. Concordare i cambiamenti agli impegni interni ed esterni "Pianificazione e Gestione Proget i"
Corret ive)
par. 4.4.9.3
e MOM
129
Progettazione del nuovo sistema procedurale
SP 2.3 Gestire Azioni Correttive
Proget o ENAV - ENVSTN003
Typical Work
1. Risultato del e azioni cor et ive
Products
Procedura Gestionale
Documento di Output
-----
-----
1. Monitorare le azioni cor et ive per il completamento
CM.02
"Verifica del e Azioni
"Pianificazione e Gestione Proget i"
Corret ive"
par. 4.4.10.1
Subpractices 2. Analiz are i risultati del e azioni intraprese al fine di
determinarne l'ef et iva ef icacia
CM.02
"Verifica del e Azioni
"Pianificazione e Gestione Proget i"
Corret ive"
par. 4.4.10.2
CM.02
3. Determinare e documentare le azioni appropriate per
"Verifica del e Azioni
cor eggere le deviazioni dai risultati pianificati per le azioni "Pianificazione e Gestione Proget i"
Corret ive"
cor et ive.
par. 4.4.10.3
130
Progettazione del nuovo sistema procedurale
131
Progettazione del nuovo sistema procedurale
6.3 Scheda Progetto
La Scheda Progetto è una tabella che riporta tutti i processi del ciclo di vita del
software, così come contemplato dalla norma ISO 12207, visto che la CHORUS si occupa di
sviluppo e manutenzione di prodotti e servizi software. Questi processi sono suddivisi in
attività, e le attività sono messe in relazione uno a uno con le pratiche e sottopratiche delle
Aree del CMMI. Il tutto poi è correlato al nuovo sistema di procedure, e questo rende la
Scheda uno strumento indispensabile per portare avanti un progetto.
Qui sotto ho riportato una parte della Scheda Progetto che abbraccia le Aree di cui mi
sono occupata. Come si evince dalla figura, ad ogni processo della 12207 corrispondono una
o più Aree del CMMI, perché i due approcci sono differenti: statico quello della 12207,
ricorsivo ed iterativo quello del CMMI. A prima vista questa mappatura può risultare inutile,
ma non è cosi. Infatti la Scheda Progetto permette di mantenere una sequenza temporale nelle
attività di progetto, sequenza che il CMMI invece non considera, perché appunto si focalizza
su Aree di attività. La Scheda quindi nasce da una doppia esigenza: continuare a soddisfare i
dettami di una norma internazionale (ISO 12207) e allo stesso tempo iniziare ad
implementarne un altro standard (CMMI). Costituisce dunque il frutto di un’esperienza
lavorativa concreta, e serve a soddisfare un’esigenza pratica che solo uno stage ha potuto
mettere in luce.
132
Progettazione del nuovo sistema procedurale
Processi del Ciclo di
Vita (norma ISO/IEC
12207)
Attività dei
Processi
Pratiche Specifiche (CMMI)
Aree di Processo (CMMI)
1.1
Obtain an Understanding of
Requirements
1.2
Obtain Commitment to Requirements
1.1
Elicit Needs
1.2
Develop the Customer Requirements
Requirements Management
5.1
Vendita (Processo
Primario)
3.1
Avvio
Requirements Development
3.2
Procedura
Gestionale
Establish Operational Concept and
Scenarios
Establish a Definition of Required
Funcionality
3.3
Analyze Requirements
3.4
Analyze Requirements to Achieve
Balance
3.5
Validate Requirements
Supplier Agreement Management
1.1
Determine Acquisition Type
Non Applicabile per il CMMI
N.A.
Avvio
Preparazione della
risposta
N.A.
Contratto
Requirements Development
Risk Management
Technical Solution
3.3
Analyze Requirements
3.4
Analyze Requirements to Achieve
Balance
TUTTE
2.4
CM.02 par. 4.2.2
Perform Make, Buy, or Reuse
Analyses
Organizational Process Definition
TUTTE
+ IPPD
Pianificazione
Project Planning
Fornitura (Processo
5.2
Primario)
Measurement and Analysis
1.1
Estimate the Scope of the Project
CM.02 par.4.1.1
1.2
Establish Estimate of Work product
and Task Attribute
CM.02 par. 4.1.2
1.4
Determine Estimates of Effort and Cost CM.02 par. 4.1.4
2.1
Establish the Budget and Schedule
CM.02 par. 4.2.1
2.2
Identify Project Risks
CM.02 par. 4.2.2
2.3
Plan for Data Management
CM.02 par. 4.2.3
2.4
Plan for Project Resources
CM.02 par. 4.2.4
2.5
Plan for Needed Knowledge and Skills
CM.02 par. 4.2.5
2.6
Plan Stakeholder Involvement
CM.02 par. 4.2.6
Monitor Project Planning Parameters
CM.02 par. 4.4.1
1.2
Monitor Commitments
CM.02 par. 4.4.2
1.3
Monitor Project Risks
CM.02 par. 4.4.3
1.4
Monitor Data Management
CM.02 par. 4.4.4
1.5
Monitor Stakeholder Involvement
CM.02 par. 4.4.5
1.6
Conduct Progress Reviews
CM.02 par. 4.4.6
1.7
Conduct Milestone Reviews
CM.02 par. 4.4.7
3.1
Review Plans that Affect the Project
CM.02 par. 4.3.1
TUTTE
1.1
Esecuzione e
controlli
Project Monitoring and Control
Riesami e
valutazioni
Project Planning
3.2
3.3
Consegna e
completamento
Reconcile Work and Resource Levels
Obtain Plan Commitment
CM.02 par. 4.3.2
CM.02 par. 4.3.3
Non trovata sulla versione 1.2
del Manuale CMMI
Figura 6.2 – Scheda Progetto.
133
Conclusioni
7.
CONCLUSIONI
Siamo partiti da una situazione aziendale in cui il livello di capability per le due Aree
di processo di cui mi sono occupata era 0, secondo la definizione per cui se anche soltanto una
pratica specifica non viene soddisfatta il livello di capability è zero.
Di seguito ho riportato le figure presenti nei capitoli precedenti, che rappresentano la
situazione delle due Aree di processo su cui ho lavorato:
PRATICHE SPECIFICHE
23,00%
6,000%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
71%
Figura 7.1 – Copertura per l’Area di Pianificazione.
PRATICHE SPECIFICHE
5,00%
14,000%
Soddisfatte
Parzialmente Soddisfatte
Non Soddisfatte
81%
Figura 7.2 – Copertura per l’Area di Monitoraggio e Controllo.
134
Conclusioni
In base all’analisi dei risultati dell’assessment, è stato ideato e realizzato un nuovo
sistema procedurale, diverso da quello esistente, in grado di soddisfare i requisiti del CMMI
per arrivare al livello 3 di maturity.
Siamo riusciti ad ottenere un metodo efficace, molto affidabile, snello, e poco
dispendioso dal punto di vista temporale, che permette 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, e di soddisfare ogni singola sottopratica di ogni singola
area di processo, il tutto senza che ci sia la necessità di fare formazione e training specifico.
Infatti, seguendo la Scheda Progetto dall’inizio fino alla chiusura del progetto, si crea
automaticamente un percorso da seguire per portare a termine ogni fase di ogni attività,
assicurando allo stesso tempo una tracciabilità totale di ogni step, e che allo stesso tempo
faccia crescere e maturare dal punto di vista professionale il personale e ogni membro dello
staff di progetto. Siamo cioè riusciti a realizzare una situazione di “Training on the Job”. La
Scheda Progetto consente inoltre una tailorizzazione del progetto schematica, chiara ed agile,
e questo è un requisito essenziale per il raggiungimento del livello 3 di maturity del CMMI,
obiettivo che la CHORUS S.r.l. si è posta di raggiungere entro il 2007.
135
Appendici
APPENDICI
APPENDICE A: Procedura “Pianificazione e Gestione Progetti”
Di seguito è riportata la Procedura Gestionale CM.02 della CHORUS S.r.l. da me
redatta, come risulta dalla sua ultima edizione e revisione.
136
Appendici
137
Appendici
138
Appendici
139
Appendici
140
Appendici
141
Appendici
142
Appendici
143
Appendici
144
Appendici
145
Appendici
146
Appendici
147
Appendici
148
Appendici
149
Appendici
150
Appendici
151
Appendici
152
Appendici
153
Appendici
154
Appendici
155
Appendici
156
Appendici
157
Appendici
158
Appendici
159
Appendici
160
Appendici
161
Appendici
APPENDICE B: TEMPLATE PMP (Project Management Plan)
162
Appendici
163
Appendici
APPENDICE C: TEMPLATE PPR (Periodical Progress Report)
164
Appendici
165
Appendici
166
Bibliografia
BIBLIOGRAFIA
[1]
Software Engineering Institute. 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.
http://www.sei.cmu.edu/publications/documents/02.reports/02tr011.html
[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.
http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html
[9]
Software Engineering Institute. The IDEAL Model.
http://www.sei.cmu.edu/ideal/ideal.html
[10]
M. Bolognani. Gestione delle società di software. Napoli: Edizioni Scientifiche
Italiane, 2003.
167
Bibliografia
[11]
International Organization for Standardization. ISO 9000: Quality management
systems – Fundamentals and vocabulary. 2000.
[12]
International Organization for Standardization. ISO 9001: Quality management
systems – Requirements. 2000.
[13]
International Organization for Standardization. ISO 9004: Quality management
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.
http://www2.umassd.edu/swpi/dod/mil-std-498/498-std.pdf
[19]
European Cooperation for Space Standardization. ECSS Web Site.
http://www.ecss.nl
168