febbraio 2007

31/6

febbraio 2007

Linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA

Manuale 6

Modelli per la Qualità delle Forniture ICT

31/6

febbraio 2007

i Quaderni n. 31 febbraio 2007 Supplemento al n.1/2007

di Innovazione

i Quaderni

sommario

Linee guida sulla qualità dei beni e dei servizi ICT

PER LA DEFINIZIONE ED IL GOVERNO DEI CONTRATTI DELLA PA

3 PREMESSA

Anno V Registrato al Tribunale di Roma

n. 523/2003

del 15 dicembre 2003

Direttore responsabile

Xxxxxx Xxxxxxxxx

Quaderno a cura di:

Xxxxx Xxxxxxx (xxxxx.xxxxxxx@xxxxx.xx)

Redazione Centro Nazionale per l’Informatica nella

Pubblica Amministrazione

Xxx Xxxxxx, 00x 00000 Xxxx

Tel. (00) 00 00000.0

xxxxxxxxxxxxx@xxxxx.xx

I Quaderni del Cnipa 25

sono pubblicati all’indirizzo:

xxx.xxxxx.xxx.xx

Stampa: Stilgrafica srl - Roma

MODELLI PER LA QUALITÀ DELLE FORNITURE ICT MANUALE DI RIFERIMENTO

1. Generalità sul documento

2. Gruppo di Lavoro

3. Modelli per la qualità delle forniture ICT

4. Punti di vista per la definizione della qualità

4.1. QUALITÀ INTRINSECA DELLA FORNITURA 17

4.2. PUNTO DI VISTA DEL FRUITORE 20

4.3. PUNTO DI VISTA DI CHI APPALTA 22

5. Ciclo di vita delle forniture

5.1. PROCESSI PRIMARI 29

5.1.1. PROCESSO DI ACQUISIZIONE 29

5.1.2. PROCESSO DI FORNITURA 31

5.1.3. PROCESSO DI PROGETTAZIONE 32

5.1.4. PROCESSO DI REALIZZAZIONE E COLLAUDO 36

5.1.5. PROCESSO DI GESTIONE OPERATIVA 39

5.1.6. PROCESSO DI MANUTENZIONE 41

5.2. PROCESSI TRASVERSALI 45

5.2.1. PROCESSO DI GESTIONE 45

5.2.2. PROCESSO DI DOCUMENTAZIONE 53

5.2.3. PROCESSO DI GESTIONE DELLA CONFIGURAZIONE 55

5.2.4. PROCESSO DI ASSICURAZIONE QUALITÀ 58

63 4. CATEGORIE ED ATTRIBUTI DI QUALITÀ DELLE FORNITURE ICT

6.1. CARATTERISTICHE DI QUALITÀ (ISO 9126) 64

6.2. DIMENSIONI DI QUALITÀ (SERVQUAL) 66

6.3. MODELLO DI QUALITÀ ADOTTATO 68

6.4. INDICATORI DI QUALITÀ 71

77 4. MODELLI PER LA GESTIONE DEI CONTRATTI ICT

7.1. MODELLO ISO (UNI ISO 10006) 77

7.1.1. LA NORMA UNI ISO 10006 78

7.1.2. SCOPO E CAMPO DI APPLICAZIONE 79

7.1.3. STRUTTURA DELLA NORMA 80

7.1.4. CONTENUTO DELLA NORMA 81

7.1.5. APPLICAZIONE NELL’AMBITO PUBBLICO 85

7.2. MODELLO PMI (PM BOK 2004) 88

7.2.1. IL XXXXX 00

7.2.2. LA METODOLOGIA TENSTEP 99

7.2.3. CORRELAZIONI ISO - PMBOK 101

7.3. Modello cnipa (monitoraggio ai sensi del

D. LGS. 39/93) 107

7.3.1. Prescrizioni legislative in tema

DI MONITORAGGIO 110

7.3.2. Attività di monitoraggio e verifica

EX POST DEI CONTRATTI ICT 113

7.3.3. Ambito di applicazione delle attività

di Monitoraggio e verifica ex post

DEI CONTRATTI ICT 116

7.3.4. QUALIFICAZIONE DEI MONITORI DA PARTE DEL CNIPA 117

7.3.5. Affidamento delle attività di monitoraggio

E VERIFICA EX POST AD UN MONITORE 134

7.3.6. DISPOSIZIONI DA INSERIRE NEL CONTRATTO ICT SOTTOPOSTO A MONITORAGGIO 137

7.3.7. Rapporti intercorrenti tra l’amministrazione,

IL MONITORE ED IL CNIPA 138

147

173

8. Glossario

9. Bibliografia

9.1. TESTI 174

9.2. SITI INTERNET 181

9.3. RIVISTE 183

Premessa

Allo scopo di incentivare l’acquisizione di prodotti e servizi ICT di qualità da parte delle pubbliche amministrazioni centrali e locali e supportare l’azione di governo dei contratti ICT, il Cnipa, nel dicembre 2003, ha istituito un apposito Gruppo di lavoro (GdL) dedicato alla qualità dei beni e dei servizi ICT.

Il GdL ha avuto come referente l’xxx. Xxxxx Xxxxxxx, Componente dell’Organo collegiale del CNIPA ed è stato coordinato dal xxxx. Xxxxx Xxxxxxx, dirigente del CNIPA. Ai lavori hanno partecipato, oltre al CNIPA, alcune amministrazioni centrali (INPS, Giustizia, MIUR), due società di informatica a capitale interamente pubblico (CONSIP, SOGEI) e le associazioni di categoria dei fornitori ICT (ANASIN/AITech, ASSINFORM; FEDERCOMIN). In aggiunta al GdL hanno contribuito alla redazione delle Linee guida un vasto gruppo di circa 120 perso- ne, dipendenti di diverse aziende, tra le più rappresentative del mercato ICT nazionale. Pur non partecipando direttamente al GdL un’utile collaborazione è stata offerta anche dalla Banca d’Italia.

A partire dal 2004 si sono realizzati sette manuali sulle Linee guida sulla qualità dei beni e servizi ICT per la definizione ed il governo dei contratti della pubblica ammini- strazione, per permettere alle amministrazioni pubbliche di attuare pienamente lo slogan posto alla base dei lavori: ottenere qualità dai fornitori di servizi ICT per for- nire qualità a cittadini ed imprese.

Non si è ha avuta l’ambizione di offrire un contributo innovativo dal punto di vista scientifi- co, piuttosto si è inteso fornire indicazioni di buon senso, pragmatiche e immediatamente applicabili, sia da parte delle amministrazioni, nel loro ruolo di stazioni appaltanti, che da parte dei fornitori, offerenti in fase di gara e, successivamente, firmatari dei contratti. Indica- zioni caratterizzate dall’essere state rese:

• indirizzate alla variegata tipologia di destinatari che ruotano attorno al processo di acquisizione di beni e servizi ICT;

• didatticamente utili per favorire la diffusione e la predisposizione di eventi formativi;

• di facile comprensione per tutte le diverse culture espresse delle professionalità a diverso titolo coinvolte nella definizione e governo dei contratti ICT;

• utilizzabili come base di partenza per la scrittura degli atti di gara;

• attuabili in fase di esecuzione dei contratti, perché concrete, semplici e non ambigue e basate su esperienze precedenti (best practices).

A valle del completamento dei lavori, l’evoluzione e la gestione delle Linee guida è stata affi- data all’Area “Governo e Monitoraggio Forniture ICT” del CNIPA, sotto la responsabilità

del xxxx. Xxxxx Xxxxxxx, già coordinatore del Gruppo di lavoro. In considerazione dei risultati raggiunti, allo scopo di garantire il mantenimento nel tempo della validità ed attualità delle Linee guida e massimizzarne l’utilizzo da parte delle amministrazioni, l’area opera per:

• recepire indicazioni, suggerimenti, richieste, provenienti sia da amministrazioni e imprese per il tramite dell’apposito canale di posta elettronica reso disponibile;

• estendere i Manuali e le classi di fornitura a nuovi servizi ICT, creando gruppi di stu- dio per l’approfondimento, aggiornamento, inserimento di specifici argomenti;

• avviare iniziative per diffondere la conoscenza delle Linee guida e favorirne l’uso da parte delle amministrazioni centrali e locali ed erogare interventi formativi sui conte- xxxx delle Linee guida;

• mantenere attivo il canale di interazione sulla contrattualistica ICT che si è creato con le Associazioni di categoria ed i Fornitori stessi.

Le Linee guida hanno lo scopo di definire:

• un quadro di riferimento complessivo per l’appalto pubblico di servizi ICT da parte delle amministrazioni;

• metodi quantitativi da applicarsi per definire misure di qualità ed identificare processi di misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediatamente applicabili, sia alle amministrazioni appaltanti che ai fornitori offerenti;

• adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di capitolati e contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla descri- zione delle attività da prevedersi contrattualmente, ai prodotti che dette attività realiz- zano, agli indicatori e misure di qualità da riferirsi sia alle attività che ai prodotti;

• clausole successivamente utili nella fase di attuazione dei contratti ICT, per la necessa- ria azione di governo del contratto e lo svolgimento del monitoraggio per la verifica del rispetto dei requisiti contrattuali in termini di tempi, costi e stato avanzamento lavori, quantità e qualità attese dei servizi ICT richiesti.

Per la stesura delle Linee guida si è adottato un approccio caratterizzato da:

• assunzione di punti di vista complementari per la definizione della qualità, il fruitore del servizio (utente finale), l’amministrazione appaltante il servizio (stazione appaltan- te), la qualità intrinseca del servizio;

• considerazione dell’intero ciclo di vita inerente l’acquisizione di una fornitura ICT (ela- borazione delle strategie di acquisto, definizione delle modalità di appalto, definizione del contratto, governo del contratto);

• considerazione di tutte le possibili dimensioni della qualità caratterizzanti prodotti e servizi ICT nelle diverse fasi del ciclo di vita;

• enfasi sulla concretezza attuata fornendo in termini pragmatici risposte a domande operative;

• eliminazione delle possibili ambiguità nell’adozione a livello contrattuale di livelli di servizio e indicatori di qualità.

Le Linee guida sono strutturate secondo 7 documenti distinti, denominati “Manuali” e 37 “Lemmi” allegati al Manuale operativo “Dizionario delle Forniture ICT elementari”.

1 Manuale d’uso “Presentazione e Utilizzo delle Linee Guida”

Questo manuale è il documento introduttivo alle Linee Guida, il suo scopo è quello di:

• evidenziare le motivazioni alla base delle Linee guida, illustrare il loro scopo, l’approc- cio adottato per la loro stesura, i destinatari ed i possibili percorsi di lettura, la struttu- ra ed i contenuti, le modalità d’uso dei diversi documenti che compongono le Linee Guida;

• esplicitare le Classi di fornitura elementari trattate nel Manuale operativo “Dizionario delle forniture ICT”;

• spiegare le modalità adottate di descrizione delle classi di fornitura ICT elementari e come usare le classi di fornitura per scrivere contratti e capitolati tecnici.

2 Manuale applicativo “Strategie di Acquisizione delle forniture ICT”

Questo manuale illustra alle amministrazioni interessate all’acquisizione di forniture ICT i vantaggi ed i rischi delle possibili scelte strategiche da compiere propedeuticamente alla realizzazione di una gara. Il suo scopo è quello di presentare ragionamenti, applicabili allo specifico contesto in cui si colloca l’amministrazione appaltante, in merito:

• alle possibili strategie di acquisizione delle forniture ICT ed alle implicazioni strategi- che, organizzative, economiche ed operative legate alle diverse scelte oltre che ai fat- tori critici di successo;

• alle diverse strategie attuabili per quanto concerne il software applicativo;

• alle possibili architetture contrattuali;

• alle diverse tipologie di contratti ICT ed all’organizzazione del contratto;

• ai contenuti del contratto ICT.

3 Manuale applicativo “Appalto pubblico di forniture ICT”

Questo manuale illustra alle stazioni appaltanti le forniture ICT le conseguenze derivanti dalle possibili scelte ed approcci inerenti l’appalto. Lo scopo di questo manuale è quello di esprimere ragionamenti applicabili alla gara che l’amministrazione deve realizzare coerente- mente alle strategie di acquisizione delle forniture ICT definite:

• la scelta dell’oggetto e della modalità di fornitura;

• scelta della procedura di gara;

• determinazione dei criteri di accesso alla gara;

• attribuzione del punteggio tecnico;

• attribuzione del punteggio economico;

• prevenzione dalle offerte anormalmente basse.

4 Manuale operativo “Dizionario delle Forniture ICT Elementari”

Questo manuale presenta il lessico dell’ICT raccolto in lemmi ordinati alfabeticamente che rappresentano specifiche tipologie di forniture ICT. Lo scopo di questo manuale è quello di fornire “ricette contrattuali”, di immediato utilizzo, utili per rappresentare contrattual- mente le esigenze della stazione appaltante, modificabili, copiabili e incollabili per l’elabo- razione di contratti e capitolati tecnici. Come un comune dizionario questo manuale si

consulta specificatamente, lemma per lemma, in funzione delle proprie esigenze. Ogni lemma prevede:

• la descrizione della Classe di fornitura ICT elementare;

• l’esplicitazione di “regole” per l’uso della classe di fornitura;

• la descrizione delle attività e dei relativi prodotti di queste attività;

• una tabella che riassume attività, prodotti e indicatori di qualità;

• una scheda per ogni indicatore di qualità;

• un glossario (facoltativo).

5 Manuale Applicativo “Esempi di applicazione”

Questo manuale aiuta a comprendere meglio le logiche di utilizzo dei lemmi contenuti nel Manuale operativo “Dizionario delle Forniture ICT Elementari”, proponendo esempi che consentono di approfondire i passi da compiere per definire la fornitura oggetto di un Capitolato tecnico:

• come individuare e personalizzare le Classi di fornitura di interesse a partire dalle esi- genze che spingono una Amministrazione ad avviare una procedura di gara;

• come selezionare e personalizzare attività e prodotti da richiedere al Fornitore in ese- cuzione del contratto;

• come selezionare e personalizzare indicatori di qualità e valori soglia per le attività ed i prodotti richiesti;

• come descrivere la fornitura nel Capitolato tecnico, integrando Classi di fornitura e processi trasversali.

6 Manuale di riferimento “Modelli per la qualità delle forniture ICT”

Questo manuale presenta i “Modelli per la qualità delle forniture ICT” illustrando gli standard e le logiche adottate per la descrizione delle forniture elementari e la definizione della loro qualità e fornisce i riferimenti culturali di base e puntamenti a possibili approfondimenti:

• i punti di vista per la definizione di qualità;

• i processi del ciclo di vita della generica fornitura;

• le categorie ed attributi di qualità della generica fornitura;

• alcuni modelli per la gestione dei contratti ICT;

• il glossario;

• la bibliografia (testi, articoli, siti).

7 Manuale Applicativo “Governo dei Contratti ICT”

Questo manuale fornisce elementi informativi utili per un efficace governo dei contratti ICT per la realizzazione di progetti e per la fornitura di beni e servizi. Tratta in maniera separata l’attività di governo per la realizzazione dei progetti da quella per l’erogazione dei servizi in quanto sono diversi i criteri di controllo, la gestione dei rischi e l’interazione amministrazione-fornitore. Sono anche separate le attività di competenza del fornitore da quelle dell’amministrazione allo scopo di indicare in modo esplicito i ruoli e le responsabi-

lità delle parti nel governo di un contratto. Descrive le modalità di governo dei contratti in termini di:

• struttura organizzativa e ruoli;

• attività e documenti di pianificazione e controllo;

• sistema di comunicazione tra il fornitore e l’amministrazione.

La logica di composizione dei manuali segue il ciclo di vita delle forniture ICT, iniziando dalle propedeutiche strategie di acquisizione, proseguendo all’appalto pubblico delle forni- ture ICT (una cui grossa componente è la redazione di capitolati tecnici attuabile sulla base del Dizionario delle forniture ICT, il cui utilizzo è esemplificato dagli esempi di applicazio- ne), per arrivare, a valle della stipula del contratto, al governo del medesimo.

Manuale applicativo

Appalto pubblico di forniture ICT

Manuale applicativo

Strategie di acquisizione delle forniture ICT

Il primo manuale, che come precedentemente scritto, descrive la presentazione e l’utilizzo delle Linee guida, rappresenta il cappello descrittivo dei diversi contenuti sviluppati, mentre i modelli per la qualità delle forniture forniscono i riferimenti e gli approfondimenti, più culturali e meno immediatamente operativi, a tutti i restanti manuali. Lo schema seguente rappresenta il disegno concettuale delle Linee guida del tutto indipendente dalla numerazione dei manuali.

Manuale d’uso Presentazione e utilizzo delle Linee Guida

Manuale operativo Governo dei contratti ICT

Manuale applicativo Esempi di applicazione

Manuale operativo Dizionario delle forniture ICT

Manuale di riferimento

Modelli per la qualità delle forniture ICT

La pubblicazione e distribuzione delle Linee guida prevede il concomitante utilizzo di diver- si canali costituiti:

• dalla sezione Qualità dei servizi ICT posta nell’home page del sito web del Cnipa all’indirizzo xxxx://xxx.xxxxx.xxx.xx/xxxx/xx-XX/;

• dal Cd-Rom Qualità dei Servizi ICT, distribuito direttamente dal Cnipa;

• dalla collana editoriale i Quaderni del Cnipa.

La struttura delle Linee guida sopra presentata sarà mantenuta invariata indipendentemente dal canale di distribuzione utilizzato.

Nella versione a stampa delle Linee guida che state leggendo relative al “Dizionario delle Forniture ICT”, vengono introdotti i concetti comuni alle singole classi di Fornitura esistenti, ma le stesse non vengono singolarmente riportate. Questo in quanto il Dizionario delle for-

niture ICT è ideato come un archivio di tipologie di forniture a cui attingere, in un’ottica di riuso (copia e incolla dei contenuti), per l’elaborazione di contratti e capitolati tecnici. Le singole classi di fornitura, seguendo la logica di quanto scritto, possono quindi essere scari- cate direttamente dal sito CNIPA.

I Manuali stampati nell’ambito della collana editoriale i Quaderni, sono i seguenti:

• Quaderno n° 31 - manuale 1: Presentazione e utilizzo delle Linee guida;

• Quaderno n° 31 - manuale 2: Strategie di acquisizione delle forniture ICT;

• Quaderno n° 31 - manuale 3: Appalto pubblico di forniture ICT;

• Quaderno n° 31 - manuale 4: Dizionario delle forniture ICT;

• Quaderno n° 31 - manuale 5: Esempi di applicazione;

• Quaderno n° 31 - manuale 6: Modelli per la qualità delle forniture ICT;

• Quaderno n° 31 - manuale 7: Governo dei Contratti ICT.

Tutti gli aggiornamenti delle Linee guida sono pubblicati sul sito CNIPA dove ognuno dei Manuali e delle Classi di fornitura è identificato con un numero di versione ed una data per facilitare l’identificazione di quello più aggiornato. In ogni caso nella sezione del sito CNIPA già citata, vengono sempre segnalati gli aggiornamenti mentre i documenti obsoleti vengo- no rimossi e non sono più accessibili.

Nei due anni trascorsi dalla pubblicazione delle Linee guida sono state distribuite oltre

8.000 copie dei primi sei manuali e 4.000 copie del settimo manuale dedicato al “Governo dei contratti ICT” (rilasciato a marzo 2006).

Ovviamente questi risultati non sono un indicatore di qualità delle Linee guida, ma testimo- niano dell’elevato interesse che i temi trattati dalla Linee guida sollevano all’interno di amministrazioni e fornitori ICT.

Alla mera distribuzione delle Linee guida, si sono affiancate attività informative e formative volte alla loro diffusione:

• complessivamente, i convegni realizzati sono stati 13 per un totale di circa 2600 perso- ne coinvolte;

• parallelamente ai convegni sinora sono stati organizzati 6 interventi formativi che hanno coinvolto dirigenti e funzionari di pubbliche amministrazioni centrali e locali per un totale di 700 giorni persona;

• a valle dell’esperienza formativa maturata, sono stati realizzati materiali didattici per complessive 34 ore di lezione che, in conseguenza dell’interesse manifestato dai par- tecipanti agli eventi sopra riportati, sono stati resi disponibili sul sito CNIPA.

Per concludere vorremmo invitarvi ad esprimere la vostra valutazione delle Linee guida compilando sul sito CNIPA un semplice e sintetico questionario (Qualità dei Manuali: la vostra valutazione). Questo allo scopo di fornire indicazioni sulla qualità riscontrata nella let- tura e l’utilizzo dei manuali, fornendo al tempo stesso utili suggerimenti di miglioramento.

Xxxxx Xxxxxxx

Responsabile Area

Governo e Monitoraggio Forniture ICT

Modelli per la Qualità delle Forniture ICT

Manuale di riferimento

febbraio 2007

Versione 3.0

1. Generalità sul documento

Le Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione hanno lo scopo di definire:

• un quadro di riferimento complessivo per l’appalto pubblico di servizi ICT da parte delle amministrazioni;

• metodi quantitativi da applicarsi per definire misure di qualità ed identificare pro- cessi di misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediata- mente applicabili, sia alle amministrazioni appaltanti che ai fornitori offerenti;

• adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di capi- tolati e contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla descrizione delle attività da prevedersi contrattualmente, ai prodotti che dette attività realizzano (deliverables contrattuali), agli indicatori e misure di qualità da riferirsi sia alle attività che ai prodotti;

• clausole successivamente utili nella fase di attuazione dei contratti ICT, per la neces- saria azione di governo del contratto e lo svolgimento del monitoraggio per la veri- fica del rispetto dei requisiti contrattuali in termini di tempi, costi e stato avanza- mento lavori, quantità e qualità attese dei servizi ICT richiesti.

Per la realizzazione di queste Linee guida, il gruppo di lavoro ha dovuto, propedeutica- mente alla scrittura delle diverse tipologie di forniture ICT, definire un modello che costi- tuisse il riferimento univoco al quale rifarsi. Ciò è stato reso necessario dall’elevato paral- lelismo con il quale si è proceduto alla scrittura delle Linee guida ed al grande numero di persone che hanno direttamente contribuito con propri scritti.

L’approccio alla base del lavoro, più dettagliatamente illustrato nel Manuale d’uso “Presentazione ed utilizzo delle Linee guida”, si basa:

• sull’identificazione dei diversi punti di vista per la definizione della qualità concor- renti in ambito contrattuale;

• sull’analisi dell’intero ciclo di vita che realizza la fornitura;

• sull’identificazione di indicatori di qualità da riferirsi alle caratteristiche di qualità delle attività e prodotti del ciclo di vita.

• sull’identificazione delle attività e delle modalità più opportune, in fase di attuazio- ne dei contratti, per la necessaria azione di governo degli stessi.

Questi aspetti fondanti del lavoro svolto sono stati esplicitati e dibattuti prima ancora di iniziare il lavoro di descrizione delle forniture ICT. A queste riflessioni si è scelto di rife- rirsi con il termine di “Modelli per la qualità delle forniture ICT”.

Scopo di questo manuale di riferimento è presentare i “Modelli per la qualità delle forni- ture ICT” illustrando gli standard e le logiche adottate per la descrizione delle forniture elementari e la definizione della loro qualità, nonché per il governo dei contratti.

Diversamente dalle altre componenti delle Linee guida, Manuali applicativi e Dizionario delle forniture ICT, questo manuale non esprime “ragionamenti in materia di appalto” o fornisce “ricette contrattuali” di immediata applicazione in fase di definizione o governo di un contratto ICT.

Ciò nonostante si è ritenuto utile completare ed integrare i contenuti affrontati dalle Linee guida in un ottica operativa e pragmatica con un Manuale di riferimento che fornisse i riferimenti culturali di base e puntamenti a possibili approfondimenti.

Questo manuale di riferimento presenta:

• punti di vista per la definizione di qualità

• processi del ciclo di vita della generica fornitura

• categorie ed attributi di qualità della generica fornitura

• modelli per le gestione dei contratti ICT

• glossario (definizioni e acronimi)

• bibliografia (testi, articoli, siti)

Riferimenti

• UNI CEI ISO/IEC 12207: 2003 “Tecnologia dell’informazione – Processi del ciclo di vita del software”;

• Norma ISO/IEC 9126-1:2001 “Software engineering – Product quality – Part 1: Quality mode”.l

2. Gruppo di Lavoro

Le Linee guida di cui il presente manuale fa parte integrante sono state elaborate da un Gruppo di lavoro, dedicato alla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti ICT della Pubblica Amministrazione. Il Gruppo di lavoro è stato costituito nel dicembre 2003 dal Centro nazionale per l’informatica nella pubblica ammi- nistrazione (CNIPA), in modo tale da rappresentare al suo interno sia alcune amministra- zioni centrali, che le associazioni di categoria dei fornitori di servizi ICT.

Il Gruppo di Lavoro, di cui è referente l’Xxx. Xxxxx Xxxxxxx, Componente dell’Organo col- legiale del CNIPA, è stato coordinato dal Xxxx. Xxxxx Xxxxxxx, Dirigente del CNIPA. Fanno parte del Gruppo di lavoro:

Xxxxxx Xxxxxxxxxx in rappresentanza del Ministero di Giustizia; Xxxxx Xxxxx CNIPA;

Xxxxxxxx Xxxx in rappresentanza del MIUR; Xxxxxxxxx Xxxxxxx in rappresentanza di FEDERCOMIN; Xxxxxxx Xxxxxxx in rappresentanza di CONSIP; Xxxxxxxx Xxxxxxxx CNIPA;

Xxxxxxx X’Xxxxx in rappresentanza dell’INPS; Xxxxxxxx Xxxx in rappresentanza di ASSINFORM; Xxxxxxx Xxxx CNIPA, consulente;

Xxxxxx Xxxxx in rappresentanza di SOGEI

Xxxxxxx X. Romano in rappresentanza di ANASIN/AITech; Xxxxxxx Xxxxxxx CNIPA, consulente.

Pur non partecipando al Gruppo di lavoro, la Banca d’Italia ha messo a disposizione l’e- sperienza codificata nel proprio manuale di qualità del software e fornito utili indirizzi sul tema dei servizi afferenti allo sviluppo del software, in particolare si ringraziano:

Xxxxxxx Xxxxxxx Xxxxx Xxxxx

Per il contributo fornito alla stesura di questo manuale si ringraziano inoltre in particolare:

Xxxxxx Xxxxxx Xxxxxxxxx Xxxxxxx Xxxxxx Xxxxxx della società CONSIP e

Xxxx Xxxxxx responsabile di TenStep Italia Andrew X. Xxxxxx xxxxxxxxxx Xxxxx

Xx Xxxxxxxxxxxxxxx direttamente coinvolte nel Gruppo di lavoro, hanno partecipato ai lavori e contribuito alla redazione delle Linee anche per il tramite di proprio personale non direttamente rappresentato nel gruppo, si ringraziano per questo:

Xxxxxx Xxxxxxxxx Xxxxx Xxxxxxx Xxxx Xxxxxxxxxxx Xxxxxxxxxx Xxxxxxxxxx Xxxxxx Xxxxx

Le imprese associate a Xxxxxx/AITech, Assinform e Federcomin, chiamate a partecipare dalle proprie associazioni, hanno risposto con entusiasmo e partecipato alla definizione delle Linee guida mettendo a disposizione le proprie fattive esperienze di erogazione dei servizi ICT e predisposizione di offerte.

Hanno contribuito con particolare continuità una ventina di diverse imprese, tra le più rappresentative del mercato ICT nazionale, che hanno contribuito affiancando il gruppo di lavoro con circa 80 persone loro dipendenti.

Accenture	Alcatel	Atesia
Bull	CSC Italia	Elsag
Laser Memory card	Microsoft	Symantec
ACI Informatica	Business Object	C&M Group
COMPUWARE	EDS Italia	FINSIEL
GETRONICS	IBM	ORACLE Italia
SAP Italia	Sistemi Informativi	Telecom Italia

Un particolare ringraziamento va pertanto a:

Xxxxx Xxxxxxxxxx Xxxxxxxx Xxxxx Xxxxxx Xxxxxx Xxxxxxxx Xxxxxxx Xxxxx Xxxxxxx Xxxxxxxx Xxxxxxxxx Xxxxx Xxxxxxxxxx Xxxxxxx Xxxxxxxxxx Xxxxxxxx Xxxxxxxx Xxxxx Xxxxxxx Xxxxxxxxxx Xxxxxxxx Xxxxx Xxxxxxxxxx Xxxxxxxx Xxxxxxxx Xxxxx Xxxxxxxxxx Xxxxxxx D’xxxxxxx Xxxxxxxx De Xxxxxxxxx Xxxxxxx De Xxxxxxxxxx Xxxxxxx Xx Xxxxx Xxxxx Xxxxxx Xxxxxxxx di Xxxxxx Xxxxx Xx Xxx Xxxxxxx Xxxxxx Xxxxx Xxxxxxx Xxxxx Xxxxxx Xxxxxxxxx Xxxxxxx Assunta Formato Xxxxxxxxxx Xxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxx Xxxxxxxx Xxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxx Xxxxxxxx Xx Xxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxxxxx Xxxxxxxxxx Xxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxxxx Xxxxxxxxx Xxxxxxx Xxxx Xxxxxxxx Xxxxxxxx Xxxxxxx Xxxxxx Xxxxxx Xxxxxxxxx Xxxxxxx Xxxxxxx Xxxxx Xxxxxx Xxxxxxxxxxx Xxxxxxxxxx Xxxxxx Xxxxxxxxx Xxxxxxxxxx Xxxxx Xxxxxxxxxx Xxxxxxxx Xxxxxxxxx Xxxxx Xxxxxxx Franco Xxxxxxx Xxxxxxxx Xxxxxx

Xxxxxxx Xxxxxx Xxxxx Xxxxxxx Xxxxx Xxxxxxxxx Xxxxxxxx Xxxxxx Xxxxxxxx Xxxxxxxxxxx Xxxxxxxx Xxxxxxxxx Xxxxxx Xxxxx Xxxxxx Xxxxxxxx Xxxx Xxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxxxx Xxxxxxx Xxxxxxx Xxxxx Xxxxxx Xxxxxx Xxxxxxx Xxxxxx Xxxxx Xxxxxxxx Xxxxxxxxxx Xxxxx Xxxxxxxx Xxxxxxxxx Xxxxx Xxxxxxxxx Xxxxxxx Xxxxxxxx Xxxxxxxx Xxxxxxx N. Xxxxxxxxxx Xxxxxxx Xxxxxxxx

Xxxxxx Xxxxxx Xxxxxxxx Xxxxxxx Xxxxx Xxxxxxx Xxxxxxx Xxxxxxxx Xxxxxxxxx Xxxxxx Xxxxx Xxxxxxxxxx Xxxxxxx Xxxxxxxxxx Xxxxxxxx Xxxxxxxxxx

In varie fasi del lavoro il Gruppo si è avvalso anche dei contributi e dei suggerimenti di altre persone ed aziende ICT che, pur non essendo coinvolte operativamente nella scrit- tura delle Linee guida, hanno seguito con interesse i lavori.

Nell’impostazione della struttura delle Linee guida, si è cercato di identificare il percorso logico più opportuno per definire dei modelli di qualità delle forniture ICT per la Pubblica Amministrazione. Non essendo disponibile in letteratura alcun riferimento certo e puntua- le, si è deciso di procedere su due fronti paralleli.

Da un lato si è cominciato a definire il campo di riferimento reale, sviluppando tre tipi di analisi delle forniture ICT:

• la prima, per identificare il più efficace livello di granularità atto a definire un insie- me il più possibile esaustivo di “forniture elementari”, desunte dall’esperienza e dalla realtà del mercato attuale; ciò allo scopo di costruire un “dizionario delle for- niture ICT” con valenza operativa e di orientamento per il futuro;

• la seconda per ottenere, in analogia con quanto sopra, il quadro delle strategie di acquisizione delle forniture ICT per arrivare alla migliore prospettiva per l’appalto pubblico delle medesime forniture.

• la terza, per definire le più opportune strategie per il governo dei contratti ICT.

Dall’altro, si è cercato di inquadrare la problematica della qualità senza partire da una pagina bianca, ma facendo riferimento a capisaldi solidi ed affermati, nel contesto dell’e- sperienza legata alle vicende delle Norme ISO e delle decennali attività industriali di svi- luppo software. Si è perciò integrata la moderna visione che privilegia la cultura del ser- vizio nei confronti di quella del prodotto, con il pur necessario recupero dei valori che al prodotto sono legati. Ciò ha comportato la necessità di ripartire con la definizione delle caratteristiche di qualità secondo i diversi punti di vista delle parti in gioco:

