21

Ing

eg

ne

rIl

Ar

ch

Ite

tt

Ilc

os

tr

ut

to

rI

I

AN

NO

LXV

II I

4_

2012

I

729

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 crostAIngegnere elettronico, consulente di direzione e di informatica

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

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. Commerciale2. Progettazione e sviluppo3. Test

4. Approvvigionamenti5. Assistenza tecnica6. Gestione delle risorse7. Gestione documentazione8. 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

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-

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

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

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.

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-

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

Processodi 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

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. La ISO/IEC 20000 costituisce, dunque, un valido strumento 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

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-DEVCapability Maturity Model Integration for Devolution Sviluppo e integrazione di prodotti software

COBITControl Objectives for Information and related Technology Governance dell’ICT

ITILInformation Technology Infrastructure Library Gestione dei servizi ICT

PM BOKGuide to the Project Management Body of Knowledge

Gestione dei progetti

PRINCE 2Projects IN Controlled Environments

Gestione dei progetti

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

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

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-

tano delle combinazioni di operazio-

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.

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.