ANALISI E MESSA IN OPERA IN AMBITO AZIENDALE DEL CMMI (CAPABILITY MATURITY MODEL INTEGRATION): PIANIFICAZIONE, MONITORAGGIO E CONTROLLO DEL PROGETTO

Transcript

1 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 CH.MO PROF. ROBERTO CUSANI LAUREANDA LUANA LIBERATORE MATRICOLA ANNO ACCADEMICO 2005/2006

2 Indice INDICE INTRODUZIONE GESTIONE DELLA QUALITA IL CONTESTO ORGANIZZATIVO STANDARD INTERNAZIONALI (ISO) UNI EN ISO 9001: UNI CEI ISO/IEC 12207: ISO IEC : ALTRI STANDARD (ECSS, MIL-STD-498, AQAP-160) MODELLI DI MATURITÀ I MODELLI CMM IL MODELLO CMMI E LA SUA EVOLUZIONE IL CMMI: OBIETTIVI E VANTAGGI IL CAPABILITY MATURITY MODEL INTEGRATION I COMPONENTI DEL MODELLO LE AREE DI PROCESSO OBIETTIVI GENERICI PRATICHE GENERICHE OBIETTIVI SPECIFICI PRATICHE SPECIFICHE TYPICAL WORK PRODUCT SOTTOPRATICHE I LIVELLI DI CAPABILITY I LIVELLI DI MATURITY LE DUE RAPPRESENTAZIONI LA RAPPRESENTAZIONE SCALARE LA RAPPRESENTAZIONE CONTINUA DIFFERENZE TRA LE DUE RAPPRESENTAZIONI...47 I

3 Indice 2.5 QUADRO CONCLUSIVO PER LA REGISTRAZIONE AZIENDALE APPROCCIO AZIENDALE AL CMMI OBIETTIVI AZIENDALI ORGANIZZAZIONE DEL GRUPPO DI LAVORO FASI DEL PROGETTO E DELLA SUA MESSA IN OPERA QUADRO D INSIEME: LE RELAZIONI TRA LE AREE DI PROCESSO PIANIFICAZIONE DEL PROGETTO DESCRIZIONE ASSESSMENT ANALISI DEI DATI RACCOLTI MONITORAGGIO E CONTROLLO DEL PROGETTO ASPETTI FONDAMENTALI FASE DI ASSESSMENT RISULTATI DELL ANALISI PROGETTAZIONE DEL NUOVO SISTEMA PROCEDURALE QUADRO D INSIEME: IL NUOVO SISTEMA PROCEDURALE PROCEDURA DI PIANIFICAZIONE E GESTIONE PROGETTI DESCRIZIONE MAPPING DELLE PRATICHE CMMI CON LA PROCEDURA SCHEDA PROGETTO CONCLUSIONI APPENDICI APPENDICE A: PROCEDURA PIANIFICAZIONE E GESTIONE PROGETTI APPENDICE B: TEMPLATE PMP (PROJECT MANAGEMENT PLAN) APPENDICE C: TEMPLATE PPR (PERIODICAL PROGRESS REPORT) BIBLIOGRAFIA II

4 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 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

5 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

6 Gestione della Qualità 1. GESTIONE DELLA QUALITA 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

7 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

8 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 e motivazione Tool ed apparecchiature Figura 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

9 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

10 Gestione della Qualità Le norme base della famiglia ISO 900X sono la ISO 9000, la ISO 9001, la ISO 9004, e la ISO 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 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

11 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 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

12 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 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 ( 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à, a livello europeo l Ente di riferimento per gli organismi di certificazione è lo IQNET ( che raggruppa enti che operano in 150 nazioni (incluso il CISQ). Questi organismi aderiscono poi allo IAF (International Accreditation Forum, ed allo EA (European Accreditation, 9

13 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 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

14 Gestione della Qualità 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

15 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

16 Gestione della Qualità Figura 1.3 I processi della ISO ISO IEC : 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

17 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 Software Engineering. Product Quality - Part 1: Quality model, 2001); 2) Le metriche per la misura della qualità esterna (ISO/IEC TR , 2003); 3) Le metriche per la misura della qualità interna (ISO/IEC TR , 2003); 4) Le metriche per la misura della qualità in uso (ISO/IEC TR , 2004). La parte per noi di maggior interesse è la 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

18 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

19 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

20 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

21 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

22 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 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

23 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) 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

24 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 IPD- CMM 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

25 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 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 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

26 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 v1.1 (1993) INCOSE SECAM (1996) Systems Engineering CMM v1.1 (1995) Software CMM v2, draft C (1997) EIA 731 SECM (1998) Integrated Product Development CMM (1997) CMMI for Acquisition v1.02 (2000) v1.1 (2002) CMMI for Development CMMI for Services Figura 1.4 Storia dei CMM 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

27 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, 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 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

28 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 ( 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

29 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 ROI (Return on Investment) 14% 7-4% 55% 4.0 : : : 1 Tabella 1: Riassunto dei risultati di performance del CMMI. 26

30 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 ERRORE TASSO DI PRODUTTIVITA Figura 1.5: Performance di produttività e di qualità del software per la Lockheed Martin. 27

31 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

32 Il Capability Maturity Model Integration Figura Struttura generale del modello CMMI 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

33 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

34 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) Descrizione Identificazione, pianificazione, coordinamento e implementazione del miglioramento. Process Management Organizational Process Definition +IPPD (OPD+IPPD) Organizational Training (OT) Organizational Process Performance (OPP) Organizational Innovation and Deployment (OID) Sviluppo e mantenimento del set di standard aziendali di processo e di prodotto. Identificazione delle necessità di formazione e di sviluppo/rilascio della formazione. Determinazione degli obiettivi quantitativi per la qualità e per le performance dei vari processi implementati dagli obiettivi di business. Selezione ed implementazione di miglioramenti incrementali ed innovativi, per generare benefici, gestendo l inversione in modo quantitativo. Figura Aree di processo della categoria Process Management. 31

35 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 Descrizione Project Management Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM) Integrated Project Management +IPPD (IPM+IPPD) Risk Management (RSKM) Quantitative Project Management (QPM) 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 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. Definizione e selezione di un processo per ogni singolo progetto che sia adattato (tailored) dallo standard dell organizzazione (vedere Organizational Process Definition +IPPD). Tale processo, definito specificatamente per un progetto, garantisce una visione integrata per quei gruppi di progetti con forte connotazione di integrazione tra le varie discipline. 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 Aree di processo della categoria Project Management. 32

36 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 relativa traduzione in requisiti di prodotto, con Requirements una soluzione concettuale di alto livello per Development (RD) ciascuna disciplina coinvolta, e sviluppo di una architettura funzionale preliminare. Gestione dei requisiti con un costante allineamento ai piani di progetto attraverso Requirements un efficace gestione delle modifiche e Management (REQM) rintracciabilità dei requisiti, dal cliente sino al prodotto finale. Sviluppo dei componenti e dati tecnici Engineering associati per la successiva integrazione Technical Solution (TS) attraverso la valutazione 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 Aree di processo della categoria Engineering. 33