• il fruitore (utente finale, sia che si tratti del cittadino utente dell’Amministrazione, sia che si tratti dell’operatore, appartenente all’Amministrazione, che opera all’inter- no del processo);

• l’appaltatore ovvero la stazione appaltante;

• la fornitura come portatrice della sua qualità intrinseca.

A questo proposito, in relazione alle varie proposte della letteratura in materia, il model- lo preso a riferimento per descrivere il ciclo di vita di una fornitura ICT è quello indica- to dalla norma UNI CEI ISO/IEC 12207. Infatti, sebbene esso sia concepito per la descri- zione di processi legati allo sviluppo del software, nondimeno risulta facilmente genera- lizzabile alla realizzazione di prodotti, servizi e sistemi in senso più ampio.

La norma, infatti, definisce un insieme di processi, attività e compiti progettati per essere personalizzati rispetto ai diversi progetti software, permettendo l’eliminazione di proces-

si, attività o compiti non applicabili. La norma, inoltre, non prescrive l’adozione di una particolare metodologia di sviluppo, né impone uno specifico ciclo di vita (a cascata, a spirale, incrementale o iterativo), elementi questi che possono variare in funzione dei pro- cessi produttivi e delle metodologie in uso presso ciascun Fornitore. Ciò che prescrive lo standard è che, qualunque sia il ciclo di vita adottato, debbano essere comunque svolti, in modo formalizzato e controllato, alcuni processi di base.

Infine si è innestato su quanto previsto dalla norma ISO/IEC 9126-1:2001 sulla qualità del prodotto software il risultato dell’integrazione dei modelli di qualità sviluppati per i servi- zi (Servqual).

Per quanto riguarda la problematica del governo dei contratti si sono presi a riferimento i modelli più accreditati per la gestione dei progetti, nei termini previsti dalla norma UNI ISO 10006:2005 – “Linee guida per la gestione della qualità nei progetti”, dal PMBOK “ La Guida al Project Management Body of Knowledge” del Project Management Institute applicata nella metodologia TenStep, e dal modello di monitoraggio utilizzato dal CNIPA (ai sensi del DGLS 39/93)

L’approccio adottato per la stesura delle Linee guida prevede di considerare diversi punti di vista al fine di identificare misure di qualità da rappresentare contrattualmente. Detti punti di vista sono quelli:

• della qualità intrinseca del servizio, direttamente correlata a caratteristiche di quali- tà del servizio e dei prodotti correlati;

• del fruitore del servizio (utente finale), direttamente interessato alla cosiddetta qua- lità attesa e percepita (qualità in uso);

• della amministrazione appaltante il servizio (stazione appaltante), interessata ai pro- cessi di sviluppo e di erogazione messi in atto dal fornitore.

I paragrafi seguenti esplorano queste diverse dimensioni di qualità che hanno tutte la necessità di trovare rappresentazione all’interno dei contratti ICT.

4.1 Qualità intrinseca della fornitura

Per lo sviluppo della Società dell’Informazione si attribuisce grande rilievo alla “digitaliz- zazione” delle Amministrazioni pubbliche ed in particolare alla diffusione delle tecnolo- gie dell’informazione e delle telecomunicazioni (ICT) come strumento per realizzare il miglioramento della qualità dei servizi resi agli utenti ed accelerare il cambiamento del- l’azione amministrativa verso obiettivi di efficienza ed efficacia.

Lo sviluppo di soluzioni ICT di ausilio per un’Amministrazione, sia per svolgere proprie funzioni istituzionali sia per erogare servizi on-line ai cittadini e alle imprese, è un’atti- vità complessa ed in continua evoluzione, che richiede professionalità e strutture spe- cialistiche non sempre presenti nell’ambito di organizzazioni il cui core business è basa- to sulla erogazione di servizi di pubblica utilità; per tali motivi le Amministrazioni ten- dono sempre più ad acquisirle rivolgendosi al mercato. L’affidamento avviene attraver- so l’esperimento di procedure concorsuali, svolte nel rispetto delle disposizioni norma- tive nazionali e comunitarie, e la successiva sottoscrizione di un contratto con il Fornitore selezionato. Il prodotto finale dell’attività amministrativa, di cui i servizi eroga- ti ai cittadini ed alle imprese costituiscono parte rilevante, è direttamente influenzato dal- l’insieme dei processi attuati da tutte le entità organizzative delle Pubbliche Amministrazioni Centrali (PAC) e Locali (PAL) coinvolte, incluse le organizzazioni dei loro Fornitori. Ne deriva che l’aspetto del rapporto con i Fornitori risulta determinante ed è importante stabilire nei contratti regole precise riguardo alle forniture che si xxxxxx- dono ed ai relativi requisiti di qualità.

La complessità, in tal senso, sta nel fatto che le forniture informatiche oggetto dei contrat- ti stipulati dalle Amministrazioni, si configurano in genere come acquisizione di servizi, che vengono erogati da un Fornitore per un certo periodo di tempo e che non sono necessariamente correlati alla produzione di beni materiali o immateriali, salvo ci siano beni rinvenienti contrattualmente determinati.

D’altra parte, anche nel caso della più semplice transazione in cui si realizza la consegna di un prodotto, esiste un rapporto comunicativo tra il Fornitore e l’Acquirente entro cui la transazione stessa si sviluppa e si configura come un servizio.

Sebbene un servizio, a differenza di un prodotto materiale, non si qualifichi per delle pro- prietà intrinseche e comporti delle logiche di acquisto diverse dalle logiche di acquisto di un prodotto, un aspetto che accomuna prodotti e servizi è insito nel concetto stesso di qualità. Secondo le norme ISO, la qualità può essere definita come … l’insieme delle pro- prietà e delle caratteristiche di un prodotto/servizio che gli conferiscono l’attitudine a sod- disfare esigenze o aspettative espresse o usualmente implicite o obbligatorie del cliente e di altre parti interessate.

Ai fini della definizione, in ambito contrattuale, dei requisiti di qualità di un prodotto/ser- vizio e delle relative modalità di verifica e controllo, è necessario pertanto identificare i clienti e le altre parti interessate alla fornitura che, nell’ambito di una Amministrazione che stipuli un contratto con un Fornitore, possono essere rappresentate dalle seguenti figure:

• fruitore o utente finale: la persona o l’organizzazione che utilizzerà il prodotto/ser- vizio oggetto di fornitura contrattuale o beneficerà dei risultati (centro di costo);

• appaltatore: la persona o l’organizzazione che richiede il prodotto/servizio, ad uso del fruitore, attraverso la stipula di un contratto con un Fornitore.

Fanno capo alla figura dell’appaltatore, potendo consistere in una stessa entità organizza- tiva o in entità distinte, le seguenti:

• la persona o l’organizzazione che finanzia il progetto per l’acquisizione della forni- tura (centro di spesa);

• la persona o l’organizzazione che è responsabile, dal lato dell’Amministrazione acquirente, di realizzare il progetto (centro di responsabilità). È il principale inter- locutore del Fornitore, per quanto riguarda le modalità di sviluppo e gestione della fornitura, secondo i requisiti espressi nel contratto.

Per quanto riguarda poi l’identificazione delle proprietà e delle caratteristiche di qualità, prendendo spunto dal modello di qualità proposto dalla norma ISO/IEC 9126-1:2001, pre- sentato di seguito in questo stesso manuale successivo, è possibile caratterizzare un pro- dotto/servizio per aspetti legati a:

• Qualità interna: determinata dall’insieme delle caratteristiche interne del prodotto/servizio;

• Qualità esterna: determinata dall’insieme delle caratteristiche che si manifestano all’esterno, quando il prodotto/servizio è usato come parte di un sistema; dette caratteristiche sono un risultato delle caratteristiche interne del prodotto/servizio;

• Qualità in uso: effetto combinato, per l’utente, delle caratteristiche di qualità inter- na ed esterna del prodotto/servizio.

Lo schema seguente mostra le relazioni esistenti tra qualità interna, qualità esterna e qua- lità in uso: la qualità del processo contribuisce a migliorare la qualità interna ed esterna del prodotto/servizio e quest’ultima contribuisce a migliorare la qualità in uso; similar- mente, la valutazione della qualità in uso può fornire un feedback per il miglioramento del prodotto/servizio, e la valutazione del prodotto/servizio può fornire un feedback per il miglioramento del processo.

Ai fini della pianificazione e del controllo delle misure di qualità di un prodotto/servizio oggetto di fornitura contrattuale, le caratteristiche di qualità intrinseche del prodotto/ser- vizio (qualità interna) o legate all’utilizzo del prodotto/servizio come parte di un sistema (qualità esterna) o in uno specifico contesto d’uso (qualità in uso), sono da esaminare con riferimento ai seguenti diversi aspetti, legati allo sviluppo, alla erogazione ed alla valuta- zione da parte dell’utente finale del prodotto/servizio:

• Qualità attesa (o prevista): è determinata dalle esigenze esplicite, implicite, obbliga- torie o latenti, ovvero dalle attese del cliente;

• Qualità progettata: è il livello di qualità definito nell’ambito del processo di svilup- po della fornitura, sulla base delle caratteristiche di qualità attesa; regola il sistema organizzativo, le modalità di realizzazione del prodotto/servizio e le condizioni ope- rative di funzionamento;

• Qualità erogata (dimostrata): è il livello di qualità risultante dal processo di gestio- ne operativa, ovvero relativo al prodotto/servizio realizzato/erogato ed è oggettiva- mente dimostrato. È l’aspetto di qualità per il quale vanno pianificate ed effettuate le misure in ambito contrattuale, al fine di applicare penalità in caso di mancato rispetto dei requisiti di qualità fissati. Le verifiche vanno commisurate alle effettive esigenze di misura, visto che l’implementazione e la gestione di un sistema di misu- ra è di per sé un costo per l’Amministrazione e per il Fornitore.

• Qualità percepita: è il livello di qualità che l’utente valuta, in base all’esperienza d’uso e tramite il confronto tra le prestazioni erogate e le proprie attese. Essa è influenzata non soltanto dall’esperienza recente sul prodotto/servizio, ma anche da altri fattori, tra i quali le precedenti esperienze vissute, il paragone con prodotti/ser- vizi analoghi, nonché l’immagine complessiva dell’organizzazione che realizza/ero- ga il prodotto/servizio. Lo scostamento della qualità percepita dalla qualità attesa, determina il livello di soddisfazione dell’utente finale.

In particolare, data la complessità tecnica, per la fornitura di un servizio ICT è di norma necessario che il committente predisponga un documento esterno al contratto, nel quale definisce in dettaglio l’oggetto della prestazione che richiede. Questo documento, chia- mato “Service Level Agreement (SLA)”, descrive la prestazione richiesta, gli obblighi del Fornitore e gli obblighi e i diritti del committente e può essere parte del Capitolato Tecnico o un suo allegato.

Non esistono SLA standard, ma in sostanza devono essere precisate in dettaglio le condi- zioni nelle quali ha validità l’accordo (ambientali, organizzative, tecniche, ecc.) e il livel- lo delle prestazioni attese (il livello di possesso atteso di determinate caratteristiche).

Comunque, a prescindere dalle metodologie e dai sistemi di misura che si possono adot- tare, ciò che conta è che il processo di pianificazione e controllo delle caratteristiche di qualità dei prodotti/servizi oggetto della esecuzione di un contratto, rilevi e renda coeren- ti le diverse concezioni di qualità da parte dei clienti della fornitura, diversità derivanti dalle differenze che necessariamente contraddistinguono il punto di vista di chi usufrui- sce del prodotto/servizio dal punto di vista di chi appalta.

4.2 Punto di vista del fruitore

Il termine fruitore si riferisce al soggetto che è l’utente o il beneficiario dei prodotti/ser- vizi oggetto di fornitura. In tal senso possono essere fruitori:

• utenti finali esterni alle Amministrazioni, ovvero i cittadini o le imprese che posso- no direttamente usufruire dei prodotti/servizi realizzati in esecuzione del contratto;

• utenti finali interni ad una stessa Amministrazione o a più Amministrazioni, quali ad es. dipendenti che utilizzano i prodotti/servizi per svolgere compiti istituzionali dell’Amministrazione di appartenenza;

• utenti interni o esterni ad una Amministrazione, appartenenti a Fornitori terzi, che devono assicurare la gestione operativa e la manutenzione dei prodotti e servizi rea- lizzati in esecuzione del contratto.

Le diverse tipologie di utenti finali, tra le quali quelle sopra evidenziate, concorrono ad identificare le caratteristiche di qualità che determinano il profilo di qualità attesa del pro- dotto/servizio da parte del fruitore.

Ogni fruitore, infatti, prende in considerazione e valuta prevalentemente quelle caratteristi- che di qualità che risultano direttamente osservabili in relazione alle proprie esigenze. In tal senso il livello di qualità attesa da parte di un fruitore che utilizzi il prodotto o servizio come utente finale è necessariamente diverso dal fruitore che dovrà prendere in carico la manutenzione o la gestione del prodotto. Con riferimento al modello proposto dalla norma ISO/IEC 9126-1:2001, l’utente finale apprezzerà prevalentemente l’usabilità e la funzionali- tà del prodotto; l’utente manutentore o gestore privilegerà anche la manutenibilità.

Tralasciando i casi in cui il fruitore sia l’utente manutentore o gestore, visto che general- mente una Amministrazione affida al Fornitore tutte le attività relative al ciclo di vita della fornitura, si può dire che:

• l’usabilità, intesa come capacità del prodotto di essere capito, utilizzato e gradito;

• la funzionalità, intesa come capacità del prodotto di soddisfare le esigenze dell’u- tente;

• l’affidabilità, intesa sia come disponibilità in termini assoluti del prodotto o servizio, sia come tolleranza ai guasti atta a garantire la disponibilità del prodotto;

• l’efficienza temporale, come capacità di rispondere tempestivamente alla richieste o tempo di risposta (a titolo di esempio, la reattività che un prodotto software deve mostrare ad uno specifico comando impartito dall’utente; la rapidità di intervento di un servizio di manutenzione attivato mediante call center da un utente);

siano le caratteristiche di qualità comunemente prese a riferimento per determinare il pro- filo di qualità attesa di un prodotto da parte del fruitore.

Dal momento che spesso l’utente non è esperto di tecnologie informatiche, un aspetto rilevante per il fruitore è la gradevolezza e la comprensibilità della interfaccia del prodot- to che, proprio perché spesso è l’unica parte del sistema con cui l’utente entra in contat- to, deve essere user-friendly (amichevole per l’utente) e consentire un facile reperimento delle funzioni di interesse. Nel caso di accesso al sistema da parte di disabili (es. di tipo motorio, visivo, uditivo), una caratteristica rilevante è l’accessibilità, che prevede il rispet- to di specifiche norme. L’accessibilità è un prerequisito dell’usabilità e non la sostituisce. Al di là delle caratteristiche di qualità di prodotti/servizi che siano maggiormente signifi- cative dal punto di vista del fruitore e che possono essere rilevate dal modello proposto, è importante evidenziare che ciò che è più facilmente misurabile e pertanto direttamente percepibile dall’utenza non è tanto la qualità interna, risultato del processo di sviluppo, quanto la qualità che attiene all’interazione dell’utente con le risorse e le attività dell’or- ganizzazione preposte alla erogazione del servizio, elementi che determinano la qualità percepita ed il livello di soddisfazione dell’utente rispetto al prodotto/servizio realizzato/erogato.

La soddisfazione, misurata attraverso lo scostamento tra qualità percepita e qualità attesa, è una reazione dell’utente influenzata dall’esperienza diretta sull’utilizzo del servizio (qua- lità in uso), in cui le caratteristiche “oggettive” del prodotto/servizio (qualità erogata) sono valutate alla luce delle aspettative, cioè delle prestazioni attese, ma sono anche influen- zate dalla comunicazione ricevuta, dal contesto esterno e da altri fattori che caratterizza- no le modalità di erogazione del servizio, quali l’accessibilità, gli strumenti utilizzati, le procedure applicate e, non ultime, la competenza e la cultura “customer-oriented” (orien- tata al cliente) del personale che interfaccia direttamente l’utente. Questo ultimo punto dimostra come la soddisfazione dell’utente sia altresì collegata alla soddisfazione dei dipendenti, sulla quale incidono diversi elementi, tra i quali il trattamento economico, le responsabilità ed il coinvolgimento nell’ambito della organizzazione, la crescita professio- nale, l’ambiente di lavoro. È frequente, infatti, rilevare che un dipendente scontento e demotivato molto difficilmente si dimostra cortese ed efficiente verso il proprio interlocu- tore; per contro un dipendente soddisfatto è una persona motivata, che è solito adottare un approccio proattivo verso l’interlocutore, contribuendo a migliorarne la percezione sulla qualità del servizio reso.

Si può quindi concludere che ciò che è importante dal punto di vista del fruitore, è che lo scostamento tra percezioni ed attese risulti minimo; tale risultato non implica peraltro che la qualità interna e la qualità erogata siano meno importanti: si tratta infatti di dimen-

sioni non alternative, ma complementari ai fini del buon esito del servizio, al quale con- tribuisce in modo determinante l’attenzione posta alle esigenze del fruitore in tulle le atti- vità che caratterizzano il ciclo di vita della fornitura.

4.3 Punto di vista di chi appalta

Il termine appaltatore è utilizzato in questo contesto per riferirsi al soggetto che rappre- senta il cliente diretto del Fornitore nell’ambito di un contratto stipulato da una Amministrazione per l’acquisizione di un prodotto/servizio ICT e che, oltre a curare le procedure concorsuali per la selezione del Fornitore, ha la responsabilità di gestire il con- tratto con il Fornitore aggiudicatario per tutto il ciclo di vita della fornitura.

Nell’organizzazione di chi appalta sono quindi presenti, oltre a potenziali fruitori e bene- ficiari del prodotto servizio oggetto di fornitura, le entità organizzative che hanno in capo la responsabilità di finanziare e realizzare il progetto e per le quali è necessario persegui- re obiettivi di:

• efficacia, intesa come grado di rispondenza dell’output agli obiettivi;

• efficienza, intesa come rapporto input/output, ovvero come relazione tra prestazio- ni ottenute e costi sostenuti.

Risulta quindi importante dal punto di vista di chi appalta, da un lato garantire che il pro- dotto/servizio oggetto di fornitura risponda alle esigenze dell’Amministrazione, soddisfi le necessità dei fruitori e sia realizzato/erogato nel rispetto dei requisiti contrattuali, garan- tendo appropriate prestazioni rispetto alle risorse utilizzate; dall’altro assicurare che la soluzione identificata ben si inserisca nel contesto informativo cui è destinata.

In tal senso, nel procedere all’acquisizione del prodotto/servizio, nel definire i requisiti della fornitura e nell’effettuare valutazioni in corso d’opera durante l’esecuzione del con- tratto, risultano importanti dal punto di vista dell’appaltatore quegli aspetti connessi alla razionalizzazione della modalità di acquisizione della fornitura, tra i quali si evidenziano a titolo indicativo e non esaustivo:

• l’integrazione del prodotto/servizio oggetto di acquisizione nel sistema informatico pre-esistente e la salvaguardia degli investimenti già effettuati. Da tale punto di vista, con riferimento alle caratteristiche di qualità indicate nel modello proposto, assumo- no importanza caratteristiche quali la interoperabilità, intesa come capacità di inte- razione del prodotto/servizio con uno o più sistemi, la conformità alla funzionalità, intesa come grado di rispondenza a standard, convenzioni e norme di legge in materia e la coesistenza, intesa come capacità di coesistere con un altro prodot- to/servizio in un ambiente specificato;

• le esigenze di addestramento/formazione del personale, connesse all’acquisizione delle fornitura. Obiettivo dell’appaltatore è adottare soluzioni che non operino scon- volgimenti nelle prassi di lavoro in uso presso l’Amministrazione e/o che siano facil- mente utilizzabili da parte degli utenti. Tale obiettivo è più facilmente perseguibile se il prodotto/servizio presenta caratteristiche di usabilità ed in particolare di com- prensibilità, di apprendibilità e di operatività;

• la possibilità che il prodotto/servizio sia in grado di operare in ambienti diversi. Detta funzione è garantita dal livello di portabilità della soluzione, caratteristica che risulta importante per l’appaltatore sia a fronte della necessità di garantire il costan- te adeguamento tecnologico dell’ambiente in cui il prodotto/servizio opera, sia ai fini di assicurare la possibilità di subentro di un nuovo Fornitore alla scadenza del contratto.

Gli aspetti sopra evidenziati contribuiscono a determinare il profilo di qualità attesa dal punto di vista dell’appaltatore e influenzano le misure effettuate nel corso della esecuzio- ne del contratto.

In particolare dal punto di vista di chi appalta assume importanza prioritaria la valutazio- ne della qualità delle prestazioni erogate dal Fornitore nel corso della durata del contrat- to secondo misure oggettive di caratteristiche di qualità (qualità erogata o dimostrata), che consentono di evidenziare il grado di conformità delle prestazioni ottenute rispetto ai requisiti contrattuali.

In tale ottica, oltre alle caratteristiche di qualità già evidenziate, possono essere di interes- se per l’appaltatore:

• valutazioni relative alla funzionalità, volte in particolare a stabilire se la soluzione realizzata è in grado di portare effettivamente a termine le operazioni per la cui ese- cuzione è stata definita e progettata;

• valutazioni derivanti da “prove di sforzo’’, volte ad individuare i limiti del sistema che realizza l’ambiente di esercizio del prodotto o di erogazione del servizio rispet- to al dimensionamento adottato ed i margini di ampliamento a fronte del variare dei parametri di dimensionamento (per esempio numero di utenti serviti, quantità di dati, tempi di esecuzione);

• valutazioni relative all’efficienza, aventi l’obiettivo di verificare la capacità di forni- re prestazioni appropriate relativamente alla quantità di risorse utilizzate, in condi- zioni stabilite;

• valutazioni volte a verificare l’affidabilità, con particolare riferimento alla capacità di ristabilire un livello di prestazioni specificato a fronte di malfunzionamenti;

• valutazioni di adeguatezza, essenzialmente indirizzate alla verifica dell’appropria- tezza del prodotto/servizio per eseguire un particolare compito e a stabilire se e come esso è in grado di soddisfare i requisiti per i quali è stato progettato. Includono valutazioni di tipo riassuntivo, destinate a verificare se un sistema già esi- stente è conforme e soddisfa le esigenze degli utenti cui è destinato e valutazioni di tipo formativo effettuate all’inizio della progettazione di un sistema allo scopo di stabilire le linee guida per il suo sviluppo futuro.

Risultano inoltre importanti misure atte a rilevare il livello di soddisfazione dei fruitori, attraverso la valorizzazione dello scostamento tra qualità attesa e qualità percepita; dette misure consentono all’appaltatore di individuare i driver (linee guida) per migliorare il servizio erogato, apportando le opportune modifiche in corso d’opera al contratto, ovvero per meglio dirigere in futuro le scelte relative all’acquisizione di nuovi prodotti e/o servizi.

5. Ciclo di vita delle forniture

Sulla base delle definizioni proposte dalla normativa ISO, una fornitura informatica ogget- to di un contratto stipulato tra un’Amministrazione e un Fornitore è il risultato “tangibile” (materiali; documenti; hardware) o “intangibile” (software; servizi; conoscenze) di un’atti- vità o di un insieme di attività correlate (processi); dette attività, nell’insieme, costituisco- no il ciclo di vita della fornitura.

Sebbene in un rapporto contrattuale tra Amministrazione e Fornitore, una fornitura abbia inizio con le attività che seguono la sottoscrizione del contratto e termini alla scadenza del contratto stesso, il ciclo di vita della fornitura copre l’intervallo temporale che va dalla nascita dell’esigenza da parte dell’Amministrazione di procedere all’acquisizione di un prodotto o di un servizio, alla dismissione del prodotto o alla cessazione del servizio oggetto di acquisizione, attraverso le fasi intermedie di realizzazione, nelle quali si con- centrano le attività che hanno una più alta incidenza sulla qualità finale.

Le modalità di acquisizione e di realizzazione di una fornitura sono diverse a seconda delle caratteristiche proprie di ogni tipologia e sono significativamente influenzate, tra l’al- tro, dalle politiche organizzative e dalle procedure, strategie e metodologie di acquisto in uso presso ciascuna Amministrazione. Nel presente paragrafo si intende presentare un metodo per definire e verificare in corso d’opera una fornitura informatica, al fine di con- sentire alle Amministrazioni di acquisire prodotti e/o servizi che siano effettivamente rispondenti alle esigenze espresse ed implicite degli utenti e che ben si integrino nel con- testo informativo cui sono destinati.

Il metodo proposto prende in esame l’intero ciclo di vita di una fornitura; fare riferimento ad un ciclo di vita, significa prevedere un’organizzazione sistematica delle attività da svolgere secondo processi opportunamente coordinati tra loro, scanditi dalla emissione di prodotti su cui si esercitano operazioni di riesame, verifica e validazione in corso d’opera. In tal modo:

• si definiscono delle regole di comportamento e dei momenti formali di controllo, sia per il Fornitore sia per l’Amministrazione, che consentono di evitare manifesta- zioni di criticità non desiderate di tempi, di costi e di qualità o che comunque ne riducono significativamente la probabilità di occorrenza;

• si costruisce una “traccia logica” della storia della realizzazione e del controllo, che dà evidenza delle operazioni effettuate e delle decisioni prese e che garantisce effi- cacia nella copertura rispetto alle criticità non volute e capacità di recupero al loro eventuale insorgere;

• si garantisce il raggiungimento degli obiettivi fissati e la coerenza tra gli stessi obiet- tivi ed il risultato finale, ovvero si riduce significativamente il rischio che il risultato finale sia non conforme agli obiettivi iniziali.

In relazione alle varie proposte della letteratura in materia, il modello che si prende a rife- rimento per descrivere il ciclo di vita di una fornitura informatica è direttamente derivato da quello indicato dalla norma UNI CEI ISO/IEC 12207. Modello che, sebbene sia conce- pito per la descrizione di processi legati allo sviluppo del software, risulta facilmente generalizzabile alla realizzazione di prodotti, servizi e sistemi in senso più ampio. La norma, infatti, definisce un insieme di processi, attività e compiti progettati per essere per- sonalizzati rispetto ai diversi progetti software, permettendo l’eliminazione di processi, attività o compiti non applicabili.

La norma, inoltre, non prescrive l’adozione di una particolare metodologia di sviluppo, né impone uno specifico ciclo di vita (a cascata, a spirale, incrementale o iterativo), elemen- ti questi che possono variare in funzione dei processi produttivi e delle metodologie in uso presso ciascun Fornitore. Ciò che prescrive lo standard è che, qualunque sia il ciclo di vita adottato, debbano essere comunque svolti, in modo formalizzato e controllato, alcuni processi di base.

In questo contesto il modello è preso a riferimento in via indicativa, con le opportune generalizzazioni e/o integrazioni, allo scopo di consentire l’individuazione in modo siste- matico e, per quanto possibile, esaustivo di tutte le caratteristiche di qualità di attività e prodotti, intermedi e/o finali, che costituiscono il risultato dei processi attuati da un Fornitore in esecuzione di un contratto stipulato con un’Amministrazione. In particolare, seguendo le indicazioni della norma, i processi del ciclo di vita di una fornitura sono scomposti in attività e per ciascuna attività sono identificati i relativi prodotti (documenti, software, soluzioni). La scomposizione si arresta ad un livello di dettaglio che consenta di individuare attività e prodotti che possono essere oggetto di verifica, validazione e, nei casi applicabili di accettazione da parte dell’Amministrazione nel corso della esecuzione di un contratto. Attività e prodotti sono indicati non con lo scopo di stabilire nome, for- mato e contenuto espliciti, quanto con lo scopo di evidenziare i “deliverable tipo” di un contratto sui quali l’Amministrazione può esercitare gli opportuni controlli per verificare in itinere il rispetto di tempi, costi e qualità. Una volta individuati attività e prodotti “tipo” di ogni processo del ciclo di vita, è possibile definire, rispettivamente per le attività e per i prodotti, le caratteristiche di qualità che si ritengono maggiormente significative in fun- zione della tipologia di ciascuna classe di fornitura e degli obiettivi di qualità attesa sul risultato finale.

La norma ISO/IEC 12207 definisce tre tipologie di processi, classificati in:

• Processi primari. I processi primari sono i processi core business, orientati alla gene- razione di prodotti e di servizi verso l’utente finale. Sono sviluppati nell’ambito di ogni singolo progetto finalizzato alla realizzazione di una fornitura e riguardano sia l’Amministrazione che il Fornitore.

• Processi di supporto. I processi di supporto, ad uso interno all’organizzazione che eroga il servizio, sono utilizzati e svolti come parte integrante di altri processi e con- tribuiscono ad assicurare il successo e la qualità del progetto nel suo complesso.

• Processi organizzativi. I processi organizzativi, di tipo manageriale, sono di solito sviluppati fuori dell’ambito di specifici progetti. Riguardano la pianificazione e il controllo del progetto, nonché la gestione delle risorse umane e materiali necessa- rie per la conduzione delle attività contrattuali.

I processi primari sono i processi produttivi veri e propri ed includono, oltre ai processi che regolano l’acquisizione della commessa (Acquisizione) e la gestione dei rapporti con il cliente (Fornitura), il processo di Sviluppo, articolato nelle fasi di progettazione e rea- lizzazione, il processo di Gestione operativa, del quale è parte integrante l’assistenza agli utenti ed infine il processo di Manutenzione, che include le attività relative alla migrazio- ne e alla dismissione del prodotto o alla cessazione del servizio.

I processi di supporto sono indipendenti dal processo primario cui si riferiscono e sono svolti in più momenti; includono la Gestione della documentazione, la Gestione della con- figurazione, il processo di Assicurazione Qualità, unitamente ai processi di Verifica, Validazione, Riesame Congiunto con il Committente, Verifiche Ispettive ed infine il pro- cesso di Risoluzione dei problemi (anomalie o non-confomità).

I processi organizzativi sono trasversali ai processi primari e ai processi di supporto ed includono l’insieme delle attività necessarie per realizzare con successo il progetto e che riguardano in particolare il processo di Gestione del progetto, di Gestione delle infrastrut- ture, di Formazione e di Miglioramento.

I 17 processi sopra indicati, definiti dalla norma, sono composti da “attività” (insieme di azioni coerenti), a loro volta ulteriormente scomponibili in “compiti” (o azioni di base). Attività e compiti generano prodotti (documenti, software, servizi, soluzioni). Nella figura che segue si riporta lo schema dei processi proposti dalla norma.

Esula dagli scopi del presente lavoro descrivere in dettaglio lo standard proposto dalla norma, alla quale si rimanda per ogni esigenza di ulteriore approfondimento.

Ai fini delle Linee guida e della descrizione delle forniture ICT si è scelto di semplificare il ciclo di vita proposto dalla norma UNI/CEI ISO/IEC 12207 riducendo il numero di pro- cessi da 17 a 9.

In particolare si sono raggruppati all’interno di un unico processo, denominato processo di Assicurazione Qualità, molti dei processi di supporto (quelli circondati da un contorno a pallini nella precedente figura raffigurante il ciclo di vita della ISO/IEC 12207): Assicurazione Qualità, Verifica, Validazione, Riesame Congiunto con il Committente, Verifiche Ispettive e Risoluzione dei problemi (anomalie o non-conformità). Analo- gamente si sono raggruppati all’interno di un unico processo, denominato processo di Gestione, tutti i processi organizzativi (circondati da un contorno a pallini nella preceden- te figura raffigurante il ciclo di vita della ISO/IEC 12207): Gestione del progetto, Gestione delle infrastrutture, Formazione e di Miglioramento. In aggiunta si è lasciata cadere la distinzione tra processi di supporto e processi organizzativi raggruppandoli insieme sotto la dizione di processi trasversali (alle singole forniture ICT).

Lo schema che ne risulta è rappresentato dalla seguente figura.

Riassumendo il Ciclo di vota adottato per le forniture ICT nelle presenti Linee guida defi- nisce due tipologie di processi, classificati in:

• Processi primari. I processi primari sono i processi core business, orientati alla gene- razione di prodotti e di servizi verso l’utente finale. Sono sviluppati nell’ambito di

