Le metodologie standard per l'ingegnere dell'informazione: quali metodi e standard dovrebbbe adottare un buon igegnere dell'informazione nello svolgimento dell'attività prpfessionale?

1. 21
IngegnerilArchitettilCostruttoriIANNOLXVIII4_2012I729
SOMMARIO
Il presente articolo ha lo scopo di illustrare alcune linee guida di svolgi-
mento della professione dell’Ingegnere dell’Informazione. In particolare si
desidera indicare le regole organizzative di massima a cui ogni Ingegnere
dell’Informazione – libero professionista o dipendente di Società – dovreb-
be attenersi nell’attuazione dei propri processi ed attività per garantire a
tutte le parti interessate un servizio in linea con le aspettative.
Le regole nel seguito descritte si ispirano a normative e standard di ca-
rattere internazionale (norme ISO, EN, UNI) relative all’organizzazione ge-
stionale del lavoro, senza voler entrare nel merito tecnico delle singole
attività, regolamentate da norme tecniche, leggi e regolamenti applicabili,
oltre che dalle specifiche e dai requisiti del committente.
SUMMARY
This article aims to illustrate some guidelines for carrying out the profes-
sion of Information Engineer. In particular, we want to indicate the orga-
nizational rules, in principle, that every Information Engineer - freelance
or employee of the Company - should follow in the implementation of its
processes and activities to ensure a service in line with expectations to all
interested parties.
The rules described below are based on international standards (ISO, EN
, UNI) related to organization of work management, without going into the
technical merit of individual activities, regulated by technical standards,
applicable laws and regulations, as well as the specifications and the re-
quirements of the customer.
PREMESSA
Oggi gli Ingegneri dell’Informa-
zione operano in vari contesti,
sia come liberi professionisti, sia
all’interno di piccoli studi profes-
sionali che spesso dirigono, sia
all’interno di aziende più struttu-
rate. Il loro ruolo è estremamente
importante in quanto la società è
sempre più governata da “infor-
mazioni” su supporto cartaceo o
elettronico, la cui gestione è sem-
pre più critica, sia per garantire
l’efficacia e l’efficienza dei processi
di business, sia per assicurare la
loro “sicurezza”, fisica e logica. Gli
Ingegneri dell’Informazione, per-
tanto, ricoprono spesso posizioni
critiche, poiché dispongono sia di
competenze tecniche, sia di com-
petenze organizzative, entrambe
frutto di conoscenze acquisite nel
curriculum scolastico e post-sco-
lastico e durante l’esperienza la-
vorativa. Ma quali sono le regole
fondamentali e le buone prassi che
ogni Ingegnere dell’Informazione
dovrebbe conoscere ed applicare?
Escludendo le normative tecniche
strettamente legate ai prodotti
progettati e realizzati dall’ingegne-
re, le normative e best practice che
descrivono le modalità gestionali
LE METODOLOGIE STANDARD PER
L’INGEGNERE DELL’INFORMAZIONE Fabrizio Di Crosta
Ingegnere elettronico, consulente di
direzione e di informatica

2. 22
ed organizzative di conduzione delle attività sono diver-
se ed hanno approcci differenti.
Nel seguito si cercherà di illustrare sinteticamente le
metodologie di lavoro da adottare nei diversi contesti
- basate su standard internazionalmente riconosciuti
(normative e best practice) - per garantire che i proces-
si gestiti dall’Ingegnere dell’Informazione siano sotto
controllo e producano i risultati attesi da tutte le parti
interessate.
L’obiettivo è anche quello di instaurare una discussio-
ne aperta che porti alla definizione ufficiale – nelle sedi
più appropriate - di standard di lavoro riconosciuti a cui
si potranno conformare gli Ingegneri dell’Informazioni,
almeno quelli iscritti all’Albo che operano in qualità di
liberi professionisti e non dipendono dalle regole im-
poste da un’organizzazione più grande all’interno della
quale lavorano.
Per i dettagli non trattati nel presente articolo si ri-
manda ai documenti normativi della sezione ed ad altri
standard in essi richiamati, pur tenendo presente che
la maggior parte di tali documenti rappresentano stan-
dard di certificazione volontaria per le organizzazioni di
vario tipo che operano nei settori di competenza degli
Ingegnere dell’Informazione. Si precisa anche che la
norma ISO 9001, essendo standard relativo ai sistemi
di gestione per la qualità di ogni tipo di organizzazio-
ne, è pienamente applicabile a qualsiasi attività svol-
ta dall’Ingegnere dell’Informazione. Sui modelli per
la qualità nell’ICT si veda anche la sezione ”Modelli di
Qualità nell’ICT”
L’ambito di applicazione
L’Ingegnere dell’Informazione opera in diversi setto-
ri specifici dell’ICT, ma in ogni caso gran parte di essi
lavorano nei processi di progettazione, sviluppo ed as-
sistenza di sistemi informatici e pertanto quasi tutte le
normative elencate nel paragrafo “Documenti e Norma-
tive di riferimento” sono applicabili alle attività che esso
svolge. Per questo motivo si prenderà come riferimento
un’organizzazione (o singolo professionista) che opera
appunto nei processi di progettazione e sviluppo, test,
assistenza e manutenzione di sistemi informatici, co-
stituiti in genere da componenti hardware, componenti
software o da una combinazione di essi eventualmente
contenuta in componenti meccanici. I sistemi informa-
tici trattano le informazioni, spesso oggetto di proble-
matiche relative alla sicurezza delle stesse, in termini
di riservatezza, integrità e disponibilità, requisiti sem-
pre più importanti al giorno d’oggi che ogni Ingegnere
dell’Informazione dovrebbe prendere in considerazione
ispirandosi alle norme della famiglia ISO 27000.
Approccio per processi
L’approccio per processi – indicato dalla norma ISO 9001
come il miglior modo per descrivere un’organizzazio-
ne - può essere recepito in un’organizzazione che opera
nell’ICT classificando ed identificando i propri processi
secondo gli schemi ISO/IEC 12207 e ISO/IEC 15504 (Mo-
dello Spice).
Per ogni processo identificato è necessario definire gli
input, le risorse necessarie, i vincoli, gli obiettivi ed i ri-
sultati attesi (ouput). Lo schema SPICE fornisce inoltre
le metodologie per la valutazione dei processi e la clas-
sificazione degli stessi in sei livelli di maturità, secondo
principi analoghi a quelli del Capability Maturità Model
(CMMI).
Tutti i processi del ciclo di vita sono classificati da en-
trambe le normative in processi primari, organizzativi
e di supporto. I processi individuati nei due documenti
sono differenti come tipologia e come numero, anche
se esistono molte analogie. Pure il livello di dettaglio
descrittivo dei singoli processi è diverso: la ISO 12207
definisce meno processi ma li descrive più dettagliata-
mente, viceversa la ISO 15504 ne individua in numero
maggiore ma si sofferma meno a lungo nel descriverli.
Figura 1 - Schema dei processi ISO 9001