37 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 Descrizione Support Configuration Management (CM) Process and Product Quality Assurance (PPQA) Measurement and Analysis (MA) Decision Analysis and Resolution (DAR) Causal Analysis and Resolution (CAR) 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 necessità e degli obiettivi di misurazione con l approccio alla misurazione, questo al fine di usare i risultati delle misurazioni per aspetti informativi o prendere appropriate azioni correttive. 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. 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 Aree di processo della categoria Support. 34

38 Il Capability Maturity Model Integration Ora passiamo alla descrizione dettagliata dei vari componenti di un area di processo 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 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 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 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

39 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 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 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

40 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

41 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. 5 Livelli di capability Area 1 Area 2 Area 3 Area 4 Aree di processo Figura 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

42 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

43 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

44 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

45 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

46 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 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

47 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 Struttura della rappresentazione scalare. La figura seguente mostra come sono raggruppate le aree di processo nella rappresentazione scalare, ovvero per livello di maturity. MA PPQA CM SAM PMC PP REQM Maturity Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 = Aree di processo selezionate per raggiungere il livello di maturità 3. Figura Aree di processo nella rappresentazione scalare. 44

48 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 Aree di processo per maturity level. 45

49 Il Capability Maturity Model Integration 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 Struttura della rappresentazione continua. 46

50 Il Capability Maturity Model Integration La figura seguente mostra come le aree di processo vengono utilizzate nella rappresentazione continua. 5 Livelli di capability Area 1 Area 2 Area 3 Area 4 Aree di processo Figura Aree di processo nella rappresentazione continua 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

51 Il Capability Maturity Model Integration Rappresentazione Continua L azienda seleziona le aree di processo e i livelli di capability basati sui propri obiettivi di miglioramento del processo. I progessi sono misurati usando i capability level, che: Misurano l istituzionalizzazione (maturity) di un particolare processo nell azienda. Vanno da 0 a 5. I profili dei capability level sono usati per raggiungere e tracciare l esecuzione del miglioramento dei processi. L Equivalent Staging (equivalente scalare) permette ad un organizzazione di utilizzare l approccio continuo al miglioramento del processo, per derivare un livello di maturity come parte di un appraisal (autovalutazione). Rappresentazione Scalare L azienda seleziona le aree di processo basate sui maturity level. I progressi sono misurati usando i maturity level, che: Misurano l istituzionalizzazione (maturity) di un insieme di processi nell azienda. Vanno da 1 a 5. I maturity level sono usati per raggiungere e tracciare l esecuzione del miglioramento dei processi. Non c è necessità di un meccanismo di equivalenza per tornare all approccio continuo. Figura 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

52 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 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

53 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

54 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

55 Il Capability Maturity Model Integration Nome Acronimo ML CL1 CL2 CL3 CL4 CL5 Requirements Management REQM 2 Project Planning PP 2 Project Monitoring and Control PMC 2 Target Profile 2 Supplier Agreement Management SAM 2 Measurement and Analysis MA 2 Process and Product Quality 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 Target Profile 3 Organizational Process Focus OPF 3 Organizational Definition +IPPD Process OPD +IPPD Organizational Training OT 3 Integrated Project Management +IPPD IPM +IPPD Risk Management RSKM 3 Decision Analysis and Resolution DAR Organizational Performance Process OPP 4 Quantitative Project Management QPM 4 Organizational Innovation and Deployment OID 5 Causal Analysis and Resolution CAR 5 Target Profile 4 Target Profile 5 Figura Target Profile. 52

56 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 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 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

57 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

58 Approccio aziendale al CMMI Project Planning Project Monitoring and Control Requirements Development Requirements Management Configuration Management Process and Product Quality Assurance Technical Solution Verification Validation Figura 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 IDEAL SM 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

59 Approccio aziendale al CMMI Il modello IDEAL non è solo una instanziazione del più famoso ciclo PDCA (Plan- Do-Check-Act), ma include una filosofia di lavoro, ben evidenziata dalla L finale, ovverosia catturare opportunamente l esperienza in database (quantitativi e qualitativi). Figura 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

60 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

61 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

62 Approccio aziendale al CMMI REQM RD RSKM TS PP VER VAL PMC PPQA CM MA Figura 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

63 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

64 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

65 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

66 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

67 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

68 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

69 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

70 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

71 Pianificazione del Progetto 4. PIANIFICAZIONE DEL PROGETTO 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

72 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

73 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

74 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

75 Pianificazione del Progetto SP 1.1 Valutare la Struttura del Progetto Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Descrizioni dei Task Descrizioni del pacchetto di lavoro (work package) WBS - Struttura di Ripartizione del Lavoro Sviluppare una WBS basata sull'architettura del prodotto PS 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 (CSK-CHO-PFSET-PMP ) Nota: (Gestione Progetto), che la WBS è del progetto, e non del prodotto genererà il PMP, e la PG.04A - PR (Progettazione e Realizzazione) Subpractices 2. Identificare i pacchetti di lavoro (work packages) con un dettaglio sufficiente a specificare le stime dei task del progetto, le responsabilità, e il programma (schedule). PS PMP, cap. 3 (CSK-CHO-PFSET-PMP ) PG.04A - GP par. 4.2 (da ampliare) 3. Identificare il prodotto o i componenti di prodotto che saranno acquisiti esternamente. PS PMP, cap. 3: "WP Inputs", nella tabella per la descrizione dei WP (CSK-CHO-PFSET-PMP ) PG.04A - GP par. 4.2 (da ampliare) 4. Identificare i "work products" che saranno riutilizzati PS PMP, cap.3: "WP Exclusions & Constraints", nella tabella per la descrizione dei WP (CSK-CHO-PFSET-PMP ) PG.04A - GP par. 4.2 (da ampliare) 72

76 Pianificazione del Progetto SP 1.2 Stabilire le Stime delle Caratteristiche dei Work Products e dei Tasks Telespazio Cosmo Sky- Med TPZPFS004 Stato Evidenza Oggettiva Note 1. Approccio tecnico Typical Work Products 2. Dimensione e complessità di task e "work products" Valutazione dei modelli Valutazione delle caratteristiche Determinare l'approccio tecnico per il progetto S SEMP (Software Engineering Management Plan): esiste un template, ma è del cliente; ADD cap.2 (CSK-CHO-PFSET-SEMP ) (CSM-UGS-STD-ADD ) PG.04A - GP Subpractices 2. Utilizzare metodi appropriati per determinare le caratteristiche dei "work products" e dei task che saranno usati per valutare i requisiti delle risorse S PMP e SEMP (Il SEMP va consegnato insieme al PMP nella fase di kick-off) (CSK-CHO-PFSET-PMP ) (CSK-CHO-PFSET-SEMP ) PG.04A - GP par e Valutare le caratteristiche dei "work products" e dei task NS PG.04A - GP par.4.2 (da ampliare) 73