ogni singolo progetto finalizzato alla realizzazione di una fornitura e riguardano sia l’Amministrazione che il Fornitore.

• Processi trasversali. I processi trasversali, ad uso interno all’organizzazione impegna- ta nella fornitura, sono utilizzati e svolti come parte integrante di altri processi e contribuiscono ad assicurare il successo e la qualità del progetto nel suo comples- so riguardando la pianificazione e il controllo del progetto, nonché la gestione delle risorse umane e materiali necessarie per la conduzione delle attività contrattuali.

Nel prosieguo, i processi individuati nel modello di ciclo di vita adottato sono descritti con le opportune personalizzazioni e generalizzazioni rispetto alla norma ISO/IEC 12207, con l’obiettivo di individuare attività e prodotti che possano essere presi a riferimento per descrivere le classi di forniture ICT e le relative misure di qualità.

Il nome attribuito a ciascuna attività e a ciascun prodotto è puramente indicativo del con- tenuto e non esclude la possibilità che l’attività o il prodotto si articolino rispettivamente in più attività o più prodotti.

La descrizione dei processi e la scomposizione di ciascun processo in attività e prodotti, non implica che per ciascuna classe di fornitura debbano essere ugualmente considerati, ai fini delle misure di qualità, tutti i processi, con le attività ed i prodotti indicati.

L’identificazione delle attività e dei prodotti di ciascun processo da prendere in conside- razione nella descrizione di una classe di fornitura e le relative caratteristiche di qualità, sono funzione della tipologia e della specificità di ciascuna classe, ivi inclusi dimensioni, criticità e rischi.

5.1 Processi primari

5.1.1. Processo di Acquisizione

Obiettivi

Il processo riguarda le attività che deve svolgere l’Amministrazione per acquisire un pro- dotto o un servizio ed ha l’obiettivo di definire le caratteristiche della fornitura richiesta, in termini di contenuti, tempi e modalità di esecuzione, requisiti di qualità.

Attivazione del processo

Il processo è attivato dall’Amministrazione quando nasce l’esigenza di acquisire un pro- dotto o un servizio per conseguire determinati obiettivi. Detti obiettivi possono scaturire, per esempio, in fase di pianificazione strategica pluriennale e/o di analisi dei processi interni, dalla necessità di adempiere a disposizioni normative, dall’esigenza di migliorare e/o di offrire servizi all’utenza, dalla necessità di migliorare la produttività interna o l’in- teroperabilità e la cooperazione con altre Amministrazioni.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Acquisizione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Acquisizione
Attività		Prodotti
AC-A1	Definizione delle esigenze	ACA1-O1	Studio di fattibilità
AC-A2	Preparazione della richiesta d’offerta	ACA2-O1	Documenti di gara (Bando di gara; Schema di contratto; Capitolato Tecnico; Schema di offerta tecnico-economica)
AC-A3	Monitoraggio del Fornitore	ACA3-O1	Registrazioni

Definizione delle esigenze. Include l’insieme delle attività svolte dall’Amministrazione preliminarmente alla indizione della gara per selezionare un Fornitore al quale affidare la realizzazione del prodotto. Dette attività riguardano in particolare:

• la formulazione dei fabbisogni di informatizzazione, sulla base dell’analisi dei pro- cessi interni e degli obiettivi da perseguire;

• l’identificazione della soluzione e la valutazione della fattibilità, dal punto di vista tecnico, dei costi connessi alla realizzazione, dei benefici attesi, dei rischi e dei vin- coli tecnologici, temporali e normativi;

• l’analisi del “make or buy”, intesa come valutazione dell’opportunità di esternaliz- zare, in tutto o in parte la realizzazione del progetto e la definizione delle modali- tà di selezione del Fornitore.

Il risultato di tale attività è un documento, Studio di fattibilità, che può essere redatto secondo le “Linee guida per la realizzazione degli studi di fattibilità” emesse dall’AIPA (oggi CNIPA).

Preparazione della richiesta di offerta. A completamento della definizione delle esi-

genze, quando l’Amministrazione abbia ritenuto opportuno e conveniente procedere all’acquisizione della fornitura ed abbia definito sia il contesto della fornitura, sia le moda- lità di selezione del Fornitore, l’Amministrazione avvia la redazione dei documenti neces- sari per espletare la procedura di gara.

Detti documenti, che descrivono in termini quantitativi e qualitativi l’oggetto della forni- tura, i requisiti e le relative modalità di esecuzione, vanno redatti secondo le disposizio- ni normative, nazionali e comunitarie, di riferimento per la tipologia di gara che si deve espletare (pubblico incanto; licitazione privata; appalto concorso; trattativa privata) e in relazione alle norme che regolano le procedure di acquisto presso ciascuna Amministrazione. In linea di massima, i documenti da predisporre sono il Bando di gara, la lettera d’invito a presentare l’offerta, lo schema di contratto, il capitolato tecnico, lo schema di offerta tecnico-economica che dovrà essere presentata da ciascun partecipan- te alla gara, la documentazione per la richiesta del parere di congruità tecnico-economi- co di cui all’art. 8 del decreto legislativo 12 febbraio 1993, n. 39.

Una volta che sia stata espletata la gara, i documenti di gara predisposti dall’Amministrazione nell’ambito della presente attività e l’offerta tecnico-economica pre- sentata dal Fornitore aggiudicatario, nell’ambito del processo di Fornitura, debitamente rivisti per riflettere eventuali modifiche emerse nel corso del procedimento di gara e sot- toscritti dalle parti contraenti, costituiscono la baseline di contratto e regolano l’esecuzio- ne della fornitura per tutto il ciclo di vita, salvo le modifiche che dovranno essere appor- tate nel corso dell’esecuzione degli altri processi.

Monitoraggio del fornitore. A seguito della sottoscrizione del contratto con il Fornitore

aggiudicatario l’Amministrazione, sia in conformità a quanto previsto all’articolo 13, comma 2, del decreto legislativo 12 febbraio 1993, n. 39, sia al fine di assicurare che la fornitura sia realizzata nel rispetto dei requisiti di tempi, costi e qualità indicati nei docu- menti contrattuali, ha il compito di eseguire il monitoraggio delle prestazioni rese dal Fornitore per tutta la durata del contratto.

L’attività è effettuata con riferimento alle disposizioni normative vigenti in materia, tra le quali la Circolare del 28 dicembre 2001, n. AIPA/CR/38, alla quale si può far riferimento per rilevare le principali attività ed i relativi prodotti.

Accettazione e completamento. L’accettazione della fornitura da parte della

Amministrazione è effettuata attraverso il collaudo, attività descritta nell’ambito del pro- cesso di Realizzazione.

Successivamente al collaudo con esito positivo della fornitura, l’Amministrazione deve farsi carico della gestione operativa e della manutenzione, nei casi in cui dette attività non siano per contratto a carico del Fornitore.

Il completamento può coincidere con la scadenza del contratto, cui può seguire il suben- tro di un nuovo Fornitore, ovvero con la dismissione del prodotto o la cessazione del ser- vizio oggetto di fornitura. Dette attività sono descritte nell’ambito del processo di Manu- tenzione.

Chiusura del processo

Il processo si conclude con l’accettazione della fornitura e quando risultino completate tutte le attività a carico del Fornitore in esecuzione del contratto.

5.1.2 Processo di Fornitura

Obiettivi

Il processo riguarda le attività che deve svolgere il Fornitore, a partire dalla predisposizio- ne dell’offerta tecnico-economica in risposta ad una richiesta di proposta da parte di un’Amministrazione, sino alla realizzazione ed alla consegna della fornitura, in caso di aggiudicazione della commessa.

Attivazione del processo

Il processo è attivato dal Fornitore a fronte della decisione di predisporre un’offerta per rispondere alla richiesta di presentazione di una proposta da parte di un’Amministrazione. Il processo prosegue quindi con la sottoscrizione del contratto con l’Amministrazione, in caso di aggiudicazione della commessa, con la determinazione delle procedure e delle risorse necessarie a gestire ed assicurare la corretta esecuzione della fornitura e con lo svolgimento di tutte le attività previste nell’ambito del contratto.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività del processo di Fornitura che riguardano la fase precedente la sottoscrizione del contratto. Le attività che il Fornitore deve svolgere a valle della sottoscrizione del contratto, ricadono nell’ambito degli altri processi primari, organizzativi e di supporto del ciclo di vita della fornitura, descritti nei relativi paragrafi a seguire.

Per le attività ed i prodotti presentati nello schema che segue, si fornisce una descrizione delle finalità e dei contenuti.

Processo di Fornitura
Attività		Prodotti
FO-A1	Preparazione della risposta	FOA1-O1	Offerta tecnico-economica
FO-A2	Riesame e sottoscrizione del contratto	FOA2-O1	Baseline di contratto (Contratto; Capitolato; Offerta tecnico-economica)

Preparazione della risposta. In risposta alla richiesta di una proposta da parte di un’Amministrazione (bando di gara, lettera d’invito, ecc.), il Fornitore predispone un’of- ferta in cui definisce modalità, tempi e costi per realizzare la fornitura, nel rispetto dei requisiti specificati dall’Amministrazione nei documenti di gara (capitolato tecnico, sche- ma di contratto, ecc.).

Il risultato dell’attività è l’offerta tecnico-economica che è vincolante per il Fornitore e, in caso di aggiudicazione della commessa, diviene parte integrante della baseline di contratto. Riesame e sottoscrizione del contratto. In caso di aggiudicazione della commessa, il Fornitore deve negoziare e sottoscrivere il contratto con l’Amministrazione.

È parte integrante dell’attività un riesame del contratto da sottoscrivere, al fine di assicu- rare che i requisiti siano adeguatamente definiti e documentati, che eventuali scostamen- ti tra i requisiti riportati nel contratto e quelli riportati nell’offerta siano risolti e che esista- no le capacità per soddisfare i requisiti indicati.

Il risultato dell’attività, a valle della sottoscrizione del contratto tra le parti e dell’accetta- zione di tutte le clausole contenute nel contratto stesso e nei suoi allegati, è la baseline di contratto, intesa come insieme dei documenti contrattuali (Contratto, Capitolato Tecnico, Offerta tecnico-economica) prodotti nell’ambito dei processi di Acquisizione e Fornitura, che regolano l’esecuzione della fornitura durante il ciclo di vita.

Chiusura del processo

Il processo di Fornitura si conclude con il completamento da parte del Fornitore di tutte le attività previste in esecuzione del contratto.

5.1.3 Processo di Progettazione

Obiettivi

Obiettivo della Progettazione è specificare le caratteristiche della fornitura a partire dai requisiti indicati negli atti contrattuali, definendo le modalità di realizzazione, di verifica e collaudo, di gestione operativa e manutenzione della fornitura, anche con riferimento

ai mezzi ed alle risorse umane e materiali necessarie per svolgere tutte le attività proprie dei processi prima indicati.

Il processo è gestito a livello di progetto secondo il processo di Gestione; le infrastruttu- re e le esigenze di formazione del personale preposto alla conduzione delle attività, sono definite e gestite rispettivamente secondo il processo di Infrastrutture ed il processo di Formazione.

Attivazione del processo

Il processo è svolto dal Fornitore ed è attivato a valle della sottoscrizione del contratto. Sono dati di input del processo l’insieme dei documenti che costituiscono la Baseline di contratto prodotti nell’ambito dei processi di Acquisizione e di Fornitura, ovvero il Contratto, il Capitolato tecnico, l’Offerta tecnico-economica del Fornitore.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Progettazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di progettazione
Attività		Prodotti
PR-A1	Analisi dei requisiti	PRA1-O1	Specifica dei requisiti
PR-A2	Progettazione tecnica	PRA2-O1	Architettura tecnica
PR-A2	Progettazione tecnica	PRA2-O2	Specifiche dei servizi
PR-A3	Progettazione applicativa	PRA3-O1	Specifiche funzionali
		PRA3-O2	Disegno della Base Dati
		PRA3-O3	Prototipo
PR-A4	Progettazione Test e Collaudi	PRA4-O2	Specifiche di collaudo

Analisi dei Requisiti. A partire dai requisiti della Fornitura indicati nei documenti con- trattuali, il Fornitore definisce tutti i requisiti, espliciti, impliciti ed obbligatori, che regole- ranno la fornitura nel corso della esecuzione del contratto. In tale attività è necessario pre- liminarmente identificare con precisione tutti gli attori interessati alla fornitura, i destina- tari diretti e gli utenti finali e confermare/rivedere le rispettive necessità relative ad obiet- tivi e requisiti della fornitura.

Sulla base delle necessità degli utenti, delle relative priorità e delle caratteristiche specifi- che di ogni tipologia di fornitura, devono essere definiti e documentati i requisiti organiz- zativi e legati a profili utenti e casi d’uso, i requisiti di sicurezza e di riservatezza, i requi- siti di ingegneria dei fattori umani (ergonomia), i requisiti del sistema, del prodotto soft- ware e/o del servizio, con riferimento al profilo di qualità previsto nel Piano di qualità ed alle caratteristiche di funzionalità, usabilità, manutenibilità, prestazioni, ...; i requisiti di progettazione, realizzazione, gestione operativa e di manutenzione, i requisiti di qualifi-

cazione, i vincoli normativi e/o di aderenza a standard, i vincoli tecnologici, i vincoli ambientali e/o legati al riuso di componenti, le esigenze di addestramento degli utenti. Nella specificazione dei requisiti, deve essere assicurata la rintracciabilità delle necessità dell’Amministrazione, la coerenza con le necessità stesse, la fattibilità della progettazione, della gestione operativa e della manutenzione.

Il risultato dell’attività è costituito dalla Specifica dei requisiti, ovvero da un documento o insieme di documenti, nei quali sono descritti tutti i requisiti della fornitura, identificati e classificati, nel senso sopra indicato, secondo criteri documentati.

Progettazione Tecnica. Sulla base dei requisiti indicati nella Specifica dei requisiti, il

Fornitore definisce l’architettura tecnica del sistema. L’architettura tecnica individua le componenti hardware, software ed infrastrutturali del sistema, le relative configurazioni e le operazioni manuali. Il Fornitore definisce il servizio da fornire e le relative modalità di realizzazione, di erogazione e di controllo delle caratteristiche di qualità.

Per la soluzione progettuale devono essere garantite la rintracciabilità dei requisiti, la coerenza con i requisiti stessi, l’adeguatezza delle norme di progetto e dei metodi utiliz- zati, la fattibilità della realizzazione, della gestione operativa e della manutenzione. Il risul- tato dell’attività può essere costituito dalle seguenti tipologie di prodotti:

• Architettura tecnica, documento o insieme di documenti, nei quali è descritta la soluzione progettuale, ovvero l’architettura hardware e software del sistema che rea- lizza gli ambienti logici di sviluppo, collaudo ed esercizio, secondo le indicazioni prima riportate;

• Specifiche del servizio, documento o insieme di documenti nei quali, con riferimen- to alle prescrizioni della norma UNI EN 29004-2:1994 “Elementi di gestione per la qualità e del sistema qualità. Guida per i servizi”, è descritto il servizio con le rela- tive caratteristiche (Specifiche del servizio), i mezzi e le modalità per realizzare ed erogare il servizio (Specifiche di realizzazione del servizio) e per controllare i livel- li di qualità (Specifiche di controllo qualità).

Progettazione Applicativa. L’attività è eseguita dal Fornitore nel caso in cui la fornitu- ra richieda la realizzazione di soluzioni software. Con riferimento ai requisiti del prodot- to software da sviluppare e/o del servizio da erogare, indicati nella Specifica dei requisi- ti, il Fornitore definisce l’architettura del prodotto e gli elementi software, dettagliando per ciascun elemento, le componenti ad alto livello e le relative unità software (moduli appli- cativi) che devono essere codificate e sottoposte a prova. Il Fornitore definisce altresì le interfacce (tra unità software, tra componenti, tra prodotto ed utente), il disegno concet- tuale, logico e fisico della Base Dati, la documentazione utente (manuali, help, tutorial, wizard, ..), il diagramma delle classi e delle interazioni nel caso di soluzioni Object Oriented e quanto specifico in funzione della tecnologia di sviluppo da adottare.

Nella soluzione progettuale deve essere garantita la rintracciabilità dei requisiti e la coerenza esterna con i requisiti, la coerenza interna tra i componenti e le unità software, la fattibilità della realizzazione, della gestione operativa e della manutenzione. Il risultato dell’attività può essere costituito dalle seguenti tipologie di prodotti:

• Specifiche funzionali – Documento o insieme di documenti nei quali è indicata l’ar- chitettura e le componenti software, il dettaglio dei moduli applicativi, il disegno

delle interfacce e della documentazione utente. Il documento contiene la rappre- sentazione dei processi e del flusso di dati che tali processi utilizzano e trasforma- no, le interazioni tra il prodotto da realizzare ed il sistema.

• Disegno della Base Dati – Documento o insieme dei documenti nei quali è descrit- to il modello concettuale e logico dei dati.

• Prototipo – Modello che contiene tutte le caratteristiche tecniche (funzionali, presta- zionali, di usabilità, ecc.) di un prodotto.

Progettazione Test e Collaudi. È parte integrante del processo di progettazione, la defi- nizione dei test interni (test unitari, test funzionali, test di prodotto, test di integrazione, test di sistema e test di qualificazione finale) che dovranno essere eseguiti dal Fornitore prima del rilascio al collaudo, per garantire che quanto realizzato sia conforme ai requi- siti indicati nella Specifica dei Requisiti e agli obiettivi fissati nel Piano di qualità. Tutti i test interni dovranno essere descritti nel Piano di test, ovvero in un documento o in un insieme di documenti nel quale, oltre ai casi di test, sono descritti l’ambiente e le risorse necessarie per l’esecuzione dei casi di test e le modalità di gestione delle anomalie, in coerenza con il processo di Risoluzione dei problemi. Il documento in genere non è un deliverable contrattuale; tuttavia, in fase di esecuzione del collaudo della fornitura, la Commissione di collaudo incaricata dall’Amministrazione può prendere visione del Piano dei test e dei relativi risultati (Test Data Report).

Nel corso di tale attività il Fornitore deve specificare le operazioni di verifica che potran- no essere effettuate dall’Amministrazione per eseguire il collaudo della fornitura. Nella descrizione delle prove di collaudo deve essere garantita la rintracciabilità dei requisiti indicati nei documenti contrattuali e nella Specifica dei Requisiti e la coerenza con i requi- siti stessi. Il risultato dell’attività è costituito dalle Specifiche di collaudo, ovvero da un documento o insieme di documenti che potranno essere utilizzati a titolo di guida dalla Commissione di collaudo nominata dall’Amministrazione acquirente per eseguire il col- laudo della fornitura. Il documento definisce le prove di collaudo in coerenza con i requi- siti indicati nei documenti contrattuali e meglio dettagliati nella Specifica dei requisiti; defi- nisce le specifiche dell’ambiente di collaudo, che dovrà riprodurre fedelmente l’ambiente di esercizio, e le figure professionali che saranno dal Fornitore per assistere la Commissione nella esecuzione delle operazioni di collaudo.

Chiusura del processo

La progettazione deve essere sottoposta a Verifica, allo scopo di assicurare la correttezza e la coerenza rispetto ai requisiti in ingresso.

Il processo si conclude di norma con un riesame della progettazione, ovvero con un’ana- lisi formale della capacità di quanto progettato di soddisfare i requisiti, espliciti, impliciti ed obbligatori, indicati nei documenti del contrattuali e/o espressi dall’Amministrazione. La funzione è a carico del Fornitore ed è svolta in collaborazione formalizzata con il Committente, nell’ambito del processo di Riesame congiunto.

Il riesame si completa con la Validazione da parte del Fornitore e l’approvazione forma- le dei prodotti del processo da parte dell’Amministrazione, approvazione che definisce la baseline di progettazione.

Il processo di Progettazione produce alla fine i seguenti risultati:

– conferma/specifica dei requisiti utente;

– Baseline di progettazione, intesa come insieme dei documenti che descrivono la soluzione progettuale e che regolano le modalità di realizzazione, di gestione ope- rativa e di manutenzione della fornitura;

– aggiornamento dei prodotti del processo di Gestione, (Piano di progetto, Piano di qualità, ..).

5.1.4 Processo di Realizzazione e Collaudo

Obiettivi

Obiettivo della Realizzazione è l’implementazione della soluzione progettuale, in termini di infrastruttura tecnologica, codice, basi di dati, documentazione utente, servizi; seguo- no l’esecuzione dei test ed il collaudo di quanto realizzato, secondo le specifiche prodot- te nel processo di Progettazione. I processi e le attività da svolgere sono regolati dai pro- cessi organizzativi e supportati dai processi di supporto.

Attivazione del processo

Il processo è svolto dal Fornitore ed è attivato a chiusura del processo di Progettazione. Sono dati di input del processo la Specifica dei requisiti e l’insieme dei documenti che costi- tuiscono la baseline di progettazione, prodotti nell’ambito del processo di Progettazione.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Realizzazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Realizzazione e collaudo
Attività		Prodotti
RE-A1	Codifica	REA1-O1	Prodotto software
RE-A2	Predisposizione del sistema	REA1-O2	Infrastruttura di collaudo e di esercizio
RE-A3	Produzione della documentazione	REA1-O3	Documentazione utente
RE-A4	Qualificazione finale	REA4-O1	Certificazione di rilascio al collaudo
RE-A5	Installazione	REA5-O1	Piano di installazione
RE-A6	Collaudo	REA6-O1	Verbale di collaudo
		REA6-O2	Fornitura (prodotto software - sistema - documentazione utente) in esercizio nella configurazione di base

Codifica. In accordo con i documenti di output del processo di Progettazione, il Fornitore avvia la realizzazione di quanto richiesto contrattualmente; in particolare, in caso di fornitura di servizi che prevedano lo sviluppo di soluzioni applicative, il Fornitore,

sulla base delle Specifiche funzionali, realizza il prodotto, procedendo alla codifica del software, sviluppando e documentando moduli, componenti e banche dati, ovvero prov- vedendo alla modifica del software nel caso in cui non si tratti di un nuovo sviluppo.

A completamento dei test unitari sui singoli moduli il Fornitore, per ciascun elemento soft- ware definito nel processo di Progettazione, procede alla integrazione delle unità softwa- re e dei componenti, eseguendo quindi i test funzionali per verificare che nell’insieme gli aggregati soddisfino i requisiti dell’elemento software. Segue quindi l’integrazione degli elementi software e l’esecuzione del test di prodotto, volto a verificare che il software rea- lizzato, con relativi dati e documentazione, soddisfi i requisiti specificati nel processo di Progettazione. È parte integrante dell’attività la produzione di procedure operative che regolamentino sia le modalità di gestione operativa che le modalità di manutenzione.

Il risultato dell’attività è il Prodotto software, ovvero l’insieme degli elementi software inte- grati, con relativi dati e documentazione nella configurazione finale risultante dal test di prodotto.

Predisposizione del sistema. In accordo con i documenti che descrivono l’architettura

tecnica e/o le Specifiche di realizzazione del servizio, il Fornitore procede alla predispo- sizione della infrastruttura hardware e software necessaria per realizzare il sistema che ospiterà gli ambienti logici di collaudo e di esercizio, provvedendo ad eseguire l’installa- zione e l’integrazione delle componenti hardware e software.

In accordo con il Piano di Test, il Fornitore esegue i test unitari delle specifiche componenti hardware e software, i test di integrazione, volti soprattutto a verificare gli aspetti di integra- zione inter-intra componenti hardware e software ed i test di sistema, volti a verificare il cor- retto funzionamento del sistema rispetto ai requisiti specificati nel processo di Progettazione. È parte integrante dell’attività la produzione di procedure operative che regolamentino sia le modalità di gestione operativa che le modalità di manutenzione.

Il risultato dell’attività è l’Infrastruttura hardware e software che ospiterà gli ambienti logi- ci di collaudo ed esercizio, intesa come insieme di componenti hardware e software inte- grati, con relativa documentazione, con le procedure e con quanto propedeutico all’in- stallazione ed esercizio del prodotto software sviluppato o all’erogazione del servizio, nella configurazione finale risultante dal test di sistema.

Produzione della documentazione. Parallelamente alla codifica del software e/o alla predisposizione del sistema il Fornitore procede alla produzione della Documentazione utente (manuali utente, tutorial, help, wizard, ...). La documentazione utente deve essere predisposta secondo standard e requisiti fissati nel processo di Progettazione e deve esse- re oggetto di verifiche formalizzate per verificarne la corrispondenza ai requisiti. Le veri- fiche devono inoltre accertare l’accuratezza, la comprensibilità e più in generale l’usabili- tà della documentazione.

Qualificazione finale. Propedeutica al rilascio della fornitura al collaudo presso l’Amministrazione, è l’esecuzione di test di validazione o qualificazione finale di quanto realizzato (prodotto software; infrastruttura di collaudo ed esercizio; documentazione utente), come ultima valutazione dello stato di consolidamento della fornitura e della sua capacità di superare il collaudo finale. I risultati di tale test, insieme a quelli di tutti i test, verifiche, validazioni e riesami effettuati precedentemente, anche relativamente ai prodot- ti output del processo di Progettazione, concorrono alla formulazione, da parte del Fornitore, di una Certificazione di rilascio al collaudo della fornitura.

Installazione. L’attività riguarda l’installazione del prodotto software sviluppato nell’am- biente di esercizio e/o l’esecuzione di compiti, non svolti nell’ambito dell’attività di Predisposizione del sistema, volti a rendere operativo il sistema o l’ambiente di erogazio- ne del servizio. Detti compiti possono riguardare, senza la pretesa di essere esaustivi: l’at- tivazione di profili utente per la sicurezza; l’attivazione di postazioni di lavoro; la confi- gurazione di prodotti software; il caricamento iniziale di dati nelle delle basi dati, a parti- re da sistemi preesistenti (legacy systems) per il tramite di attività di migrazione, o diret- tamente da dati cartacei tramite attività di acquisizione dati (data entry).

L’attività è svolta secondo un Piano di installazione, correlato al Piano di progetto, nel quale sono indicati attività, tempi, modi e risorse necessarie.

Il risultato dell’attività è il sistema che ospita l’ambiente di erogazione del servizio, con il prodotto software sviluppato e le relative basi dati installate e correttamente funzionanti, secondo i requisiti contrattuali e progettuali, ovvero con tutto quanto necessario a garan- tire l’erogabilità dei servizi oggetto di fornitura, nel rispetto dei requisiti contrattuali e di progettazione.

Collaudo. L’attività è eseguita da una Commissione di collaudo nominata dall’Ammini-

strazione ed individuata, nella sua composizione, sulla base delle capacità professionali e di giudizio richieste. La Commissione opera con autonoma responsabilità e secondo le prescrizioni della normativa di riferimento ed ha il compito di verificare che quanto rea- lizzato dal Fornitore sia conforme ai requisiti indicati nella baseline di contratto. Possono essere oggetto di collaudo, secondo quanto richiesto nel contratto, il prodotto software realizzato, il sistema che ospita l’ambiente di esercizio, il modello di funzionamento del servizio oggetto di fornitura e tutta la documentazione utente. Le prove di collaudo sono di regola eseguite nell’ambiente di collaudo predisposto dal Fornitore secondo quanto specificato nel processo di Progettazione.

Il Fornitore deve supportare la Commissione nella esecuzione delle prove, nel rilevamen- to dei risultati, nella stesura del rapporto finale. Per svolgere le prove di collaudo la Commissione può utilizzare, a titolo di guida, le Specifiche di collaudo predisposte dal Fornitore nell’ambito del processo di Progettazione, e può prendere visione dei risultati dei test interni eseguiti dal Fornitore nel corso del processo di Realizzazione e di ogni registrazione concernente le attività di Riesame, Verifica e Validazione svolta. Il Piano di collaudo, la documentazione di esecuzione delle prove e delle non-conformità rilevate dovranno essere formalizzati in documenti.

La verifica con esito positivo della fornitura termina con l’emissione di un Verbale di col- laudo positivo, che sancisce la conformità ai requisiti contrattuali del prodotto software e/o l’erogabilità del servizio oggetto di fornitura. L’accettazione da parte dell’Ammi- nistrazione dell’esito positivo del collaudo, dà luogo all’accettazione della fornitura. In caso di esito negativo del collaudo e/o di non-conformità rispetto ai requisiti contrattua- li, il Fornitore, in accordo con il processo di Risoluzione dei problemi, è tenuto a rimuo- vere i malfunzionamenti e a presentare nuovamente la fornitura al collaudo, nei tempi e nei modi stabiliti nel contratto. La conclusione del collaudo con esito positivo e l’accet- tazione da parte dell’Amministrazione della fornitura, comportano il congelamento della

configurazione di base del prodotto software e/o del sistema che ospita l’ambiente di erogazione del servizio.

Avviamento alla gestione operativa. Successivamente all’accettazione della fornitura

può essere prevista una attività di avviamento che consiste nell’esercizio del prodotto software nella configurazione di base presso utenze pilota. Tale attività ha l’obiettivo di verificare l’affidabilità, le prestazioni, l’usabilità, la sicurezza del prodotto e la sua manu- tenibilità.

A conclusione del periodo di avviamento viene fornito un “Rapporto su qualità e presta- zioni del prodotto software” in cui sono riportati gli indicatori rilevati ed il relativo anda- mento rispetto ai valori di soglia e/o target di riferimento prefissati. Il periodo di garanzia ha di norma durata di 12 mesi.

Chiusura del processo

La Realizzazione si conclude con il completamento con esito positivo del collaudo. Il pro- cesso produce, in sintesi, i seguenti risultati:

rilascio del prodotto software e/o del sistema che realizza l’ambiente di erogazione del servizio, corredati della relativa documentazione utente; detti elementi sono individuati e documentati, nelle loro componenti, nella configurazione risultante dal collaudo, che rap- presenta la configurazione di base per le successive attività previste nell’ambito dei pro- cessi di Gestione operativa e Manutenzione;

rilascio della documentazione utente, nella configurazione risultante dal collaudo; aggiornamento della baseline di progettazione e dei prodotti del processo di Gestione.

5.1.5 Processo di Gestione operativa

Obiettivi

Obiettivo del processo è l’erogazione dei servizi, unita alla conduzione funzionale e tec- nica del sistema. Le attività da svolgere sono regolati dai processi organizzativi e suppor- tati dai processi di supporto.

Attivazione del processo

Il processo è attivato al termine del processo di Realizzazione, con la messa in eser- cizio del prodotto software e/o del sistema che ospita l’ambiente di erogazione del servizio, corredati della documentazione utente e della documentazione necessaria per la gestione. In particolare sono input del processo, oltre ai prodotti delle attività di Realizzazione, la Specifica dei requisiti, le Specifiche del servizio, le Specifiche di realizzazione del Servizio e le Specifiche di controllo qualità del servizio, prodotte nel processo di Progettazione, come eventualmente modificate dal processo di Realizzazione, nonché le procedure operative prodotte nell’ambito del processo di Realizzazione.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Gestione operativa e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Gestione operativa
Attività		Prodotti
GO-A1	Prove delle forniture rilasciate in esercizio	GOA1-O1	Fornitura (prodotto software – sistema – documentazione utente) nella nuova configurazione
GO-A2	Gestione operativa	GOA2-O1	Registrazioni relative alla conduzione tecnico-funzionale del sistema
GO-A3	Assistenza agli utenti	GOA3-O1	Registrazioni relative all’assistenza fornita
GO-A3	Assistenza agli utenti	GOA3-O2	Registrazione dei problemi e delle richieste di modifica provenienti dall’utente

Prove delle forniture rilasciate in esercizio. Per ogni nuova versione dei componen- ti del prodotto software e/o del sistema rilasciata in esercizio, il Fornitore deve svolgere appropriati test che verifichino la capacità del componente (nella versione in prova) di soddisfare i requisiti specificati per la sua gestione operativa. L’esecuzione di tali test deve essere propedeutica alla accettazione in gestione operativa del componente. In particola- re, i test devono accertare che il componente si attivi, esegua correttamente le sue fun- zioni, termini le sue attività così come descritto nei manuali di gestione operativa e nei piani relativi e che non determini malfunzionamenti nelle altre componenti del sistema (test di non regressione). Il risultato dell’attività è il prodotto software e/o il sistema nella nuova configurazione (configurazione corrente).

Gestione Operativa. In accordo con le Specifiche di realizzazione del servizio e le

Specifiche di controllo qualità del servizio, il Fornitore eroga il servizio oggetto di forni- tura contrattuale.