3. 23
Allineando la mappa dei processi definita in ISO 12207
e ISO 15504 alla ISO 9001:2008 si potrebbe giungere ad
una identificazione dei processi come riportato di se-
guito.
I processi primari potrebbero essere i seguenti:
• Acquisizione (della commessa/contratto);
• Fornitura (del prodotto software al cliente);
• Sviluppo (del software);
• Gestione Operativa;
• Manutenzione.
I processi di supporto, invece, potrebbero essere:
• Documentazione;
• Controllo di configurazione;
• Assicurazione (Gestione) qualità;
• Gestione anomalie.
I processi organizzativi, infine, potrebbero essere:
• Direzione;
• Gestione delle risorse;
• Misure;
• Miglioramento.
Ulteriori approfondimenti sui modelli citati sono rias-
sunti nei paragrafi relativi e del presente documento.
Per piccole organizzazioni (ad esempio studi di inge-
gneria) che progettano e sviluppano sistemi informatici
ed erogano i servizi connessi (installazione, formazione,
assistenza) la cosiddetta mappa dei processi può esse-
re semplificata e ridotta ai seguenti processi:
1. Commerciale
2. Progettazione e sviluppo
3. Test
4. Approvvigionamenti
5. Assistenza tecnica
6. Gestione delle risorse
7. Gestione documentazione
8. Gestione qualità
9. Direzione
Nel seguito esamineremo i requisiti principali dei sud-
detti processi per un Ingegnere dell’Informazione, ov-
vero descriveremo le regole che un Ingegnere dell’In-
formazione dovrebbe seguire nello svolgimento delle
proprie attività.
Descrizione dei processi
Processo commerciale
Il processo commerciale, o di acquisizione commesse,
riguarda:
• tutte le attività commerciali, promozionali e di mar-
keting finalizzate al contatto con il potenziale cliente
per l’acquisizione della commessa o la vendita del
prodotto;
• la preparazione dell’offerta tecnico-economica per la
fornitura;
• la definizione del contratto per la vendita del prodotto
e/o servizio.
Oltre al rispetto della deontologia professionale, le atti-
vità cosiddette “commerciali” dell’Ingegnere dell’Infor-
mazione devono essere improntate alla massima tra-
sparenza e chiarezza nella pubblicità dei propri servizi:
tutta la documentazione promozionale (sito web, bro-
chure, ecc.) dovrebbe descrivere in modo preciso e cor-
retto le competenze e le attività effettivamente svolte
dall’Ingegnere dell’Informazione o dall’organizzazione
che gestisce, nonché i prezzi e le tariffe applicate.
Nella fase di offerta l’Ingegnere dell’Informazione do-
vrebbe raccogliere con la massima attenzione tutti i
requisiti e le esigenze del cliente, comprese quelle im-
plicite che il committente dà per scontate e quelle che il
cliente non conosce, ma l’Ingegnere dell’Informazione
sì, pertanto le deve esplicitare in offerta. Tutti i requisi-
ti del cliente e quelli cogenti dovrebbero essere docu-
mentati in offerta o nei documenti in esso richiamati, o
comunque identificati in documenti interni.
Le prestazioni professionali (progettazione, consulenza,
assistenza, formazione, ecc.) dovrebbero essere chia-Figura 2 - Esempio diagramma dei processi

4. 24
ramente indicate in offerta con le
relative modalità di erogazione e
quotate – a corpo oppure in base
ad una tariffa professionale oraria/
giornaliera – in modo da essere
chiaramente comprese dal cliente.
L’offerta dovrebbe contenere chiari
riferimenti a tutti i servizi inclusi ed
esclusi dall’offerta.
L’offerta dovrebbe essere chiara-
mente identificabile (anche nel suo
stato di revisione), datata e firma-
ta dal professionista o dall’orga-
nizzazione che rappresenta. Ogni
revisione/modifica dell’offerta do-
vrebbe indicare chiaramente che
sostituisce/integra la versione pre-
cedente.
Il contratto per il servizio o per la
fornitura del prodotto può essere
rappresentato dall’accettazione
formale dell’offerta, controfirman-
dola per accettazione o mediante
un apposito ordine scritto che si ri-
ferisce ad essa.
Nel caso in cui le parti decidano di
sottoscrivere un contratto apposi-
to, esso deve riportare i contenuti
dell’offerta o richiamarla; ogni sco-
stamento del contratto o dell’ordi-
ne cliente rispetto all’offerta deve
essere attentamente riesaminato
dall’Ingegnere dell’Informazione,
tenendo eventualmente traccia
scritta degli accordi presi verbal-
mente (modalità di pagamento,
sconti, ecc.) ed inviando al cliente
una conferma delle variazioni pat-
tuite.
Ogni modifica del contratto succes-
siva alla sua stipula o all’avvio della
fornitura deve essere documentata
in forma scritta e sottoscritta dalle
parti (si ricorda che oltre alla firma
autografa, solo la firma digitale ha
valore legale; un’approvazione via
e-mail potrebbe essere discono-
sciuta in sede legale).
Processo di progettazione
e sviluppo
L’Ingegnere dell’Informazione può
condurre attività di progettazione
di sistemi informatici a vari livelli:
progettazione di hardware, softwa-
re, firmware, sistemi di telecomu-
nicazione o di una combinazione
dei precedenti. L’attività di proget-
tazione e sviluppo parte dalla de-
finizione delle prime specifiche di
alto livello, spesso stabilite in fase
di offerta del prodotto, e giunge fino
al progetto esecutivo del prodotto –
nel caso di sistemi hardware – op-
pure fino al software eseguibile,
funzionante su hardware del clien-
te o di terze parti.
La progettazione dovrebbe essere
condotta dall’Ingegnere dell’Infor-
mazione documentando tutti gli
input e gli output alle successive
fasi progettuali; nel caso della pro-
gettazione software dovrebbero es-
sere documentate ed approvate la
Specifica dei Requisiti (che descri-
ve il funzionamento del sistema ed
è scritta in linguaggio comprensibi-
le per il cliente), l’Analisi Funzionale
e l’Analisi Tecnica. Nella specifica
dei requisiti - principale input al
processo di progettazione e svi-
luppo vero e proprio - dovrebbero
essere esplicitati i requisiti cogenti
del sistema, oltre a quelli esplicitati
dal cliente contrattualmente o ver-
balmente. Ogni tipo di organizza-
zione può definire fasi progettuali
in modo differente e denominare i
documenti di output diversamente,
ma dovrebbe comunque mantene-
re un adeguato livello di descrizio-
ne dei successivi approfondimenti
progettuali.
I requisiti di qualità del software
(cfr. ISO/IEC 25000:2008 “Softwa-
re Engineering - Software product
Quality Requirements and Evalua-
tion (SQuaRE) Guide to SQuaRE” e
ISO/IEC 9126-1:2001 “Software en-
gineering - Product quality - Part 1:
Quality model”) dovrebbero essere
stabiliti e progettati.
La progettazione e sviluppo del sof-
tware può avvenire secondo diversi
modelli di ciclo di vita (cfr. UNI CEI
ISO/IEC 12207: 2003 “Tecnologia
dell’informazione - Processi del ci-
clo di vita del software”), ma ogni
organizzazione dovrebbe definire il
proprio in modo documentato.
Tutto il processo di progettazione
dovrebbe essere pianificato con un
livello di dettaglio dipendente dal-
la complessità e dall’articolazione
del progetto (durata, numerosità
delle fasi identificate, numerosi-
tà delle risorse coinvolte, ecc.). Il
piano del progetto dovrebbe esse-
re documentato in formato idoneo
(testo descrittivo accompagnato da
tabelle, diagrammi di Gantt, Pert,
WBS, ecc.) e sistematicamente ag-
giornato. Esso dovrebbe compren-
dere l’allocazione delle varie fasi
e attività progettuali alle risorse
disponibili ed esplicitare vincoli di
precedenza e milestone (consegne,
fatturazioni, installazioni,...). Per
progetti più complessi il piano di
progetto dovrebbe essere accom-
pagnato da un piano della qualità
(vedi UNI ISO 10005:2007 “Siste-
mi di gestione per la qualità - Li-
nee guida per i piani della qualità”
per i contenuti) che ha lo scopo di
tradurre i requisiti contrattuali in
specifiche, contestualizzare e det-
tagliare le procedure che si intende
adottare per il progetto in questio-
ne.
I principali output della progetta-
zione (specifica dei requisiti, docu-
menti di analisi, ecc.) dovrebbero
essere revisionati dal personale re-