77 Pianificazione del Progetto SP 1.3 Definire il Ciclo di Vita del Progetto Telespazio Cosmo Sky- Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work 1. Pianificare le fasi del Ciclo di Vita S Products PMP cap. 3 (CSK-CHO-PFSET-PMP ) PG.04A - GP par

78 Pianificazione del Progetto SP 1.4 Determinare le Stime di Impegno e Costo Telespazio Cosmo Sky- Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Valutazione delle motivazioni delle decisioni (rationale) S 2. Stime dell'impegno sul Progetto Stime del Costo del Progetto Raccogliere i modelli o i dati storici che saranno utilizzati per trasformare le caratteristiche dei "work products" e dei task in stime delle ore di lavoro e del costo. PS JFD (Justification File Document) (CSM-CHO-UGS-PFS-TNO ) SAP (Stato di Avanzamento del Progetto) Non c'è una PG: manca la Non si utilizzano modelli, ma soltanto dati raccolta di modelli e la storici, costituiti dai SAP di progetti costituzione di una repository precedenti di dati storici strutturata Subpractices 2. Includere le necessità di una infrastruttura di supporto durante la stima di impegno e costo. S PMP, nella parte dedicata all'hardware procurement (CSK-CHO-PFSET-PMP ) PG.04A - GP, par. 4.4 PG.03 (Gestione Offerte), par Stimare impegno e costo utilizzando modelli e/o dati storici. PS Solo stime empiriche basate su SAP storici PG.04A - GP, par. 4.4 PG.03 (Gestione Offerte), par

79 Pianificazione del Progetto SP 2.1 Stabilire il Budget e il Programma (Schedule) Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note 1. Programmi (Schedules) di progetto Typical Work Products 2. Dipendenze di programma (schedule) Budget di progetto Identificare le "milestones" più importanti S 2. Identificare le assunzioni di programma (schedule) S SOW (Statement Of Work), cap. 6.3 "Schedule and Milestones" (CSM-UGS-STD-SOW ) PMP, cap. 3 (Le assunzioni si riferiscono alla durata di determinate attività) (CSK-CHO-PFSET-PMP ) PG.03 PG.03 PG.04A - GP 3. Identificare i vincoli S PMP, cap. 3 (CSK-CHO-PFSET-PMP ) PG.03 PG.04A - GP Subpractices 4. Identificare le dipendenze tra i compiti (tasks) S PMP, cap.3 (CSK-CHO-PFSET-PMP ) 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 ) PG.03 PG.04A - GP 6. Stabilire i criteri delle azioni correttive S RMP (Risk Management Plan) (CSK-CHO-PFSET-RMP ) PG.04A - GP 76

80 Pianificazione del Progetto SP 2.2 Identificare i Rischi di Progetto Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Rischi identificati Effetti di rischio e probabilità di occorrenza Priorità di rischio Identificare i rischi PS RMP (Risk Management Plan) (CSK-CHO-PFSET-RMP ) PG.04A - GP PG "Gestione rischi" (da creare) Subpractices 2. Documentare i rischi PS 3. Revisionare e ottenere un'accordo con gli stakeholder sulla completezza e correttezza dei rischi documentati 4. Revisionare i rischi in modo appropriato PS PS RMP (CSK-CHO-PFSET-RMP ) MOM (Minute Of Meeting) di riunioni con gli stakeholder; MPR (Monthly Progress Report) (CSM-CHO-UGS-PFS-MPR ) MPR (CSM-CHO-UGS-PFS-MPR ) PG.04A - GP PG "Gestione rischi" (da creare) PG "Gestione rischi" (da creare) PG "Gestione rischi" (da creare) 77

81 Pianificazione del Progetto SP 2.3 Piano per la Gestone dei Dati Typical Work Products Telespazio Cosmo Sky-Med TPZPFS Piano della gestione dei dati S 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 5. Requisiti di privacy S 6. Requisiti di sicurezza S Stato Evidenza Oggettiva Note CDMP-Configuration & Data Management Plan (documento applicabile A33 del SOW) (CSM-UGS-STD-SOW ) SOW cap.8; GDC (Giornale Di Configurazione) (CSM-UGS-STD-SOW ) (TPZPFS-GDC-e1.ro.xls) SOW e PGC (come risposta al SOW) (CSM-UGS-STD-SOW ) SOW e PGC (CSM-UGS-STD-SOW ) SOW (documenti applicabili A38, A39, A40); PGC (CSM-UGS-STD-SOW ) SOW (documenti applicabili A38, A39, A40); (CSM-UGS-STD-SOW ) Subpractices 7. Procedure di sicurezza S 8. Meccanismo di recupero, riproduzione e distribuzione dei dati 9. Programma (schedule) per la raccolta dei dati di progetto S 10. Lista dei dati di progetto da raccogliere S 1. Stabilire i requisiti e le procedure per assicurare la privacy e la sicurezza dei dati 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 S SOW (documenti applicabili A38, A39, A40); (CSM-UGS-STD-SOW ) SOW e PGC (CSM-UGS-STD-SOW ) SOW e PGC (CSM-UGS-STD-SOW ) SOW e PGC (CSM-UGS-STD-SOW ) 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 ) PG08A SOW : dice come archiviare i dati (documenti applicabili: A33-CDMP, A34) (CSM-UGS- STD-SOW ) 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 ) PG03 PG15A:"Backup ed archiviazione del software" PG08A PG03 PG08A 78

82 Pianificazione del Progetto SP 2.4 Piano per le Risorse di Progetto Typical Work Products Telespazio Cosmo Sky-Med TPZPFS Pacchetti di lavoro (work packages) delle WBS S 2. Dizionario dei task delle WBS S 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 S 6. Lista dei requisiti dell'amministrazione del programma S 1. Determinare i requisiti del processo S Stato Evidenza Oggettiva Note S S PMP, cap. 3 (CSK-CHO-PFSET-PMP ) PMP, cap. 3 (CSK-CHO-PFSET-PMP ) PMP, cap. 2 (CSK-CHO-PFSET-PMP ) "Technical Proposal": è un documento che va allegato al PMP, e contiene una lista di compon. HW/SW (CSK-CHO-PFSET-TP ) PMP, per la definizione del processo (ADD per il prodotto) (CSK-CHO-PFSET-PMP ) PMP, cap.3 (C'è un WP dedicato al PM, con l'indicazione di tutte le attività che deve svolgere) (CSK-CHO-PFSET-PMP ) PMP, cap.3 (i requisiti del processo sono intesi come attività da svolgere nel progetto) (CSK-CHO-PFSET-PMP ) PG04A - GP Subpractices 2. Determinare i requisiti del personale S PMP, cap.2 (CSK-CHO-PFSET-PMP ) PG04A - GP 3. Determinare i requisiti di facilities, apparecchiature e componenti S "Technical Proposal": è un documento che va allegato al PMP, e contiene una lista di compon. HW/SW (CSK-CHO-PFSET-TP ) PG04A - GP 79