Oltre ai compiti che sono specifici della tipologia di servizio da erogare, indicati nei docu- menti sopra citati, il Fornitore nell’ambito di tale attività svolge in via continuativa un insieme di compiti che sono finalizzati a garantire che il sistema operi in accordo con quanto contenuto nelle Specifiche del servizio e nella documentazione utente e che ren- dono possibile la corretta fruizione del servizio da parte dell’utente finale. Detti compiti possono includere, ad esempio:

• inizializzazione e disattivazione di componenti del sistema;

• presidio degli strumenti di controllo e degli ambienti di controllo;

• gestione delle procedure operative;

• gestione degli accessi e delle convenzioni;

• interventi sui malfunzionamenti hardware e software per il ripristino delle funzio- nalità;

• controllo della operatività del sistema e gestione delle procedure di restart e reco- very;

• gestione dei supporti utilizzati nella gestione dei dati e delle stampe;

• controllo remoto dei sistemi non presidiati, installati presso utenze periferiche;

• schedulazione ed esecuzione delle attività e produzione rapporti di riepilogo.

L’attività di Gestione operativa deve essere svolta in accordo con il Piano di progetto, il Piano di qualità ed eventuali documenti correlati ed in accordo con le procedure e la documentazione predisposta allo scopo nell’ambito del processo di Realizzazione.

Nello svolgimento di questa attività, devono essere identificate, registrate e risolte, le ano- malie riscontrate, in accordo con il processo di Risoluzione dei problemi.

È parte integrante dell’attività la predisposizione ed attivazione del sistema per controlla- re in via continuativa che le Specifiche del servizio siano soddisfatte e per rilevare e misu- rare la qualità del servizio erogato. Le registrazioni delle misure effettuate devono permet- tere di valutare l’andamento del servizio e le azioni correttive/preventive da intraprende- re per assicurare il rispetto dei requisiti di qualità contrattuali.

Il risultato dell’insieme dei compiti che il Fornitore svolge nella Gestione operativa è costi- tuito dalle Registrazioni delle attività svolte per garantire il corretto funzionamento del sistema e l’erogazione del servizio all’utente finale in accordo con le Specifiche del servi- zio e la documentazione utente.

Assistenza agli utenti. Il Fornitore, su richiesta, deve fornire assistenza e consulenza agli utenti nell’utilizzo del sistema. Le richieste di assistenza, che devono essere registrate e tracciate fino alla loro conclusione, possono dare luogo a modifiche al sistema. Tali modi- fiche, che possono consistere in correzioni permanenti, nuove versioni che includano fun- zionalità o funzioni precedentemente omesse o miglioramenti del sistema, devono essere gestite in accordo con il processo di Manutenzione.

Chiusura del processo

Il processo di Gestione operativa è attuato in via continuativa fino alla conclusione del ciclo di vita della fornitura, che può coincidere con la dismissione del prodotto software o del sistema da parte dell’Amministrazione o con la scadenza del contratto, nel caso in cui sia previsto dall’Amministrazione il subentro di un nuovo Fornitore.

Il processo produce, in sintesi, i seguenti risultati:

• corretto funzionamento del sistema ed erogazione del servizio agli utenti nel rispet- to delle Specifiche del servizio e della documentazione utente;

• aggiornamento alla configurazione di base del prodotto software e/o del sistema e conseguenti modifiche alla documentazione utente

5.1.6 Processo di Manutenzione

Obiettivi

Obiettivo del processo è sottoporre a modifica il prodotto software e/o il sistema preser- vandone l’integrità. Il processo include le attività di migrazione e dismissione.

Le modifiche devono essere attuate e gestite in accordo con il processo di Gestione delle Configurazione.

Attivazione del processo

Il processo è attivato quando è necessario apportare modifiche al prodotto software, al sistema ed alla relativa documentazione. L’esigenza di modifica può nascere nell’ambito del processo di Gestione operativa ed in particolare da segnalazione dell’utente o da parte dello stesso Fornitore o può derivare da richieste dell’Amministrazione. Sono input del

processo i prodotti del Processo di Progettazione e di Realizzazione. Il processo deve essere attuato secondo piani e procedure documentate.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Manutenzione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Manutenzione
Attività		Prodotti
MA-A1	Analisi dei problemi e delle modifiche	MAA1-O1	Piano delle modifiche
MA-A2	Esecuzione delle modifiche	MAA2-O1	Fornitura (prodotto software – sistema – documentazione utente) nella nuova configurazione
MA-A2	Esecuzione delle modifiche	MAA2-O2	Registrazioni relative alle modifiche ed alle prove
MA-A3	Riesame/accettazione delle modifiche	MAA3-O1	Fornitura (prodotto software – sistema – documentazione utente) in esercizio nella nuova configurazione (configurazione corrente)
MA-A4	Migrazione	MAA4-O1	Piano di migrazione
MA-A5	Dismissione	MAA5-O1	Piano di dismissione

Analisi dei problemi e delle modifiche. Il Fornitore deve analizzare le Registrazione dei problemi e delle richieste di modifica provenienti dall’utente, nonché ogni altra richiesta o esigenza di modifica al prodotto software e/o al sistema, in base ai seguenti elementi:

• Tipologia: correttiva, migliorativa, preventiva, adattativa ad un nuovo ambiente;

• Campo di applicazione: ampiezza della modifica, elementi del sistema da modifica- re, tempi richiesti, costi previsti;

• Criticità: impatto sul funzionamento del sistema, sulle prestazioni e sulla sicurezza.

Le modifiche di tipo correttivo sono innescate da impedimenti all’esecuzione di funzioni o da differenze riscontrate fra l’effettivo funzionamento del prodotto software e quello atteso, previsto nella relativa documentazione o comunque determinato dalla prassi dell’utente. Tali modifiche, a differenza delle altre tipologie sopra indicate, seguono una modalità di esecu- zione di tipo continuativo ed, in linea di massima, non sono pianificabili, essendo orienta- te alla rimozione dei difetti causati dal prodotto software o dal sistema stesso.

Il risultato dell’attività è il Piano delle modifiche, ovvero un documento o un insieme di documenti nel quale sono indicati le tipologie di modifiche, i risultati dell’analisi per quan- to riguarda il campo di applicazione e la criticità di ciascuna modifica, nel senso sopra indicato, le opzioni di soluzione.

Fatta eccezione per le modifiche di tipo correttivo che non sono pianificabili, il Fornitore deve ottenere dall’Amministrazione l’approvazione del Piano delle modifiche prima di dare luogo alla esecuzione delle modifiche individuate.

Esecuzione delle modifiche. Sulla base del Piano delle modifiche, il Fornitore realizza le modifiche seguendo il processo di Progettazione ed il processo di Realizzazione ed in particolare assicurando che:

• siano definiti, eseguiti e documentati i test (unitari, funzionali, di prodotto, di siste- ma, di non regressione) delle parti modificate e non modificate (unità software, componenti ed elementi di configurazione) del sistema. L’esecuzione dei test deve essere effettuata nell’ambiente di collaudo ed i risultati devono essere documentati.

• sia assicurata la completa e corretta realizzazione dei requisiti nuovi o modificati. Deve essere inoltre assicurato il corretto funzionamento del sistema rispetto ai requisiti originali non modificati.

Il risultato delle attività è costituito dal prodotto software e/o dal sistema, con relativa documentazione, nella nuova configurazione, verificata nell’ambiente di collaudo rispetto ai requisiti nuovi e ai requisiti non modificati.

Riesame/Accettazione delle modifiche. L’attività è volta a verificare l’integrità del siste-

ma modificato, attraverso riesami condotti con l’Amministrazione o con l’organizzazione che autorizza le modifiche sulla base di tutte le registrazioni relative alle modifiche effet- tuate ed ai risultati delle prove eseguite (Test Data Report).

L’approvazione delle modifiche da parte dell’Amministrazione, secondo modalità stabilite nel contratto, comporta l’accettazione da parte dell’Amministrazione del prodotto softwa- re e/o del sistema, con la relativa documentazione, nella nuova configurazione (configu- razione corrente), che diviene operativa nell’ambiente di esercizio e in relazione alla quale vengono svolte le attività proprie dei processi di Gestione operativa e di Manutenzione. Migrazione. L’attività è svolta nel caso in cui debba essere effettuata la migrazione del prodotto software e/o del sistema che realizza l’ambiente di erogazione del servizio in un nuovo ambiente operativo o nel caso in cui debba subentrare un nuovo soggetto nella erogazione del servizio oggetto di fornitura contrattuale. In tal caso il Fornitore deve pia- nificare ed eseguire tutte le attività necessarie a garantire il corretto funzionamento del prodotto software e/o del sistema o a garantire la corretta erogazione del servizio in un nuovo ambiente.

Il Fornitore deve predisporre un Piano di migrazione, che indichi:

• requisiti della migrazione;

• attività di migrazione;

• mezzi, modalità e tempi per eseguire la migrazione;

• modalità di verifica del prodotto software, del servizio e/o del sistema nel nuovo ambiente operativo.

Nel caso in cui alla scadenza del contratto sia prevista l’erogazione del servizio da parte di un nuovo soggetto, il Piano di migrazione deve contenere tutte le informazioni neces- sarie per consentire il subentro, con particolare riferimento a:

• procedure, documentazione e quanto necessario per la gestione operativa e la manutenzione del sistema;

• modalità di erogazione della formazione e dell’affiancamento al soggetto subentrante.

Il Fornitore deve svolgere in parallelo le attività del processo di gestione operativa nel- l’ambiente di origine, fino al completamento della migrazione ed alla verifica del corretto funzionamento di quanto realizzato.

Il completamento delle attività di migrazione deve essere notificato a tutti gli interessati. Tutta la documentazione, il codice e i dati associati al prodotto software, al sistema o al servizio devo- no essere archiviati, quando necessario, e accessibili in accordo con i requisiti contrattuali.

Dismissione. Quando l’Amministrazione abbia deciso di procedere alla dismissione del

prodotto software e/o del sistema o di sospendere l’erogazione del servizio, il Fornitore deve predisporre ed eseguire un Piano di dismissione delle attività connesse, con parti- colare riferimento alle attività di gestione operativa e di manutenzione. Il documento deve contenere dati di pianificazione con riferimento agli elementi di seguito elencati:

• cessazione totale o parziale del servizio e dell’assistenza dopo un determinato perio- do di tempo;

• archiviazione del prodotto software e della relativa documentazione associata;

• responsabilità per ogni eventuale necessità di assistenza da fornire in futuro;

• transizione al nuovo prodotto software e/o al nuovo sistema, qualora applicabile;

• accessibilità alle copie degli archivi dei dati e della documentazione

Il Piano di dismissione, con l’indicazione delle attività previste, deve essere notificato agli utenti interessati. Le notifiche devono comprendere:

• descrizione delle attività di sostituzione o di aggiornamento, con relative date di dis- ponibilità;

• descrizione delle altre opzioni di assistenza disponibili una volta che il supporto sia stato rimosso.

In caso di avvio di un nuovo prodotto software e/o di un nuovo sistema in sostituzione del precedente, dovrebbero essere condotte attività di parallelo tra dismissione del vec- chio ambiente ed avvio del nuovo.

Il completamento delle attività di dismissione deve essere notificato a tutti gli interessati. Tutta la documentazione, il codice e i dati utilizzati dal prodotto software e/o dal sistema o ad essi associati devono essere archiviati, quando necessario, e accessibili in accordo con i requisiti contrattuali.

Chiusura del processo

Il processo di Manutenzione è attuato in via continuativa fino alla conclusione del ciclo di vita della fornitura, che può coincidere con la dismissione del prodotto software o del sistema da parte dell’Amministrazione o con la migrazione in un nuovo ambiente opera- tivo alla scadenza del contratto, nel caso in cui sia previsto dall’Amministrazione il sub- entro di un nuovo Fornitore. Il processo produce, in sintesi, i seguenti risultati:

• corretto funzionamento del prodotto software e/o del sistema, attraverso attività che assicurano in via continuativa la rimozione dei malfunzionamenti, il miglioramento delle funzionalità e delle prestazioni, l’adeguamento costante all’ambiente tecnologico;

• definizione delle modalità di migrazione e dismissione del prodotto software e/o del sistema o di cessazione del servizio.

5.2 Processi Trasversali

I processi trasversali, ad uso interno all’organizzazione impegnata nella fornitura, sono uti- lizzati e svolti come parte integrante di altri processi e contribuiscono ad assicurare il suc- cesso e la qualità del progetto nel suo complesso, includono la Gestione, la Gestione della documentazione, la Gestione della configurazione, l’Assicurazione Qualità.

5.2.1 Processo di Gestione

Obiettivi

Obiettivo del processo è consentire al Fornitore la conduzione coordinata del progetto che deve essere sviluppato in esecuzione del contratto, con l’obiettivo ultimo di comple- tare con successo il progetto, nel rispetto dei requisiti di tempi, costi e qualità indicati nei documenti contrattuali.

Xxxxxxxx nell’ambito di questo processo tutte le attività preliminari all’avvio del processo di Progettazione, come la pianificazione delle attività, l’acquisizione delle risorse, la defi- nizione dell’organizzazione del progetto e l’avvio delle attività, nonché tutte le attività di coordinamento delle risorse assegnate al progetto in corso d’opera; il processo include inoltre le attività di controllo dell’andamento del progetto, la produzione di stati di avan- zamento di tutte le attività necessarie al conseguimento degli obiettivi contrattuali, inclu- sa la fornitura alle parti interessate delle informazioni sulle evoluzioni e sugli avanzamen- ti del progetto e della opportuna documentazione e le attività condotte per identificare, valutare e gestire i rischi del progetto.

Xxxxxxxx altresì nell’ambito di questo processo la definizione e manutenzione dell’infra- struttura necessaria allo svolgimento degli altri processi, questa ultima attuata in via con- tinuativa fino alla conclusione di tutti i processi del ciclo di vita della fornitura che lo uti- lizzano. L’infrastruttura può includere hardware, software, strumenti, tecniche, norme e apparecchiature per i processi di Progettazione, Realizzazione, Gestione Operativa e Manutenzione, nonché per i processi di Gestione della Documentazione e Gestione delle Configurazioni.

Il processo ha anche l’obiettivo di misurare e migliorare i processi attuati dal Fornitore nell’ambito del ciclo di vita della fornitura fino alla conclusione di tutti i processi svolti dal Fornitore per eseguire la fornitura oggetto del contratto. Anche rendendo disponibi- le, in via continuativa, personale adeguatamente addestrato e formato all’avvio di ciascu- na attività pianificata per l’esecuzione del contratto..

Attivazione del processo

Il processo è svolto dal Fornitore ed è attivato a valle della sottoscrizione del contratto. Sono dati di input del processo l’insieme dei documenti che costituiscono la baseline di contratto, prodotti nell’ambito dei processi di Acquisizione e di Fornitura, ovvero il Contratto, il Capitolato tecnico, l’Offerta tecnico-economica del Fornitore.

A questi si aggiungono l’insieme dei documenti prodotti nel processo di Progettazione per quanto concerne la definizione dell’infrastruttura e le Registrazioni prodotte nel corso della esecuzione delle attività, rilevanti ai fini delle misure da effettuare per ciascun pro- cesso, per quanto concerne il miglioramento dei processi produttivi.

Di norma le principali milestone che regolano la pianificazione delle attività ed il rilascio all’Amministrazione di prodotti intermedi e/o finali sono fissati nel contratto. Ulteriori momenti e/o elementi di verifica possono essere concordati tra Fornitore ed Amministrazione nel corso della esecuzione del contratto.

Le attività di “pianificazione” vera e propria di tempi, costi, qualità, gestione rischi e gestione delle comunicazioni, sono propedeutiche a tutti i processi del ciclo di vita e sono volte a programmare tutte le attività da svolgere nel corso della esecuzione del contratto, in modo da rispettare i vincoli ed i requisiti previsti nel contratto stesso. I documenti di pianificazione ed in particolare la baseline dei tempi e dei costi e della qualità, costruita in questa fase iniziale, costituisce il programma di riferimento con il quale confrontare i successivi aggiornamenti nelle fasi realizzative ed esercitare le funzioni di controllo fino alla conclusione del progetto.

Attività e prodotti

Processo di Gestione
Attività		Prodotti
GE-A1	Pianificazione del progetto	GEA1-O1	Piano di progetto
GE-A2	Analisi dei rischi	GEA2-O1	Piano di gestione dei rischi
GE-A3	Pianificazione della comunicazione	GEA3-O1	Piano di gestione delle comunicazioni
GE-A4	Pianificazione della qualità	GEA4-O1	Piano di qualità
GE-A5	Esecuzione del progetto	GEA5-O1	Registrazioni
GE-A5	Esecuzione del progetto	GEA5-O2	Richieste di cambiamenti
GE-A6	Controllo del progetto	GEA6-O1	Stato Avanzamento Lavori (SAL)
GE-A7	Revisione, Riesame e valutazione	GEA7-O1	Registrazioni
GE-A7	Revisione, Riesame e valutazione	GEA7-O2	Richieste di cambiamenti
GE-A8	Definizione dell’infrastruttura	GEA8-O1	Specifiche dell’infrastruttura
GE-A9	Manutenzione dell’infrastruttura	GEA9-O1	Registrazioni
GE-A10	Definizione dei processi	GEA10-O1	Disegno dei processi
GE-A11	Valutazione dei processi	GEA11-O1	Registrazioni
GE-A12	Miglioramento dei processi	GEA12-O1	Piano di miglioramento dei processi
GE-A13	Definizione delle esigenze	GEA13-O1	Piano di formazione
GE-A14	Sviluppo del materiale di formazione	GEA14-O1	Materiali didattici e strumentazione
GE-A15	Esecuzione della formazione	GEA15-O1	Registrazioni
GE-A16	Conclusione del progetto	GEA16-A1	Archivio del progetto

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Gestione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Pianificazione del progetto. Il punto di partenza per la pianificazione del progetto da realizzare in esecuzione del contratto, è la definizione degli obiettivi del progetto (ambi- to del progetto), ovvero dei criteri qualitativi e quantitativi che devono essere soddisfatti perché il progetto possa considerarsi completato con successo; segue, quindi, l’individua- zione di tutte le entità organizzative (individui o organizzazioni) che sono attivamente coinvolte nel progetto, o i cui interessi possono essere influenzati, in modo positivo o negativo, dall’esito del progetto.

In genere le entità organizzative interessate alla fornitura oggetto di un contratto includo- no le seguenti:

• Responsabile di contratto – la persona, rispettivamente lato Fornitore e lato Amministrazione, che è responsabile di tutto quanto attiene alla esecuzione del con- tratto;

• Responsabile di progetto – la persona, rispettivamente lato Fornitore e lato Amministrazione, che è responsabile di gestire il progetto. Le figure del Responsabile di contratto e del Responsabile di progetto in molti casi possono coincidere; in altri si differenziano per i profili professionali richiesti, che nel caso del Responsabile di contratto risultano più orientati alle competenze giuridico-amministrative.

• Centro di costo – la persona o l’organizzazione che beneficerà dei risultati del pro- getto;

• Centro di responsabilità – la persona o l’organizzazione, rispettivamente lato Fornitore e lato Amministrazione, che è coinvolta a vario titolo nella realizzazione il progetto;

• Centro di spesa – l’organizzazione che provvede ad impegnare i fondi per il progetto.

Segue quindi la pianificazione operativa vera e propria che, a partire dai deliverable con- trattuali, ovvero dalle attività e dai prodotti propri dei processi primari, ed attraverso una scomposizione secondo un livello di dettaglio via via crescente, porta a definire una dis- aggregazione gerarchica del lavoro da svolgere ed all’individuazione delle unità elemen- tari di lavoro, alle quali è possibile assegnare tempi di esecuzione, risorse e costi. Tale attività consente di definire la baseline di riferimento per misurare le prestazioni di tempi e costi nel corso della esecuzione del progetto.

Il risultato dei compiti sopra descritti è contenuto nel Piano di progetto, ovvero un docu- mento (o un insieme di documenti) formale, approvato, utilizzato per gestire e controlla- re l’esecuzione del progetto. Il Piano di progetto è un documento dinamico, che può variare man mano che si consolidano le informazioni sul progetto, a differenza della base- line dei tempi e dei costi che invece è uno strumento di controllo, che può variare di rego- la solo a fronte di cambiamenti approvati degli obiettivi di progetto.

Il Piano di progetto può essere organizzato e presentato in diversi modi; in genere inclu- de almeno, direttamente o attraverso il riferimento ad altri documenti, le seguenti infor- mazioni:

• informazioni di sintesi sulle caratteristiche del progetto (requisiti e/o obiettivi strategi- ci che il progetto si prefigge di soddisfare; descrizione del prodotto e/o del servizio che il progetto dovrà realizzare per soddisfare i requisiti del contratto; durata com-

plessiva (inizio-fine); eventuali vincoli e supposizioni; eventuali risorse che devono essere rese disponibili dalle Amministrazioni; Responsabile di progetto assegnato);

• gli obiettivi del progetto e le entità organizzative coinvolte;

• l’organizzazione di progetto, le risorse assegnate ed i relativi ruoli e profili profes- sionali;

• le interfacce organizzative e tecniche;

• la Work Breakdown Structure (WBS) riferita alle attività ed ai prodotti propri dei processi primari, ovvero la scomposizione dei deliverables contrattuali al fine di definire le unità di lavoro al livello di dettaglio in base al quale sarà necessario eser- citare il controllo in fase di esecuzione del progetto;

• la stima dei costi, la programmazione temporale delle attività e le assegnazioni di responsabilità per ciascuna unità di lavoro della WBS;

• la baseline di riferimento per misurare le prestazioni di tempi e costi;

• la definizione della periodicità con cui verrà rilevato lo stato di avanzamento lavo- ri (SAL), le metriche da utilizzare per misurare l’avanzamento, le date programmate di svolgimento di Riesami e Verifiche;

• le principali milestone, vale a dire i momenti a cui corrispondono fatti rilevanti dal punto di vista gestionale e che sostituiscono dei punti di controllo essenziali per la verifica del corretto avanzamento dei lavori;

• i problemi aperti e/o le decisioni pendenti;

• le modalità per la gestione dei cambiamenti.

Analisi dei rischi. Include le attività condotte per identificare, valutare e gestire i rischi del progetto. Non è un’attività da attuarsi una tantum, ma dovrebbe essere eseguita in modo sistematico durante tutto il ciclo di vita della fornitura.

L’identificazione dei rischi ha come scopo principale quello di identificare e classificare le principali sorgenti di rischio del progetto in esame. Le sorgenti di rischio più comuni sono:

• cambiamenti di requisiti e/o requisiti ambigui;

• errori, omissioni o incorretta applicazione dei requisiti in fase di progettazione;

• sottostima di tempi, costi e risorse;

• non chiara definizione di ruoli e responsabilità;

• non adeguata competenza del personale;

• dipendenze esterne.

Una volta individuate e classificate le sorgenti di rischio, si determina:

• la probabilità (alta; media; bassa) che si verifichino fattori di rischio da ciascuna classe;

• la frequenza con cui potrebbero verificarsi;

• la fase del progetto nella quale potrebbero accadere;

• l’impatto sul progetto (alto; medio; basso), valutato prendendo in esame la perdita (economica; di immagine o altro) che si avrebbe se l’evento si verificasse;

• le entità organizzative coinvolte.

Dalla combinazione di uno o più degli elementi precedentemente evidenziati, si determi- na l’approccio da seguire per la gestione. In particolare, la valutazione porta il Responsabile di progetto a decidere quali rischi debbano essere:

• mitigati (attraverso azioni preventive/correttive volte a limitare la probabilità che si verifichino e l’impatto sul progetto);

• accettati (accettare le conseguenze);

• evitati (attraverso azioni volte ad eliminare le cause).

Il risultato dell’attività è il Piano di gestione dei rischi o un documento equivalente che, oltre a documentare i risultati delle fasi di identificazione e valutazione, nel senso sopra indicato, descrive le azioni e le procedure per gestire i rischi e le responsabilità di gestio- ne delle varie aree di rischio.

Pianificazione delle comunicazioni. È l’attività con la quale si determinano le esigen-

ze di informazione e di comunicazione di tutte le entità organizzative coinvolte nel pro- getto e/o destinatarie dei risultati del progetto.

Il prodotto dell’attività è il Piano di gestione delle comunicazioni, o un documento equi- valente, che includa almeno:

• un metodo di raccolta ed archiviazione delle varie tipologie di informazione;

• un sistema di distribuzione, che dettagli a chi andranno le informazioni ed in che modo (rapporti scritti, incontri, ecc.):

• una descrizione delle informazioni da distribuire (tipologia, formato, contenuto, livello di dettaglio, convenzioni/definizioni da assumere);

• una programmazione temporale, che assicuri la tempestività nella generazione e dis- tribuzione delle informazioni;

• un metodo per aggiornare e revisionare il Piano di gestione delle comunicazioni in funzione delle evoluzioni del progetto.

Il livello di dettaglio del documento è dettato dalle esigenze di condivisione di informa- zioni e comunicazioni determinate dal progetto.

Pianificazione della qualità. È l’attività con la quale, a partire dai requisiti specificati nei

documenti contrattuali, si dettagliano e si documentano tutti i requisiti di qualità espressi, impliciti ed obbligatori e si definisce come tali requisiti saranno soddisfatti e controllati.

Il prodotto dell’attività è il Piano di qualità, o un documento equivalente, che deve indi- rizzare il controllo di qualità, l’assicurazione di qualità ed il miglioramento di qualità per tutte le fasi del ciclo di vita della fornitura. Descrive almeno gli obiettivi di qualità, i con- trolli e le verifiche, i criteri di entrata/uscita delle varie fasi progettuali, i criteri di accetta- zione dei prodotti delle fasi.

Esecuzione del progetto. L’attività consiste nella esecuzione di quanto pianificato nel

Piano di progetto, nel Piano di gestione dei rischi, nel Piano di gestione delle comunica- zioni e nel Piano di qualità.

In particolare in tale fase si dà luogo alla esecuzione delle attività proprie dei processi pri- mari, secondo il programma temporale definito nel Piano di progetto, alla gestione dei rischi, secondo il Piano di gestione dei rischi, alla distribuzione delle informazioni secon- do il Piano di gestione delle comunicazione.

Nel corso di tale attività, sulla base dei risultati dell’attività di Controllo del progetto di seguito descritta, il Fornitore deve rilevare, analizzare e risolvere criticità e problemi emer- si. La risoluzione di tali problemi può comportare modifiche ai piani.

I prodotti dell’attività, oltre ai prodotti propri di ciascuna attività afferente ai processi pri- mari che vengono svolti in tale ambito, sono:

• le Registrazioni delle attività svolte;

• eventuali richieste di cambiamenti (estendere l’ambito del progetto; modificare la stima dei costi, ecc.), che danno quindi luogo ad una modifica ai piani.

Controllo del progetto Il controllo viene esercitato costantemente durante l’esecuzione del progetto. L’obiettivo è rilevare e gestire i cambiamenti rispetto ai piani, al fine di assicura- re il completamento del progetto nel rispetto dei tempi, dei costi e della qualità richiesta. I compiti principali sono costituiti dal controllo complessivo dei cambiamenti e dalle regi- strazione delle prestazioni di progetto.

Il controllo complessivo dei cambiamenti consiste essenzialmente nel coordinare e gesti- re i cambiamenti attraverso tutto il progetto.

I cambiamenti si rilevano attraverso:

• il controllo dei tempi: rilevazione dei cambiamenti alla schedulazioni rispetto alla baseline dei tempi;

• il controllo dei costi: rilevazione dei cambiamenti al budget del progetto rispetto alla baseline dei costi;

• il controllo della qualità: verifica che i risultati delle varie fasi rispettino i requisiti di qualità;

• il controllo dei rischi: verifica dell’efficacia delle azioni previste per mitigare/evitare i rischi e gestione dei cambiamenti nei rischi individuati.

La registrazione delle prestazioni di progetto ha lo scopo di raccogliere in modo sistema- tico i risultati sull’andamento del progetto, in modo da fornire alle entità organizzative interessate le informazioni sull’avanzamento delle attività in termini di quantità messe in opera (attività completate e/o deliverableprodotti) e risorse spese.

Il risultato finale dell’attività di Controllo del progetto è uno Stato Avanzamento Lavori (SAL), ovvero un documento, o un insieme di documenti, prodotti periodicamente, secon- do la periodicità e le modalità indicate nel Piano di progetto ed approvate dall’Amministrazione, che contenga almeno le seguenti informazioni:

• registrazioni sullo stato delle attività alla data;

• registrazioni sull’avanzamento alla data;

• previsioni e stime a finire

• risultati delle attività svolte in esecuzione del Piano di progetto (quali deliverable sono stati parzialmente o completamente realizzati, in che tempi e con quali costi rispetto alle previsioni indicate nelle rispettive baseline).

Revisione, riesame e valutazione. Periodicamente, secondo la periodicità e le modali- tà indicate nel Piano di progetto e nel Piano di qualità e comunque quando opportuno,

vanno effettuate delle Revisioni a vari livelli (nell’ambito del team di progetto; con le enti- tà organizzative interessate), aventi ad oggetto elementi quali:

• esame delle attività correnti e del loro stato;

• verifica dello stato di avanzamento delle attività e degli eventuali scostamenti dai piani;

• esame delle criticità ed identificazione delle relative azioni correttive;

• analisi dei rischi in essere e delle azioni collegate.

Il Fornitore deve assicurare che i piani e le attività svolte nell’ambito del processo di gestione siano adeguati rispetto ai requisiti contrattuali.

I prodotti dell’attività, sono:

• le Registrazioni;

• eventuali richieste di cambiamenti, che danno quindi luogo ad una modifica ai piani.

Definizione dell’infrastruttura. All’avvio del processo di Progettazione, il Fornitore deve pianificare e definire l’infrastruttura necessaria per svolgere tutte le attività previste nell’ambito dei processi del ciclo di vita della fornitura. In particolare, sulla base dei requi- siti contrattuali, della Specifica dei requisiti e considerando le procedure applicabili, le norme, gli strumenti e le tecniche, il Fornitore deve definite le risorse hardware e softwa- re, i mezzi materiali e quanto altro necessario a soddisfare i requisiti del processo che uti- lizza il processo di Infrastruttura e deve pianificare e documentare la relativa configura- zione, in accordo con il processo di Gestione della Configurazione.

Il risultato dell’attività è costituito dalle Specifiche dell’Infrastruttura, ovvero un documen- to o un insieme di documenti nel quale, per ciascun processo che utilizza il processo di Infrastruttura, è definita l’infrastruttura da utilizzare e sono indicate le modalità di realiz- zazione con costi e vincoli temporali, le caratteristiche di funzionalità, prestazioni, sicu- rezza, riservatezza, disponibilità, requisiti di spazio e attrezzature, la configurazione delle risorse hardware, software e della documentazione.

L’installazione della infrastruttura è propedeutica alla esecuzione del processo che la richiede. Manutenzione dell’infrastruttura. Il Fornitore deve assicurare che l’infrastruttura sia gestita, mantenuta e se necessario modificata, al fine di garantire che continui a soddisfa- re i requisiti del processo che la utilizza. Detta attività è svolta nell’ambito dei processi di Gestione operativa e di Manutenzione e dà luogo ai prodotti ivi evidenziati. Le modifiche alla infrastruttura vengono realizzate in linea con il processo di Gestione della Configurazione. Il Fornitore nel corso dell’attività produce le Registrazioni relative alla gestione della infrastruttura e alle modifiche effettuate

Definizione dei processi. Con riferimento ai processi che caratterizzano il ciclo di vita

della fornitura, il Fornitore identifica, organizza e gestisce la propria rete di processi e le relative interfacce. In particolare devono essere individuati e pianificati tutti i processi che hanno diretta influenza sulla qualità della fornitura e che possono avere impatto sulla sod- disfazione dell’utente. Detti processi sono descritti in un documento o in un insieme di documenti, Disegno dei processi, nel quale oltre ad essere indicati attività, input ed out- put dei processi, sono indicate le loro applicazioni a specifici casi ed i meccanismi di con- trollo volti a sviluppare, monitorare, valutare e migliorare i processi stessi.

Valutazione dei processi. È l’attività volta a misurare le prestazioni di ciascun proces- so, in termini qualitativi e quantitativi. Le valutazioni sono condotte periodicamente ad intervalli definiti, secondo piani, sulla base dei dati (dati prestazionali; dati tecnici; dati sui costi della qualità; ecc.) tratti dalle Registrazioni delle attività svolte in esecuzione dei pro- cessi stessi.