5. sponsabile prima della loro approvazione formale: nel
piano di progetto dovrebbero essere stabiliti momenti di
riesame formale della progettazione (valutazione dello
stato di avanzamento del progetto, riesame del sod-
disfacimento dei requisiti per la parte di progetto svi-
luppata fino al momento del riesame, riunioni con rap-
presentanti del committente e di altre funzioni interne
all’organizzazione, ad es. commerciale ed acquisti) e
verifiche tecniche degli output progettuali per valutare
la correttezza dell’iter di progettazione percorso. L’esito
di tali riesami e verifiche dovrebbero essere documen-
tati, indicando le azioni da attuare emerse dal riesame
o dalla verifica.
Per la progettazione e sviluppo di software a valle
dell’analisi tecnica dovrebbe collocarsi la fase di svi-
luppo/codifica del codice sorgente. Quest’ultimo dovrà
essere sottoposto a controllo di configurazione per ge-
stirne correttamente le versioni successive e parallele,
inoltre dovrebbe essere formalmente verificato prima
di essere compilato per produrre codice eseguibile o
comunque essere rilasciato per l’utilizzo.
Il buon esito di tutti i test interni e dell’eventuale test di
accettazione del cliente nell’ambiente operativo di uti-
lizzo porta alla validazione del prodotto software, che
dovrebbe essere registrata (data, responsabile, esito,
osservazioni).
Test
La fase di test del software può comprendere ciclica-
mente successive modifiche del codice sorgente fino ad
ottenere un eseguibile conforme ai requisiti. La confor-
mità del prodotto software dovrebbe essere formaliz-
zata tramite test approfonditi e documentati il cui su-
peramento è imprescindibile per il rilascio del prodotto
software.
Quando appropriato dovrebbe essere predisposto ed
approvato un piano dei test ed una specifica di test pri-
ma di procedere alla fase di test. La specifica di test è
necessaria quando i documenti di specifica e di analisi
del sistema non sono sufficienti a descrivere la moda-
lità corretta di esecuzione dei test (quali dati di input
utilizzare, in quale ambiente di test effettuare le prove,
quali prove eseguire e così via).
Il test può suddividersi in test unitario, funzionale (even-
tualmente di integrazione) e di sistema e richiedere
l’impiego di risorse indipendenti per aumentare l’affi-
dabilità delle fasi finali di test. Ogni attività di test do-
vrebbe essere registrata, ad eccezione del test unitario
che può essere registrato anche solo ad esito positivo.
Ogni test superato o non superato con la descrizione
delle anomalie riscontrate costituisce un’importante
informazione dell’andamento della progettazione e svi-
luppo del prodotto, nonché una preziosa informazione
per imparare dagli errori (la c.d. return of experience).
Il rilascio del software pronto per l’installazione può av-
venire solo al superamento di tutti i test previsti.
L’eventuale installazione presso il cliente dovrebbe
sempre essere seguita dall’esecuzione di un test di ac-
cettazione alla presenza del cliente.
Assistenza
Il processo di assistenza può comprendere la risolu-
zione di eventuali malfunzionamenti nel periodo di ga-
ranzia contrattuale del prodotto e/o come servizio ag-
giuntivo a pagamento. In entrambe i casi ogni anomalia
segnalata dal cliente dovrebbe essere accuratamente
registrata, ne dovrebbe essere effettuata la diagnosi al
fine di identificare le cause del malfunzionamento ed
infine dovrebbe esserne formalmente pianificata la ri-
soluzione (responsabile, attività, tempi).
La correzione del malfunzionamento – tramite modifica
del codice - dovrebbe essere seguita da un test accura-
to del prodotto per verificare l’effettiva rimozione dell’a-
nomalia, comprendendo – quando opportuno – anche
appositi test di regressione per verificare che altre parti
del sistema non presentino anomalie causate dall’in-
tervento di assistenza.
Tutte le attività del processo di assistenza dovrebbe-
ro essere registrate (autore, descrizione delle attività
svolte, tempi,...) anche al fine di calcolare utili indica-
tori sui tempi di risposta del servizio (talvolta specificati
contrattualmente come SLA, Service Level Agreement) e
sulla qualità del software prodotto.
Per i servizi informatici si veda anche la ISO/IEC
20000:2005 “IT - Service Management – Part 1: Specifi-
cation & Part 2: Code of Practice” che descrive in modo
più ampio le regole a cui attenersi quando si fornisce
servizi informatici. Infatti il processo di assistenza può
essere visto in modo più ampio come processo di “sup-
porto”, comprendendo la manutenzione e gestione del
sistema informativo, talvolta rappresentato da applica-
zione web ospitata su un sito del fornitore.
25

6. 26
Approvvigionamenti
Gli acquisti più importanti per una organizzazione che
progetta e sviluppa sistemi informatici generalmente
riguardano hardware commerciale o su specifica, sof-
tware commerciale o software su specifica commissio-
nato a fornitori, servizi professionali (consulenze spe-
cialistiche, personale in outsourcing). Altre forniture,
tra cui materiali di consumo, prodotti (apparecchiature
tecnologiche, arredi,...) e servizi (manutenzione im-
pianti, pulizie, consulenze legali e fiscali, ecc.) per la
struttura, sono meno critiche.
Per tutte le forniture critiche – servizi professionali e
sviluppi software commissionati esternamente in pri-
mis – occorre valutare preventivamente il fornitore in
modo il più possibile oggettivo, qualificarlo formalmen-
te e tenerlo monitorato rivalutandolo con frequenza al-
meno annuale per garantire che soddisfi i requisiti del-
la fornitura. Tale valutazione e rivalutazione periodica
deve essere dettagliata per i diversi aspetti di qualità
del prodotto/servizio acquistato (qualità del prodotto,
tempi di consegna, assistenza,...) e documentata. Una
valutazione più snella con registrazioni più sintetiche
dovrebbe essere effettuata anche per le forniture se-
condarie. Inoltre, per le forniture critiche che entrano
direttamente nell’oggetto di fornitura al cliente occorre
valutare di chiedere al fornitore di produrre registrazio-
ni sui controlli/test da lui effettuati al suo interno, sulle
procedure adottate e su eventuali certificazioni della
fornitura che è in grado di rilasciare.
Questi ultimi requisiti vanno richiesti al fornitori nell’or-
dine di acquisto o contratto per la fornitura in oggetto.
In caso di servizi forniti da singoli professionisti ana-
loghi a quelli svolti dall’organizzazione in cui opera
l’Ingegnere dell’informazione la qualifica del profes-
sionista (ad esempio un altro ingegnere dell’informa-
zione) può confluire nella gestione delle risorse umane
(cfr.”Gestione delle risorse”).
Laddove il servizio fornito è un outsourcing vero e pro-
prio è opportuno effettuare degli audit (di parte secon-
da) al fornitore per verificare le modalità di svolgimento
dell’attività al suo interno.
Se completa ed esaustiva può essere accettata formal-
mente l’offerta/preventivo formulata dal fornitore e
conferirgli valenza contrattuale.
Evidentemente, per le attività svolte dall’Ingegnere
dell’Informazione, l’acquisto di alcuni prodotti hardwa-
re e software commerciali è chiaramente determinato
dai requisiti della fornitura al cliente (ad esempio nel
caso in cui nella fornitura debba essere incluso un sof-
tware commerciale ben identificato oppure un’appa-
recchiatura hardware completamente identificata dalla
marca e dal modello); in tali situazioni il fornitore può
essere valutato e scelto unicamente per il prezzo e per
il servizio (consegna, installazione,...).
Gestione delle risorse
Il processo in oggetto riguarda sia la gestione delle ri-
sorse umane (personale interno e collaboratori ester-
ni), sia la gestione delle risorse tecniche (hardware,
sistemi informativi, apparati di telecomunicazione,
strumenti di lavoro e di misura/controllo).
La gestione delle risorse umane coinvolte nell’organiz-
zazione in cui opera l’Ingegnere dell’Informazione deve
prevedere:
• La definizione dei requisiti minimi di competenza
(istruzione di base, formazione/addestramento, qua-
lifiche ottenute, conoscenze acquisite, esperienza,
capacità/abilità,...) per ricoprire ogni ruolo (ad es.
capo progetto, project manager, analista-program-
matore, ecc.);
• La registrazione del curriculum professionale di ogni
collaboratore (ad es. scheda personale comprenden-
te dati anagrafici, titoli conseguiti, esperienze pre-
gresse, formazione ricevuta, altre competenze pos-
sedute,..), aggiornato con frequenza almeno annuale;
• La pianificazione della formazione ed addestramen-
to del personale in base alle esigenze di formazione/
addestramento identificate (carenze da colmare ri-
spetto al ruolo ricoperto, esigenze legate ad attività
di progettazione e sviluppo per una commessa, ecc.),
• La registrazione di tutti gli eventi formativi svolti (cor-
si interni ed esterni, addestramenti, seminari infor-
mativi, convegni, training on the job, aggiornamenti
autodidattici, affiancamenti).
Le risorse tecniche devono essere gestite al fine di garanti-
re il funzionamento, l’adeguatezza e l’efficienza di tutti gli
strumenti di lavoro impiegati nell’attività di progettazione,
sviluppo, test ed assistenza tecnica. Dunque occorre ga-
rantire il buon funzionamento di tutto l’hardware (Server,
PC, periferiche,...) ed il software (applicativi di office auto-
mation, ambienti di sviluppo e test, tool di ausilio al test,
ecc.) utilizzato attraverso la valutazione dell’adeguatezza