83 Pianificazione del Progetto SP 2.5 Piano per le Conoscenze e le Competenze Richieste Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Inventario delle necessità delle competenze (skill) S 2. Piani per la costituzione dello staff e per le nuove assunzioni Database (i.e., competenze e formazione) PS SOW per l'identificazione delle risorse; "Nota Risorse e Progetti" Esiste un file che contiene tutte 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 necessarie per eseguire il progetto S Renzulli: SOW, e "Nota Risorse e Progetti" PG03 PG04A - GP Subpractices 2. Valutare le conoscenze e le competenze disponibili NS Non esiste un template, e non c'è un'evidenza oggettiva vera e propria PG04A - GP 3. Selezionare i meccanismi per procurarsi le conoscenze e le competenze necessarie S C'è una procedura, "Recruiting", che viene seguita ed attuata Procedura "Recruiting" 4. Incorporare i meccanismi selezionati nel piano di progetto NS Non viene fatto PG04A - GP 80

84 Pianificazione del Progetto SP 2.6 Piano per il Coinvolgimento degli Stakeholder Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Piano per il coinvolgimento dello Stakeholder S PMP, cap.2 (questo capitolo specifica tutti i ruoli e, per ogni ruolo, le responsabilità); cap.3 (qui sono indicati i tempi di intervento di ogni stakeholder) (CSK-CHO-PFSET-PMP ) PG04A - GP Esempi Fare una lista di tutti gli stakeholder Motivazioni (rationale) per il coinvolgimento degli stakeholder Ruoli e responsabilità degli stakeholder riguardo al progetto, attraverso la fase del ciclo di vita del progetto Rapporti tra gli stakeholder Importanza dello stakeholder relativa al successo del progetto, attraverso la fase del ciclo di vita del progetto Risorse (e.g., training, materiali, tempo, fondi) necessari ad assicurare l'interazione dello stakeholder Programmazione (schedule) delle fasi dell'interazione dello stakeholder 81

85 Pianificazione del Progetto SP 2.7 Stabilire il Piano di Progetto Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Piano di progetto generale S PMP; MPR per l'avanzamento del piano, ed eventuali scostamenti rispetto alla pianificazione iniziale (CSK-CHO-PFSET-PMP ) (CSM-CHO-UGS-PFS-MPR ) PG04A - GP Esempi Piano Principale Integrato - un piano event-driven che documenti realizzazioni significative mediante criteri successo/insuccesso sia per il business che per gli elementi tecnici del progetto e che leghi ogni realizzazione con un evento chiave del programma. Programma (schedule) Principale integrato un programma dei compiti integrato e interconnesso a più livelli, richiesto per completare il lavoro documentato in un Piano Principale Integrato correlato. Piano di Gestione Ingegneria dei Sistemi un piano che descrive in dettaglio l'impegno tecnico integrato attraverso tutto il progetto. Programma (schedule) Principale Ingegneria dei Sistemi un programma event-based che contenga una raccolta di realizzazioni tecniche chiave, ognuna con criteri misurabili, e che richieda un completamento con successo per il superamento di eventi identificati. Programma (schedule) Dettagliato Ingegneria dei Sistemi un programma dettagliato, a dipendenza temporale, task-oriented, che associ specifiche date e milestones al Programma Principale Ingegneria dei Sistemi. 82

86 Pianificazione del Progetto SP 3.1 Revisionare i Piani che Influenzano il Progetto Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work 1. Registrazione delle revisioni dei piani che influenzano Products il progetto MPR S PG.04A - GP (CSM-CHO-UGS-PFS-MPR ) 83

87 Pianificazione del Progetto SP 3.2 Conciliare i Livelli di Lavoro e delle Risorse Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note 1. Metodi revisionati e corrispondente valutazione dei parametri (per esempio, strumenti migliori e uso di componenti immediatamente disponibili) S MPR (CSM-CHO-UGS-PFS-MPR ) PG.04A - GP Typical Work Products 2. Budget rinegoziati S 3. Programmi (schedules) revisionati S MPR,per le ore; SAP, per il costo (CSM-CHO-UGS-PFS-MPR ) MPR (CSM-CHO-UGS-PFS-MPR ) PG.04A - GP PG.04A - GP 4. Lista dei requisiti revisionata S MPR (CSM-CHO-UGS-PFS-MPR ) PG.04A - GP 5. Accordi con lo stakeholder rinegoziati S MPR e MOM (CSM-CHO-UGS-PFS-MPR ) PG.04A - GP 84

88 Pianificazione del Progetto SP 3.3 Ottenere l'impegno all'esecuzione del Piano Telespazio Cosmo Sky-Med TPZPFS004 Stato Evidenza Oggettiva Note Typical Work Products 1. Richieste documentate per gli impegni Impegni documentati Impegno (commitment)= Ordine controfirmato per accettazione 1. Identificare il supporto necessario e negoziare gli impegni con gli stakeholder. S SAP e PMP (CSK-CHO-PFSET-PMP ) (supporto necessario = persone) PG.03 PG.04A - GP 2. Documentare tutti gli impegni organizzativi, sia pieni che provvisori, accertando il livello adatto dei firmatari. S SAP e PMP (CSK-CHO-PFSET-PMP ) Tutte le commesse sono documentate col SAP, il PMP è usato per questo scopo solo in Telespazio, ma non negli altri progetti; "Note Conclusive" del Direttore Tecnico PG.03 PG.04A - GP 3. Revisionare le commesse interne con l'amministrazione principale in modo appropriato. S SAP, per le revisioni delle commesse; MPR (CSM-CHO-UGS-PFS-MPR ) PG.04A - GP Subpractices 4. Revisionare gli impegni esterni con il management in modo appropriato. S SAP per le revisioni; PMP (CSK-CHO-PFSET-PMP ) 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 5. Identificare gli impegni sulle interfacce tra gli elementi del progetto e degli altri progetti ed unità organizzative, in modo che possano essere monitorati. S PMP,cap.2 (identificazione delle persone) e cap.3 (identificazione delle attività) (CSK-CHO-PFSET-PMP ) PG.04A - GP 85

89 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

90 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

91 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

92 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

93 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

94 Monitoraggio e Controllo del Progetto SP 1.1 Monitorare i Parametri della Pianificazione del Progetto Progetto Enav - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work Products 1. Registrazioni della performance di progetto PS 2. Registrazione di deviazioni significative rispetto al piano S SAP (Stato di Avanzamento del Progetto): evidenza a livello economico, ma non a livello temporale contemporaneamente MoM di riunioni; SAP; MPR (Monthly Progress Report) 1. Monitoraggio dello stato di avanzamento lavori e S Sullo stato di avanzamento progetto (SAP) scostamenti rispetto alla pianificazione vengono riportati i dati relativi agli indicatori di PG04A - GP progetto come costi,impegni,milestone riportati 2. Monitoraggio dei costi e dell'impegno previsto S nel piano evidenziando i valori stimati e quelli effettivi dando evidenza di eventuali scostamenti PG04A - GP Subpractices 3. Monitoraggio delle caratteristiche dei Task e dei work products 4. Monitoraggio delle risorse approvigionate e impiegate NS PS L'unico attributo dei work package monitorato ad oggi è il peso rispetto all'intero progetto, dato 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 PG04A - GP 5. Monitoraggio degli skill e delle conoscenze del personale assegnato al progetto NS (ENAV) S (Telespazio) ENAV: Non si fa neanche nel Project Planning, ad oggi; Per Telespazio: SAP PG04A - GP 6. Documentare gli scostamenti significativi nei parametri di pianificazione del progetto S Si evidenziano dai Progress Report periodici (mensili per ENAV), compilati dal PM (Project Manager); esistono template per i MPR PG04A - GP 91