I risultati di ciascuna valutazione, documentati nelle relative Registrazioni, costituiscono i dati di input necessari per il miglioramento dei processi.

Miglioramento dei processi. I risultati dell’attività di valutazione vengono analizzati dal

Fornitore per individuare i punti di forza e di debolezza dei processi impiegati. Queste analisi rappresentano l’input per la definizione ed attuazione di un Piano di miglioramen- to dei processi, che individui le azioni correttive e preventive da adottare al fine di risol- vere e prevenire i problemi e le non-conformità nei prodotti oggetto di fornitura, nonché allo scopo di raccomandare modifiche nello sviluppo del progetto (o di progetti succes- sivi) e determinare i necessari avanzamenti tecnologici. Nel corso di tale attività viene aggiornata la documentazione dei processi, per riflettere le modifiche attuate per miglio- rare i processi stessi.

Definizione delle esigenze. Sulla base dei requisiti del progetto, il Fornitore definisce le esigenze di acquisizione di nuove risorse specialistiche e/o di sviluppo delle capacità pro- fessionali esistenti all’interno dell’organizzazione.

In particolare il Fornitore, in relazione alle attività indicate nel Piano di progetto, definisce la tipologia delle risorse necessarie con il livello di formazione richiesto e predispone un Piano di formazione, nel quale sono decritti i requisiti delle risorse, le necessità di formazione, i contenuti degli interventi formativi richiesti, le modalità di erogazione della formazione (corsi in aula, training on the job, ecc.), i materiali didattici e gli strumenti da utilizzare, i tempi di esecuzione. Il Piano deve prevedere inoltre specifiche attività di valutazione del grado di apprendimento degli allievi, ai fini della valutazione dell’efficacia del processo formativo.

Nella pianificazione degli interventi formativi il Fornitore deve assicurare che personale adeguatamente formato sia disponibile in modo tempestivo per le attività pianificate.

Sviluppo del materiale di formazione. È l’attività di predisposizione del materiale

didattico e degli strumenti da utilizzare per eseguire gli interventi formativi, in accordo con quanto stabilito nel Piano di formazione.

Esecuzione della formazione. È l’esecuzione del Piano di formazione, secondo tempi

e modi ivi indicati. L’attività dà luogo alle Registrazioni degli interventi formativi effettua- ti, che consentono di valutare l’efficacia del processo formativo e di pianificare ulteriori interventi, in funzione di nuove esigenze.

Conclusione del progetto. È l’attività conclusiva, che comprende l’esecuzione di tutti gli

adempimenti di fine contratto, la verifica del completamento effettivo di tutte le attività e la verifica finale, avente lo scopo di misurare il successo del progetto rispetto agli obiet- tivi. È parte integrante dell’attività la storicizzazione dei documenti e delle registrazioni prodotte nel corso della esecuzione del processo, che devono essere archiviati secondo modalità specificate nel contratto.

Il risultato dell’attività è l’Archivio di progetto, inteso come l’insieme di tutte le informa- zioni che lo definiscono e lo caratterizzano, in riferimento all’intero ciclo di vita, raccolte, gestite ed utilizzate dalla nascita al completamento, ovvero fino alla conclusione del con- tratto con l’Amministrazione.

Chiusura del processo

Il processo di Xxxxxxxx si conclude quando risultino completate tutte le attività e gli adem- pimenti previsti dal contratto e siano soddisfatti gli obiettivi del progetto.

5.2.2 Processo di Documentazione

Obiettivi

Obiettivo del processo è consentire al Fornitore la gestione sistematica dei documenti pro- dotti nel ciclo di vita della fornitura. Secondo la norma ISO 9001, i meccanismi di gestio- ne della documentazione si applicano sia ai documenti che ai dati. I dati possono essere tabelle, grafici, diagrammi di flusso, banche dati, prospetti, dati informatici e qualunque altra forma di rappresentazione di informazioni relative al ciclo di vita della fornitura.

Il processo si esplica attraverso un insieme di attività volte a pianificare, progettare, pro- durre e distribuire i documenti necessari a tutte le entità organizzative interessate.

Attivazione del processo

Il processo è svolto dal Fornitore in via continuativa, indipendentemente dai processi pri- mari attivati con la sottoscrizione del contratto. La definizione delle modalità di gestione dei documenti connessi al ciclo di vita della fornitura segue la sottoscrizione del contrat- to. Sono dati di input i requisiti indicati nei documenti che costituiscono la baseline di contratto, prodotti nell’ambito dei processi di Acquisizione e di Fornitura, nonché i docu- menti prodotti nell’ambito del processo di Progettazione, nei quali sono specificati rego- le, strumenti, standard e convenzione per la produzione e gestione dei documenti relati- vi alla fornitura.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Documentazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Documentazione
Attività		Prodotti
DO-A1	Pianificazione	DOA1-O1	Piano di gestione della documentazione
DO-A2	Progettazione e sviluppo	DOA2-O1	Documento approvato
DO-A3	Distribuzione e conservazione	DOA3-O1	Registrazioni
DO-A4	Manutenzione	DOA4-O1	Documento approvato (nuova versione)

Pianificazione. Il Fornitore deve definire e documentare le modalità per identificare tutti i documenti che devono essere prodotti durante il ciclo di vita della fornitura e per rego- lamentare le relative modalità di progettazione, sviluppo, distribuzione, conservazione e manutenzione.

I documenti prodotti nel ciclo di vita della fornitura possono essere in genere di origine inter- na e di origine esterna. I documenti di origine interna sono tutti i documenti generati all’in- terno della organizzazione del Fornitore, prodotti nel corso della esecuzione del contratto;

possono essere deliverable contrattuali, quali documenti di Specifiche, manuali utente, docu- menti di pianificazione, ecc, o possono essere documenti contenenti istruzioni o guide sulle attività da svolgere e sulle relative modalità di svolgimento. I documenti di origine esterna includono i documenti prodotti da entità organizzative esterne all’organizzazione del Fornitore e rilevanti per la fornitura, quali ad esempio le norme, gli standard, i documenti emessi dall’Amministrazione, i documenti dei sub-fornitori, ecc. Tali documenti devono esse- re gestiti esclusivamente in configurazione secondo il loro livello di aggiornamento (revisio- ne, versione, ecc.) e secondo le modalità previste di distribuzione e di conservazione.

Tutti i documenti, sia di origine interna che di origine esterna, che servono per descrive- re la fornitura in tutto il ciclo di vita, devono essere gestiti in configurazione, in accordo con il processo di Gestione della Configurazione.

Il risultato dell’attività di Pianificazione è il Piano di gestione della documentazione, ovve- ro un documento o un insieme di documenti nel quale sono identificati e classificati per tipologia e contenuti, secondo criteri ivi indicati, tutti i documenti che devono essere pro- dotti durante il ciclo di vita della fornitura e, per ciascun documento identificato, sono indicati un identificativo (titolo o nome), lo scopo, i destinatari, le procedure e responsa- bilità per input, sviluppo, riesami, modifiche, approvazioni, produzione, conservazione, distribuzione, manutenzione, gestione della configurazione, pianificazione delle versioni intermedie e finali.

Progettazione e sviluppo. Sulla base del Piano di gestione della documentazione, cia- scun documento di origine interna identificato deve essere progettato secondo modelli di documentazione applicabili per quanto riguarda formati, descrizioni del contenuto, mar- cature di sicurezza e di proprietà, imballaggio ed altri eventuali elementi di presentazio- ne, in accordo con i requisiti e con gli standard eventualmente fissati nei documenti con- trattuali e/o nell’ambito del processo di Progettazione.

Completato il disegno dei documenti, è possibile attivare per ciascun documento il flusso di sviluppo, utilizzando strumenti automatici per la documentazione e prevedendo le appropriate forme di controllo (redazione, verifica ed approvazione) da parte di persona- le autorizzato, che ne verifica l’adeguatezza rispetto ai requisiti indicati. Il risultato dell’at- tività è il documento approvato, che può proseguire nel successivo iter di distribuzione e di conservazione, secondo le modalità fissate nel Piano di gestione della documentazione. Distribuzione e conservazione. È l’attività relativa alla distribuzione dei documenti e alla loro conservazione, secondo le modalità indicate nel Piano di gestione della documentazio- ne. L’attività riguarda sia i documenti di origine interna che i documenti di origine esterna. La distribuzione è finalizzata ad assicurare che siano disponibili edizioni appropriate dei documenti a tutte le entità organizzative interessate, siano esse interne o esterne all’orga- nizzazione del Fornitore. Per la distribuzione possono essere utilizzati diversi supporti, quali carta, dispositivi elettronici o altre tipologie di supporto. La distribuzione è effettua- ta di regola secondo elenchi di distribuzione prestabiliti e può avvenire in forma control- lata o non controllata, a seconda che sia a carico dell’entità emittente distribuire eventua- li nuove versioni del documento o debba essere l’entità ricevente a richiederne eventua- li nuovi aggiornamenti.

Per quanto riguarda la conservazione, di cui è parte integrante l’archiviazione, i materiali ori- ginali devono essere conservati secondo i requisiti di tempi e modi relativi a conservazione delle registrazioni, riservatezza, sicurezza, manutenzione ed eventuali prescrizioni normative.

La conservazione dei documenti deve prevedere modalità, quali ad esempio la gestione di elenchi dei documenti, atte ad impedire l’utilizzo di documenti non più validi e superati. Il risultato dell’attività è rappresentato dalle Registrazioni relative alla distribuzione ed alla conservazione dei documenti.

Manutenzione. Nel caso in cui i documenti di origine interna, approvati e distribuiti,

debbano essere modificati, si applica il processo di Manutenzione, con particolare riferi- mento alle attività di Analisi dei problemi e delle modifiche, Esecuzione delle modifiche, Riesame/accettazione delle modifiche.

La progettazione e sviluppo del documento modificato e la relativa distribuzione e con- servazione, avvengono attraverso le attività sopra descritte e secondo il Piano di gestione della documentazione. Per i documenti da gestire in configurazione, le modifiche devo- no essere apportate in accordo con il processo di Gestione della configurazione. Il risul- tato dell’attività è costituito dal documento nella nuova versione.

Chiusura del processo

Il processo di Gestione della documentazione si conclude con la conclusione del ciclo di vita della fornitura, quando risultino completate tutte le attività relative alla distribuzione e conservazione dei documenti ed in generale tutte le attività previste nel Piano di gestio- ne della documentazione.

5.2.3 Processo di Gestione della Configurazione

Obiettivi

Il processo ha l’obiettivo di garantire l’integrità e la rintracciabilità di tutti gli elementi che compongono la fornitura nell’intero ciclo di vita, attraverso attività, sia tecniche che gestio- nali, d’identificazione e documentazione delle caratteristiche funzionali e fisiche degli ele- menti, di controllo dei cambiamenti delle caratteristiche, di registrazione e notifica dello stato di realizzazione.

La gestione della configurazione identifica la configurazione di un prodotto in alcuni momenti del ciclo di vita; si basa sulla creazione progressiva di baseline, ognuna delle quali definisce lo stato del prodotto in un dato momento. Ogni modifica apportata ad un elemento della baseline deve essere effettuata in modo controllato.

Attivazione del processo

Il processo è svolto dal Fornitore in via continuativa, indipendentemente dai processi prima- ri attivati con la sottoscrizione del contratto. La definizione delle modalità di gestione della configurazioni dei prodotti connessi al ciclo di vita della fornitura segue la sottoscrizione del contratto. Sono dati di input i requisiti indicati nei documenti che costituiscono la baseline di contratto, prodotti nell’ambito dei processi di Acquisizione e di Fornitura, nonché i documen- ti prodotti nell’ambito del processo di Progettazione, nei quali sono specificati regole, stru- menti e modalità per la gestione delle configurazioni dei prodotti oggetto del contratto.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività proprie del proces- so di Gestione della Configurazione e dei prodotti che costituiscono il risultato di ciascu- na attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Gestione della Configurazione
Attività		Prodotti
CO-A1	Pianificazione	COA1-O1	Piano di gestione della configurazione
CO-A2	Identificazione della configurazione	COA2-O1	Documenti di configurazione
CO-A2	Identificazione della configurazione	COA2-O2	Prodotto nella configurazione di base
CO-A3	Controllo della configurazione	COA3-O	Prodotto nella configurazione corrente
CO-A4	Registrazione dello stato di configurazione	COA4-O1	Registro delle configurazioni
CO-A5	Rilascio e consegna	COA5-O1	Registrazioni

Pianificazione. Il Fornitore deve definire e documentare le modalità di gestione delle configurazioni dei prodotti durante il ciclo di vita, attraverso la predisposizione di un Piano di gestione della configurazione, ovvero di un documento o di un insieme di docu- menti nel quale sono indicati:

• le attività di gestione della configurazione, le procedure, il programma temporale di svolgimento delle attività;

• le entità organizzative coinvolte nella esecuzione delle attività, le responsabilità assegnate a ciascuna e la loro interrelazione con altre organizzazioni, tra le quali quelle preposte alle attività proprie dei processi di Realizzazione e Manutenzione;

• gli strumenti, le tecniche e le metodologie di gestione della configurazione da utilizzare;

• lo stadio al quale ciascun elemento dovrebbe essere passato sotto controllo di con- figurazione.

Identificazione della configurazione. Il Fornitore, in accordo con il Piano di gestione della configurazione, deve identificare e documentare gli elementi di configurazione e le loro versioni. Per ciascuna versione di ciascun elemento devono essere identificati la documentazione che stabilisce la baseline, le connessioni con la versione, ogni altro det- taglio che ne permetta l’identificazione, ivi incluse le necessarie caratteristiche funzionali e fisiche di ciascun elemento, con le interfacce, le modifiche, le deroghe e le concessio- ni (documenti di configurazione). Per esempio per i prodotti software, per ciascuna ver- sione di un elemento devono essere identificati le specifiche tecniche e funzionali, gli stru- menti di sviluppo che abbiano influenza su tali specifiche, le interfacce con altri elemen- ti software o con l’hardware ed i documenti e gli archivi informatici relativi all’elemento. L’identificazione dell’elemento software deve essere di regola organizzata in modo che si possa dimostrare la relazione tra l’elemento ed i requisiti contrattuali.

Il Fornitore deve identificare le versioni degli elementi di configurazione che, integrati tra loro, costituiscano una specifica versione del prodotto completo. Con accordi formali, in momenti determinati del ciclo di vita, deve essere stabilita la configurazione di base del prodotto ed usata come punto di partenza per il controllo formale della configurazione e per lo sviluppo delle versioni successive (configurazione corrente). Per esempio, in un rapporto contrattuale tra Fornitore ed Amministrazione la configurazione di base di un

prodotto a completamento del processo di Realizzazione è ratificata dalla conclusione con esito positivo del collaudo.

L’attività di identificazione della configurazione, produce come risultati i documenti di configurazione, che descrivono le caratteristiche funzionali e fisiche di ciascun elemento di configurazione, secondo quanto sopra indicato, e la ratifica della configurazione di base del prodotto.

Controllo della configurazione. L’attività è svolta secondo il Piano di gestione della

configurazione ed ha lo scopo di assicurare che, dopo il rilascio iniziale dei documenti di configurazione e la ratifica della configurazione di base, tutte le modifiche siano apporta- te in modo controllato. In particolare nel corso di tale attività il Fornitore deve:

• identificare e registrare le richieste di modifica;

• analizzare e valutare le modifiche, con riferimento ai requisiti, al campo di applica- zione (ampiezza della modifica; elementi da modificare) ed alla criticità (impatto sul funzionamento del prodotto, sulle prestazioni e sulla sicurezza).

• sottoporre i risultati dell’analisi all’iter di approvazione previsto nel Piano di gestio- ne della configurazione;

• attuare e verificare le modifiche approvate;

• rilasciare gli elementi modificati.

Per proteggere l’integrità della configurazione e fornire la base per il controllo delle modi- fiche è necessario che gli elementi di configurazione, le unità che le costituiscono e la documentazione relativa siano tenuti dal Fornitore in un ambiente che:

• sia commisurato con le condizioni ambientali richieste (ad esempio software, dati, documenti, ecc.);

• li protegga da modifiche non autorizzate o da danneggiamenti;

• fornisca i mezzi per ricostruirli in caso di danneggiamento;

• nel caso di software, dati, documenti e disegni, permetta il recupero di una copia dell’originale sotto controllo;

• consenta di relazionare la configurazione del prodotto come risultante rispettiva- mente dal processo di Progettazione e dal processo di Realizzazione.

Il risultato dell’attività è rappresentato dall’insieme degli elementi modificati che nell’insie- me costituiscono il prodotto nella configurazione corrente.

Registrazione dello stato della configurazione. L’attività consiste nel predisporre

registrazioni sulla gestione della configurazione e rapporti di situazione che mostrino lo stato e la storia degli elementi controllati, inclusi i documenti relativi alla baseline. La regi- strazione dello stato di configurazione inizia dal momento in cui i dati di configurazione sono generati per la prima volta.

Il Fornitore in particolare deve alimentare e gestire un Registro delle configurazioni, che consenta di documentare lo stato di costruzione di ciascun prodotto e dei relativi elemen- ti nelle diverse versioni e nelle diverse fasi del ciclo di vita, con particolare riferimento a:

• prodotti in corso di realizzazione, di gestione operativa e di manutenzione o in eser- cizio presso le Amministrazioni;

• elenco degli elementi controllati e dei documenti relativi alla baseline;

• configurazione di base ciascun prodotto, che rappresenta la definizione del prodot- to nel momento specifico;

• configurazione corrente, costituita dalla configurazione di base e dalle modifiche approvate, realizzate e collaudate;

• documentazione riguardante le modifiche e lo stato di attuazione, verifica e collau- do delle stesse.

Rilascio e consegna. L’attività riguarda il rilascio, la consegna e la conservazione dei prodotti e della relativa documentazione.

Propedeutica al rilascio è la valutazione della configurazione del prodotto, avente lo scopo di assicurare la completezza funzionale e fisica degli elementi rispetto ai requisiti. I materiali originali (codice, documenti, ..) devono essere mantenuti per tutto il ciclo di vita e devono essere trattati, consegnati e conservati nel rispetto di requisiti relativi a con- servazione delle registrazioni, riservatezza, sicurezza, manutenzione ed eventuali prescri- zioni normative.

Il risultato dell’attività è rappresentato dalle Registrazioni relative al rilascio ed alla conse- gna dei prodotti.

Chiusura del processo

Il processo di Gestione della Configurazione si conclude con la conclusione del ciclo di vita della fornitura, quando risultino completate tutte le attività relative al rilascio ed alla consegna dei prodotti ed in generale tutte le attività previste nel Piano di gestione della configurazione.

5.2.4 Processo di Assicurazione Qualità

Obiettivi

Il processo ha l’obiettivo di fornire adeguate assicurazioni che i prodotti ed i processi svol- ti nel ciclo di vita della fornitura siano conformi ai requisiti specificati e conformi ai rela- tivi piani. La norma UNI CEI ISO/IEC 12207 prevede che il processo di Assicurazione Qualità debba essere svolto in modo coordinato con i processi di Verifica, Validazione, Riesame congiunto, Verifica Ispettiva e Risoluzione dei problemi. Per tale motivo detti pro- cessi, nel seguito, sono visti come attività proprie del processo di Assicurazione Qualità, essendo ad esso strettamente collegati.

Attivazione del processo

Il processo è attivato parallelamente al processo di Gestione e svolto dal Fornitore secon- do attività pianificate, in accordo quanto definito nel Piano di qualità.

Attività e prodotti

Nello schema che segue si fornisce una rappresentazione delle attività del processo di Assicurazione Qualità; sono incluse in tale ambito anche le attività proprie dei processi di Verifica, Validazione, Riesame congiunto, Verifiche ispettive e Risoluzione dei problemi, in quanto sono strettamente connesse all’assicurazione qualità.

Per tutte le attività ed i prodotti evidenziati, si fornisce a seguire una descrizione delle finalità e dei contenuti.

Processo di Assicurazione Qualità
Attività		Prodotti
AQ-A1	Pianificazione	AQA1-O1	Piano di assicurazione qualità
AQ-A2	Assicurazione qualità	AQA2-O1	Registrazioni
AQ-A3	Verifica	AQA3-O1	Registrazioni
AQ-A4	Validazione	AQA4-O	Registrazioni
AQ-A5	Riesame congiunto	AQA5-O1	Registrazioni
AQ-A6	Verifica ispettiva	AQA6-O1	Piano di verifica
AQ-A6	Verifica ispettiva	AQA6-O2	Rapporto di verifica
AQ-A7	Risoluzione dei problemi	AQA7-O1	Piano di gestione dei problemi
AQ-A7	Risoluzione dei problemi	AQA7-O2	Registrazioni

Pianificazione. Sulla base dei requisiti del progetto e in accordo con il Piano di qualità ed il Piano di progetto, il Fornitore deve sviluppare ed attuare, per tutta la vita del con- tratto, un Piano di assicurazione qualità che contenga i seguenti elementi:

• livelli di qualità, metodologie, procedure e strumenti per svolgere le attività di assi- curazione qualità;

• procedure relative al riesame del contratto ed alla conseguente coordinazione;

• risorse, programma temporale e responsabilità della conduzione delle attività di assicurazione qualità, ivi incluse le attività di Verifica, Validazione, Riesame congiun- to, Verifica ispettiva.

Assicurazione qualità. L’attività si specializza nelle seguenti:

• Assicurazione di prodotto – è volta ad assicurare che tutti i piani predisposti in ese- cuzione del contratto soddisfino il contratto stesso, siano tra di loro compatibili e siano eseguiti secondo le modalità richieste. È finalizzata inoltre ad assicurare che i prodotti siano realizzati in aderenza ai piani e che, al momento della consegna, sod- disfino i requisiti contrattuali e siano accettabili dall’Amministrazione.

• Assicurazione di processo – è volta ad assicurare che tutti i processi relativi al ciclo di vita della fornitura (Fornitura, Progettazione, Realizzazione, Gestione operativa, Manutenzione e processi di supporto) sviluppati in esecuzione del contratto soddi- sfino il contratto stesso e siano aderenti ai piani. Ha l’obiettivo inoltre di assicurare che quanto realizzato da sub-fornitori soddisfi i requisiti del contratto principale sti- pulato dal Fornitore con l’Amministrazione.

• Assicurazione del sistema qualità – include le ulteriori attività di gestione della qua- lità, che devono essere assicurate secondo i requisiti della norma ISO 9001 e come specificato nel contratto.

Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte e ai risultati conseguiti.

Verifica. Le verifiche sono eseguite, secondo piani, su attività e prodotti del ciclo di vita

che si ritengono critiche in base alle finalità, all’impatto sul progetto ed alla complessità. L’attività può essere condotta con vari gradi di indipendenza, nel senso che, a seconda degli obiettivi e del prodotto da sottoporre a verifica, il grado di indipendenza può spa- ziare da una stessa persona o persone differenti nella stessa organizzazione, sino a per- sone di organizzazioni differenti.

La verifica può specializzarsi nelle seguenti attività:

• Verifica del contratto – ha lo scopo di verificare aspetti quali la capacità del Fornitore di soddisfare i requisiti, la coerenza dei requisiti e l’adeguatezza rispetto alle necessità dell’utente, l’esistenza di procedure formali per la gestione delle modi- fiche ai requisiti, per la risoluzione dei problemi, per l’accettazione della fornitura e per la gestione dei rapporti tra i contraenti.

• Verifica del processo – è volta a verificare che ciascun processo sviluppato per l’e- secuzione del progetto sia adeguato ed eseguito secondo i piani ed in accordo con il contratto e che il personale assegnato sia adeguato alle esigenze ed opportuna- mente formato, come richiesto dal contratto.

• Verifica dei requisiti – è eseguita al fine di assicurare che i requisiti siano coerenti, fattibili, verificabili e che siano appropriatamente distribuiti sugli elementi hardwa- re, sugli elementi software e sulle attività manuali, in accordo con i criteri di pro- gettazione e possano essere sottoposti a prove

• Verifica della progettazione – ha lo scopo di assicurare la correttezza e la coerenza della soluzione progettuale rispetto ai requisiti.

• Verifica del prodotto – è volta a determinare che il prodotto software, il sistema o, più in generale, il risultato di un’attività soddisfi i requisiti o le condizioni imposti loro dalle attività precedenti, che detti elementi siano tracciabili verso la progetta- zione e verso i requisiti, che siano corretti e verificabili.

• Verifica della integrazione – è volta a verificare che le unità ed i componenti soft- ware di ciascun elemento siano state completamente e correttamente integrati, che gli elementi hardware, gli elementi software e le attività manuali siano state com- pletamente e correttamente integrate nel sistema, e che i compiti e le attività di inte- grazione siano state svolte secondo i piani.

• Verifica della documentazione – ha lo scopo di assicurare che la documentazione sia adeguata, completa e coerente, che sia prodotta tempestivamente e che sia gesti- ta in configurazione secondo le procedure previste.

Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte e ai risultati conseguiti.

Validazione. La validazione ha lo scopo di determinare che il prodotto realizzato soddi-

sfi i requisiti iniziali, fissati nel contratto e che operi correttamente in relazione alla sua destinazione d’uso. Analogamente alla Verifica, l’attività può essere condotta con vari gradi di indipendenza, nel senso che, a seconda degli obiettivi e del prodotto da valida- re, il grado di indipendenza può spaziare da una stessa persona o persone differenti nella stessa organizzazione, sino a persone di organizzazioni differenti.

L’attività è condotta secondo un piano (Piano di test o documento equivalente), nel quale sono indicati gli elementi da validare, i test da eseguire, le risorse necessarie e le relative responsabilità, il programma temporale di esecuzione dei casi di test, le modalità di noti- fica dei risultati agli interessati.

Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte, di cui sono parte integrante i risultati dei test eseguiti (Test Data Report).

Riesame congiunto. È eseguito da una qualsiasi delle parti contraenti, l’Amministrazione

o il Fornitore, che possono svolgere rispettivamente il ruolo di parte riesaminante e parte riesaminata, con lo scopo di valutare lo stato ed i prodotti di un’attività; il riesame con- giunto può essere eseguito periodicamente per tutta la durata del contratto, secondo date identificate nel Piano di progetto, oppure può essere svolto in modo non pianificato, quando ritenuto necessario da una delle due parti. In ogni caso è eseguito previa defini- zione dei prodotti e dei problemi oggetto di riesame, delle risorse coinvolte, dei mezzi e delle modalità di conduzione.

Il riesame congiunto può specializzarsi nelle seguenti attività:

• Riesame della gestione del progetto – è volto a valutare lo stato del progetto in rela- zione ai piani di progetto, ai documenti di stato avanzamento lavori, alle norme e linee guida applicabili, allo scopo di verificare che le attività procedano secondo i piani e di intraprendere le opportune azioni per modificare la direzione del proget- to e/o valutare e gestire i rischi rilevati.

• Riesame tecnico – è condotto sui prodotti delle attività, con lo scopo di verificare che essi siano completi, conformi alle norme e alle specifiche, siano realizzati in accordo con il programma temporale e possano essere dati in input all’attività suc- cessiva. L’attività è anche volta a verificare che la progettazione, la realizzazione, la gestione operativa e la manutenzione siano condotte secondo i piani.

Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte e ai risultati conseguiti. Per quanto riguarda i risultati, in particolare, le parti devono concor- dare le reciproche responsabilità di gestione delle azioni conseguenti.

Verifica ispettiva. Le Verifiche Ispettive interne (verifiche ispettive di prima parte), di

responsabilità del Fornitore, sono eseguite allo scopo di determinare se le attività svolte ed i risultati ottenuti sono in accordo con quanto pianificato e risultano adeguati per il conseguimento degli obiettivi contrattuali. Sono programmate e condotte periodicamen- te, secondo date indicate nei piani di progetto, e sono effettuate da personale con com- petenze multidisciplinari, individuato in modo da assicurare la completa indipendenza da chi ha diretta responsabilità per le attività ed i prodotti sottoposti a verifica.

L’esecuzione di ciascuna verifica ispettiva è preceduta dalla predisposizione ed invio alla/e organizzazione/i interessata/e di un Piano di verifica, volto a stabilire obiettivi ed estensione della verifica, attività e prodotti oggetto di verifica, entità organizzative interes- sate, modalità di esecuzione, documenti di riferimento e criteri di entrata e di uscita della verifica. La verifica è di regola condotta attraverso colloqui con il personale, esame delle registrazioni delle attività interessate e dei relativi prodotti, esame dei documenti di riferi- mento ed osservazione diretta del modo di operare rispetto ai documenti di riferimento. A conclusione della verifica viene redatto un rapporto di verifica, o documento equiva- lente, distribuito alla parte verificata ed alle entità organizzative interessate, nel quale sono

indicati i risultati della verifica e la pianificazione delle azioni di soluzione ai problemi o alle non conformità rilevate.

In relazione a quanto stabilito nel contratto, il Fornitore deve consentire all’Ammini- strazione la facoltà di procedere alle Verifiche ispettive di seconda parte, di cui all’art. 8 della Deliberazione AIPA n. 49/2000, verifiche che dovranno essere condotte secondo le modalità indicate dalla norma EN ISO 10011. Inoltre il Fornitore, se previsto, deve rende- re disponibile all’Amministrazione la documentazione attestante l’esito delle visite di sor- veglianza della società di certificazione della qualità (Verifiche ispettive di terza parte).

Risoluzione dei problemi. Il processo ha l’obiettivo di analizzare i problemi e le non-

conformità, qualunque sia la loro natura o origine, che vengono individuati durante l’e- secuzione dei processi del ciclo di vita della fornitura. L’obiettivo è fornire un modo tem- pestivo, responsabile e documentato per assicurare che tutti i problemi rilevati siano ana- lizzati e risolti e siano individuate le linee di tendenza, al fine di intraprendere per tempo adeguate azioni preventive.

I problemi e le non-conformità relative ad attività e prodotti devono essere gestiti dal Fornitore secondo un ciclo chiuso, in grado di assicurare che per ciascun problema venga intrapresa una azione, che le parti interessate siano informate dell’esistenza del problema e della sua evoluzione, che siano identificate, analizzate e rimosse le cause e siano forni- te soluzioni in merito, che sia tracciato e riportato lo stato del problema e siano conser- vate le relative registrazioni, in accordo con quanto previsto dal contratto.

Per ciascun problema il Fornitore, in un Piano di gestione dei problemi o in un documen- to equivalente, deve definire le modalità di gestione, provvedendo in particolare a classi- ficare ciascun problema per categoria e priorità, secondo uno schema predefinito, ad ese- guire analisi volte a verificare l’impatto del problema sul progetto, le linee di tendenza, le soluzioni da implementare, le responsabilità ed i tempi per implementare le soluzioni, le relative modalità di esecuzione e verifica. Le verifiche devono assicurare che le modifiche siano state apportate correttamente, che non abbiano introdotto ulteriori problemi e che le linee di tendenza negative siano state invertite.

L’esecuzione del Piano di gestione dei problemi, documentata dalle Registrazioni relative alle attività svolte, consente la risoluzione del problema e delle sue cause, che deve esse- re verificata secondo quanto previsto nel Piano e notificata tempestivamente alle parti interessate.

Chiusura del processo

Il processo di Assicurazione Qualità è attuato in via continuativa fino alla conclusione di tutti i processi svolti dal Fornitore per eseguire la fornitura oggetto del contratto.

Le Registrazioni ed i prodotti delle attività relative al processo di Assicurazione Qualità devono essere resi disponibili all’Amministrazione, secondo quanto stabilito nel contrat- to, e costituiscono dati di input al processo di Miglioramento.

6. Categorie ed attributi di qualità delle fornitu- re ICT

Il concetto di qualità si è significativamente trasformato negli ultimi anni. Questa evolu- zione è conseguenza della crescente attenzione da parte dei fornitori alla soddisfazione del cliente come fattore critico di successo.

Un presupposto fondamentale per raggiungere questo obiettivo riguarda i processi di ero- gazione dei servizi adottati dai fornitori che devono essere definiti, formalizzati, control- lati e, se necessario, modificati in base al monitoraggio dei risultati.Un altro elemento altrettanto importante riguarda l’individuazione di tutti requisiti di qualità della fornitura, compito che spetta prevalentemente al cliente sulla base delle proprie esigenze e che deve chiaramente descrivere negli atti contrattuali.