7. 27
ai requisiti (ad es. per il corretto fun-
zionamento degli applicativi software
impiegati) ed una adeguata manu-
tenzione periodica1
che ne garantisca
la disponibilità e l’affidabilità.
Sotto questi aspetti risulta impor-
tante garantire un adeguato livello di
sicurezza dei sistemi informatici, ove
per sicurezza si intende garantire la
riservatezza, l’integrità e la disponi-
bilità delle informazioni (comprese
quelle memorizzate su supporto car-
taceo per cui si veda il processo Ge-
stione documentazione) gestite du-
rante l’attività. Ciò implica dotarsi di:
• adeguati tool per la protezione dei
sistemi informatici (anti-malware
aggiornati frequentemente, fi-
rewall hardware e/o software,
IDS,...);
• sistemi di autenticazione con cre-
denziali sicure (il Codice per la pro-
tezione dei dati personali, D.Lgs
196/2003, nell’Allegato B impone
un codice utente ed una password
segreta di almeno 8 caratteri da
cambiare ogni 3 o 6 mesi a secon-
da che si gestisca dati sensibili) e
profili di accesso adeguati ed ag-
giornati;
• procedure di backup e restore fre-
quenti e testate;
• aggiornamento del sistema ope-
rativo e del software di base con
patch di sicurezza;
• sistemi di protezione da assenza di
energia elettrica;
• sistemi di configuration manage-
ment;
• policy e procedure di sicurezza
per l’uso di internet e della posta
elettronica, l’utilizzo di PC portatili,
unità di memorizzazione rimovibi-
li, smartphone/palmari, apparec-
chiature di nettworking, ecc.;
• procedure di comportamento per
il personale volte prevenire perdita
di sicurezza delle informazioni.
Per approfondimenti sulla sicurez-
za delle informazioni si veda la ISO/
IEC 27001:2005 – “IT - Security tech-
niques - Information security mana-
gement systems – Requirements”
– UNI ISO/IEC 27001:2006 “Tecnolo-
gie dell’informazione - Tecniche di
sicurezza - Sistemi di gestione della
sicurezza delle informazioni – Re-
quisiti e le normative collegate della
famiglia ISO 27000. In funzione della
criticità dei dati e delle informazioni
trattate sarebbe opportuno dotarsi
dei controlli citati in suddetta fami-
glia di norme.
Laddove nell’attività di test e di assi-
stenza tecnica si impieghi attrezzatu-
re hardware (es. simulatori di segna-
le, tester, dispositivi di diagnosi e/o
misura di reti telematiche) occorre
accertarsi che essi siano in buono
stato di manutenzione e garantisca-
no un funzionamento accurato anche
nell’indicazione di valori numerici o
misure puntuali, eventualmente ri-
correndo a procedure di calibrazio-
ne/taratura periodiche presso enti
specializzati ed autorizzati che rila-
scino apposito rapporto di verifica.
Gestione documentazione
L’Ingegnere dell’Informazione do-
vrebbe operare secondo procedure
documentate che descrivano i pro-
cessi interni, approvate, distribuite
in modo controllato2
e disponibili
nel luogo di lavoro dove e quando
servono. Anche tutta la modulistica
di registrazione delle attività deve
essere resa disponibile - in forma-
to cartaceo o informatico – in forma
controllata. È dunque opportuno
apporre un indice di revisione pro-
gressivo, una data di emissione, un
autore ed un responsabile dell’ap-
provazione a tutte le procedure in-
terne ed ai documenti ed elaborati
a circolazione interna e/o esterna.
In caso di modifica è opportuno te-
nere traccia delle stesse non solo
attraverso l’incremento dell’indice
di revisione, ma anche riportando
una breve sintesi delle modifiche
apportate in copertina oppure ri-
correre ai sistemi di tracciamento
delle revisioni forniti da alcuni sof-
tware di wordprocessing.
In caso di revisione successiva di
un documento occorre garantire
che i documenti obsoleti (non più
validi) siano rimossi da tutti i centri
di distribuzione (cartacei ed elet-
tronici). È opportuno mantenere
aggiornati elenchi dei documenti
validi/in vigore disponibili a tutti.
I moduli (o form elettronici), una
volta compilati diventano delle re-
gistrazioni delle attività svolte e
pertanto devono essere conservati
in modo sicuro, garantendone l’i-
dentificazione, la rintracciabilità, la
leggibilità, la riferibilità temporale
ed alla persona che li ha prodotti
per un periodo stabilito.
La protezione delle informazioni
in termini di riservatezza deve ga-
rantire almeno i requisiti cogenti
stabiliti dal D. Lgs 196/2003 (Codi-
ce della Privacy) oltre a quelli del
clienti e di terzi riguardo a proprie-
tà intellettuale o segreti industriali.
Vanno gestite in modo controllato
(attraverso apposito elenco) anche
tutte le leggi, normative e regola-
menti applicabili all’attività, curan-
done la diffusione e la conoscenza
all’interno dell’organizzazione per
garantirne il costante rispetto.
Tutti i documenti in formato elet-
tronico possono essere ben gestiti
da buon sistema documentale che
gestisca anche i workflow dei docu-
menti.