95 Monitoraggio e Controllo del Progetto SP 1.2 Monitorare gli Impegni del Progetto Typical Work Products Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note 1. Registrazione delle revisioni degli impegni S MPR (Monthly Progress Report) 1. Revisionare regolarmente gli impegni (sia interni che esterni) S MPR (Monthly Progress Report) (commesse esterne=fornitori) PG04A - GP Subpractices 2. Identificare gli impegni che non sono stati soddisfatti o che hanno un significativo rischio di non essere soddisfatti S Questa identificazione viene effettuata tramite MPR, ma non è legata ai costi; Per Telespazio, è da considerare pure il SAP, insieme al MPR PG04A - GP 3. Documentare i risultati delle revisioni degli impegni S MPR (Monthly Progress Report) PG04A - GP 92

96 Monitoraggio e Controllo del Progetto SP 1.3 Monitorare i Rischi di Progetto Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work Products 1. Registrazioni del monitoraggio dei rischi di progetto Subpractices 1. Verificare periodicamente i piani di rischio in relazione all'attuale stato del progetto ed analizzare eventuali criticità 2. Effettuare aggiornamenti sui piani di rischio non appena ci sono informazioni disponibili, per incorporare le modifiche ai suddetti piani S S Verifica periodica effettuata tramite MPR Aggiornamento del Piano di Gestione dei Rischi (RMP) PG04A - GP PG "Gestione Rischi" (da creare) PG04A - GP PG "Gestione Rischi" (da creare) 3. Condividere e comunicare al personale coinvolto sia interno che ad eventuali fornitori o collaboratori gli eventuali rischi emersi S Viene compilato il Risk Management Report (RMR): è un documento.xls; viene consegnato a chi riceve il MPR; Per Telespazio: non c'è il RMR PG04A - GP 93

97 Monitoraggio e Controllo del Progetto SP 1.4 Monitorare la Gestione dei Dati Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work Products 1. Registrazione della gestione dei dati Revisionare periodicamente le attività di gestione dei dati in base alla loro descrizione nel piano di progetto S MPR (anche per Telespazio) PG04A - GP 2. Identificare e documentare problemi significativi ed i loro impatti S MPR (anche per Telespazio) PG04A - GP Subpractices 3. Documentare i risultati delle revisioni delle attività di gestione dei dati S (Per Telespazio: Verbali di Riesame (delle Verifiche Interne per la Qualità); PAR,cap.8: riguarda le attività della qualità sul progetto - mod. VRS (CSM-CHO-UGS-PFS-PAR-0235)) PG04A - GP 94

98 Monitoraggio e Controllo del Progetto SP 1.5 Monitorare il Coinvolgimento degli Stakeholder Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work Products 1. Registrazioni del coinvolgimento degli stakeholder Verificare periodicamente lo stato del coinvolgimento degli stakeholder NS (Enav e Telespazio) La verifica viene effettuata tramite mail (per Telespazio, anche MOM di riunioni), ma non è periodica e sistematica PG04A - GP Subpractices 2. Identificare e documentare problemi significativi ed i loro impatti S Alcuni problemi vengono documentati nel MPR (problemi di scostamento dai piani) PG04A - GP 3. Documentare i risultati delle revisioni dello stato di coinvolgimento degli stakeholder NS (Enav e Telespazio) PG04A - GP 95

99 Monitoraggio e Controllo del Progetto SP 1.6 Effettuare Revisioni sullo Stato di Avanzamento Typical Work Products Progetto ENAV - ENVSTN Documentare i risultati delle attività di revisione sul progetto Stato Evidenza Oggettiva Note Servono per tenere gli stakeholders informati; le verifiche possono non essere specificate esplicitamente nei piani di progetto (dal manuale) 1. Comunicare regolarmente lo stato delle attività assegnate e dei "work products" agli stakeholder 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 2. Revisionare i risultati della raccolta e dell'analisi delle misure per controllare il progetto 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 Subpractices 3. Identificare e documentare le problematiche e le deviazioni significative rispetto al piano S MoM di riunioni Per Telespazio: MPR (CSM-CHO-UGS-PFS-MPR ) 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 96

100 Monitoraggio e Controllo del Progetto SP 1.7 Effettuare Revisioni sulle Milestone Typical Work Products Progetto ENAV - ENVSTN003 1.Risultati documentati delle revisioni effettuate sulle milestone 1. Effettuare revisioni sui punti cardine del programma (schedule) di progetto, come il completamento di fasi selezionate, con gli stakeholder 2. Revisionare gli impegni, il piano, lo stato ed i rischi del progetto Stato Evidenza Oggettiva Note S MPR (Milestones Critiche) PG04A - GP S MPR PG04A - GP Subpractices 3. Identificare e documentare problemi significativi ed i loro impatti S SPR (Software Problem Report) e RID (per la parte documentale) del MPR PG04A - GP 4. Documentare i risultati della revisione, delle eventuali attività e decisioni S MPR, PAL (Il PAL costituisce un elenco che mette insieme RID, SPR e le soluzioni ai problemi) PG04A - GP 5. Tenere traccia degli items delle azioni di chiusura. S MPR PG04A - GP 97

101 Monitoraggio e Controllo del Progetto SP 2.1 Analizzare i Problemi Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work 1. Lista dei problemi che hanno bisogno di azioni Products correttive S MPR - Open Points (ENAV - STL); MPR - List Action Item and Status (Cosmo Sky) PG04A - GP 1. Riunire i problemi per l'analisi Subpractices 2. Analizzare i problemi per determinare l'esigenza di azioni correttive

102 Monitoraggio e Controllo del Progetto SP 2.2 Effettuare Azioni Correttive Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work Products 1. Piano per le azioni correttive PS PAL ( Progress Action List) Per Telespazio: non c'è un piano per le azioni correttive 1. Determinare e documentare le azioni necessarie e appropriate per indirizzarsi verso i problemi identificati PS Compilazione da parte del PM di progetto di una nota tecnica o di un verbale di ruinione dove vengono evidenziate le azioni. Per Telespazio: MPR per il piano (azioni necessarie) (CSM-CHO-UGS-PFS-MPR ) PG14A "Gestione Azioni Correttive e Preventive" (da ampliare) Subpractices 2. Revisionare e ottenere un accordo con gli stakeholder sulle azioni da prendere S MoM PG14A "Gestione Azioni Correttive e Preventive" (da ampliare) 3. Concordare i cambiamenti agli impegni interni ed esterni S MoM (da cui possono scaturire azioni) PG14A "Gestione Azioni Correttive e Preventive" (da ampliare) 99