Per fornire un supporto allo svolgimento di questa attività l’ISO (International Standard Organization) ha prodotto una serie di norme sia sulla qualità dei processi produttivi sia sulla qualità dei prodotti/servizi. In particolare per quanto riguarda i prodotti software è stato definito un modello di riferimento, rappresentato dalla norma ISO/IEC 9126:2001, nel quale sono definite 6 caratteristiche principali di qualità interna ed esterna (con 27 sot- tocaratteristiche) e 4 fattori di qualità in uso.

Questa norma è stata emessa in una prima versione nel 1991, e poi revisionata nel 2001 con l’emissione di una nuova versione dal titolo “Information Technology: Software pro- duct quality” suddivisa in quattro parti. La prima versione definiva nelle linee generali anche un modello di valutazione della qualità basato sulle sei caratteristiche. Con la suc- cessiva versione questa parte è stata enucleata e inglobata nella norma ISO/IEC 14598 dal titolo “Software Product Evaluation”.

Riguardo ai servizi, una possibile definizione è la seguente tratta dal glossario dei termi- ni e delle definizione per la qualità di cui alla norma UNI EN ISO 9000:2000: il servizio è il risultato di attività svolte all’interfaccia tra fornitore e cliente e di attività proprie del for- nitore per soddisfare le esigenze del cliente.

Le caratteristiche intrinseche di un generico servizio derivanti da questa definizione si riflet- tono sul rapporto tra cliente e fornitore che si viene ad instaurare in conseguenza dell’e- rogazione di un servizio e, conseguentemente, sul contratto che formalizza tale rapporto. Relativamente alla definizione data i servizi si caratterizzano, rispetto ad altre tipologie di forniture, quali l’acquisto o locazione di beni (anche software) o le opere pubbliche, per alcuni elementi distintivi fondamentali:

• sono intangibili, qualificandosi in termini delle loro prestazioni piuttosto che relati- vamente a qualche attributo fisico posseduto; possono in ogni caso essere connes- si alla realizzazione del servizio la fabbricazione, utilizzazione, acquisto o locazio- ne, di beni tangibili;

• sono attività continuative, in altre parole la produzione, o erogazione del servizio, e la sua fruizione non sono separabili; ovviamente come vedremo meglio di segui- to la continuità di erogazione del servizio può anche attuarsi per il tramite di unità elementari, discrete, di servizio attivate nel tempo automaticamente o su specifica richiesta dell’utente;

• presentano una forte variabilità nel tempo, da attribuirsi a possibili fluttuazioni, delle componenti organizzative, tecnologiche, umane, e dallo stesso processo del forni- tore fornisce la prestazione, che influenzano le prestazioni raggiunte;

• sono eterogenei, variando nelle prestazioni, da fornitore a fornitore, al variare del processo produttivo o ciclo di vita adottato; da utente ad utente, al variare del modus operandi adottato in funzione delle conoscenze e competenze pregresse.

In funzione delle caratteristiche evidenziate, per i servizi sono proposti in letteratura diver- si modelli di riferimento per la misura della qualità che differiscono in parte dal modello per la valutazione del prodotto software rappresentato dalla norma ISO/IEC 9126. Questi modelli di valutazione della qualità dei servizi si basano sulla percezione che ha il clien- te del servizio erogato ed a questo scopo stabiliscono delle caratteristiche di qualità del servizio alle quali tipicamente un utente si riferisce nella valutazione del servizio (punti di vista di chi appalta e, soprattutto, del fruitore). Queste caratteristiche sono misurate attra- verso un’indagine diretta sugli utenti del servizio per rilevarne il grado di soddisfazione. Questo tipo di rilevazione ha però due limiti importanti: il primo riguarda il carattere sog- gettivo della valutazione che, in parte, può essere superato selezionando e dimensionan- do correttamente il campione d’indagine, il secondo riguarda il fatto che si tratta di una valutazione di carattere qualitativo e non quantitativo fatta in corso d’opera non utile, quindi, per stabilire i requisiti di qualità del servizio negli accordi contrattuali con il for- nitore. È necessario che le caratteristiche di qualità che percepisce il cliente siano espres- se in forma quantitativa per poter essere definite preliminarmente, concordate e misurate durante l’erogazione in modo oggettivo.

A questo scopo occorre individuare indicatori specifici per tipologie di servizio, che con- sentano di tradurre almeno in parte le aspettative di qualità dell’utente, attraverso la defi- nizione di valori di soglia.

Il tipo di relazione tra grado di soddisfazione dell’utente ed i valori di soglia degli indica- tori adottati può essere individuato basandosi su esperienze pregresse sul medesimo ser- vizio o servizi simili. Per questo risulta essenziale che nel corso di erogazione di un ser- vizio sia effettuato un monitoraggio continuo degli indicatori di qualità e rilevazioni perio- diche sulla soddisfazione degli utenti.

I modelli più diffusi per la rilevazione della soddisfazione del cliente sono quelli propo- sti da Xxxxxxxxxxx e Kano che definiscono le caratteristiche di qualità che concorrono alla valutazione della soddisfazione dei clienti.

6.1. Caratteristiche di qualità (ISO 9126)

La nuova norma ISO 9126 “Information Technology: Software product quality” definisce una classificazione gerarchica a due livelli dei requisiti di qualità dei prodotti software.

Tale classificazione può essere, almeno in parte adottata, per classificare anche i requisi- ti di qualità dei servizi. La norma individua tre classi di qualità, qualità esterna, qualità interna e qualità in uso:

• la qualità esterna si riferisce alle caratteristiche del prodotto rilevabili in fase di ese- cuzione nell’ambiente in cui sarà utilizzato, in un certo qual modo corrisponde al punto di vista di chi appalta;

• la qualità interna si riferisce alle caratteristiche rilevabili analizzando il codice e la documentazione di progetto e per l’utente, come punto di vista corrisponde alla qualità intrinseca della fornitura.;

• la qualità in uso si riferisce a caratteristiche del prodotto rilevabili in uno specifico contesto e misura quanto il prodotto supporta l’utente nel raggiungere i suoi obiet- tivi, corrisponde pienamente al punto di vista del fruitore.

Se si considera che l’utilizzo di un prodotto non è altro che un servizio che questo eroga ad un utente, è possibile utilizzare la parte del modello di qualità proposto dalla norma che riguarda la qualità esterna e la qualità in uso per descrivere la qualità in merito alla modalità di erogazione di un servizio.

Estendendo questo approccio, si può ritenere che il prodotto sia il risultato dell’attività di progettazione e realizzazione del servizio stesso (es. Nr. di addetti, curricula professiona- li, strumenti di supporto, organizzazione, etc.) e quindi può essere applicato al risultato dei processi di progettazione e realizzazione del servizio.

Il modello proposto individua per la qualità interna e esterna sei caratteristiche e 27 sot- tocaratteristiche associate come segue:

Qualità interna ed esterna

Funzionalità

Affidabilità

Usabilità

Efficienza

Mantenibilità

Portabilità

• Adeguatezza

• Accuratezza

• Interoperabilità

• Sicurezza

• Conformità alla funzionalità

• Maturità

• Tolleranza ai guasti

• Ripristinabilità

• Conformità alla affidabilità

• Comprensibilità

• Apprendibilità

• Operabilità

• Attrattività

• Conformità alla sabilità

• Prestazioni temporali

• Utilizzo risorse

• Conformità alla efficienza

• Analizzabilità

• Modificabilità

• Stabilità

• Collaudabilità

• Conformità alla mantenibilità

• Adattabilità

• Installabilità

• Coesistenza

• Sostituibilità

• Conformità alla portabilità

La qualità in uso è descritta attraverso quattro caratteristiche che non sono associate a sot- tocaratteristiche:

Qualità in uso
Efficacia	Produttività	Salvaguardia	Soddisfazione

Tra queste caratteristiche quelle che descrivono meglio i requisiti di qualità di erogazione di un servizio sono le 4 caratteristiche che si riferiscono alla qualità in uso e la funziona- lità, l’affidabilità, l’usabilità, l’efficienza per la qualità interna/esterna.

Per ogni sottocaratteristica sopra elencata le norma ISO 9126 parte 2, 3, 4 individua una o più metriche per poter misurare in modo quantitativo il profilo di qualità di un prodot- to software. Sono proposte metriche (o indicatori) diverse per misurare la stessa sottoca- ratteristica in quanto riguardano aspetti specifici che insieme concorrono a valutare la medesima. Ogni fornitura ha esigenze specifiche anche in relazione alla qualità ed è necessario, quindi, selezionare di volta in volta le metriche opportune. Per esempio se abbiamo l’esigenza di sviluppare dei programmi batch, che sappiamo saranno utilizzati solo per una volta, non si dovrà dare enfasi al grado di strutturazione del suo codice che misura la facilità di comprensione del programma in fase di manutenzione.

Questa metrica diviene al contrario importante in un’applicazione ad alto grado di utiliz- zo, che si interfaccia o integra numerose applicazioni e per la quale si prevede un este- so periodo di esercizio. Tale considerazione può essere estesa anche ai profili di qualità che riguardano le modalità di erogazione di un servizio.

6.2 Dimensioni di qualità (Servqual)

Ogni servizio ha lo scopo primario di soddisfare i bisogni di chi lo utilizza e di conse- guenza il grado di soddisfazione del cliente è la misura che permette di stabilire se il ser- vizio è erogato con il giusto livello di qualità.

Negli ultimi tre decenni un consistente numero di studiosi ha affrontato il tema della qua- lità e della sua misura e il concetto che si è andato via via affermando è che la qualità del servizio è il risultato tra il confronto che fa il cliente tra le sue aspettative riguardo a quan- to dovrebbe offrire il fornitore e le prestazioni effettivamente erogate.

L’indagine svolta tramite interviste a 12 focus group da Parasuram, Zeithalm e Xxxxx ha fatto emergere che il cliente associa la qualità del servizio alla differenza tra le sue aspet- tative e la percezione del servizio riguardo a dieci diversi aspetti di valutazione:

• Aspetti fisici: aspetto delle strutture fisiche, dell’attrezzatura, del personale e degli strumenti di comunicazione;

• Affidabilità: capacità di prestare il servizio promesso in modo affidabile e preciso;

• Capacità di risposta: volontà di aiutare i clienti e di fornire prontamente il servizio;

• Competenza: possesso delle abilità e delle conoscenze necessarie a prestare il servizio;

• Cortesia: gentilezza, rispetto, considerazione e cordialità del personale;

• Credibilità: attendibilità, credibilità ed onestà;

• Sicurezza: assenza di pericoli, rischi o dubbi;

• Accessibilità e facilità di contatto;

• Comunicazione: informazione ai clienti, mediante linguaggi comprensibili ed atten- zione ad ascoltarne la voce;

• Comprensione del cliente: impegno preconoscere i clienti e le loro esigenze.

Nell’ottica di sviluppare un sistema di misura della discrepanza tra percezioni e aspettati- ve del cliente Parasuram, Zeithaml e Xxxxx hanno sviluppato un sistema per la misura della qualità (Servqual) basato sulle differenze tra due valutazioni effettuate su una scala a sette valori da applicare a 97 proposizioni inerenti le 10 dimensioni sopra elencate.

Il sistema Servqual è stato successivamente affinato in quanto, dall’analisi dei risultati del- l’applicazione del metodo, risultarono effettivamente significative 34 proposizioni e sette dimensioni di qualità. La somministrazione successiva del sistema così modificato a 200 clienti di cinque diverse categorie di servizi ha permesso di semplificare ulteriormente il modello eliminando ulteriori proposizioni scarsamente rilevanti in modo da creare un modello a 5 dimensioni di qualità e 22 proposizioni.

Dimensioni di qualità

Aspetti fisici

Affidabilità

Capacità

DI RISPOSTA

Capacità

DI RASSICURAZIONE

Empatia

• aspetto delle attrezzature

• aspetto delle strutture fisiche

• aspetto del personale a contatto con il cliente

• aspetto dei materiali associati al servizio (opuscoli, presentazioni, ecc)

• mantenimento delle promesse

• interesse a risolvere i problemi del cliente

• corretta erogazione del servizio la prima volta

• puntualità

• informare il cliente su quando sarà erogata la prestazione

• tempestività di erogazione

• disponibilità ad aiutare il cliente

• personale disponibile quando richiesto

• Il personale deve ispirare fiducia

• I clienti devono sentirsi sicuri nelle loro transazioni

• il personale deve essere cortese

• Il personale deve avere le competenze per rispondere efficacemente alle domande dei clienti

• attenzione individuale al cliente

• orari di apertura comodi

• personale che si occupa personalmente dei clienti

• personale che ha a cuore i principali interessi del cliente

• personale che comprende le specifiche esigenze dei clienti

Il sistema Servqual è stato realizzato per poter essere applicato ad un’ampia gamma di servizi. La struttura di base messa a punto dagli autori su cinque servizi di riferimento e basata su queste cinque dimensioni, può essere adattata e personalizzata, se necessa- rio, modificando, sostituendo o aggiungendo nuove proposizioni che meglio si adatta- no alle caratteristiche del servizio ed al contesto di erogazione. Le dimensioni di quali- tà del sistema Servqual corrispondono ai punti di vista di chi appalta e del fruitore del servizio.

Il sistema Servqual risulta particolarmente valido quando è impiegato in modo ripetuto insieme ad altri metodi di misura della qualità in quanto permette di stabilire delle affi- dabili correlazioni tra quanto si aspetta il cliente e gli indicatori quantitativi di misura della qualità del servizi. In questo modo è anche possibile seguire l’evoluzione delle aspettative e delle percezioni dei clienti rispetto alle diverse dimensioni di qualità del servizio.

Analizzando le 22 proposizioni del sistema Servqual è possibile in parte associare le 5 dimensioni di qualità alle caratteristiche e sottocaratteristiche definite dalla norma ISO 9126.

La tabella che segue indica dimensioni e caratteristiche di qualità che presentano aspetti comuni:

Caratteristiche di qualità ISO 9126		Dimensioni di qualità (SERVQUAL)
Aree di qualità	Caratteristiche	ASPETTI FISICI	AFFIDABILITÀ	CAPACITÀ DI RISPOSTA	CAPACITÀ DI RASSICURAZIONE	EMPATIA
qualità esterna	Funzionalità		X
	Affidabilità		X
	Usabilità	X
	Efficienza			X	X
	Manutenibilità
	Portabilità
qualità in uso	Efficacia
	Produttività
	Salvaguardia
	Soddisfazione		X	X	X	X

6.3 Modello di qualità adottato

I due modelli di qualità descritti individuano, in parte, elementi diversi da utilizzare nella descrizione del profilo di qualità di un servizio. È opportuno quindi fare riferimento ad un modello completo che rappresenti tutti gli elementi e che aggreghi insieme quelli comuni.

A tale scopo occorre confrontare le definizioni associate alle caratteristiche/sottocaratteri- stiche di qualità nella norma ISO 9126 interpretate nell’ottica più generale di erogazione di un servizio e le definizioni delle dimensioni/proposizioni del modello Servqual.

Il modello che si propone, riassunto nella tabella della pagina seguente, si compone di 10 caratteristiche di qualità e 32 sottocaratteristiche.

Caratteristiche

Sottocaratteristiche

Funzionalità

adeguatezza accuratezza interoperabilità sicurezza

conformità alla funzionalità

Affidabilità

maturità tolleranza ripristinabilità conformità

68 (segue)

Usabilità	comprensibilità apprendibilità operabilità attrattività conformità all’usabilità
Efficienza	efficienza temporale utilizzazione delle risorse conformità all’efficienza
Manutenibilità	analizzabilità modificabilità stabilità testabilità conformità alla manutenibilità
Portabilità	adattabilità installabilità coesistenza sostituibilità conformità alla portabilità
Efficacia	efficacia
Produttività	produttività
Salvaguardia	salvaguardia
Soddisfazione	empatia capacità di rassicurazione

Le relative definizioni delle caratteristiche e sottocaratteristiche del modello di qualità adottato, riportate di seguito, possono essere applicate ad ogni specifico processo di cui si compone un servizio.

Funzionalità. Nel servizio/prodotto sono presenti le funzioni che, con le relative pro-

prietà, gli conferiscono la capacità di soddisfare le esigenze dell’utente. Sottocaratteristiche associate:

• adeguatezza – presenza delle funzioni appropriate per i compiti specificati e gli obiettivi dell’utente

• accuratezza – capacità di fornire i corretti o concordati risultati o effetti con il necessario grado di precisione;

• interoperabilità – capacità del servizio/prodotto di interagire con uno o più sistemi specificati;

• sicurezza – capacità di proteggere i dati e l’informazione in modo da evitare che persone o sistemi non autorizzati possano acquisirla o modificarla e in modo da non rifiutarne l’accesso alle persone e ai sistemi autorizzati;

• conformità alla funzionalità – capacità di rispettare standard, convenzioni e norme di legge e normative similari relativamente alla funzionalità.

Affidabilità. Capacità di mantenere un determinato livello di operatività in determinate condizioni di utilizzo. Sottocaratteristiche associate:

• maturità – capacità di erogare correttamente il servizio/prodotto la prima volta senza la necessità di dover ripetere la prestazione e puntualità nell’erogazione della prestazione;

• tolleranza – capacità di mantenere un livello specificato di prestazioni in caso di malfunzionamenti;

• ripristinabilità –capacità di ristabilire un livello di prestazioni specificato in caso di malfunzionamento;

• conformità – capacità di essere conforme a standard, convenzioni o regole perti- nenti all’affidabilità.

Usabilità. Capacità del servizio/prodotto di essere compreso, imparato, usato ed essere attraente per l’utilizzatore, quando sia usato in condizioni specificate. Sottocaratteristiche associate:

• comprensibilità, capacità di mettere l’utente in grado di capire se il servizio è ade- guato, e come può essere utilizzato per compiti particolari e particolari condizioni d’uso;

• apprendibilità, capacità di mettere l’utente in grado di imparare ad usare il servizio;

• operabilità, capacità di mettere l’utente in grado di controllare l’avanzamento a seguito di una richiesta di prestazione;

• attrattività, capacità del servizio/prodotto di essere attraente per l’utilizzatore anche in relazione alla comodità dell’orario di erogazione del servizio, all’aspetto delle attrezzature, delle personale a contatto con il cliente e del materiale associato al ser- vizio (opuscoli, presentazioni, ecc.);

• conformità all’usabilità, capacità di rispettare standard, convenzioni, raccomanda- zioni stilistiche o regole riguardanti l’usabilità.

Efficienza. Capacità del servizio/prodotto di fornire appropriate prestazioni relativamen- te alla quantità di risorse usate, in condizioni stabilite. Sottocaratteristiche associate:

• Efficienza temporale, capacità di rispondere tempestivamente alle richieste e di ero- gare tempestivamente la prestazione in condizioni stabilite.

• Utilizzazione delle risorse, capacità di usare quantità e tipi appropriati di risorse durante lo svolgimento delle sue funzioni in condizioni stabilite.

• Conformità all’efficienza, capacità di rispettare standard o convenzioni riguardanti l’efficienza.

Manutenibilità. Capacità del servizio/prodotto di essere modificato. Le modifiche posso- no includere interventi sull’organizzazione, le risorse e gli strumenti a fronte di cambia- menti di ambiente, e di requisiti e specifiche funzionali. Sottocaratteristiche associate:

• Analizzabilità, capacità del servizio/prodotto di essere diagnosticato relativamente a deficienze nell’erogazione, o relativamente agli elementi, di cui si avvale, da iden- tificare per essere modificati.

• Modificabilità, capacità di consentire la realizzazione di una modifica specificata.

• Stabilità, capacità di evitare effetti inattesi dovuti a modifiche degli elementi di cui si avvale il servizio.

• Testabilità, capacità di consentire la validazione di a seguito di modifiche degli ele- menti.

• Conformità alla manutenibilità, capacità di rispettare standard o convenzioni riguardanti la manutenibilità.

Portabilità. Questa caratteristica si adatta in particolare ad un prodotto software e riguar- da la capacità di essere trasferito da un ambiente ad un altro. Sottocaratteristiche associate:

• Adattabilità, capacità di adattarsi a diversi ambienti specificati senza l’impiego di azioni o mezzi diversi da quelli forniti espressamente a questo scopo per il softwa- re considerato.

• Installabilità, capacità di essere installato in un ambiente specificato.

• Coesistenza, capacità di coesistere con altro software indipendente in un ambiente comune, condividendo risorse comuni.

• Sostituibilità, capacità di essere utilizzato nello stesso ambiente al posto di un altro prodotto software specificato per lo stesso scopo.

• Conformità alla portabilità, capacità di rispettare standard o convenzioni riguardan- ti la portabilità.

Efficacia. Capacità di mettere in grado gli utenti di raggiungere obiettivi specificati con accuratezza e completezza in un contesto d’uso specificato.

Produttività. Capacità di mettere in grado gli utenti di impiegare quantità di risorse appropriate in relazione all’efficacia ottenuta in un contesto d’uso specificato. (Risorse rile- vanti in relazione alla produttività possono includere il tempo per completare il lavoro, l’impegno dell’utente, materiali o il costo finanziario dell’utilizzazione).

Salvaguardia. Capacità di ottenere livelli di rischio accettabili per danni alle persone, all’azienda, al software, alla proprietà o all’ambiente in uno specifico contesto d’uso.

Soddisfazione. Capacità di soddisfare gli utenti in uno specificato contesto d’uso (la soddi- sfazione è la risposta dell’utente all’interazione con il servizio). Sottocaratteristiche associate:

• Empatia, capacità del personale di porre attenzione individuale al cliente, di com- prendere le specifiche esigenze dei clienti, di avere a cuore i principali interessi del cliente, di dimostrare impegno nel risolvere i problemi, di informare il cliente su quando sarà erogata la prestazione.

• Capacità di rassicurazione, capacità del personale di ispirare fiducia, di essere cor- tese, di trasmettere sicurezza nelle sue transazioni.

6.4 INDICATORI DI QUALITÀ

Per la misura delle caratteristiche e sottocaratteristiche del modello sopra descritto, si propone un insieme di indicatori di qualità per la definizione del profilo di qualità del servizio.

Per ogni singola fornitura occorre preliminarmente selezionare le caratteristiche e sotto- caratteristiche di qualità significative e scegliere successivamente gli indicatori di qualità associati, che descrivono più efficacemente questi elementi nel contesto di riferimento della fornitura.

Ogni indicatore di qualità adottato deve essere quindi associato ad un valore di soglia o valore obiettivo, che può essere determinato prendendo a riferimento dati di letteratura o, se disponibili, valori relativi a precedenti forniture equivalenti che dovranno essere per- sonalizzati in base alle specifiche esigenze.

La tabella che segue, a fronte delle 10 caratteristiche di qualità e delle 32 sottocaratteristi- che definite all’interno del modello di qualità adottato, presenta per ciascuna di queste ultime un esempio di indicatore di qualità. Ad ogni sottocaratteristica di qualità possono essere associati più indicatori, quelli di seguito identificati, uno per sottocaratteristica, vogliono solo essere degli esempi. Per questo motivo la lista degli indicatori di qualità di seguito prodotta non deve essere intesa in senso esaustivo.

Metriche di misura della qualità – 1/4
CARATTERISTICA/ SOTTOCARATT.	NOME DELLA METRICA	DESCRIZIONE DELLA METRICA	MISURA, FORMULA E DATI ELEMENTARI
funzionalità/ adeguatezza	adeguatezza funzionale	misura il rapporto tra funzioni implementate e funzioni richieste	X = 1-A/B A = numero delle funzioni mancanti. B = Numero di funzioni previste nei requisiti
funzionalità/ accuratezza	accuratezza delle funzioni implementate	misura il rapporto tra funzioni implementate con il livello di accuratezza richiesto e le funzioni i cui requisiti prevedono specifici livelli di accuratezza	X = A/B A = numero di funzioni implementate con il livello di accuratezza richiesto B = numero di funzioni i cui requisiti prevedono specifici livelli di accuratezza
funzionalità/ interoperabilità	Difetti nello scambio dei dati tra applicazioni	misura il numero di casi in cui la funzione di interfaccia provoca errori	X = 1-A/B A = numero di casi in cui è usata la funzione di interfaccia e sono rilevati errori. B = numero di casi in cui è usata la funzione di interfaccia
funzionalità/ sicurezza	controllo degli accessi	Conta il numero dei requisiti di controllo degli accessi implementati rispetto al numero dei requisiti di controllo degli accessi	X = A/B A = numero dei requisiti di controllo degli accessi implementati B = numero dei requisiti di controllo degli accessi
funzionalità/ conformità	conformità funzionale	Conta il numero di item per i quali è assicurata la conformità rispetto al numero di item per i quali è richiesta la conformità	X = A/B A = numero di item per i quali è assicurata la conformità B= numero di item per i quali è richiesta la conformità

Metriche di misura della qualità –2/4
CARATTERISTICA/ SOTTOCARATT.	NOME DELLA METRICA	DESCRIZIONE DELLA METRICA	MISURA, FORMULA E DATI ELEMENTARI
affidabilità/ maturità	tempo intercorrente tra due errori (MTBF)	Conta il numero di errori che si presentano durante un periodo definito e calcola l’intervallo medio tra due errori	Y = T/A T = somma degli intervalli di tempo tra due errori A = numero totale di errori rilevati
affidabilità/ tolleranza	Malfunzioni che impediscono l’utilizzo del sistema	misura il rapporto tra le malfunzioni che producono la sospensione dell’uso del sistema ed il totale delle malfunzioni rilevate	X = 1- A/B A = numero di malfunzioni che producono la sospensione dell’uso del sistema B = numero di malfunzioni rilevate
affidabilità/ ripristinabilità	Disponibilità	misura la disponibilità del servizio in un determinato periodo di tempo	X = {To/(To + Tr)} To = tempo in cui il servizio è operativo Tr = tempo per le riparazioni
affidabilità/ conformità	conformità per l’affidabilità	misura la conformità del prodotto/servizio a regolamenti, standard e convenzioni applicabili riguardo all’affidabilità	X = 1 – A/B A = Numero di elementi implementati conformi riguardo all’affidabilità B = Numero totale di elementi per cui è richiesta la conformità
usabilità/ comprensibilità	completezza della descrizione	Misura la percentuale di funzioni che risultano comprensibili dopo la lettura della descrizione del prodotto/servizio	X = A/B A = Numero di funzioni comprensibili B = Numero totale di funzioni
usabilità/ apprendibilità	facilità d’uso delle funzioni	Misura il tempo necessario per apprendere ad usare una funzione	T = tempo medio necessario per imparare ad utilizzare una funzione correttamente
usabilità/ operabilità	comprensibilità dei messaggi/ comunicazioni	misura il grado di comprensione dei messaggi/comunicazioni trasmessi in fase di utilizzo del prodotto/servizio	X = A/UOT A = numero di volte che l’utente deve ripetere la stessa operazione in quanto non è in grado di operare correttamente a fronte di un messaggio UOT = periodo di osservazione
usabilità/ attrattività	attrattività dell’interazione con il prodotto/ servizio	misura quanto l’utente valuta attraente l’interazione con il prodotto/servizio	Uso di questionari e metodi assegnazione del punteggio
usabilità/ conformità all’usabilità	conformità all’usabilità	misura la conformità del prodotto/servizio a regolamenti, standard e convenzioni applicabili riguardo all’usabilità	X = 1 – A/B A = Numero di elementi implementati conformi riguardo all’usabilità B = Numero totale di elementi per cui è richiesta la conformità

Metriche di misura della qualità – 3/4
CARATTERISTICA/ SOTTOCARATT.	NOME DELLA METRICA	DESCRIZIONE DELLA METRICA	MISURA, FORMULA E DATI ELEMENTARI
efficienza/ efficienza temporale	tempo di risposta	misura il tempo medio di attesa tra la formulazione di una richiesta e la sua completa evasione	X = Tmedio/TXmedio Tmedio = Â(Ti)/N, (per i=1 a N) TXmedio = tempo medio di risposta richiesto
efficienza/ utilizzazione delle risorse	per i prodotti sw si misura il grado di utilizzo di dispositivi di I/O, memoria, risorse di trasmissione per i servizi si misura il grado di competenza e di efficienza del personale impiegato	misura il numero di errori che si verificano in una unità di tempo simulando una condizione di massimo carico misura quanto l’utente valuta competente il personale preposto all’erogazione del servizio	X = A/T A = numero di messaggi di errore T = tempo di osservazione Uso di questionari e metodi assegnazione del punteggio per la valutazione della competenza delle risorse
efficienza/ conformità all’efficienza	conformità all’efficienza	misura la conformità del prodotto/servizio a regolamenti, standard e convenzioni applicabili riguardo all’efficienza	X = 1 – A/B A = Numero di elementi implementati conformi riguardo all’efficienza B = Numero totale di elementi per cui è richiesta la conformità
manutenibilità/ analizzabilità	supporto alla diagnosi	misura il grado di difficoltà nel diagnosticare malfunzionamenti	X = A/B A = Numero di malfunzionamenti che possono essere diagnosticate con il supporto delle funzioni di diagnosi B = numero totale di malfunzionamenti rilevati
manutenibilità/ modificabilità	efficienza del ciclo di modifica	misura il tempo medio necessario a rimuovere un malfunzionamento	Tempo medio: Tav = Somma (Tu)/N Tu = tempo intercorrente tra la richiesta di intervento ed il suo completamento N = numero di interventi richiesti
manutenibilità/ stabilità	stabilità a seguito di interventi	misura la percentuale di interventi di modifica che producono malfunzioni	X = Na/Ta Na = Numero di interventi che hanno prodotto malfunzioni Ta = Tempo di erogazione durante il periodo di osservazione successivo all’intervento
manutenibilità/ testabilità	efficienz per i test	misura il tempo necessario per verificare l’effettiva rimozione di un malfunzionamento	X = Somma(T)/N T = Tempo impiegate per assicurarsi l’effettiva risoluzione di un malfunzionamento N = numero di malfunzionamenti risolti
manutenibilità/ conformità alla manutenibilità	conformità alla manutenibilità	misura la conformità del prodotto/servizio a regolamenti, standard e convenzioni applicabili riguardo alla manutenibilità	X = 1 – A/B A = Numero di elementi implementati conformi riguardo alla manutenibilità B = Numero totale di elementi per cui è richiesta la conformità

Metriche di misura della qualità – 4/4
CARATTERISTICA/ SOTTOCARATT.	NOME DELLA METRICA	DESCRIZIONE DELLA METRICA	MISURA, FORMULA E DATI ELEMENTARI
portabilità/ adattabilità	facilità di porting del software	misura la facilità di adattare il software all’ambiente	T = Tempo speso dall’utente per adattare il software all’ambiente
portabilità/ installabilità	facilità di installazione	misura la facilità di installazione del software all’ambiente operativo	X = A/B A = Numero di casi in cui l’utente riesce a modificare le operazioni di installazione per esigenze specifiche B = Numero totale di casi in cui l’utente tenta di modificare le operazioni di installazione
portabilità/ coesistenza	Utilizzo concorrente con altri sistemi	misura il numero di malfunzioni nell’unità di tempo dovuti ad utilizzo concorrente con altri sistemi	X = A/T A = numero di malfunzioni nel periodo T T = periodo di utilizzo in concorrenza con altri sistemi
portabilità/ sostituibilità	continuità nell’uso dei dati	misura la quantità di dati che è possibile usare passando dal precedente software senza effettuare interventi	X = A/B A = numero di dati usati con il software da sostituire che possono essere usati senza interventi B = numero di dati usati con il software da sostituire che devono essere usati
portabilità/ conformità alla portabilità	conformità alla portabilità	misura la conformità del prodotto/servizio a regolamenti, standard e convenzioni applicabili riguardo alla portabilità	X = 1 – A/B A = Numero di elementi implementati conformi riguardo alla portabilità B = Numero totale di elementi per cui è richiesta la conformità
efficacia	efficacia del task	misura la percentuale di obiettivi del servizio/prodotto raggiunti nel suo utilizzo	M = 100-SAi Ai = percentuale di obiettivo raggiunto
produttività	produttività economica	misura il rapporto tra costo di utilizzo e riduzione del costo per la svolgimento dei compiti dell’utente	C = Cu/Cr Cu = costo di utilizzo in un periodo di tempo Cr = Risparmio economico nello svolgimento dei compiti dell’utente in periodo di tempo
salvaguardia	salute e sicurezza dell’utente	misura l’incidenza di problemi di salute sugli utenti	X = 1-A/B A = numero di utenti che presentano ripetuti sintomi di stanchezza, mal di testa, ecc. B = numero totale di utenti
soddisfazione/ empatia	Empatia	misura la percezione dell’utente riguardo alla disponibilità nel porre attenzione individuale al alle sue esigenze, di avere a cuore i suoi principali interessi, di dimostrare impegno nel risolvere i problemi, di informarlo su quando sarà erogata la prestazione	Uso di questionari e metodi assegnazione del punteggio
soddisfazione/ capacità di rassicurazione	capacità di rassicurazione	misura la percezione dell’utente capacità del personale di ispirare fiducia, di essere cortese, di trasmettere sicurezza nelle sue transazioni.	Uso di questionari e metodi assegnazione del punteggio