8. 28
Gestione di qualità
Il processo comprende le attività seguenti, proprie di un
sistema di gestione per la qualità:
• Gestione delle non conformità e reclami cliente;
• Gestione delle azioni correttive e preventive;
• Gestione degli audit interni;
• Monitoraggio di indicatori di misura dell’efficacia e
dell’efficienza dei processi e della soddisfazione del
cliente.
Le non conformità (NC) rappresentano tutto ciò che è sta-
to svolto in modo difforme da quanto stabilito da requisiti
cliente, requisiti cogenti o procedure interne3
. Esse vanno
registrate con tutte le informazioni correlate atte a dimo-
strare sia l’efficace risoluzione del problema (correzione
della NC), sia l’identificazione delle cause che le hanno
provocate al fine di valutare l’opportunità di adottare idonee
azioni correttive. Le azioni preventive invece vanno attuate
quando un problema è solo potenziale (non si è verificato),
ma l’analisi del rischio che si verifichi consiglia di adot-
tare idonee azioni di prevenzione. Sia le azioni correttive
che quelle preventive vanno registrate per documentarne
la pianificazione, le responsabilità, i tempi di attuazione e
la valutazione della loro effettiva efficacia.
Gli audit (verifiche ispettive) interni vanno condotti, possi-
bilmente da personale indipendente, per verificare la cor-
retta attuazione delle procedure e regole interne, nonché
dei requisiti contrattuali e di quelli cogenti. Gli audit de-
vono essere pianificati in modo da coprire tutti i processi
aziendali almeno una volta all’anno (in funzione del volu-
me e della criticità dei processi primari sarebbe opportu-
no verificarli più volte). Ogni audit deve essere registrato
in apposito rapporto che conterrà l’elenco delle anomalie
(non conformità rispetto alle procedure stabilite o sempli-
ci osservazioni per il miglioramento dei processi) a cui il
responsabile dell’area o processo interessato dovrà porre
rimedio in tempi adeguati (anche qui con azioni correttive
o preventive/di miglioramento).
Appositi indicatori dovrebbero essere stabiliti per moni-
torare nel tempo l’andamento dei processi in termini di
qualità, tempi e costi. Gli indicatori dovrebbero soprattut-
to monitorare e misurare il perseguimento degli obietti-
vi dell’organizzazione stabiliti dalla Direzione. I classici
aspetti da monitorare per le attività in oggetto sono il rap-
porto fra il valore delle offerte andate a buon fine e quelle
emesse (per misurare il processo commerciale), il rispetto
dei tempi di consegna del prodotto al cliente e la quanti-
tà di anomalie registrate in un primo periodo di garanzia
del prodotto (per monitorare il processo di progettazione,
sviluppo e test), il rispetto dei tempi di intervento e di riso-
luzione delle anomalie in assistenza (per misurare il pro-
cesso di assistenza tecnica), ecc..
Fra gli indicatori e le attività di monitoraggio e misurazione
non bisogna escludere la valutazione della soddisfazione
del cliente, attuata attraverso questionari, interviste, valu-
tazioni di indicatori o altri metodi indiretti.
Direzione
La Direzione della nostra organizzazione (ad esempio i
soci, titolari dello Studio di Ingegneria) ha l’impegno di:
• Definire la politica e gli obiettivi dell’organizzazione
coerentemente con la soddisfazione dei requisiti del
cliente;
• Definire la struttura organizzativa (organigramma/
funzionigramma e mansionario);
• Riesaminare periodicamente i risultati conseguiti
ponendo nuovi obiettivi più ambiziosi e/o adottando
azioni opportune per conseguire gli obiettivi non rag-
giunti;
• Mettere a disposizione le risorse (umane, tecnologi-
che, finanziarie) per conseguire gli obiettivi;
• Pianificare il miglioramento dell’efficacia e dell’effi-
cienza dei processi.
Tutte le attività suddette devono essere documentate e
comunicate agli interessati.
Modelli di qualità nell’ICT
Gli elementi fondamentali che costituiscono i contenuti
dei paragrafi della sezione precedente derivano dagli
standard normativi indicati alla sezione “Documen-
ti e Normative di riferimento” del presente articolo e
soprattutto ai requisiti della norma ISO 9001, declinati
dalla norma ISO 90003 per quanto riguarda il software.
Nel seguito sono sintetizzati gli elementi principali di
altre normative che trattano principi di qualità nell’ICT.
La norma ISO 12207
In relazione alle varie proposte della letteratura in ma-
teria, il modello principale preso a riferimento per de-
scrivere il ciclo di vita di una fornitura ICT è quello indi-

9. 29
cato dalla norma UNI CEI ISO/IEC 12207. Infatti, sebbene
esso sia concepito per la descrizione di processi legati
allo sviluppo del software, tuttavia risulta facilmente
generalizzabile alla realizzazione di prodotti, servizi e
sistemi in senso più ampio.
La norma, infatti, definisce un insieme di processi, at-
tività e compiti (task) progettati per essere personaliz-
zati rispetto ai diversi progetti software, permettendo
l’eliminazione di processi, attività o compiti non appli-
cabili. La norma, inoltre, non prescrive l’adozione di
una particolare metodologia di sviluppo, né impone uno
specifico ciclo di vita (a cascata, a spirale, incrementa-
le o iterativo), elementi questi che possono variare in
funzione dei processi produttivi e delle metodologie in
uso presso ciascun fornitore. Quello 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.
La norma ISO/IEC 12207 definisce tre tipologie di processi,
classificati in:
• Processi primari. I processi primari sono i processi core
business, orientati alla generazione di prodotti e di ser-
vizi verso l’utente finale. Sono sviluppati nell’ambito di
ogni singolo progetto finalizzato alla realizzazione di una
fornitura e riguardano sia il Cliente che il Fornitore.
• Processi di supporto. I processi di supporto, ad uso in-
terno all’organizzazione che eroga il servizio, sono uti-
lizzati e svolti come parte integrante di altri processi e
contribuiscono 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 un progetto specifico. Riguardano la pianificazione e il
controllo del progetto, nonché la gestione delle risorse
umane e materiali necessarie per la conduzione delle
attività previste in contratto.
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, articola-
to nelle fasi di Progettazione e Realizzazione (Codifica), il
processo di Gestione Operativa, del quale è parte integran-
te l’assistenza agli utenti ed infine il processo di Manuten-
zione, che include le attività relative alla migrazione 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 Configurazione, il processo di Assicurazione Qualità,
unitamente ai processi di Verifica, Validazione, Riesame
Congiunto con il Committente, Verifiche Ispettive (audit) ed
infine il processo di Risoluzione dei problemi (anomalie o
non conformità).
I processi organizzativi sono trasversali ai processi primari
e ai processi di supporto ed includono l’insieme delle at-
tività necessarie per realizzare con successo il progetto e
che riguardano in particolare il processo di Gestione del
progetto (Project Management), di Gestione delle infrastrut-
ture, di Formazione e di Miglioramento.
I 17 processi sopra indicati, definiti dalla norma, sono com-
posti da “attività” (insieme di azioni coerenti), a loro volta
ulteriormente scomponibili in “compiti” (o azioni di base).
Attività e compiti generano prodotti (documenti, softwa-
re, servizi, soluzioni). Nella figura che segue si riporta lo
schema dei processi proposti dalla norma.
La norma ISO 9126 e le caratteristiche di
qualità
La 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 adotta-
ta, per classificare anche i requisiti 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 esecuzione nell’ambiente in
UNI CEI ISO/IEC 12207
Processo
di Sviluppo
- Progettazione
- Realizzazione
Processo
di
Gestione operativa
Processo
di Manutenzione
PROCESSI PRIMARI
Processo di Acquisizione
Processo di Fornitura
Processo di Assicurazione Qualità
Processo di Verifica
Processo di Validazione
Processo del Riesame Congiunto
Processo di Verifica Ispettiva
Processo di Risoluzione dei problemi
PROCESSI DI SUPPORTO
Processo di Documentazione
Processo di Gestione della Configurazione
Processo di gestione
Processo di miglioramento
Processo di Infrastruttura
Processo di Formazione
PROCESSI ORGANIZZATIVI