103 Monitoraggio e Controllo del Progetto SP 2.3 Gestire Azioni Correttive Progetto ENAV - ENVSTN003 Stato Evidenza Oggettiva Note Typical Work Products 1. Risultato delle azioni correttive Monitorare le azioni correttive per il completamento S Controllo formale: Giornale di Configurazione (GDC) (PAL). Per Telespazio: MPR (CSM-CHO-UGS-PFS-MPR ) PG14A, paragrafo "Gestione Azioni Correttive"; L'AQ procede a verificare la chiusura delle azioni correttive. Documento di riferimento: "Verifica Azione Correttiva" Subpractices 2. Analizzare i risultati delle azioni intraprese al fine di determinarne l'effettiva efficacia S Controllo di merito: SAP MPR PG14A, paragrafo 4.4: "Verifica dell'efficace attuazione delle azioni correttive"; Documento di riferimento:"verifica Azione Correttiva" 3. Determinare e documentare le azioni appropriate per correggere le deviazioni dai risultati pianificati per le azioni correttive. S SAP e MPR PG14A, paragrafo 4.4: "Verifica dell'efficace attuazione delle azioni correttive"; Documento di riferimento:"verifica Azione Correttiva" 100

104 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

105 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

106 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

107 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 Gestione dei Requisiti Procedura Gestione Offerte e Ordini di Vendita Procedura Gestione Rischi REQM RD RSKM TS PP Procedura Progettazione Sviluppo e Implementazione VER VAL Procedura Verifica e Validazione Procedura Pianificazione e Gestione Progetti PMC PPQA Sistema di Gestione per la Qualità CM Procedura Gestione della Configurazione MA Procedura Metriche Figura 6.1 Il nuovo sistema procedurale. 104

108 Progettazione del nuovo sistema procedurale 6.2 Procedura di Pianificazione e Gestione Progetti 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

109 Progettazione del nuovo sistema procedurale 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

110 Progettazione del nuovo sistema procedurale SP 1.1 Valutare la Struttura del Progetto Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output Typical Work Products 1. Descrizioni dei Task Descrizioni del pacchetto di lavoro (work package) WBS - Struttura di Ripartizione del Lavoro Sviluppare una WBS basata sull'architettura del prodotto CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 2. Identificare i pacchetti di lavoro (work packages) con un dettaglio sufficiente a specificare le stime dei task del progetto, le responsabilità, e il programma (schedule). 3. Identificare il prodotto o i componenti di prodotto che saranno acquisiti esternamente. CM.02 "Pianificazione e Gestione Progetti" par CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) PMP (Project Management Plan) 4. Identificare i "work products" che saranno riutilizzati CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 107

111 Progettazione del nuovo sistema procedurale SP 1.2 Stabilire le Stime delle Caratteristiche dei Work Products e dei Tasks Telespazio Cosmo Sky- Med TPZPFS004 Procedura Gestionale Documento di Output 1. Approccio tecnico Typical Work Products 2. Dimensione e complessità di task e "work products" Valutazione dei modelli Valutazione delle caratteristiche Determinare l'approccio tecnico per il progetto CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 2. Utilizzare metodi appropriati per determinare le caratteristiche dei "work products" e dei task che saranno usati per valutare i requisiti delle risorse CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 3. Valutare le caratteristiche dei "work products" e dei task CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 108

112 Progettazione del nuovo sistema procedurale SP 1.3 Definire il Ciclo di Vita del Progetto Telespazio Cosmo Sky- Med TPZPFS004 Procedura Gestionale Documento di Output Typical Work 1. Pianificare le fasi del Ciclo di Vita Products CM.02 PMP "Pianificazione e Gestione Progetti" (Project Management Plan) par

113 Progettazione del nuovo sistema procedurale SP 1.4 Determinare le Stime di Impegno e Costo Telespazio Cosmo Sky- Med TPZPFS004 Procedura Gestionale Documento di Output 1. Valutazione delle motivazioni delle decisioni (rationale) Typical Work Products 2. Stime dell'impegno sul Progetto Stime del Costo del Progetto Raccogliere i modelli o i dati storici che saranno utilizzati per trasformare le caratteristiche dei "work products" e dei task in stime delle ore di lavoro e del costo. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 2. Includere le necessità di una infrastruttura di supporto durante la stima di impegno e costo. SCM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 3. Stimare impegno e costo utilizzando modelli e/o dati storici. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 110

114 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 1. Programmi (Schedules) di progetto Typical Work Products 2. Dipendenze di programma (schedule) Budget di progetto Identificare le "milestones" più importanti CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 2. Identificare le assunzioni di programma (schedule) CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 3. Identificare i vincoli CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 4. Identificare le dipendenze tra i compiti (tasks) CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 5. Definire il budget e il programma (schedule) CM.02 "Pianificazione e Gestione Progetti" par SAP (Stato di Avanzamento Progetto) e GANTT 6. Stabilire i criteri delle azioni correttive CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 111

115 Progettazione del nuovo sistema procedurale SP 2.2 Identificare i Rischi di Progetto Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output Typical Work Products 1. Rischi identificati Effetti di rischio e probabilità di occorrenza Priorità di rischio Identificare i rischi CM.02 "Pianificazione e Gestione Progetti" par RMP (Risk Management Plan) 2. Documentare i rischi CM.02 "Pianificazione e Gestione Progetti" par RMP (Risk Management Plan) Subpractices 3. Revisionare e ottenere un'accordo con gli stakeholder sulla completezza e correttezza dei rischi documentati CM.02 "Pianificazione e Gestione Progetti" par RMP (Risk Management Plan) 4. Revisionare i rischi in modo appropriato CM.02 "Pianificazione e Gestione Progetti" par RMP (Risk Management Plan) 112

116 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 Lista principale dei dati gestiti Contenuto dei dati e descrizione del formato Liste dei requisiti sui dati per acquirenti e fornitori Typical Work Products 5. Requisiti di privacy Requisiti di sicurezza Procedure di sicurezza Meccanismo di recupero, riproduzione e distribuzione dei dati Programma (schedule) per la raccolta dei dati di progetto Lista dei dati di progetto da raccogliere 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) Subpractices 2. Stabilire un meccanismo per archiviare i dati e per accedere 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

117 Progettazione del nuovo sistema procedurale SP 2.4 Piano per le Risorse di Progetto Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output 1. Pacchetti di lavoro (work packages) delle WBS Dizionario dei task delle WBS Typical Work Products 3. Requisiti di personale basati sulla dimensione e campo di applicazione del progetto Lista delle facilities (applicazioni)/apparecchiature critiche Definizioni e diagrammi del processo/flusso di lavoro Lista dei requisiti dell'amministrazione del programma Determinare i requisiti del processo CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 2. Determinare i requisiti del personale CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 3. Determinare i requisiti di facilities, apparecchiature e componenti CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 114