7. Modelli per la Gestione dei Contratti ICT

7.1 MODELLO ISO (UNI ISO 10006)

Le tematiche relative al complesso di attività inquadrate dalla dizione “Gestione dei pro- getti” non potevano non richiedere un’attenzione particolare da parte dell’International Organization for Standardization (ISO, Organizzazione Internazionale per la Standardizzazione), il global network dedicato da diversi decenni a recepire le necessità in fatto di standard in campo commerciale, sociale e della pubblica amministrazione di tutto il mondo, sviluppare gli standard stessi in compartecipazione con i settori che dovranno porli in atto, adottarli con procedure trasparenti basate su decisioni a livello nazionale e infine diffonderli per essere utilizzati estesamente a livello mondiale. In Italia, l’UNI (Ente Italiano per l’Unificazione) è l’organismo che si occupa di recepire e diffon- dere in campo nazionale gli standard emessi dall’ISO, curandone anche gli aspetti di adat- tamento e traduzione.

L’ISO attua la sua opera di standardizzazione tramite l’emissione di norme cogenti (il cui rispetto è considerato obbligatorio per la corretta certificazione delle attività coinvolte) o di linee guida per la facilitazione e la diffusione della cultura e delle buone pratiche pro- mosse dall’organizzazione.

Le norme sono generate dall’azione di singoli gruppi di lavoro (siglati WG, workgroup), dipendenti da specifici sottocomitati (SC) inclusi in più ampi comitati tecnici (TC, Technical Committee) nati per la gestione dei temi d’interesse. I comitati, sottocomitati e gruppi di lavoro sono identificati numericamente in ordine di nascita. La presenza di numeri bassi è evidentemente riferita a comitati che trattano argomenti perduranti nel tempo (d’ambito industriale soprattutto) e richiedenti continua attenzione. I numeri più alti sono relativi alle tematiche più recenti ed innovative, ad esempio l’ultimo TC nato, il 229, è dedicato alle “nanotecnologie”.

Per quanto riguarda il mondo ICT, se si prescinde dai singoli aspetti legati alla produ- zione industriale (ad es., il trattamento di materiali durante la produzione di hardware che comporta varie attenzioni normate) o di aspetti trasversali o correlati (ad es. la stan- dardizzazione delle informazioni relative alla salute, trattate dallo specifico comitato TC215 o quelle relative alle applicazioni di gestione documentale, trattate dal comitato TC171), il complesso delle attività ISO che producono documentazione d’interesse per chi opera in tale campo si può considerare legato fondamentalmente al lavoro di due comitati:

• il primo e più specifico, è il JTC1, intitolato “Information Technology”, un comitato nato nel 1987 e che deve la sua sigla all’essere attualmente il primo e unico Joint

Technical Committée ISO/IEC, cioè un comitato tecnico congiunto tra ISO e IEC (International Electrotechnical Commission), la commissione internazionale che emana norme a livello mondiale nel campo elettrotecnico ed elettronico. Il comitato ha lo scopo specifico di sviluppare e promuovere la standardizzazione nelle discipline dell’Information Technology, utilizzando pariteticamente le esperienze messe a dispo- sizione da entrambe le suddette organizzazioni. Informazioni dettagliate sulle sue atti- vità si possono trovare all’indirizzo Internet xxx.xxx0.xxx.;

• il secondo (non per importanza), di carattere più generale, è il TC176, intitolato “Quality Management and Quality Assurance” (Gestione per la Qualità ed Assicurazione della Qualità), responsabile della serie di standard ISO 9000, una fami- glia di norme alla base dei Sistemi per la Gestione della Qualità e quindi dell’orga- nizzazione generale delle aziende, private o pubbliche, che promuovono una politi- ca principalmente mirata a dare visibilità ai loro clienti od utenti circa i prodotti ed i servizi forniti dalle stesse. Il comitato ha già prodotto tre principali edizioni di tali norme, nel 1987, 1994 e 2000, rispettivamente. L’ultimo corpus di norme è stato com- plessivamente definito “Vision 2000” per l’importante cambio di prospettiva offerta, riorganizzando la materie secondo principi di Total Quality Management. Il comita- to opera in connessione alle attività del TC205 (“Gestione Ambientale”, generatore della famiglia di norme 14001) per uno sviluppo coerente delle due famiglie di norme. Informazioni dettagliate sulle sue attività si possono trovare all’indirizzo Internet xxx.xx000.xxx.

Riguardo l’argomento trattato nel presente manuale i riferimenti più importanti si trovano nell’operato del secondo comitato citato, il TC176, e ciò sostanzialmente per ragioni di generalità dell’argomento analoghe ai motivi con cui lo stesso è incluso nel modello di riferimento utilizzato dalla presente documentazione, mutuato dalla norma ISO 12207 e descritto in precedenza: le attività concernenti la gestione di un progetto e rivolte ad assi- curarne il buon andamento non sono dipendenti essenzialmente dalla natura dello speci- fico progetto ma sono bensì di carattere assolutamente generale e pertanto comuni e tra- sversali a tutte le possibili classi di forniture.

In tal senso sono stati definiti processi trasversali i processi che “sono utilizzati e svolti come parte integrante di altri processi e contribuiscono ad assicurare il successo e la qua- lità del progetto nel suo complesso riguardando la pianificazione e il controllo del pro- getto, nonché la gestione delle risorse umane e materiali necessarie per la conduzione delle attività contrattuali” (cfr § 5.2). Ricordiamo che i quattro processi trasversali classifi- cati sono: Gestione, Gestione della Documentazione, Gestione della Configurazione, Assicurazione Qualità. Il primo, inteso qui nel senso stretto della Gestione del Progetto è il più strettamente attinente a quanto di seguito trattato e fortemente correlato all’ultimo (Assicurazione Qualità), soprattutto nella lettura ISO.

7.1.1 LA NORMA UNI ISO 10006

La norma specifica emessa dall’ISO riguardo la gestione dei progetti s’intitola “Linee guida per la gestione della qualità nei progetti” e la sua ultima versione è stata emessa dall’ISO nel giugno 2003, recepita dall’UNI e pubblicata in lingua italiana nel gennaio 2005. La prima edizione italiana della norma è anteriore ed è stata emessa nel 1999, a complemen-

to della prima importante revisione delle norme sui Sistemi Qualità culminata nelle rela- tive norme emesse nel 1994 (ISO 9001 e altre connesse).

L’ascrizione del compito della sua redazione al gruppo di lavoro TC 176 testimonia dunque:

• un’ottica di generalizzazione delle attività cardine per l’assolvimento del compito pro- gettuale, qualsiasi sia la natura del progetto e degli oggetti da esso trattati.

• l’inquadramento dell’argomento nell’ambito più strutturato dei Sistemi di gestione per la qualità.

Ciò comporta innanzitutto, come ricordato nell’introduzione alla norma, “che essa sia appli- cabile a diverse tipologie di progetti, da quelli piccoli a quelli molto articolati, da quelli sem- plici a quelli complessi” e per lo stesso motivo può risultare per certi versi troppo dettaglia- ta, per altri contenente quanto effettivamente necessario alle esigenze dei lettori.

Inoltre la norma pone come presupposto l’esecuzione dei processi legati alla gestione del progetto nel quadro di un Sistema di Gestione per la Qualità. Pertanto le attività sono inquadrate nell’operato di un Sistema di Gestione per la Qualità del progetto, direttamen- te emanato dall’organizzazione che ha costituito il gruppo di progetto e per quanto pos- sibile allineato col sistema di gestione della qualità della stessa.

In particolare l’ultima revisione della norma UNI ISO 10006, quella appunto del 2005, è stata effettuata proprio con lo scopo di renderla coerente con l’attuale versione della norma ISO relativa ai sistemi qualità, nota come “Vision 2000”.

7.1.2 SCOPO E CAMPO DI APPLICAZIONE

Lo scopo dichiarato della norma è quello di fornire “una guida relativa all’applicazio- ne della gestione per la qualità nei progetti”, indipendentemente dalla loro dimensio- ne, complessità, durata e obiettivi. La sua impostazione generale può comportare la necessità di qualche adattamento per tener conto di particolari progetti, per stessa ammissione della norma. Nel caso presente bisogna quindi aver cura di calibrare quan- to indicato dalla norma rispetto al mondo ICT ed alla propria attività progettuale in par- ticolare.

In realtà, già le norme della famiglia ISO 9000, ovvero Vision 2000, nel descrivere come l’organizzazione attua propriamente i suoi processi di produzione orientati al soddisfaci- mento del cliente e delle altre parti interessate, necessariamente trattano argomenti riguar- danti anche la gestione progettuale, fornendo indicazioni in merito. Tali indicazioni sono comunque relative ai processi di realizzazione del prodotto nell’ambito del progetto. La norma UNI ISO 10006 vuole, in questo quadro, essere considerata solo un’integrazione a tali informazioni e quindi “un supplemento alla guida riportata nella ISO 9004”, per quan- to riguarda l’efficacia operativa mentre per gli orientamenti di carattere generale il riferi- mento rimane la norma ISO 9000:2000.

Più esplicitamente, nel definire il proprio campo d’applicazione, la norma UNI ISO 10006 specifica che essa “non costituisce da sola una guida per la “gestione del progetto”, ma fornisce consigli per la qualità nei processi di gestione del progetto. La guida per la qua- lità nei processi relativi al prodotto del progetto, e per l’approccio per processi, è fornita dalla norma UNI ISO 9004:2000 “Sistemi di gestione per la qualità – Linee guida per il miglioramento delle prestazioni”.

In conclusione:

• la norma UNI ISO 10006:2005 ha carattere di guida e quindi non è utilizzabile per scopi di certificazione;

• dev’essere considerata complementare alla ISO 9004 e quindi le due norme dovrebbe- ro essere utilizzate congiuntamente;

• la norma UNI ISO 10006 tratta specificatamente i “processi di gestione del proget- to” mentre nella norma UNI ISO 9004 sono trattati i “processi di realizzazione del prodotto”.

L’ultimo punto chiarisce evidentemente la collocazione del presente capitolo nella manua- listica predisposta dal CNIPA e specifica meglio l’oggetto della norma in questione, la quale riguarda processi generali e trasversali di controllo, come già detto, mentre, volen- do considerare le raccomandazioni ISO riguardo le modalità generali di esecuzione delle attività di produzione, bisognerebbe correlare i relativi paragrafi della norma UNI ISO 9004 (in particolare quelli del cap. 7, “Realizzazione del prodotto”) con le specifiche atti- vità relative all’oggetto di fornitura trattate nelle varie classi di fornitura descritte all’inter- no del Manuale 4 – Dizionario delle forniture ICT.

7.1.3 STRUTTURA DELLA NORMA

La norma è articolata secondo la struttura comune agli standard della famiglia Vision 2000 con l’indice riportato di seguito:

	INTRODUZIONE
1	SCOPO E CAMPO DI APPLICAZIONE
2	RIFERIMENTI NORMATIVI
3	TERMINI E DEFINIZIONI
4	SISTEMI DI GESTIONE PER LA QUALITÀ NEI PROGETTI
5	RESPONSABILITÀ DELLA DIREZIONE
6	GESTIONE DELLE RISORSE
7	REALIZZAZIONE DEL PRODOTTO
8	MISURAZIONE, ANALISI E MIGLIORAMENTO
Appendice A	SCHEMA DI FLUSSO DEI PROCESSI NEI PROGETTI
	BIBLIOGRAFIA

con preciso riferimento al Modello di sistema di gestione per la qualità basato sui proces- si, la cui descrizione è contenuta nella norma UNI ISO 9000:2000 (v. par. 2.4) e al quale fa riferimento la figura successiva.

Nota: Il testo indicato tra parentesi non si applica alla ISO 9001. Fonte: UNI EN ISO 9000:2000

Il modello, notoriamente, sviluppa un circolo virtuoso di tipo Plan-Do-Check-Act (richia- mato esplicitamente nella norma 10006 al par. 5.2.7) costituito essenzialmente dalle attivi- tà descritte nei capitoli dal 5 all’8: Responsabilità della Direzione, Gestione delle risorse, Realizzazione del prodotto, Misurazione, analisi e miglioramento. Tra queste possiamo considerare il primo e ultimo raggruppamento come maggiormente relativi al metodo e all’organizzazione orientate al miglioramento, quindi più affini ad argomenti trattati nel- l’ambito del processo trasversale “Assicurazione della qualità” nel corpo dei manuali CNIPA mentre i due raggruppamenti centrali (“Gestione delle risorse” e “Realizzazione del prodotto”) sono quelli più peculiari alle attività di Project management.

7.1.4 CONTENUTO DELLA NORMA

Le parti introduttive della norma (fino al capitolo 3), Introduzione, Scopo, Riferimenti e Termini sono in pratica sintetizzate da quanto già detto nell’introduzione al presente capi- tolo e comportano, ovviamente un continuo riferimento alla norma ISO 9000 e 9004 del 2000. Da sottolineare, tra le poche definizioni aggiunte al glossario base, l’importante rife- rimento al “Piano di gestione del progetto” che diventa un documento cardine del pro- cesso e che specifica “tutto ciò che occorre per conseguire gli obiettivi del progetto”. Nel termine tutto è implicato, evidenziato anche da opportune note, che tale documento dev’essere il riferimento di base per la gestione del progetto. Pertanto in esso devono essere ricompresi (se la bassa complessità del progetto lo rende possibile) oppure riferiti tutti gli altri piani che devono necessariamente comunque sussistere per consentire un

corretto controllo del progetto: primo fra tutti il Piano della qualità (per la cui stesura esi- ste una specifica guida, la UNI ISO 10005:1996) ma senza dimenticare la necessità di un Piano di gestione della configurazione (anche per il quale esiste una specifica norma ISO a supporto, la UNI ISO 10007:1997), l’opportunità di un Piano di gestione dei rischi, un eventuale Piano di allocazione risorse (specie nel caso di progetti di costituzione di ser- vizi permanenti) o i possibili altri documenti utili all’efficace gestione del progetto.

Il capitolo 4 “Sistemi di gestione per la qualità nei progetti” chiarisce cosa s’intende per progetto, processi del progetto e sistema di gestione della qualità del progetto. In questo senso è di fondamentale introduzione alle parti successive, soprattutto per i seguenti punti:

• Distinzione tra “organizzazione madre” e “organizzazione incaricata del progetto”, essendo la prima quella che decide di intraprendere il progetto e la seconda quel- la cui è assegnato il compito di portarlo a compimento. La distinzione tra le due organizzazioni implica che la seconda, per quanto autonoma, possa essere parte dell’organizzazione madre stessa ma solo come una delle varie possibilità. In realtà non c’è alcuna restrizione alle configurazioni possibili: l’organizzazione madre può essere unica oppure un consorzio o altro tipo d’associazione e lo stesso potrebbe essere per l’organizzazione incaricata del progetto, quest’ultima potrebbe anche essere una specifica azienda inclusa nel consorzio dell’organizzazione madre o sem- plicemente un suo ufficio tecnico. Inoltre molteplici organizzazioni di progetto pos- sono essere incaricate da un’unica organizzazione madre. I vincoli da considerare sono solo relativi all’approccio metodologico che richiede obiettivi, metodi e deci- sioni coerenti tra organizzazione madre e organizzazioni di progetto e allineati ai principi generali di gestione della qualità, ispiratori della norma (v. 4.2.1).

• Definizione dei sistemi di qualità da considerare ed in particolare la necessità di costituzione di un Sistema di gestione della qualità del progetto possibilmente alli- neato al preesistente Sistema di gestione della qualità presente nell’organizzazione madre. A concretizzazione di ciò, il Sistema di gestione della qualità costituito dovrebbe essere descritto all’interno del Piano di qualità del progetto, a sua volta contenuto o riferito dal Piano di gestione del progetto.

• Definizione dei processi inerenti la gestione del progetto. La prima distinzione svol- ta è tra processi di gestione del progetto e processi di realizzazione del prodotto. Il documento tratta i primi lasciando i secondi a quanto contenuto nel cap. 7 delle linee guida UNI ISO 9004 e presenta una suddivisione in undici gruppi dei processi prin- cipali di gestione. L’appendice A riporta una struttura più articolata, definita “Schema di flusso dei processi nei progetti”, in realtà più una decomposizione strutturale dei gruppi di processi indicati, di cui solo l’ultimo livello ha parziale significato di flusso potendo attribuirsi in diversi casi (ma non sempre) caratteristiche di dipendenza e consecutività tra le attività elencate nella descrizione del processo. Costituisce comunque un ottima mappa riassuntiva dell’argomento trattato dalla norma.

• Per maggiore chiarezza riportiamo di seguito, preceduti dai nomi dei paragrafi rela- tivi, gli undici raggruppamenti di processi considerati dalla norma:

5.2 – Processo strategico

6.1 – Processi relativi alle risorse

6.2 – Processi relativi al personale

7.2 – Processi relativi alle interdipendenze

7.3 – Processi relativi allo scopo

7.4 – Processi relativi ai tempi

7.5 – Processi relativi ai costi

7.6 – Processi relativi alle comunicazioni

7.7 – Processi relativi ai rischi

7.8 – Processi relativi agli acquisti

8 – Misurazione, analisi e miglioramento

Il capitolo 5 “Responsabilità della Direzione” non si limita, come ruolo classico del capi- tolo negli analoghi documenti ISO, a richiamare l’attenzione sul coinvolgimento dell’alta direzione delle organizzazioni coinvolte (quella madre e quella di progetto) come impe- gno di sostegno e orientamento strategico del progetto nonché riesame periodico per assi- curare appropriatezza al sistema di qualità del progetto. Contiene in realtà una sintetica ma completa guida generale alla gestione della qualità, costruita sulla base degli otto prin- cipi utilizzati come riferimento dalla Vision 2000 nell’ottica del miglioramento continuo. Nella visione dei redattori della norma tale indicazioni dovrebbero fornire un complemen- to di supporto alle indicazioni più specifiche contenute nei capitoli seguenti e quindi esse- re di orientamento per tutti casi in cui non si ritrovassero esplicitamente in tali capitoli le indicazioni necessarie alla gestione delle attività.

In tale capitolo compare più esplicitamente il ruolo di guida e memoria dell’organizzazio- ne madre: la sua importanza non è infatti solo nell’essere l’originatrice dei compiti pro- gettuali e nell’aver fissato precisi obiettivi per gli stessi ed avere eventualmente fornito il sistema di qualità di riferimento da utilizzarsi per perseguirli ma anche nel recepire tutto quanto ottenuto in esito alle varie fasi del progetto, anche dal punto di vista delle proble- matiche intervenute, e farne base per il miglioramento o una più efficace predisposizio- ne di attività successive dello stesso o di altri progetti. Soprattutto in quest’ultimo caso il compito dell’organizzazione madre è considerato determinante: l’organizzazione di pro- getto è pur sempre un’organizzazione a termine e quindi tutto quanto il progetto può aver fornito di informazioni significative sul suo andamento e sul suo esito per poter essere riutilizzato deve essere analizzato, memorizzato e riutilizzato coerentemente da un’altra organizzazione, appunto quella madre del progetto, cui l’organizzazione di progetto inca- ricata dell’esecuzione deve trasferire tali informazioni.

Questo il motivo per cui il ruolo attivo dell’organizzazione madre è richiamato in questo capitolo e soprattutto nell’ultimo (cap. 8 “Misurazione, analisi e miglioramento”), proprio in relazione all’importante compito di “memoria storica di progetto” che consente di perpetua- re l’attività ciclica di miglioramento continuo, mentre la stessa è citata solo come recettore di informazioni o modello di riferimento nei capitoli 6 e 7, più precipuamente operativi.

Il capitolo 6 “Gestione delle risorse” insieme al successivo cap. 7 “Realizzazione del pro- dotto” sono il nucleo della norma per quanto riguarda le indicazioni date specificatamen- te all’organizzazione di progetto su come eseguire le attività vitali per il controllo del buon andamento del progetto. In particolare il capitolo 6 si occupa della gestione di tutte le risorse necessarie al progetto, trattandole dapprima in modo complessivo (par. 6.1) com- prendendo sia le risorse umane che tutte le risorse materiali, finanziarie, informative etc. di cui è necessario prevedere la disponibilità nel corso del progetto. Le raccomandazioni

contenute in tale parte riguardano quindi gli aspetti quantitativi (numero, peso, copie, tipologie etc.) delle risorse necessarie e la loro pianificazione temporale (quando le sud- dette quantità o parti di esse dovranno essere disponibili al progetto), includendo le dovu- te attenzioni ai vincoli che possono sussistere sia fisici (logistici ad esempio: dove esse saranno rese disponibili e dove dovranno essere invece allocate) che legali, amministra- tivi etc. (ad esempio accordi sindacali nel caso di risorse umane, licenze o diritti di pro- prietà nel caso di utilizzo di elementi coperti da brevetto etc.). Non trascurabile è ovvia- mente anche l’attenzione dinamica all’utilizzo delle risorse nel tempo, al loro possibile eccesso o carenza e la revisione dei piani di utilizzo al proposito, quella che complessi- vamente viene definita “tenuta sotto controllo delle risorse”.

La seconda parte del capitolo è invece dedicata alla gestione qualitativa della risorsa più importante nel quadro di riferimento metodologico della norma: il personale. L’argomento è trattato tramite i tre processi relativi al personale in cui è scomposto l’argomento:

• la definizione della struttura organizzativa del progetto

• l’assegnazione del personale

• lo sviluppo del gruppo.

I tre processi rendono dunque conto della corretta costituzione del gruppo di lavoro con appropriata definizione dei ruoli e responsabilità relative, in cui ha importanza non tra- scurabile la definizione delle modalità di interfacciamento verso i clienti e le altre parti interessate, prima fra tutte l’organizzazione madre. Considerano poi l’importanza della selezione del personale in rapporto alle specifiche competenze necessarie per lo svolgi- mento del compito, la partecipazione alla selezione da parte del capoprogetto e non ulti- ma, la comprensione delle mansioni assegnate e la motivazione alle stesse del personale selezionato.

In ultimo ma significativo, lo spazio dedicato allo sviluppo del gruppo, sia nel senso delle competenze che della sensibilità e della partecipazione condivisa agli obiettivi del proget- to, in un’ottica di miglioramento continuo, in questo caso applicata alla gestione delle risorse umane.

Il capitolo 7 “Realizzazione del prodotto” comprende la parte più sostanziale e in diretto rap- porto con l’attività corrente di gestione del progetto, ripartita in sette famiglie di processi:

• interdipendenze;

• scopo;

• tempi;

• costi;

• comunicazioni;

• rischi;

• acquisti;

di cui è di per sé evidente la significatività nell’ambito della gestione di progetto. Ricordando che il progetto è visto come un processo esso stesso, costituito da una rete di attività coordinate e tenute sotto controllo (v. definizione in 3.5) si comprende perché la prima classe di processi trattati, quella relativa alle interdipendenze, sia da considerare

con particolare attenzione. In essa sono infatti raccolte tutte le raccomandazioni relative alle azioni di collegamento, connessione, motivazione, revisione delle varie attività che compongono il progetto, la cui struttura portante è indirizzata dal Piano di gestione del progetto che in questo capitolo è dettagliatamente descritto (v. 7.2.2) rispetto ai requisiti che dovrebbe assolvere in quanto a funzioni e a contenuti da considerare, direttamente dettagliati o indirettamente attraverso altri piani da esso riferiti. Da notare che il Piano è connotato prima come azione che come documento: per piano s’intende soprattutto quanto da esso previsto più che semplicemente documentato, ad esempio l’importanza di prevedere delle misurazioni che consentano di monitorare l’avanzamento del progetto oppure revisioni regolari che assicurino il rispetto dei requisiti contrattuali durante il per- seguimento degli obiettivi. Il documento “Piano di gestione del progetto diventa quindi solo la testimonianza formale della volontà e dell’esecuzione effettiva di tali azioni.

Ovviamente, nel carattere della norma, non è mai citato il ‘come’ dovrebbero essere rispettati i requisiti indicati ma è solo sollevata l’attenzione su cosa dovrebbe essere tenu- to sotto controllo per il buon esito dell’attività.

Il gruppo di processi relativi allo scopo sottintende soprattutto all’attenzione ai requisiti da soddisfare verso il cliente e tutte le altre parti interessate che orientano lo scopo del progetto e ne possono guidare anche la strutturazione tramite attività di decomposizione, ad esempio tramite la tecnica della WBS (work breakdown structure). Come tormentone comune a tutte le norme recenti anche qui appare giustamente la raccomandazione che ogni attività dovrebbe essere definita in modo che i suoi risultati siano misurabili.

Analogamente sono sviluppati gli altri argomenti specifici (tempi, costi, etc.) tra cui è da sottolineare l’importanza del gruppo di processi dedicato alle comunicazioni, soprattutto per quanto riguarda quelle in cui i risultati e l’esperienza accumulata nel progetto (anche riguardo le criticità, le innovazioni, le tecniche adottate etc.) sono comunicate all’organiz- zazione madre. Tale attività, in parte coinvolgente anche i clienti e i fornitori, è quella che, come si è detto, consente di accumulare memoria storica del progetto riutilizzabile anche in altre future situazioni progettuali per una loro più efficace ed efficiente esecuzione, determinando quindi il valore aggiunto del progetto stesso.

Nel capitolo 8 “Miglioramento continuo”, infine, tutto quanto eseguito, monitorato e docu- mentato nel progetto è riutilizzato per evolvere l’esecuzione dello stesso. In tale occasione interviene dunque nuovamente in modo preponderante l’organizzazione madre che, avendo il ruolo di gestire l’informazione storica relativa ai progetti realizzati, consente di fornire al progetto in corso tutte le informazioni tecniche, statistiche, di confronto o d’altro genere che possono essere utili per migliorarne l’esecuzione facendo tesoro delle precedenti esperienze analoghe, memorizzate opportunamente dall’organizzazione madre. Il sistema di gestione del progetto dovrà ovviamente contribuire a tale raccolta organizzando al meglio la propria gestione delle informazioni per consentire il trasferimento all’organizzazione madre e questa dovrà assicurarsi, anche tramite specifici momenti di verifica (ad es. alla chiusura del proget- to), di eseguire un riesame che consenta di appurare quanto dell’esperienza del progetto può essere salvaguardato e documentato per essere riutilizzato in progetti futuri.

7.1.5 APPLICAZIONE NELL’AMBITO PUBBLICO

La lettura della norma ISO può ovviamente essere effettuata in relazione al diretto inte- resse verso le caratteristiche di processo che possono influenzare l’esecuzione di un pro-

xxxxx e la qualità dei suoi risultati da parte di quegli enti pubblici che hanno le strutture adatte a porre in esecuzione direttamente i progetti. Non essendo però questa, in gene- re, la situazione delle organizzazioni pubbliche, l’interesse potrà più generalmente essere concentrato sulla lettura delle implicazioni riguardo i compiti e le responsabilità esigibili distintamente dall’organizzazione che assegna l’esecuzione dei progetti e da quelle depu- tate a realizzarli effettivamente.

La distinzione tra organizzazione madre e incaricata del progetto compiuta dalla norma può infatti render conto anche della condivisione di un progetto tra ente appaltante che decide l’esecuzione del progetto, ne definisce gli obiettivi e ne è quindi in qualche modo ‘proprietario’ (v. “Termini e definizioni”, par. 3.2) e l’appaltatore chiamato ad eseguirlo. Con ciò si giustifica pienamente la richiesta dell’ente pubblico appaltante di soddisfare determinati requisiti nella costruzione del Piano di progetto (di fatto il Piano di gestione del progetto della norma) come anche del Piano di qualità, meglio ancora se proponen- done esso stesso gli schemi di base, perché in tal modo richiede più o meno implicita- mente un allineamento al proprio sistema di gestione (della qualità, se tale, o comunque all’organizzazione prevista al proprio interno come congrua al soddisfacimento dei com- piti progettuali).

L’organizzazione madre, indicata come tale nella norma, ha dunque necessariamente una doppia chiave di lettura nell’ambito della P.A.:

• da una parte è l’organizzazione che emana direttamente la struttura di progetto. In tal senso può essere vista come l’azienda, l’organizzazione appaltatrice, anche com- plessa, di un contratto per l’esecuzione di uno o più progetti. In tal caso essa si fa garante prima della qualità dell’esecuzione e del sistema di qualità utilizzato (se requisito contrattuale) nonché portatrice di quell’esperienza sull’argomento che, tra l’altro, le avrà consentito di essere scelta. In tal senso essa potrebbe gestire corret- tamente l’insieme dei suoi progetti secondo quanto descritto dalla norma ma, salvo attività ispettive di parte seconda svolte dal committente, ciò rimarrebbe alquanto invisibile alla Pubblica Amministrazione appaltante che continuerebbe a vedere solo i prodotti rilasciati dalle specifiche organizzazioni di progetto definite.

• dall’altra, soprattutto nella lettura dell’organizzazione madre come proprietaria del progetto da parte della norma, è opportuno e utile visualizzare anche la stessa pub- blica amministrazione appaltante come organizzazione madre e leggere quindi in tal senso molte delle raccomandazioni riportate nella norma che possono essere con- densate in quanto segue:

• allineamento delle modalità di gestione della qualità dell’organizzazione di pro- getto a quanto preesistente nell’organizzazione madre. Nel caso dei Sistemi di Gestione della Qualità ciò ha un esplicito significato di correlazione e congruen- za tra le procedure dei due Sistemi. In loro assenza, tale allineamento corrispon- de, al minimo, alla determinazione da parte dell’Amministrazione delle caratte- ristiche organizzative e procedurali e della garanzia di qualità, ovvero il suo livello, che essa s’aspetta da parte dell’organizzazione del fornitore. Quindi, in sostanza, nell’assicurazione della qualità che deve scaturire da quanto da questi predisposto, soprattutto nel Piano della Qualità. Un’Amministrazione che aves- se già una sua proposta di Piano di Progetto (nel senso ampio previsto dalla

xxxxx) come anche di Piano della Qualità, cui i fornitori di progetti debbano aderire, avrebbe quindi una chiave più forte di garanzia nell’esecuzione dei pro- pri progetti.

• Memorizzazione di tutte le informazioni utili provenienti dai progetti eseguiti, relativamente a tempi, costi, rischi, metodi etc. per l’utilizzo in progetti ulteriori. Il possesso, la gestione e l’aggiornamento di tali informazioni (in forma minima, tramite database locali, fino a quella più ampia, tramite strutturazione di reposi- tory di informazioni costituiti da Data Mart o Datawarehouse ad accesso via Web) e la loro eventuale rielaborazione avanzata (tramite strumenti di Business Intelligence, ad esempio) possono costituire un capitale significativo per ogni amministrazione consentendole di:

• stimare più opportunamente le caratteristiche e il grado di successo possibile per le future iniziative,

• individuare più facilmente le tipologie di aziende fornitrici più adatte alla loro esecuzione (ovvero i requisiti di gara relativi).

Ciò è possibile a patto di abituali, precise e chiare modalità di comunicazio- ne e trasferimento delle informazioni intercettate dall’organizzazione proget- tuale verso l’Amministrazione, possibilmente in forme tecnologicamente avan- zate (inserimento automatizzato delle informazioni nel repository) e non pura- mente documentali.

• Trasferimento delle informazioni storiche in possesso dell’amministrazione relative ad una classe di progetti (per la parte ritenuta congrua) all’organiz- zazione di progetto di volta in volta chiamata ad operare in merito, accele- rando la sua comprensione dell’argomento e dei requisiti inerenti, evitando equivoci sugli oggetti e gli scopi e consentendo comunque un trasferimento di best practices o anche riuso di elementi esistenti, a tutto vantaggio dei tempi e costi del progetto e soprattutto del raggiungimento efficace dell’o- biettivo previsto.