10. 30
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 prodot-
to rilevabili in uno specifico contesto e misura quanto il
prodotto supporta l’utente nel raggiungere i suoi obietti-
vi, 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 uti-
lizzare la parte del modello di qualità proposto dalla nor-
ma 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 pro-
dotto sia il risultato dell’attività di progettazione e realiz-
zazione del servizio stesso e quindi può essere applicato al
risultato dei processi di progettazione e realizzazione del
servizio.
Il modello proposto individua per la qualità interna e ester-
na 6 caratteristiche e 27 sottocaratteristiche associate
come segue:
La qualità in uso è descritta attraverso quattro caratteristi-
che che non sono associate a sottocaratteristiche:
Tra queste caratteristiche quelle che descrivono meglio i
requisiti di qualità di erogazione di un servizio sono le 4 ca-
ratteristiche che si riferiscono alla qualità in uso e la fun-
zionalità, 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
prodotto software. Sono proposte metriche (o indicatori)
diverse per misurare la stessa sottocaratteristica in quan-
to riguardano aspetti specifici, che insieme concorrono a
valutare la medesima. Ogni fornitura ha esigenze specifi-
che anche in relazione alla qualità ed è necessario, quindi,
selezionare di volta in volta le metriche opportune.
Le norme ISO 20000 per i servizi ICT
Lo standard ISO/IEC 20000, sviluppato sulla base del BS
15000 (British Standard), del quale ne mantiene la strut-
tura, è completamente allineato con l’IT Infrastructure
Library (ITIL).
Lo standard consente alle organizzazioni di poter effet-
tuare dei benchmark sulla propria capacità nell’eroga-
zione dei servizi, nel misurare i livelli di servizio e nella
valutazione delle performance.
La definizione di Service Level Agreement (SLA) costitu-
isce il passo principale verso una appropriata relazione
con il cliente/utente. La ISO/IEC 20000 fa di questo do-
cumento il cardine attraverso il quale gestire sia inter-
namente che esternamente i servizi senza dimenticare
gli aspetti tecnici, finanziari e di sicurezza del servizio.
LaISO/IEC20000costituisce,dunque,unvalidostrumento
per la riprogettazione dei processi di business e per l’ot-
timizzazione degli aspetti di gestione dei servizi per l’IT.
L’ISO/IEC 20000 è stata suddivisa in due distinte pub-
blicazioni:
• La norma ISO 20000-1:2011 è la specifica formale, contie-
ne una lista di controlli a cui una organizzazione “deve”
essere aderente per fornire servizi di gestione ad una
qualità accettabile per i suoi clienti, e potersi certificare.
• La ISO 20000-2:2012 descrive le best practice per i pro-
cessi di gestione dei servizi IT all’interno del ISO 20000-1.
Contiene linee guida e suggerimenti che “dovrebbero”
essere messi in pratica dalle organizzazioni, e risulta
particolarmente utile a quelle organizzazioni che desi-
derano prepararsi per essere certificate ISO 20000 o pia-
nificano miglioramenti del servizio.
Successivamente lo standard è stato arricchito di altre
parti (parte 3°. “Information technology - Service manage-
ment - Part 3: Guidance on scope definition and applicability
of ISO/IEC 20000-1”, parti 4a e 5a, usciti come Technical Re-
port) fi minore importanza.
Qualità interna ed esterna
FUNZIONALITÀ AFFIDABILITÀ USABILITÀ EFFICIENZA MANTENIBILITÀ PORTABILITÀ
- Adeguatezza - Maturità - Comprensibilità
- Prestazioni
temporali
- Analizzabilità - Adattabilità
- Accuratezza
- Tolleranza ai
guasti
- Apprendibilità - Utilizzo risorse - Modificabilità - Installabilità
- Interoperabilità - Ripristinabilità - Operabilità
- Conformità alla
efficienza
- Stabilità - Coesistenza
- Sicurezza
- Conformità alla
affidabilità
- Attrattività - Collaudabilità - Sostituibilità
- Conformità alla
funzionalità
- Conformità alla
usabilità
- Conformità alla
mantenibilità
- Conformità alla
portabilità
Qualità in uso
EFFICACIA Produttività Salvaguardia Soddisfazione

11. 31
Le “Best Practice”
Per quanto riguarda la proble-
matica del governo dei contratti
si prende 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”.
Le best practice riepilogate nella
seguente tabella, costituiscono un
insieme tra loro complementare,
rappresentativo delle migliori pra-
tiche esistenti a livello internazio-
nale.
CMMI-DEV: Capability Ma-
turity Model Integration
for Development
È un modello di definizione e valu-
tazione dell’efficacia dei processi
afferenti all’ingegneria del softwa-
re (sviluppo, manutenzione, inte-
grazione di software applicativo) o
dei sistemi, che ne definisce un ap-
proccio al miglioramento. Il CMMI
può agevolare l’integrazione fra le
differenti funzioni di una medesima
organizzazione, per fissare obiettivi
di miglioramento e per ridurre i ri-
schi di progetto.
Si basa una specializzazione del Ca-
pability Maturity Model (CMM) origi-
nariamente sviluppato dal Software
Engineering Institute (SEI), un ente
di ricerca e sviluppo, finanziato dal
governo federale degli Stati Uniti d’A-
merica e affiliato alla Carnegie Mel-
lon University (CMU).
Nel manuale, liberamente scaricabile
dal sito del SEI (http://www.sei.cmu.
edu/cmmi/) è analizzata solo la com-
ponente, detta anche “costellazione”,
CMMI-DEV v1.3 destinata principal-
mente agli sviluppatori di software.
L’approccio adottato dal modello è
quello di definire un insieme di aree
di processo critiche (Process Area,
PA), che consentano, quando siano
propriamente implementate, di defi-
nire e migliorare i processi di un’or-
ganizzazione dedita alla realizzazio-
ne di prodotti software ICT.
Nella valutazione del miglioramento
dei processi CMMI individua due pos-
sibili itinerari di evoluzione organiz-
zativa:
a) La rappresentazione continua,
nella quale le aree di processo
sono raccolte in quattro famiglie
(categorie) in funzione degli obiet-
tivi perseguiti:
- Gestione di Progetto (Project Ma-
nagement);
- Gestione di Processo (Process
Management);
- Supporto (Support);
- Sviluppo Tecnico (Engineering)
b) La rappresentazione scalare, che
individua 5 livelli di maturità utiliz-
zabili per la valutazione del siste-
ma informativo aziendale:
- Livello 1: Iniziale;
- Livello 2: Gestito;
- Livello 3: Definito;
- Livello 4: Quantitativo;
- Livello 5: Ottimizzato.
Riassumendo, i concetti fondamenta-
li su cui si basa il modello CMMI sono
le 4 Categorie in cui sono organizzate
le 22 Aree di processo e i 5 livelli di
maturità.
Il SEI rende disponibili diverse certifi-
cazioni, sia per la propria rete di part-
ner, al fine di convalidare l’affidabilità
dei servizi offerti dai professionisti
associati, sia per le organizzazioni
che adottano uno dei modelli delle
costellazioni CMMI, al fine di conva-
lidare la corretta interpretazione ed
applicazione dei principi del modello
relativo. La certificazione aziendale
è articolata su tre diversi livelli, che
possono essere raggiunti con il supe-
ramento di esami con crescenti livelli
di indagine e di approfondimento,
condotti da personale autorizzato dal
SEI.
COBIT: Control OBjectives
for Information and rela-
ted Technology
È un sistema di best practice fi-
nalizzate al governo ed il controllo
dei sistemi informatici (Information
Technology Governance) redatto
dall’Information Systems Audit and
Control Association (ISACA) e suc-
cessivamente gestito dall’IT Gover-
nance Institute (ITGI).
Fornisce un quadro di riferimento
fatto di domini e processi e presen-
Best Practice Ambito di applicazione
CMMI-DEV
Capability Maturity Model Integration for Devolution
Sviluppo e integrazione di prodotti software
COBIT
Control Objectives for Information and related Technology
Governance dell’ICT
ITIL
Information Technology Infrastructure Library
Gestione dei servizi ICT
PM BOK
Guide to the Project Management Body of Knowledge
Gestione dei progetti
PRINCE 2
Projects IN Controlled Environments
Gestione dei progetti