118 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 1. Inventario delle necessità delle competenze (skill) Typical Work Products 2. Piani per la costituzione dello staff e per le nuove assunzioni Database (i.e., competenze e formazione) Identificare le conoscenze e le competenze necessarie per eseguire il progetto CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 2. Valutare le conoscenze e le competenze disponibili 3. Selezionare i meccanismi per procurarsi le conoscenze e le competenze necessarie CM.02 "Pianificazione e Gestione Progetti" par CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) PMP (Project Management Plan) 4. Incorporare i meccanismi selezionati nel piano di progetto CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 115

119 Progettazione del nuovo sistema procedurale SP 2.6 Piano per il Coinvolgimento degli Stakeholder Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output Typical Work Products 1. Piano per il coinvolgimento dello Stakeholder CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Esempi Fare una lista di tutti gli stakeholder Motivazioni (rationale) per il coinvolgimento degli stakeholder Ruoli e responsabilità degli stakeholder riguardo al progetto, attraverso la fase del ciclo di vita del progetto Rapporti tra gli stakeholder Importanza dello stakeholder relativa al successo del progetto, attraverso la fase del ciclo di vita del progetto Risorse (e.g., training, materiali, tempo, fondi) necessari ad assicurare l'interazione dello stakeholder Programmazione (schedule) delle fasi dell'interazione dello stakeholder 116

120 Progettazione del nuovo sistema procedurale SP 2.7 Stabilire il Piano di Progetto Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output Typical Work Products 1. Piano di progetto generale CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Esempi Piano Principale Integrato - un piano event-driven che documenti realizzazioni significative mediante criteri successo/insuccesso sia per il business che per gli elementi tecnici del progetto e che leghi ogni realizzazione con un evento chiave del programma. Programma (schedule) Principale integrato un programma dei compiti integrato e interconnesso a più livelli, richiesto per completare il lavoro documentato in un Piano Principale Integrato correlato. Piano di Gestione Ingegneria dei Sistemi un piano che descrive in dettaglio l'impegno tecnico integrato attraverso tutto il progetto. Programma (schedule) Principale Ingegneria dei Sistemi un programma event-based che contenga una raccolta di realizzazioni tecniche chiave, ognuna con criteri misurabili, e che richieda un completamento con successo per il superamento di eventi identificati. Programma (schedule) Dettagliato Ingegneria dei Sistemi un programma dettagliato, a dipendenza temporale, task-oriented, che associ specifiche date e milestones al Programma Principale Ingegneria dei Sistemi. 117

121 Progettazione del nuovo sistema procedurale SP 3.1 Revisionare i Piani che Influenzano il Progetto Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale documento di Output Typical Work 1. Registrazione delle revisioni dei piani che influenzano il Products progetto CM.02 MOM di riunioni attivate dal "Pianificazione e Gestione Progetti" PMP par (Project Management Plan) 118

122 Progettazione del nuovo sistema procedurale SP 3.2 Verifica di Copertura delle Attività con le Risorse Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output 1. Metodi revisionati e corrispondente valutazione dei parametri (per esempio, strumenti migliori e uso di componenti immediatamente disponibili) CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 2. Budget rinegoziati CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Typical Work Products 3. Programmi (schedules) revisionati CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 4. Lista dei requisiti revisionata CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 5. Accordi con lo stakeholder rinegoziati CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 119

123 Progettazione del nuovo sistema procedurale SP 3.3 Ottenere l'impegno all'esecuzione del Piano Telespazio Cosmo Sky-Med TPZPFS004 Procedura Gestionale Documento di Output Typical Work Products 1. Richieste documentate per gli impegni Impegni documentati Identificare il supporto necessario e negoziare gli impegni con gli stakeholder. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 2. Documentare tutti gli impegni organizzativi, sia pieni che provvisori, accertando il livello adatto dei firmatari. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 3. Revisionare le commesse interne con l'amministrazione principale in modo appropriato. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) Subpractices 4. Revisionare gli impegni esterni con il management in modo appropriato. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 5. Identificare gli impegni sulle interfacce tra gli elementi del progetto e degli altri progetti ed unità organizzative, in modo che possano essere monitorati. CM.02 "Pianificazione e Gestione Progetti" par PMP (Project Management Plan) 120

124 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 Typical Work Products 1. Registrazioni della performance di progetto Registrazione di deviazioni significative rispetto al piano Monitoraggio dello stato di avanzamento lavori e scostamenti rispetto alla pianificazione CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) 2. Monitoraggio dei costi e dell'impegno previsto CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) Subpractices 3. Monitoraggio delle caratteristiche dei Task e dei work products 4. Monitoraggio delle risorse approvigionate e impiegate CM.02 "Pianificazione e Gestione Progetti" par CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) PPR (Periodical Progress Report) MPR 5. Monitoraggio degli skill e delle conoscenze del personale assegnato al progetto CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) 6. Documentare gli scostamenti significativi nei parametri di pianificazione del progetto CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) 121

125 Progettazione del nuovo sistema procedurale SP 1.2 Monitorare gli Impegni del Progetto Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Registrazione delle revisioni degli impegni Subpractices 1. Revisionare regolarmente gli impegni (sia interni che esterni) 2. Identificare gli impegni che non sono stati soddisfatti o che hanno un significativo rischio di non essere soddisfatti CM.02 "Pianificazione e Gestione Progetti" par CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) PPR (Periodical Progress Report) 3. Documentare i risultati delle revisioni degli impegni CM.02 "Pianificazione e Gestione Progetti" par MOM (Minute Of Meeting) aggiornate 122

126 Progettazione del nuovo sistema procedurale SP 1.3 Monitorare i Rischi di Progetto Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Registrazioni del monitoraggio dei rischi di progetto Verificare periodicamente i piani di rischio in relazione all'attuale stato del progetto ed analizzare eventuali criticità CM.02 "Pianificazione e Gestione Progetti" par Aggiornamento del RMP (Risk Management Plan) Subpractices 2. Effettuare aggiornamenti sui piani di rischio non appena ci sono informazioni disponibili, per incorporare le modifiche ai suddetti piani CM.02 "Pianificazione e Gestione Progetti" par Aggiornamento del Piano di Gestione dei Rischi (RMP) 3. Condividere e comunicare al personale coinvolto sia interno che ad eventuali fornitori o collaboratori gli eventuali rischi emersi CM.02 "Pianificazione e Gestione Progetti" par RMP/MOM (di riunioni previste nel RMP stesso) 123

127 Progettazione del nuovo sistema procedurale SP 1.4 Monitorare la Gestione dei Dati Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Registrazione della gestione dei dati Subpractices 1. Revisionare periodicamente le attività di gestione dei dati in base alla loro descrizione nel piano di progetto 2. Identificare e documentare problemi significativi ed i loro impatti CM.02 "Pianificazione e Gestione Progetti" par CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) PPR (Periodical Progress Report) 3. Documentare i risultati delle revisioni delle attività di gestione dei dati CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) 124