Probabilmente questa è la chiave più significativa in cui dovrebbe essere letto il documen- to ISO da parte della Pubblica Amministrazione ma non trascurabile è, anche in conse- guenza a questa lettura, il suo utilizzo per poter individuare puntualmente, processo per processo, quali siano le aree coperte più o meno correttamente dalle attività di progetto previste o in corso (in quanto ad azioni e documentazione predisposta) e quindi utilizzar- ne i contenuti per richiedere al fornitore la presentazione di evidenze che consentano di comprendere quali mezzi e metodi intende mettere in atto per garantire la qualità di ese- cuzione della fornitura progettuale.

L’utilizzo non è comunque solo ex ante, in fase di redazione della documentazione di gara ma anche in corso d’opera per determinare quali controlli potrebbero essere utili ad evi- denziare criticità o necessità di revisione delle attività.

Infine la norma potrebbe essere utilizzata dall’amministrazione stessa nell’ottica di guida- re una propria organizzazione della Politica per la Qualità relativamente alla gestione dei progetti, supportando la definizione al proprio interno dei ruoli e delle attività di gestio- ne e controllo necessarie per una sua migliore espressione, indipendemente o meno da obiettivi di certificazione di un Sistema Qualità nel rispetto della normativa ISO.

7.2 MODELLO PMI (PM BOK 2004)

Il PMI è un’associazione senza scopo di lucro fondata nel 1969 a Philadelphia in Pennsylvania con oltre 207.000 membri appartenenti a 150 paesi ed è la maggiore auto- xxxx mondiale nell’ambito della professione della gestione dei progetti (project manage- ment).

Il PMI stabilisce gli standard industriali, conduce ricerche e si occupa della formazione e della certificazione professionale.

I membri del PMI godono di una serie di vantaggi quali l’accesso ad alcuni servizi loro riservati nonché la possibilità di usufruire di sconti su prodotti e servizi. Ad esempio, rice- vono la versione aggiornata del PMBOK, la guida al Project Management Body of Knowledge, il più noto studio pubblicato dal PMI considerato, a livello internazionale, come il principale schema di riferimento per la gestione dei progetti. Con cadenze men- sili o trimestrali tutti i membri ricevono pubblicazioni, alcune delle quali disponibili sul sito web ufficiale del PMI xxx.xxx.xxx nell’area a loro riservata. Tali pubblicazioni trat- tano diverse tematiche riguardanti informazioni e aggiornamenti sia sull’Istituto che sulla professione del ‘project management’.

Nel corso degli anni i membri PMI hanno lavorato per cercare di standardizzare e divul- gare tecniche e procedure utili per la gestione dei progetti. Ciò ha portato, nel 2004 , alla pubblicazione della terza versione del PMBOK, il cui argomento è trattato in un paragra- fo successivo.

I membri possono mettersi in contatto con i diversi tipi di organizzazione in cui si artico- la il PMI; le principali sono:

• i ‘Chapter’ che sono sezioni locali presenti in molti paesi con il fine di promuovere missioni e obiettivi del PMI;

• i ‘SIG’ (Specific Interests Groups) che sono gruppi di interesse specifico distinti a seconda della tipologia di azienda o di interesse; si occupano di definire standard da adottare, di pubblicare linee guida e sviluppare documenti tecnici;

• i ‘College’ che sono composti da membri PMI che hanno sviluppato l’approccio for- male ad una o più aree di conoscenza presenti nel PMBOK che continuano ad aggiornare.

Ogni anno vengono organizzati a livello internazionale congressi e seminari. In Italia il PMI è presente con tre sezioni:

• Northern Italy Chapter;

• Rome-Chapter;

• Southern Italy Chapter.

I membri beneficiano quindi di un continuo supporto al loro sviluppo professionale che i Chapter forniscono attraverso l’organizzazione di attività, meeting e programmi di for- mazione.

Il PMI Northern Italy Chapter (NIC), fondato nel 1996 da membri provenienti dal mondo aziendale, accademico e professionale si è da subito caratterizzato come un punto di

aggregazione aperto in cui confluiscono esperienze e competenze differenziate per area geografica, settore, azienda: industria farmaceutica, information technology, formazione e consulenza, grande distribuzione, industria meccanica ed automobilistica, costruzioni ed impiantistica, settore pubblico, telecomunicazioni ed altre ancora. Ha la sede principale a Milano ma opera in tutta l’Italia settentrionale e centrale con presenze molto significative nel Nordest ed a Torino.

Il PMI Rome Chapter, fu fondato nel 1997 da un team di capi progetto di diverse compa- gnie di un importante gruppo industriale italiano operanti sia sul territorio nazionale che all’estero in vari industrie. È aperto a chiunque si interessi di gestione di progetti, qualun- que sia l’ambito in cui opera.

Il PMI Southern Italy Chapter (SIC) è stato fondato nel 2004, dopo 35 anni dalla fonda- zione del PMI, da un gruppo di professionisti, consulenti e manager d’impresa. Ha sede a Napoli e la sua competenza si estende a tutto il sud Italia, isole comprese.

Nei tre siti internet, relativi ai tre Chapter, si possono trovare informazioni relative a: iniziative volte a promuovere il PM;

• cosa fare per certificarsi;

• cosa fare per associarsi;

• meeting e programmi di formazione.

7.2.1 IL PMBOK

Per comprendere l’importanza e la necessità della gestione dei progetti è necessario capi- re la complessità che caratterizza tale attività. Si prenda in considerazione una delle possi- bili definizione di ‘progetto’: per progetto si intende un insieme di attività necessarie a raggiungere un risultato definito, unico, tramite l’impiego di risorse e capitali, entro un tempo prestabilito, con costi definiti e con un predeterminato livello di qualità. Come si può notare, la difficoltà di gestire e portare a compimento un progetto di successo è insita nella definizione stessa. Si parla infatti di un prodotto o un servizio ‘unico’ e quindi mai realizzato in precedenza; di vincoli forti: a priori occorre stabilire costi, tempi, qualità da rispettare, risorse necessarie (qualità e quantità, competenze,...).

Emerge quindi l’esigenza che il capo progetto metta in campo non solo la conoscenza e l’esperienza personale acquisita nel settore in cui si trova ad operare, qualità che certa- mente aiutano, ma soprattutto l’adozione di pratiche consolidate e riconosciute valide, quelle che la terminologia inglese definisce ‘best practices’.

La guida al Project Management Body of Knowledge costituisce il testo di riferimento che comprende l’insieme delle conoscenze relative alla gestione dei progetti. In esso sono identificate e descritte le conoscenze e le pratiche universalmente riconosciute ossia appli- cabili nella maggior parte dei progetti. La guida definisce i processi e gli strumenti fina- lizzati alla possibilità di realizzare con successo un progetto.

In più di trent’anni di attività organizzata dal PMI, i vari gruppi di lavoro coinvolti hanno cercato di produrre una guida sempre più sistematica e organizzata cercando di affinare i concetti trattati, di recepire le osservazioni dei revisori, di aggiungere documentazione di pratiche e tecniche e strumenti riconosciuti validi, di usare un linguaggio quanto più

possibile chiaro e facilmente traducibile. Si fa presente che esiste la versione italiana della guida.

Struttura del PMBOK

In questo paragrafo viene illustrata la struttura della ‘Guida al PMBOK’ , versione 3, pub- blicata nel 2004.

Il documento è suddiviso in tre sezioni:

1. la prima descrive il ‘contesto del Project Management’ enfatizzando il ciclo di vita del progetto e la struttura organizzativa;

2. la seconda definisce lo ‘standard per il Project Management di un progetto’ sulla base di cinque gruppi di processi;

3. la terza illustra le nove aree di conoscenza evidenziando, per ciascuna di esse, i pro- cessi elementari che la caratterizzano. Di seguito vengono illustrate le tre sezioni prendendo come riferimento la versione ultima della ‘Guida al PMBOK’.

Il contesto del Project Management

È costituito da due capitoli e si occupa di:

• definire concetti di base quali: Project Management, Project Management Office, programma, progetto e sottoprogetto;

• illustrare la struttura dell’intero documento;

• definire il ciclo di vita del progetto;

• identificare tutte le persone e le strutture coinvolte nel progetto e quelle che pos- sono subire le conseguenze, positive o negative, della sua realizzazione o comple- tamento;

• spiegare come le diverse tipologie di struttura organizzativa aziendale possono influire sullo svolgimento del progetto.

I 5 GRUPPI DI PROCESSI

La gestione di un progetto richiede al capo progetto di mettere in atto tutta una serie di attività per raggiungere l’obiettivo. Queste attività sono state raggruppate in processi cor- relati tra loro, spesso ciclici e comuni alla maggior parte dei progetti indipendentemente dalla loro natura.

Questi sono:

• gruppo di processi di avvio;

• gruppo di processi di pianificazione;

• gruppo di processi di esecuzione;

• gruppo di processi di monitoraggio e controllo;

• gruppo di processi di chiusura.

Per poter comprendere meglio come i gruppi di processi possano essere schematizzati è utile riportare la rappresentazione grafica presente sull’ultima edizione della ‘Guida al PMBOK’.

Analizzando la figura, appare immediato come i due gruppi di processi di avvio e di chiu- sura delimitino il progetto; come quelli di pianificazione e di esecuzione possano essere ciclici ed innescarsi a vicenda, ad esempio ogni volta che viene richiesta dal committente una modifica ai requisiti; come il gruppo di processi di monitoraggio e controllo sia presen- te dall’inizio alla fine del progetto in qualità di processi trasversali e di integrazione.

Nella ‘Guida al PMBOK’ , per ciascun gruppo, sono identificati i processi elementari che lo costituiscono e gli input e gli output che lo caratterizzano.

Di seguito viene dato una descrizione di cosa sono e cosa prevedono i gruppi di proces- so. Questa non vuole essere esaustiva, ma piuttosto va vista come una traccia di quanto presente sulla ‘Guida al PMBOK’ alla quale il lettore potrà riferirsi per maggiori dettagli e schematizzazioni. Inoltre, laddove possibile, vengono segnalati punti di attenzione e sug- gerimenti da seguire nelle attività individuate nei gruppi di processi. Il tutto per cercare di dare una chiave di lettura meno teorica della ‘Guida al PMBOK’ .

Il gruppo di processi di avvio parte dall’esigenza del cliente, dalla sua idea di realizzare un progetto e/o uno studio di fattibilità. Le attività previste sono la realizzazione del ‘pro- ject charter’ e la definizione dell’ambito del progetto.

Il ‘project charter’ è un documento nel quale vengono descritti gli obiettivi del progetto e i prodotti che si devono ottenere, viene fatto un preventivo di spesa e la pianificazione dei tempi, viene definito il gruppo di lavoro e la responsabilità dell’accettazione dei pro- dotti. Inoltre è fondamentale che venga stabilito: come si deve misurare lo stato di avan- zamento lavori, come verranno gestiti i cambiamenti che emergeranno in corso d’opera (gestione dei cambiamenti), i criteri di valutazione della qualità (indicatori) e i livelli di servizio e ciò che determina la conclusione del progetto; è necessario che ciò venga sta- bilito fin dall’inizio per evitare di perdere uno dei concetti fondamentali del progetto ossia ‘la durata limitata nel tempo’.

La prima versione del piano dei costi, tempi e dei deliverable, costituisce la ‘baseline’, ossia il punto di partenza che dovrà fare da guida per tutta la durata del progetto. Ogni volta

che si dovrà modificare la pianificazione è bene effettuare un confronto con la baseline di riferimento in modo da poter valutare gli scostamenti rispetto alla situazione d’origine.

La definizione dell’ambito del progetto è un documento che serve per delineare i confini del progetto stesso. Per schematizzare si può dire che qui viene descritto cosa rientra nel progetto ma anche tutto ciò che esula dal progetto. Nel documento vengono inoltre defi- niti i ‘deliverable’ del progetto.

Il gruppo di processi di pianificazione viene attivato appena il progetto è stato vara- to, e serve a:

• suddividere il progetto in sottoprogetti o componenti per ciascuna delle quali devo- no essere individuate le attività necessarie per la produzione dei deliverable;

• stimare ed allocare le risorse necessarie per ciascuna attività; per le risorse umane occorre valutare le competenze, l’impegno e la disponibilità necessarie per poter completare ciascuna attività alle quali sono associate e contestualmente identificar- ne i ruoli all’interno del progetto e le responsabilità;

• stimare i tempi per ciascuna attività e la loro schedulazione: è possibile che alcune attività di possano effettuare in parallelo mentre altre no;

• stimare ed allocare i costi per ciascuna attività,

• pianificare la qualità e la comunicazione tra tutti gli interessati al progetto (stakehol- der)’;

• identificare e analizzare i rischi, pianificarne la gestione e la conseguente risposta;

• pianificare gli acquisti e le forniture.

L’insieme di tutti questi piani , che nel PMBOK vengono definiti come secondari, costitui- scono il piano di Project Management.

La pianificazione, anche se ciò può sembrare ovvio, deve tener conto dei ‘vincoli’ espres- si dal committente durante la raccolta dei requisiti. Il proverbio ‘presto e bene raro avvie- ne’ risulta appropriato in questo contesto. Per completezza la pianificazione potrebbe pre- vedere la ‘matrice dei vincoli’, che si basa su tre principi fondamentali il Tempo, il Costo e la Qualità (TCQ). Essa esprime in modo semplice quale sia il vincolo più forte al quale il committente da priorità e qual è il compromesso da accettare. In questa matrice, che vuole essere una rappresentazione simpatica ed immediata del concetto espresso, una fac- cina può stare su una sola riga e una sola colonna. Nel caso riportato il vincolo forte è il rispetto dei tempi, ho un budget da rispettare il tutto a scapito della qualità.

92 Matrice dei vincoli (Fonte ADFOR)

In questo contesto è possibile dare alcuni consigli sulla base dell’ esperienza: il responsabi- le del progetto dell’Amministrazione committente, che deve approvare la pianificazione pro- posta dal fornitore, dovrebbe verificare come sono state effettuate tutte le stime di pianifica- zione facendosi fornire i razionali adottati, ciò per evitare il più possibile sgradite sorprese in corso d’opera . Ad esempio, può chiedere informazioni di dettaglio, quali i curricula, per veri- ficare che le risorse allocate abbiano effettivamente competenze adeguate all’attività nella quale è previsto che vengano impiegate; può verificare che il piano preveda un impegno delle risorse impiegate in modo adeguato ossia non siano sottoutilizzate o sovraccaricate; può verificare che effettivamente le attività sono state schedulate in modo opportuno e rendersi conto di quale possano essere le attività poste sul ‘percorso critico’ (critical path).

Prenderà quindi coscienza che per tali attività dovrà essere stata fatta un’analisi accurata del rischio e dovrà valutare di conseguenza come è stata pianificata la gestione del rischio e la relativa risposta. Sempre in tema di rischio, è opportuno verificare se nella gestione del rischio sono state prese in considerazione risposte che prevedono dei costi, ad esem- pio un’assicurazione, che questi siano presenti nel budget stimato. Stessa cosa per le risor- se: se una risposta ad un determinato rischio può essere quella di aumentare il numero di figure professionali o di sostituire le risorse con profili professionali più alti è necessa- rio che tutto ciò sia previsto nel budget.

Relativamente alle risposte al rischio, è possibile che a fronte di un eventuale ritardo accu- mulato su un’attività la soluzione classica proposta dal fornitore sia quella di affiancare nuove risorse a quelle già allocate. A tal proposito, è opportuno da parte dell’Am- ministrazione committente, che verifica e approva il piano di gestione della risposta al rischio, porre l’attenzione sul fatto che inserire più risorse per portare a termine un’attività non necessariamente sia una soluzione efficace. Oltre un certo numero di persone, si crea maggior confusione legata alle interazioni tra le persone stesse e paradossalmente un numero alto di risorse può allungare la durata di un’attività. Inoltre, molte attività elemen- tari non possono essere ulteriormente suddivise e, quindi, assegnate a risorse diverse.

Si ricorda che nell’effettuare la stima dei costi occorre tener conto oltre dei costi diretti, anche di quelli indiretti e delle spese generali. Si riporta un esempio non esaustivo di que- sti costi: per un progetto ICT quale lo sviluppo di un’applicazione, l’addestramento degli utenti dell’applicazione è un costo indiretto del progetto così come il costo del software di base ed eventuali macchine (PC, server …); tra le spese generali rientrano il costo del personale di staff, degli ambienti utilizzati, delle trasferte, ecc. È opportuno che il respon- sabile dell’Amministrazione, che deve approvare il preventivo di spesa preparato dal for- nitore, verifichi che anche queste tipologie di costi siano state inserite nel budget.

Si è parlato di risorse: è necessario che sia definito il ruolo e la responsabilità per tutti gli attori che prendono parte al progetto. Un modo efficace e schematico per capire in cia- scuna attività chi fa cosa è quello di rappresentarlo per mezzo della ‘matrice di responsa- bilità’. Nella matrice si riportano tutte le attività e i ruoli o le funzioni e in corrisponden- za di ciascun incrocio l’azione che deve essere effettuata. Una regola da rispettare nel riempire le caselle della matrice è che in ciascuna colonna, quindi per ogni attività, sia identificata la figura responsabile che prende la decisione. Per semplicità si riportano due esempi relativi alla realizzazione di software. Nel primo sono presenti l’Amministrazione in qualità di committente/cliente/utente e il fornitore, nel secondo alle due parti si aggiun- ge quella del monitore.

Matrice di responsabilità: esempio 1 – Amministrazione/Fornitore

Attività Ruoli	Attivazione	Definizione REQUISITI	Analisi	Realizzazione	Collaudo
Amministrazione – Dir. Generale	D	d	I		I
Amministrazione - Responsabile progetto	X	P	P/d	P/d	D/X
Amministrazione Dir. Ufficio che necessita l’applicazione	C	D	C	C	d
Amministrazione Utenti applicazione	I	d	d		d
Fornitore	I	X	D/X	D/X	C

Legenda:

D = decide,

d = partecipa decisione, I = viene informato,

C = deve essere consultato, X = esegue,

P = coordina

Matrice di responsabilità: esempio 2 – Amministrazione/Monitore/Fornitore

Attività Ruoli	Attivazione	Definizione REQUISITI	Analisi	Realizzazione	Collaudo
Amministrazione Dir. Generale	D	d	I		I
Amministrazione Responsabile progetto	X	d	d	d	D/X
Amministrazione Dir. Ufficio che necessita l’applicazione	C	D	C	C	d
Amministrazione Utenti applicazione	I	d	d		d
Monitore		P	P	P	P
Fornitore	I	X	D/X	D/X	C

In una corretta pianificazione, non può mancare il piano di qualità, nel quale vengono definiti gli standard di processo e di prodotto che devono essere applicati al progetto, gli indicatori di qualità che si dovranno misurare periodicamente. Quando si parla di prodot- to in questo caso si intende tutto ciò che risulta essere un output di tutte le fasi del pro- getto (deliverable), quindi anche i documenti sono visti come prodotti.

Altra cosa a cui è fondamentale dare la giusta rilevanza è la comunicazione. Spesso non si ritiene necessario pianificare come debba avvenire la comunicazione formale e non, ma chiunque abbia lavorato in un progetto sa che i più grossi problemi possono derivare da cattiva o mancata comunicazione. Nella maggior parte dei progetti, un capo progetto si può trovare a lavorare con attori che hanno bisogno di utilizzare linguaggi diversi, ad esempio, nel campo ICT, il linguaggio usato dal fornitore molto spesso è più tecnico di quanto un responsabile amministrativo riesca a comprendere. Fare riunioni, scambiarsi

lettere, messaggi e documenti più o meno formali non necessariamente porta ad una comunicazione ‘efficace’. Occorre quindi sia pianificare il come e quando comunicare sia capire quali sono gli interlocutori che di volta in volta comunicano.

Il gruppo di processi di esecuzione viene attivato per la prima volta quando il piano di Project Management, preparato dal fornitore viene approvato dal responsabile del pro- getto del committente. I processi appartenenti a questo gruppo provvedono a:

• assicurare l’approvvigionamento mediante stipula di contratti con i fornitori;

• acquisire le risorse necessarie a formare il team di progetto e sviluppare il proces- so di miglioramento delle competenze e dell’interazione tra i membri del team;

• dirigere e gestire l’esecuzione del progetto, assicurandone la qualità, distribuendo le informazioni a tutti gli interessati al progetto e gestendo le modifiche in corso d’opera.

Per l’approvvigionamento possono essere usate varie modalità a secondo del progetto che si intende realizzare. Per questo fare riferimento al manuale 2 delle ‘linee guida sulla quali- tà dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA’ del CNIPA. La gestione del progetto nell’attuazione di questo gruppo di processi prevede che venga- no adottati criteri per la rilevazione dello ‘stato di avanzamento lavori’ (SAL). Per i criteri da adottare si rimanda al manuale 7 delle ‘linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA’ del CNIPA.

Queste informazioni così come tutte quelle previste nel piano della comunicazione devo- no essere fornite con cadenze regolari definite sempre nello stesso piano. È importante trovare una forma semplice ed efficace per veicolarle, la struttura della reportistica pro- dotta dal fornitore deve essere inoltre essenziale, completa, e comprensibile dal destina- tario dell’informazione. Per dirla in breve: ‘poche informazioni ma buone’.

Anche la gestione dei cambiamenti viene affrontata in questi gruppo di processi. Come è ovvio è difficile che un progetto una volta definiti vincoli e requisiti, questi restino immu- tati per tutta la durata del progetto. Chiunque abbia un minimo di esperienza sa che il ‘cambiamento’ è qualcosa che deve mettere in conto sin dall’inizio. È necessario quindi definire come verranno gestite le richieste di modifiche, spesso infatti devono essere approvate perché vanno ad incidere sia sui costi che sui tempi pianificati e approvati in precedenza. Quanto illustrato porta a comprendere come questo gruppo di processi possa innescare il gruppo dei processi di pianificazione. Entrambi possono essere innescati più volte in tutta la durata del progetto.

Il gruppo di processi di monitoraggio e controllo, come il gruppo di processi prece- dente, quando viene attivato per la prima volta prende in input il piano di Project Management. Come è stato già detto, è costituito da processi trasversali che durano per tutta la durata del progetto. Ha come obiettivo il monitoraggio e il controllo dell’esecu- zione del progetto al fine di poter intraprendere azioni correttive a fronte di problemi che emergono in corso d’opera. È possibile che sia la figura del ‘monitore’ a svolgere in gran parte le attività previste in questi processi affiancando il responsabile del progetto dell’Amministrazione. I processi appartenenti a questo gruppo provvedono a:

• controllare che la gestione delle modifiche, sia nuove richieste che correzioni di difetti, avvenga secondo quanto in precedenza definito e pianificato;

• controllo della schedulazione e dei costi, confronto tra quanto misurato e quanto preventivato (baseline);

• controllo della qualità misurando periodicamente gli indicatori presenti nel piano di qualità;

• verifica della consegna di tutti i deliverable di fase entro i termini pianificati, non- ché del loro contenuto ai fini dell’approvazione;

• monitoraggio e controllo dei rischi, verifica del piano di attuazione per la risposta al rischio e misura dell’efficacia delle risposte;

• gestione delle risorse;

• gestione di tutti gli attori coinvolti nel progetto;

• gestione del contratto.

Può sembrare ovvio ma si ritiene utile fare presente che un monitoraggio efficace effet- tuato con cadenze regolari, che possono variare in relazione al tipo di progetto, alla sua complessità e alla durata, può contribuire enormemente alla riuscita del progetto. Da parte dell’Amministrazione è anche importante sensibilizzare il fornitore a condividere in modo tempestivo qualunque problema, non aspettando di arrivare alle date prefissate per incon- tri sullo stato avanzamento lavori o alla stesura del rapporto di monitoraggio.

Il gruppo di processi di chiusura comprende i processi necessari a completare tutte le attività del progetto. In particolare il rilascio delle risorse e la chiusura del contratto. Può sembrare strano ma la chiusura di un progetto inizia nel ‘project charter’. Sin dall’avvio del progetto è necessario determinare quando il progetto sarà completato e cosa ne deter- minerà la fine. È alto infatti il rischio di non considerare mai concluso il progetto: il clien- te tende sempre a chiedere attività che magari non rientrano nell’ambito del progetto, anche questo definito nei processi di avvio. Il fornitore, di conseguenza, cerca di assecon- dare il cliente imputando tempi e costi al progetto. Il tutto rischia di sfuggire di mano a chi deve gestire il progetto.

È importante che venga archiviata tutta la documentazione prodotta in modo che possa essere facilmente reperibile in caso di necessità.

Una buona norma che si suggerisce di adottare è quella di avere un archivio dei progetti (‘lesson learned’), meglio se informatizzato, dove vengono registrati tutti i progetti conclu- si e dove il responsabile del progetto può annotare, in modo strutturato, le difficoltà incon- trate, gli errori commessi, le soluzioni adottate, gli strumenti di ausilio al suo lavoro, e tutto quello che può essere ritenuto utile al fine di rendere la sua specifica esperienza patrimo- nio comune all’interno dell’Amministrazione. Stessa cosa si consiglia di fare al fornitore. Tutti i gruppi di processi descritti interagiscono tra loro: ogni gruppo di processi prevede input e output; questi ultimi possono essere input per il gruppo di processi successivo. È utile sottolineare che i cinque gruppi di processi non corrispondono puntualmente alle fasi che compongono il ciclo di vita del progetto; infatti il ciclo di vita è finalizzato alla realizzazione del prodotto più che alla gestione del progetto. Esso può variare a secondo della tipologia del progetto o dell’ambito in cui esso si svolge. In teoria all’interno di cia- scuna fase è possibile attuare tutti i cinque gruppi di processi.

Per capire meglio quanto è stato detto si riporta un esempio facilmente intuibile: il grup- po di processi di ‘pianificazione’ va attuato durante la definizione dei requisiti, l’imposta-

zione o l’analisi, la progettazione e spesso anche durante la realizzazione per via di sco- stamenti che si verificano in corso d’opera. Questi possono essere dovuti ad una serie di fattori quali ad esempio la gestione di nuove richieste, la modifica di requisiti e/o di vin- coli, un imprevisto non gestito da un piano di gestione del rischio.

Le aree di conoscenza

Ciascuna area di conoscenza raggruppa l’insieme di processi e/o attività necessari per ese- guire e completare il progetto relativamente alla tematica trattata.

Le nove aree di conoscenza presenti sulla ‘Guida al PMBOK’ sono:

• gestione dell’integrazione di progetto;

• gestione dell’ambito del progetto;

• gestione dei tempi di progetto;

• gestione dei costi di progetto;

• gestione della qualità di progetto;

• gestione delle risorse umane di progetto;

• gestione della comunicazione di progetto;

• gestione dei rischi di progetto;

• gestione dell’approvvigionamento di progetto.

Le nove aree di conoscenza sono articolate in quarantaquattro processi elementari che appartengono ai cinque gruppi di processi già analizzati. Per la mappatura dei processi elementari raggruppati e le aree di conoscenza si rimanda alla ‘Guida al PMBOK’. Nel testo, relativamente a ciascuna area vengono suggeriti e descritti non solo gli input gli out- put dei processi elementari, ma anche gli strumenti e le tecniche da adottare.

Di seguito viene fornita una panoramica sugli aspetti principali delle aree, per i dettagli e le rappresentazioni schematiche si rimanda alla ‘Guida al PMBOK’.

Gestione dell’integrazione di progetto comprende i processi necessari al coordina- mento di tutto ciò che compone il progetto; i processi elementari individuati appartengo- no a tutti i cinque gruppi. Nella versione 3 della ‘Guida al PMBOK’ si è data maggior importanza a quest’area alla quale sono stati aggiunti processi elementari sia per il grup- po di processi di avvio che per quello di processi di chiusura. Ciò per sottolineare come l’integrazione di tutti gli elementi che compongono il progetto sia uno dei fattori critici di successo. È fondamentale quindi che tutto sia coordinato e per farlo occorre che sia pia- nificato, diretto, gestito e monitorato.

Gestione dell’ambito del progetto comprende i processi che assicurano la produzione di tutto e solo quello che è necessario per realizzare il progetto. Si ribadisce il concetto che quando viene definito l’ambito è necessario che siano definiti i confini del progetto e tutto ciò che in esso non rientra. Uno dei processi elementari fondamentali che si vuole eviden- ziare è la creazione della WBS (work breakdown structure) ossia la suddivisione di tutto il lavoro del progetto in attività codificate che realizzano prodotti autoconsistenti; può esse- re interpretata come un modo per vedere il progetto come serie di prodotti strutturati.

Gestione dei tempi di progetto comprende i processi che servono ad assicurare che il progetto si concluda nei tempi previsti. Nella versione 3 della ‘Guida al PMBOK’ è stato

aggiunto il processo di ‘stima delle risorse delle attività’. Nel seguire i processi previsti in questa area si raccomanda di porre particolare attenzione alla scelta delle tecniche di pia- nificazione per verificare la sequenza con la quale possono essere svolte le attività (nella versione italiana della guida si parla di ‘sequenzializzazione’) e delle tecniche di schedu- lazione.

Gestione dei costi di progetto comprende i processi che servono ad assicurare che i costi del progetto si mantengano entro il budget previsto. I processi previsti sono quelli relativi alla stima, allocazione e controllo dei costi. Come per l’area di conoscenza prece- dente è importante conoscere le tecniche che possono essere adottate per stimare i costi del progetto. Anche se può sembrare scontato si evidenzia che migliore è la stima effet- tuata e meno rischi di sforare il budget si avranno. Nel processo di controllo una delle tecniche più conosciute è quella dell’earned value o valore assorbito. Per una illustrazio- ne completa della tecnica si rimanda alla ‘Guida al PMBOK’.

Gestione della qualità di progetto comprende i processi necessari a garantire che il pro- getto sia completato soddisfacendo le esigenze per le quali è stato avviato nel rispetto della qualità predefinita. I processi previsti sono quelli di pianificazione, assicurazione e controllo della qualità. Sulla ‘Guida al PMBOK’ sono presenti molte tecniche per i tre pro- cessi elementari, in particolare per l’effettuazione del controllo.

Gestione delle risorse umane di progetto comprende i processi necessari ad assicurare che il gruppo di progetto sia utilizzato meglio possibile, non solo come impegno ma anche che ciascuna figura professionale abbia le conoscenze richieste per l’attività che le è stata assegnata. I processi devono anche garantire che i ruoli e la responsabilità siano state asse- gnate correttamente e siano condivise dalle risorse stesse. Nella versione 3 della ‘Guida al PMBOK’ sono stati riformulati i tre processi di pianificazione, acquisizione e sviluppo del gruppo di progetto ed è stato aggiunto il processo ‘gestire il gruppo di progetto’.

Gestione della comunicazione di progetto comprende i processi che servono ad assicu- rare che tutte le informazioni di progetto siano, in modo adeguato e tempestivo, generate, raccolte, distribuite e opportunamente archiviate per poter essere reperite. Nella versione 3 della ‘Guida al PMBOK’ è stato soppresso il processo di ‘chiusura amministrativa’ mentre è stato aggiunto quello di gestione degli ‘stakeholder’. Sull’importanza della comunicazione si è già scritto, qui si vuole ricordare il detto latino ‘verba volant, scripta manent’.

Gestione dei rischi di progetto comprende i processi necessari a garantire che venga- no identificati, analizzati, pianificati e monitorati i rischi e pianificate e gestite le risposte relative. Nella versione 3 della ‘Guida al PMBOK’ è stato aggiunto il processo di ‘monito- raggio e controllo dei rischi’. Se identificare i rischi legati al particolare progetto è cosa non facile, ancora più difficile è prevedere i rischi sconosciuti. In questo caso una buona fonte di informazione e spunto di analisi può essere l’archivio dei progetti dove sono state annotate esperienze precedenti. In questi casi il gruppo di progetto deve comunque tro- vare una risposta al rischio, è quindi opportuno preparare una riserva (contingecy) ad esempio l’aggiunta di un intervallo temporale o una riserva finanziaria. Oltre all’identifi- cazione dei rischi è fondamentale l’analisi per capirne l’impatto e programmare una rispo- sta adeguata. Anche per quest’area nella ‘Guida al PMBOK’ vengono illustrati strumenti e tecniche da adottare.

Gestione dell’approvvigionamento di progetto comprende i processi per l’acquisizio- ne di prodotti e servizi provenienti da strutture esterne necessari a portare a compimen-

Document Metadata

Table of Contents

febbraio 2007

Document Metadata