12. 32
ta le attività in una struttura gestibile e logica. Le buo-
ne pratiche contenute in COBIT (http://www.isaca.org/
COBIT/Pages/default.aspx) sono condivise dagli esperti
e riguardano principalmente il controllo piuttosto che
gli aspetti operativi con l’intento di fornire un riferimen-
to con valenza generalizzata che raccoglie le migliori
prassi nella gestione e Governance dell’ICT, senza par-
ticolari specificità ad ambiti di mercato o settori indu-
striali.
In COBIT (ora alla versione 5.0) è dichiarato l’obiettivo di
proporsi come modello che possa supportare l’Alta Di-
rezione nell’implementazione di opportune pratiche di
IT Governance, ma interessa tutti gli operatori aziendali
impegnati nella conduzione dei sistemi informativi.
La prima versione di COBIT risale al 1996 ed è stata il
risultato di un gruppo di ricerca pluriennale di ISACA.
Tale organizzazione rilascia certificazioni alla persona,
articolate su più livelli, che attestano la conoscenza e le
competenze raggiunte sul modello. Non esistono inve-
ce certificazioni aziendali in assenza di specifiche nor-
me da adottare e rispettare.
ITIL: Information Technology Infrastruc-
ture Library
È una raccolta di best practice, ispirate dalla pratica
per la gestione dei servizi ICT e fornisce una descri-
zione dettagliata di importanti pratiche, con checklist
complete, compiti, procedure e responsabilità. ITIL è
caratterizzato da un approccio innovativo, che privile-
gia l’utilizzabilità rispetto all’organicità ed omogeneità
della trattazione. Ad alto livello ITIL è focalizzato sulle
componenti della gestione del Servizio e su come que-
ste sono tra loro correlate. Il ciclo di vita dei Servizi è
caratterizzato da cinque fasi, ciascuna trattata all’inter-
no di uno specifico volume di ITIL:
• Service Strategy;
• Service Design;
• Service Transition;
• Service Operation;
• Continual Service Improvement.
Ogni fase del ciclo di vita è caratterizzata da degli obietti-
vi che, partendo dalla definizione delle strategie, si fanno
sempre più operativi. Ogni volume di ITIL è una raccolta di
migliori pratiche, molto spesso organizzate come processi,
omogenee da punto di vista delle finalità, che complessiva-
mente hanno come riferimento cardinale la soddisfazione
del business e del cliente.
ITIL si presenta come una metodologia estremamente
flessibile per la progettazione e l’implementazione di un
modello di gestione dei servizi ICT adattabile a qualsiasi
organizzazione.
Le Best Practice di ITIL sono state sviluppate per essere
adattate e questa peculiarità ha reso l’ambito di applica-
zione molto vasto. Infatti le indicazioni sull’erogazione di
servizi, e sui processi e mezzi necessari a supportarli,
possono essere idonee a qualsiasi organizzazione ICT, sia
quelle al cui interno esista una funzione ICT, indipenden-
temente dal settore di riferimento e dalla natura dei propri
clienti, sia quelle che abbiano la fornitura dei servizi ICT
come core business.
Per quanto riguarda la copertura essa è amplia e appro-
fondita relativamente all’erogazione dei servizi ICT, mentre
le attività di realizzazione del software sono ancora tratta-
te in modo piuttosto marginale. Tale situazione comunque
potrà evolvere perché il modello conosce continui aggior-
namenti ed estensioni.
Non esistono dirette certificazioni aziendali di conformità
ad ITIL, di fatto tale certificazione è assolta dalla ISO 20000.
Tuttavia esistono certificazioni professionali, articolate in
più livelli, rilasciate da Organizzazioni di Training accredi-
tate, attestanti il livello di competenze ed expertise.
PMBOK: guide to the Project Management
Body Of Knowledge
Il PMBOK costituisce il testo di riferimento che si pro-
pone di raccogliere l’insieme delle conoscenze relative
alla gestione dei progetti. In esso sono identificate e de-
scritte le conoscenze e le pratiche riconosciute applica-
bili nella maggior parte dei progetti. La guida definisce
i processi e gli strumenti finalizzati alla possibilità di
realizzare con successo un progetto.
Tale guida, giunta alla quarta edizione, è pubblicata dal
Project Management Institute (PMI, http://www.pmi.org/
PMBOK-Guide-and-Standards.aspx), un’associazione
senza scopo di lucro fondata nel 1969 a Philadelphia
in Pennsylvania, riconosciuta a livello internazionale,
come autorevole nel campo del Project Management e
riferimento fondamentale per tutti coloro che sono in-
teressati alla professione del Project Manager.
Il PMBOK presenta la disciplina della Gestione proget-
tuale organizzando la conoscenza concernente tale do-
minio in due dimensioni trasversali: i processi di project