128 Progettazione del nuovo sistema procedurale SP 1.5 Monitorare il Coinvolgimento degli Stakeholder Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Registrazioni del coinvolgimento degli stakeholder Verificare periodicamente lo stato del coinvolgimento degli stakeholder CM.02 "Pianificazione e Gestione Progetti" par MOM di riunioni periodiche con gli stakeholder Subpractices 2. Identificare e documentare problemi significativi ed i loro impatti CM.02 "Pianificazione e Gestione Progetti" par MOM di riunioni periodiche con gli stakeholder 3. Documentare i risultati delle revisioni dello stato di coinvolgimento degli stakeholder CM.02 "Pianificazione e Gestione Progetti" par MOM di riunioni periodiche con gli stakeholder 125

129 Progettazione del nuovo sistema procedurale SP 1.6 Effettuare Revisioni sullo Stato di Avanzamento Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Documentare i risultati delle attività di revisione sul progetto Comunicare regolarmente lo stato delle attività assegnate e dei "work products" agli stakeholder CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) e conseguente aggiornamento del GANTT 2. Revisionare i risultati della raccolta e dell'analisi delle misure per controllare il progetto CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) e conseguente aggiornamento del GANTT Subpractices 3. Identificare e documentare le problematiche e le deviazioni significative rispetto al piano CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) e 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 PPR (Periodical Progress Report) 5. Documentare i risultati delle revisioni CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) e documenti applicabili richiamati 6. A chiusura registrare i report dei cambiamenti ed i problemi riscontrati CM.02 "Pianificazione e Gestione Progetti" par PAL (Progress Action List) da creare 126

130 Progettazione del nuovo sistema procedurale SP 1.7 Effettuare Revisioni sulle Milestone Typical Work Products Progetto ENAV - ENVSTN003 1.Risultati documentati delle revisioni effettuate sulle milestone Procedura Gestionale Documento di Output Effettuare revisioni sui punti cardine del programma (schedule) di progetto, come il completamento di fasi selezionate, con gli stakeholder CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) 2. Revisionare gli impegni, il piano, lo stato ed i rischi del progetto CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) Subpractices 3. Identificare e documentare problemi significativi ed i loro impatti CM.02 "Pianificazione e Gestione Progetti" par PPR (Periodical Progress Report) SPR (Software Problem Report) RID (Review Item Discrepance) 4. Documentare i risultati della revisione, delle eventuali attività e decisioni CM.02 "Pianificazione e Gestione Progetti" par SPR (Software Problem Report) RID (Review Item Discrepance) PAL (Progress Action List) 5. Tenere traccia degli items delle azioni di chiusura. CM.02 "Pianificazione e Gestione Progetti" par PAL (Progress Action List) 127

131 Progettazione del nuovo sistema procedurale SP 2.1 Analizzare i Problemi Typical Work Products Progetto ENAV - ENVSTN Lista dei problemi che hanno bisogno di azioni correttive Procedura Gestionale CM.02 "Pianificazione e Gestione Progetti" par Documento di Output PAL (Progress Action List) 1. Riunire i problemi per l'analisi Subpractices 2. Analizzare i problemi per determinare l'esigenza di azioni correttive

132 Progettazione del nuovo sistema procedurale SP 2.2 Effettuare Azioni Correttive Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Piano per le azioni correttive Determinare e documentare le azioni necessarie e appropriate per indirizzarsi verso i problemi identificati CM.02 "Pianificazione e Gestione Progetti" par PAC (Piano per le Azioni Correttive) Subpractices 2. Revisionare e ottenere un accordo con gli stakeholder sulle azioni da prendere CM.02 "Pianificazione e Gestione Progetti" par PAC (Piano per le Azioni Correttive) e MOM 3. Concordare i cambiamenti agli impegni interni ed esterni CM.02 "Pianificazione e Gestione Progetti" par PAC (Piano per le Azioni Correttive) e MOM 129

133 Progettazione del nuovo sistema procedurale SP 2.3 Gestire Azioni Correttive Progetto ENAV - ENVSTN003 Procedura Gestionale Documento di Output Typical Work Products 1. Risultato delle azioni correttive Monitorare le azioni correttive per il completamento CM.02 "Pianificazione e Gestione Progetti" par "Verifica delle Azioni Correttive" Subpractices 2. Analizzare i risultati delle azioni intraprese al fine di determinarne l'effettiva efficacia CM.02 "Pianificazione e Gestione Progetti" par "Verifica delle Azioni Correttive" 3. Determinare e documentare le azioni appropriate per correggere le deviazioni dai risultati pianificati per le azioni correttive. CM.02 "Pianificazione e Gestione Progetti" par "Verifica delle Azioni Correttive" 130

134 Progettazione del nuovo sistema procedurale 131

135 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 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

136 Progettazione del nuovo sistema procedurale Processi del Ciclo di Vita (norma ISO/IEC 12207) Attività dei Processi Aree di Processo (CMMI) Pratiche Specifiche (CMMI) Procedura Gestionale Requirements Management Obtain an Understanding of Requirements Obtain Commitment to Requirements 1.1 Elicit Needs 1.2 Develop the Customer Requirements 5.1 Vendita (Processo Primario) Avvio Requirements Development Establish Operational Concept and Scenarios Establish a Definition of Required Funcionality 3.3 Analyze Requirements Analyze Requirements to Achieve Balance Validate Requirements Supplier Agreement Management 1.1 Determine Acquisition Type Avvio Preparazione della risposta Contratto Pianificazione Non Applicabile per il CMMI Requirements Development Risk Management Technical Solution Organizational Process Definition + IPPD N.A. 3.3 Analyze Requirements to Achieve 3.4 Balance TUTTE CM.02 par Perform Make, Buy, or Reuse 2.4 Analyses TUTTE N.A. Analyze Requirements 1.1 Estimate the Scope of the Project CM.02 par Establish Estimate of Work product 1.2 CM.02 par and Task Attribute 1.4 Determine Estimates of Effort and Cost CM.02 par Project Planning 2.1 Establish the Budget and Schedule CM.02 par Identify Project Risks CM.02 par Fornitura (Processo Primario) 2.3 Plan for Data Management CM.02 par Plan for Project Resources CM.02 par Plan for Needed Knowledge and Skills CM.02 par Plan Stakeholder Involvement CM.02 par Esecuzione e controlli Riesami e valutazioni Consegna e completamento Figura 6.2 Scheda Progetto. Measurement and Analysis Project Monitoring and Control Project Planning Non trovata sulla versione 1.2 del Manuale CMMI TUTTE 1.1 Monitor Project Planning Parameters CM.02 par Monitor Commitments CM.02 par Monitor Project Risks CM.02 par Monitor Data Management CM.02 par Monitor Stakeholder Involvement CM.02 par Conduct Progress Reviews CM.02 par Conduct Milestone Reviews CM.02 par Review Plans that Affect the Project CM.02 par Reconcile Work and Resource Levels CM.02 par Obtain Plan Commitment CM.02 par

137 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 81% 5,00% 14,000% Soddisfatte Parzialmente Soddisfatte Non Soddisfatte Figura 7.2 Copertura per l Area di Monitoraggio e Controllo. 134

138 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

139 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

140 Appendici 137

141 Appendici 138

142 Appendici 139