13. 33
management (suddivisi a loro volta in cinque insiemi) e
le aree di conoscenza utili per il project management.
I processi elementari (caratterizzati da flusso, input
e output) da mettere in atto per la realizzazione di un
progetto sono stati raccolti in gruppi di processi corre-
lati tra loro: i gruppi di processi di avvio e di chiusura,
da eseguirsi una sola volta, i gruppi di pianificazione
ed esecuzione, che formano un ciclo e si innescano a
vicenda ad ogni variazione progettuale ed il gruppo di
processi di monitoraggio e controllo, attività trasversali
e di integrazione da condurre durante tutta la durata
progettuale.
Gli stessi processi elementari, utilizzando un diverso
punto di vista, sono raggruppati rispetto ad una tema-
tica andando a costituire così un’area di conoscenza, la
quale raggruppa l’insieme di processi e/o attività ne-
cessarie per eseguire e completare il progetto relativa-
mente alla tematica trattata.
I concetti fondamentali su cui si basa PMBOK sono i 5
gruppi di processo, che cadenzano l’evoluzione del pro-
getto e le 9 aree di conoscenza che raccolgono le infor-
mazioni utili per il capo progetto.
I destinatari sono tutte le organizzazioni che utilizzano
la modalità di lavoro a progetti, sia al proprio interno
sia verso i propri clienti, all’esterno, in quanto interes-
sate ad avere, fra i propri membri, persone in possesso
di approfondita cultura nell’ambito del Project Mana-
gement. Le certificazioni PMI riguardano le persone e
sono articolate su più livelli per coprire tutti i possibili
ruoli impegnati nella gestione progettuale.
Metodologia TenStep
Un approfondimento “operativo” rispetto a quanto pre-
visto dal PMBOK, che arriva a definire esaustivamen-
te i processi afferenti al project management, è fornito
dalla metodologia TenStep, sviluppata dall’omonima
organizzazione americana specializzata nello sviluppo
di metodologie di business e servizi di formazione e
consulenza.
Il “Processo di Project Management TenStep” è un pro-
cesso flessibile e scalabile adatto per gestire qualsiasi
lavoro come un progetto sulla base di dieci passi (ten
step); è applicabile in modo diverso a secondo della di-
mensione del progetto che viene determinata dai se-
guenti fattori: l’impegno previsto, l’esperienza del capo
progetto, la complessità unita alla criticità.
La metodologia comprende processi, tecniche, best
practice, modulistica e materiale di formazione e può
essere adottata per gestire qualsiasi tipo di progetto,
anche se molti riferimenti ed esempi sono forniti per
progetti di sviluppo software.
La struttura del processo è composta da dieci passi di cui
due iniziali:
1. definizione del lavoro;
2. sviluppo del piano di lavoro e del budget;
3. gestione del piano di lavoro e del budget;
4. gestione dei problemi;
5. gestione del contenuto;
6. gestione della comunicazione;
7. gestione del rischio;
8. gestione della documentazione;
9. gestione della qualità;
10. gestione delle metriche.
I primi due processi sono essenziali e sono interdipendenti
fra loro. Gli altri otto processi sono indipendenti e si ap-
plicano con rigore crescente in base alle dimensioni, alla
complessità ed all’importanza del progetto.
La metodologia TenStep si propone di seguire il capo pro-
getto dall’avvio al compimento del progetto; illustra come
applicare le tecniche enunciate nel PMBOK e fornisce
modelli (template) dei deliverable, fornendo anche esempi
pratici.
Occorre sottolineare che il PMBOK ed il Processo TenStep
non sono in contrapposizione tra loro; in TenStep si defini-
sce il PMBOK come “una base fondamentale delle aree di
conoscenza … ma non è una metodologia che si può utilizzare
per gestire direttamente un progetto”.
Al fine di evidenziare le analogie e le differenze tra i due
approcci, in TenStep è presente una mappatura delle nove
aree di conoscenza del PMBOK con i processi descritti nei
dieci passi della metodologia TenStep.
Il Gruppo TenStep, su licenza del PMI, ha sviluppato un
prodotto denominato ‘TenStep PB’, anche in lingua italia-
na (http://www.tenstep.it/). Si tratta dell’abbinamento del-
lo schema di riferimento del PMI, contenuto nel PMBOK
2004, con le spiegazioni approfondite dei processi della
metodologia TenStep.
PRINCE2: PRojects IN Controlled Envi-
ronments.
È un metodo strutturato di project management per or-
ganizzare, gestire e controllare i progetti sulla base di

14. 34
un approccio generico e flessibile,
basato sulla pratica. La genericità
deriva dal fatto che sia stato formu-
lato per essere utilizzabile come
metodologia per la gestione di
progetti, applicabile indipendente-
mente dall’oggetto e dalle dimen-
sioni del progetto.
Il metodo (http://www.prince-of-
ficialsite.com/), che affronta tutte
le discipline coinvolte nel project
management, si concentra in par-
ticolare sugli aspetti relativi alla
giustificazione del progetto e al
collegamento dello stesso con le
esigenze del business.
La best practice si caratterizza per
essere orientata al risultato: un
progetto per poter essere eseguito
deve rappresentare, nella termino-
logia utilizzata in Prince2, un busi-
ness case, cioè deve costantemente
tendere ad un obiettivo preciso che
possieda la capacità di creare valo-
re per l’organizzazione, altrimenti
va abbandonato. Il business case
,deve essere espresso in termini di
rapporto costi/benefici misurabili,
affinché possa essere costante-
mente controllato (ex ante, in itine-
re, ex post).
Un altro aspetto importate della
metodologia è il fatto che il con-
trollo in un progetto PRINCE2 è
strutturato su due livelli composti
da un Comitato di Progetto (Project
Board), con la responsabilità di de-
cidere, e il Project Manager a cui è
attribuita la responsabilità di coor-
dinare l’esecuzione del progetto e
un potere decisionale da esercitarsi
nei limiti delle tolleranze ammesse.
PRINCE2 è strutturato secondo tre
entità principali:
a) Un set di 8 processi interconnessi
fra di loro e svolti in modo control-
lato, che coprono la preparazione,
l’esecuzione e la chiusura dei pro-
getti ed illustrano in modo caden-
zato le attività che devono essere
eseguite.
b) Un set 8 componenti, cioè i modu-
li indispensabili per una corretta
implementazione del progetto da
parte dei processi, che esplicitano
la filosofia di base che caratteriz-
za il metodo e come possa essere
utilizzata.
c) Un set di 3 tecniche che rappresen-
tanodellecombinazionidioperazio-
ni tali da consentire lo svolgimento
di un’azione ed il conseguimento
del relativo risultato. Una sola di
tali tecniche è imposta dalla pras-
si: la “tecnica di pianificazione ba-
sata sul prodotto”, a causa degli
evidenti benefici che arreca. Per il
resto il metodo demanda al project
manager la responsabilità di quali
tecniche effettivamente utilizzare.
documenti e Normati-
ve di riferimento
Le normative seguenti sono sta-
te prese come riferimento nella
stesura del presente articolo, in
quanto standard internazionali ri-
conosciuti nei settori in cui opera
l’Ingegnere dell’Informazione per
le attività da esso svolte, in forma
individuale oppure nell’ambito di
organizzazioni più strutturate.
[1] UNI EN ISO 9001:2008 “Sistemi
di gestione per la qualità. Requi-
siti”
[2] UNI CEI ISO/IEC 90003:2005
“Ingegneria del software e di si-
stema - Guida per l’applicazione
della ISO 9001:2000 al software
per elaboratore”
[3] UNI CEI ISO/IEC 12207: 2003
“Tecnologia dell’informazione -
Processi del ciclo di vita del sof-
tware”
[4] ISO/IEC 9126-1:2001 “Software
engineering - Product quality -
Part 1: Quality model”
[5] ISO/IEC 27001:2005 – “IT - Se-
curity techniques - Information
security management systems
– Requirements” – UNI ISO/IEC
27001:2006 “Tecnologie dell’in-
formazione - Tecniche di sicu-
rezza - Sistemi di gestione della
sicurezza delle informazioni –
Requisiti”
[6] ISO/IEC 20000:2005 “IT - Service
Management – Part 1: Specifica-
tion & Part 2: Code of Practice”
[7] UNI ISO 10006:2005 “Linee guida
per la gestione per la qualità nei
progetti”
[8] ISO/IEC 15504-1:2004/06 “Infor-
mation technology - Process as-
sessment Part 1÷5”
[9] ISO/IEC 25000:2008 “Software
Engineering - Software product
Quality Requirements and Eva-
luation (SQuaRE) Guide to SQua-
RE”.
Si rimanda anche ai seguenti docu-
menti ex DIGITPA, Ora Agenzia per
l’Italia Digitale (www.digitpa.gov.
it sezione Manuali Qualità ICT) per
approfondimenti sulle tematiche
inerenti l’ICT e le forniture per la
Pubblica Amministrazione:
a) La qualità dei beni e servizi nei
contratti della pubblica ammi-
nistrazione: linee guida per una
migliore gestione
b) Ricognizione di alcune best prac-
tice applicabili ai contratti ICT
c) Modelli per la qualità delle for-
niture ICT.
In particolare il Manuale di cui al
punto b) tratta alcune best practice
internazionali relative alle attività di
fatto svolte dall’Ingegnere dell’In-
formazione. I contenuti di tali best
practice sono stati riassunti nella
sezione relativa alle best practice.

15. 35
CONCLUSIONI
Come abbiamo visto i modelli da cui attingere per de-
finire una metodologia di lavoro, orientata a stabilire
come gestire l’organizzazione dei processi, piuttosto
che gli aspetti tecnici della professione, sono diversi
ed alcuni di essi si sovrappongono su determinati ar-
gomenti. È comunque auspicabile che sia definito in fu-
turo un modello di metodologia di lavoro formalizzato,
basato su standard internazionali, che possa distingue-
re gli Ingegneri dell’Informazione liberi professionisti
che vorranno aderire al modello da altri soggetti, più o
meno qualificati, che operano sul mercato.
Al momento, oltre all’esistenza di un gruppo di lavoro
“Metodi e Procedure” che opera in ambito CNI, si se-
gnala un gruppo attivo su Linkedin (Ingegneri dell’In-
formazione dell’Ordine di Bologna”) all’indirizzo http://
www.linkedin.com/groups?gid=4692554 nel quale poter
sviluppare la discussione sulle tematiche esposte nel
presente articolo.
NOTE
1
Per i PC ciò comprende pulizia dei file cancellati, eventualmente
del registro di sistema e di altri elementi che ne appesantisco-
no il funzionamento, aggiornamento del sistema operativo e dei
principali programmi. Il tutto tramite apposite utility specifiche.
2
Si intende che ognuno abbia a disposizione sempre la versione
aggiornata del documento in caso di modifiche.