Linee Guida per la realizzazione di Studi di Fattibilità

7.2 Progetto di massima della soluzione

7.2.1 Requisiti della soluzione

In questa parte del documento di studio di fattibilità si debbono evidenziare i requisiti della soluzione proposta, ossia le condizioni essenziali che la soluzione proposta deve rispettare sia dal punto di vista informatico che dagli altri punti di vista.

I requisiti sono quindi tendenzialmente invarianti in tutte le fasi successive del ciclo di sviluppo ed in particolare, in caso di successiva gara per la realizzazione, rappresenteranno delle caratteristiche "mandatorie" su cui non potrà esserci proposizione di ipotesi diverse nelle offerte dei fornitori.

Il compito dello studio di fattibilità nell'individuare i requisiti è quindi anche quello di circoscrivere esattamente l'area da essi coperta, in maniera tale di garantire:

• da una parte che le specifiche modalità di realizzazione della soluzione che saranno presenti nelle offerte siano tutte capaci di rispondere efficacemente alle esigenze essenziali individuate, e quindi da questo punto di vista omogenee;
• dall'altra di non precludere, su aspetti non essenziali delle caratteristiche del sistema e della sua qualità, la possibilità alle offerte di esprimere completamente capacità progettuale e propositiva, in maniera da non precludere all'amministrazione la possibilità di ricevere anche ipotesi migliorative.

Questa parte dello studio di fattibilità consiste nella individuazione e rappresentazione del nuovo assetto che il/i processo/i di servizio impattati assumeranno a conclusione del progetto o dell'insieme degli interventi di cambiamento individuati.

Si tratta pertanto di tratteggiare la situazione a regime a cui si tende, vista non solo dal punto di vista informativo ma considerando tutto l'insieme delle componenti del processo.

In questa parte del documento sarà utile ricorrere, oltreché ad una esposizione testuale, ai medesimi modelli utilizzati in precedenza per la rappresentazione dello stato attuale del processo e dei flussi informativi, in quanto l'utilizzo dello stesso modello consente di evidenziare con maggiore chiarezza i cambiamenti proposti.

L'individuazione del nuovo assetto (la soluzione del problema/opportunità) rappresenta quella parte più "creativa" dello studio di fattibilità per la quale è necessario dotarsi della necessaria capacità professionale e di una forte esperienza progettuale. Occorre quindi che il gruppo di lavoro a cui è affidato lo studio di fattibilità comprenda, oltre alla completa conoscenza dell'organizzazione, conoscenze organizzative, metodologiche e tecnologiche (principalmente in termini di opportunità fornite dell'offerta tecnologica).

Nel caso in cui ci si trovi di fronte ad un programma di cambiamento articolato in vari interventi sulle diverse componenti del processo, l'individuazione e la rappresentazione della soluzione dovrà coprire, con pari livello di approfondimento, l'insieme delle viste sul processo. In particolare si dovranno specificare:

• le modifiche alla natura e alle caratteristiche del prodotto/servizio erogato;
• il nuovo flusso operativo del processo;
• cambiamenti nella quantità e qualità delle risorse umane coinvolte nel processo;
• la necessità di revisione delle strutture organizzative coinvolte e della distribuzione delle responsabilità;
• le modifiche alle caratteristiche professionali del personale da utilizzare e della loro distribuzione;
• la proposta di una nuova struttura logistica;
• .....

Tutti questi elementi sono il risultato degli interventi di reingegnerizzazione dei processi e quindi costituiscono il prodotto di questo tipo di intervento. Nel caso che sia stato effettuato dall'amministrazione un intervento di BPR sarà quindi sufficiente un rimando alla specifica documentazione, in caso contrario sarà comunque necessario definire lo stato finale dell'assetto del processo per tutti quegli elementi per cui si ipotizza una modifica della situazione esistente.

E' questo il caso tipico di quando il progetto informatico è l'unico progetto formalizzato, il che significa che la modifica sulle altre componenti non è radicale e che pertanto è sufficiente definire soltanto quei cambiamenti che sono collegati al progetto informatico stesso.

Questo documento non intende approfondire le tematiche connesse alla revisione complessiva dei processi di servizio, che saranno oggetto di specifico approfondimento da parte dell'Autorità e di successiva diffusione verso le amministrazioni.

Quello che si intende ribadire è la necessità che lo studio di fattibilità consideri tutte le dimensioni del processo di servizio, evitando di privilegiare la sola dimensione tecnologica.

Questa parte dello studio di fattibilità consiste nella descrizione dei progetti e delle iniziative di cambiamento su tutti gli aspetti non informatici. Contiene pertanto la descrizione di quanto si prevede di fare per arrivare alla soluzione finale individuata, descrizione che dovrà naturalmente essere adeguata alle specifiche caratteristiche degli interventi previsti.

In caso di presenza di altri progetti formalizzati contestuali al progetto informatico, sarà sufficiente il rimando alla relativa documentazione, altrimenti sarà necessario dettagliare almeno gli aspetti principali.

In caso di progetto essenzialmente informatico, andrà esplicitata l'invarianza degli altri aspetti e dettagliato quanto più direttamente connesso al progetto informatico, in particolare il piano di utilizzo del personale e la formazione prevista.

Questa parte del documento, derivante dall'analisi della normativa già vista in precedenza, consiste nella esplicitazione delle modifiche normative che si ravvisano come necessarie e dei passaggi previsti per la loro attuazione.

In caso di importanza particolare di queste modifiche, quando cioè esse si configurino di fatto come pre-requisiti all'attivazione del nuovo sistema, dovrà essere dedicata a questo aspetto particolare attenzione, specificatamente:

• ipotizzando un percorso per il cambiamento della normativa coerente con le scadenze ed il piano di progetto;
• considerando questa questione come uno dei principali fattori di rischio da gestire e quindi definendo la necessità di specifiche responsabilità;
• prevedendo la ratifica delle modifiche alla normativa come uno dei punti di rilascio e definendo un eventuale punto di decisione sul prosieguo del progetto in relazione a tale rilascio.

Questa parte dello studio di fattibilità consiste nella individuazione e rappresentazione dei requisiti essenziali a cui il nuovo sistema informativo dovrà rispondere.

I requisiti riguardano le informazioni che dovranno essere trattate, le funzioni che dovranno essere informatizzate, le modalità di lavoro previste, gli elementi architetturali che dovranno essere rispettati per garantire l'integrazione del nuovo sistema nella situazione esistente, le caratteristiche di qualità richieste, l'esplicitazione di volumi, tempi, durate ecc. che dovranno essere rispettate.

Queste tematiche sono quelle su cui più ampia è l'esperienza e la conoscenza da parte delle amministrazioni, per cui non si ritiene necessario inserire in questo documento una trattazione compiuta di questi argomenti. Si rimanda pertanto alla "Guida operativa" sia una ripresa generale dei principali metodi, modelli e tecniche utilizzabili, sia la pubblicazione di una bibliografia ragionata.

Ci si limita qui ad una elencazione di massima dei principali punti da trattare.

E' poi importante che ci sia una verifica di completezza e coerenza tra le varie classi di requisiti, che sono ovviamente interrelate tra di loro. Una semplice modalità di verifica è data dall'utilizzo di matrici di relazione tra informazioni, sotto-sistemi applicativi, classi di utenza, tecnologie utilizzate.

La descrizione delle informazioni trattate è necessaria per tutti i progetti che riguardano sistemi applicativi, per i quali è essenziale individuare i principali elementi informativi che faranno parte del sistema e le relazioni che intercorrono tra di loro, comprese le relazioni di aggregazione e generalizzazione. Il modello Entità/Relazioni è un modello di rappresentazione ampiamente diffuso e stabilizzato che potrà proficuamente essere adottato, anche se è evidente che, a livello di studio di fattibilità, sarà sufficiente individuare solo le principali informazioni, ossia fermarsi all'individuazione delle "classi di informazioni", e che non sarà necessario descrivere in maniera completa gli attributi, limitandosi a segnalare quelli più importanti, tipicamente gli attributi identificativi.

E' poi importante, specie in determinati contesti, correlare al modello le informazioni relative:

• alla dimensione della base informativa;
• alle specifiche necessità di sicurezza;
• alla evoluzione degli elementi informativi in termini di cambiamento di stato.

La descrizione delle funzionalità applicative è indispensabile per tutti i progetti che riguardano sistemi applicativi, per i quali è essenziale individuare i principali sottosistemi applicativi che costituiranno il sistema e le relazioni che intercorrono tra di loro, in termini di flussi informativi.

Per la rappresentazione delle funzionalità (cioè dell'architettura applicativa) sono ampiamente diffusi vari modelli con svariati livelli di dettaglio. A livello di studio di fattibilità sarà sufficiente individuare i sotto-sistemi logici e non le singole funzionalità, cercando di rispondere al principio di indipendenza funzionale e concentrando l'attenzione sulle funzionalità critiche anche attraverso lo sviluppo di livelli di dettaglio diversi tra le varie parti.

E' poi importante, specie in determinati contesti, correlare al modello le informazioni relative:

• alle necessità di utilizzo dei vari sottosistemi, specie in termini di volumi di utilizzo dei sistemi interattivi;
• agli eventi di attivazione;
• alla specificazione delle eventuali necessità di interfaccia tra sottosistemi e dei sottosistemi con altri sistemi applicativi, esterni al progetto;
• la matrice di relazione tra informazioni e sotto-sistemi applicativi.

La descrizione delle principali modalità di utilizzo del nuovo sistema informativo è necessaria per tutti i progetti, compresi i progetti relativi a infrastrutture tecnologiche e di automazione d'ufficio.

Questo implica la necessità di individuare le principali classi di utenza, in termini di numero e tipologia di utenti, di unità organizzative coinvolte e di localizzazione geografica.

E' particolarmente utile la rappresentazione, anche attraverso matrici di relazione:

• delle modalità di utilizzo degli elementi informativi da parte delle principali classi di utenza (creazione, aggiornamento, cancellazione, consultazione);
• delle modalità di utilizzo dei sottosistemi da parte delle principali classi di utenza.

Un altro elemento importante relativo alle modalità di lavoro, per i sistemi applicativi, è la definizione dei requisiti in termini di interfaccia utente, definendo gli elementi essenziali delle modalità di presentazione previste, dell'accesso e dell'uscita dalle applicazioni, della disponibilità di help in linea ecc.

Il sistema informativo che si intende realizzare si dovrà comunque collocare, nella generalità dei casi, all'interno del più complessivo sistema informativo dell'amministrazione, con inevitabili necessità di interfaccia con altri sotto-sistemi e dovrà comunque essere coerente con la visione tecnologica complessiva dell'amministrazione.

Inoltre, nella maggior parte dei casi, si pone anche un problema di interfaccia con sistemi di altre amministrazioni, per garantire sia la possibilità di condivisione delle informazioni e di accesso alle applicazioni da parte di utenti esterni, sia la risoluzione di specifici problemi applicativi di cooperazione.

Da queste considerazioni scaturisce la possibilità che l'amministrazione possa definire specifici requisiti in ordine all'architettura tecnologica del sistema applicativo o dell'infrastruttura tecnologica da realizzare, affinché la nuova realizzazione sia coerente con la strategia complessiva di utilizzo delle tecnologie e possa compiutamente integrarsi nell'ambiente in cui dovrà operare.

E' evidente cioè che le indicazioni rispetto a problematiche quali le scelte di fondo su decentramento/accentramento, le esigenze di connettività, interoperabilità e portabilità, la definizione delle necessità di condivisione delle basi di dati ecc., non potranno essere rimesse in discussione in ogni specifica realizzazione e dovranno essere definite dallo studio di fattibilità come requisiti che dovranno avere piena esplicitazione nel capitolato della gara realizzativa.

E' importante sottolineare che i requisiti debbono essere espressi come tali, ossia come condizioni a cui il sistema che si deve realizzare deve rispondere, e non come specificazioni, sia pure di alto livello, ossia come indicazioni esplicite di modalità operative, ambienti software, strumenti.

Anche in questo ambito lo studio di fattibilità potrà peraltro produrre indicazioni vincolanti, secondo quanto verrà specificato nel successivo paragrafo.

In questo paragrafo andranno evidenziati i requisiti di qualità sia in termini di qualità del processo di produzione, sia in termini di qualità del prodotto/servizio che il progetto deve costruire/erogare, ossia ad esempio il sistema applicativo che si intende realizzare oppure i servizi che dovranno essere erogati da una infrastruttura tecnologica.

Per quanto riguarda la qualità del processo di produzione, ossia le modalità di assicurazione della qualità che dovranno essere attivate nella conduzione del progetto realizzativo, lo studio di fattibilità dovrà fornire delle indicazioni, anche considerando la stretta correlazione che esiste tra le modalità di assicurazione della qualità previste nella conduzione del progetto e la qualità del prodotto/servizio finale.

A questo fine è prevista nello studio di fattibilità una parte specifica su questo argomento, le "Indicazioni per la gestione del piano di qualità", collocata all'interno della sezione relativa alle "Raccomandazioni per le fasi realizzative". Tale collocazione deriva dal fatto che lo studio di fattibilità potrà fornire su questo tema delle indicazioni piuttosto che veri e propri requisiti e dal fatto che una compiuta formulazione di tali indicazioni non deriva soltanto dalle caratteristiche di qualità richieste al prodotto/servizio ma anche, in larga misura, dall'analisi del rischio del progetto.

Le indicazioni prodotte dallo studio di fattibilità potranno essere recepite nel capitolato in misura totale o parziale, secondo una valutazione della dirigenza dell'amministrazione che dovrà tener conto della criticità del progetto e del livello di rischio evidenziato, ma anche del livello di maturità espresso dall'offerta di mercato nello specifico settore di fornitura richiesta.

Si potrà ad esempio:

• porre come condizione obbligatoria che il fornitore abbia superato un meccanismo di certificazione formale promosso dall'ISO (International Organization for Standardization) e sostenuto dall'Unione Europea, denominato Certificazione ISO 9000 (EN 29000);
• porre come condizione obbligatoria l'applicazione di solo una parte delle modalità di assicurazione della qualità contenute nelle norme ISO 9000;
• richiedere al fornitore di specificare quali modalità di assicurazione della qualità intende adottare e utilizzare le conseguenti indicazioni dei fornitori come criterio di selezione.

In questo contesto è quindi importante che i requisiti vengano espressi in relazione agli standard ISO 9000, ed in particolare con la ISO/DIS 9000-3 - "Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software".

I requisiti di qualità relativi al prodotto/servizio sono dei requisiti che dovranno essere recepiti integralmente dal capitolato, in quanto costituiscono delle condizioni essenziali affinché il prodotto/servizio acquisito possa portare effettivamente ai risultati attesi e quindi contribuisca al raggiungimento degli obiettivi.

Per quanto riguarda la qualità del prodotto/servizio è necessario fare una distinzione tra i progetti che riguardano la realizzazione di sistemi applicativi (e quindi in primo luogo prodotti software) e progetti che riguardano l'acquisizione di servizi informativi o la realizzazione di infrastrutture informatiche tese all'erogazione di tali servizi.

Per quanto riguarda i sistemi applicativi gli standard di riscontro sono costituiti dagli standard ISO/IEC 9126:1991 - Information technology - "Software product evaluation - Quality characteristics and guidelines for their use", che rappresenta il punto di riferimento centrale per la definizione dei requisiti di qualità del software. Tali standard individuano 6 requisiti di qualità primari, ognuno specificabile attraverso alcune caratteristiche di fondo. La tabella seguente schematizza l'impostazione dei requisiti di qualità secondo tale norma.

Sulla base di queste indicazioni lo studio di fattibilità dovrà esplicitare le caratteristiche di qualità che assumono particolare importanza nello specifico contesto del progetto, individuando metriche e valori obiettivo o comunque specifici requisiti per ognuna di esse.

Per quanto riguarda i servizi informativi, e di conseguenza anche le infrastrutture tecnologiche che debbono erogare tali servizi, il punto di riferimento è costituito dalla norma ISO9004-2:1991 - Quality management and quality system elements -- Part 2: Guidelines for services", con particolare riguardo a quanto contenuto nelle sezioni relative alle "specifiche del servizio", "specifiche di realizzazione del servizio" e "specifiche controllo qualità del servizio".

Per quanto riguarda poi le tecnologie (apparati e apparecchiature) si potrà fare riferimento, ove disponibili, a specifiche norme e standard, sia in termini di caratteristiche ergonomiche che di MTBF, MTTR ecc.

Riguardo ai servizi è indispensabile produrre una descrizione esauriente dei servizi forniti e delle caratteristiche previste, principalmente in termini di disponibilità (ad es. orario di attivazione), di tempi di risposta, di affidabilità ecc.

E' poi importante definire anche alcune caratteristiche relative alle modalità di produzione/erogazione del servizio (personale dedicato come numero e caratteristiche professionali, risorse strumentali dedicate, modalità di controllo e di regolazione ecc.), ed è utile definire le regole di comunicazione con l'utenza sia in termini di informazione e assistenza che come modalità di ricezione delle problematiche e delle esigenze di miglioramento.

Sarà compito dello studio di fattibilità definire le esigenze di fondo su queste tematiche, sia in termini qualitativi che quantitativi, modellandole sulle specifiche caratteristiche del servizio informatico erogato, individuando metriche e valori obiettivo.

Si rimanda alla "Guida Operativa..." per un approfondimento degli standard e delle norme citate e per la proposizione di esempi ed indicazioni.

In questa parte del documento di studio di fattibilità si debbono evidenziare le specifiche generali del sistema informativo da realizzare o modificare, ossia quelle caratteristiche o proprietà essenziali che il sistema dovrà avere per rispondere alle esigenze e ai requisiti individuati.

In particolare dovranno essere recepite nello studio le specifiche necessarie a ché il nuovo sistema informativo si integri convenientemente nel complesso del sistema informativo dell'amministrazione e risponda alle scelte architetturali complessive dell'amministrazione (la "visione" tecnologica") e agli standard aziendali vigenti.

Lo studio di fattibilità non dovrà naturalmente evidenziare specifiche di dettaglio, che potranno essere definite solo in fase di progettazione di dettaglio (sia applicativa che tecnica) e si concentrerà soltanto su quelle specifiche che incidono sulla natura stessa della soluzione e che pertanto è importante definire come vincolanti nella fornitura.

Come già affermato nel paragrafo relativo alla valutazione delle alternative, è infatti certamente vantaggioso dare ai fornitori la possibilità ai fornitori di indicare nelle offerte anche sistemi con differenti caratteristiche tecniche e funzionali nonché diverse modalità di realizzazione, purché rispondenti ai requisiti e alle specifiche generali.

L'esatta determinazione del confine tra l'opportunità di limitarsi, nello studio di fattibilità, alla definizione dei requisiti e la necessità di esprimere delle specifiche dipende inevitabilmente dai diversi contesti in cui si colloca il progetto e dalle caratteristiche del progetto stesso, per cui è in notevole misura affidata alla professionalità e alla sensibilità di chi conduce lo studio.

E' ad esempio perfettamente legittimo che un'amministrazione, avendo già in esercizio, ad esempio, un buon numero di reti locali governate da un certo sistema operativo di rete o avendo impiegato un determinato DBMS, ed avendo costruito su questi strumenti una notevole esperienza che consente di effettuare con proprie risorse l'attività di gestione e di prima manutenzione (pensiamo anche agli uffici periferici), ritenga opportuno indicare come specifica di un nuovo sistema da realizzare l'utilizzo di quel sistema operativo o di quel determinato DBMS.

Ma è altrettanto legittimo, in un contesto differente non caratterizzato dalle condizioni precedenti, che lo studio di fattibilità e di conseguenza il capitolato di gara si limitino alla esposizione dei requisiti funzionali e prestazionali, lasciando ai fornitori e alle offerte la possibilità di indicare prodotti diversi.

Le specifiche applicative riguarderanno l'architettura dati e l'architettura applicativa, ossia l'individuazione e la descrizione dei principali archivi e dei vari sotto-sistemi che forniscono l'insieme delle funzionalità informatizzate del sistema.

Dal punto di vista dei dati si dovrà porre specifica attenzione alle problematiche di avvio (popolazione iniziale delle basi di dati) e alle problematiche di gestione (modalità di aggiornamento, assicurazione della coerenza e integrità ecc.).

Dal punto di vista delle funzioni sarà necessario individuare gli insiemi di funzioni che andranno a costituire specifici sottosistemi distinti, per collocazione, modalità di accesso, modalità di gestione.

In quest'area un elemento essenziale consiste nella necessità di definire la distribuzione di dati e applicazioni, all'interno di un'ottica client-server, definizione che impone implicitamente l'esame di più alternative.

Si dovranno pertanto svolgere sia considerazioni riguardanti la funzionalità, l'affidabilità e la sicurezza del sistema, sia considerazioni riguardanti aspetti più direttamente connessi con il costo del progetto quali la necessità di impiego delle infrastrutture di comunicazione e l'esigenza di assistenza tecnica e manutenzione in periferia.

Per questo aspetto può costituire un valido punto di riferimento la classificazione dei modelli di distribuzione proposta da alcuni osservatori internazionali che individua sei tipologie di distribuzione: presentazione distribuita, presentazione remota, logica applicativa distribuita, gestione dati remota, gestione dati distribuita, gestione dati distribuita e logica distribuita.

Si fa riferimento alla "Guida Operativa.." sia per questo schema di classificazione che per indicazioni sulle tecniche da utilizzare per individuare il progetto della distribuzione di dati e applicazioni.

Si ritiene peraltro che una compiuta disamina delle alternative in termini di distribuzione sia opportuna nello studio di fattibilità qualora la scelta abbia conseguenze significative in termini di risvolti organizzativi e operativi e di responsabilità, ad esempio nella determinazione di chi sarà chiamato a svolgere le attività di amministrazione dei dati e di conduzione e manutenzione dei sistemi, mentre potrà essere lasciata alle offerte negli altri casi.

Un altro elemento di specifica riguarda le problematiche di presentazione, ossia in senso lato l'interfaccia utente, elemento essenziale per assicurare apprendibilità e facilità d'uso e quindi in ultima analisi l'accettazione del nuovo sistema da parte degli utenti.

Le specificazioni dovranno riguardare le modalità di presentazione, le modalità di navigazione all'interno delle applicazioni, la "robustezza" del sistema rispetto ad operazioni improprie, particolari esigenze di sicurezza per le quali non è sufficiente l'enunciazione di requisiti ma è utile definire specifici meccanismi da utilizzare (ad es. il riconoscimento dell'utente con meccanismi più sofisticati del consueto sistema basato su codice e password), la disponibilità e l'organizzazione di aiuto in linea ecc.

In quest'area la soluzione ottimale è naturalmente rappresentata dall'esistenza di standard dell'amministrazione, nel qual caso lo studio di fattibilità potrà limitarsi alla semplice riaffermazione della necessità di adeguarsi ad essi, concentrandosi su eventuali elementi di specificità del progetto.

Se il progetto prevede l'erogazione di servizi si dovranno definire le loro caratteristiche specifiche essenziali. Questo vale sia per servizi erogati da infrastrutture tecnologiche, per i quali potrà essere importante definire ad esempio modalità di accesso e modalità di erogazione, sia per servizi collaterali previsti dal progetto quali ad esempio la formazione e l'assistenza utenti (help-desk), di cui dovranno essere individuate e descritte contenuti, caratteristiche, modalità di accesso ed erogazione ecc.

In questa sezione del documento si dovranno definire gli elementi essenziali riguardanti la configurazione tecnologica del sistema in termini di numero, distribuzione e caratteristiche dei posti di lavoro, di dimensioni, caratteristiche e natura dei poli elaborativi, di struttura e caratteristiche della rete di comunicazione, di software di base e di software di rete da utilizzare.

E' in quest'area che si dovranno risolvere le problematiche di dimensionamento dei sistemi e della rete, partendo dai requisiti espressi in termini di volumi da trattare (sia come volume di dati che come carico operativo del sistema) e applicando le opportune tecniche di Capacity Planning e Capacity Mangement. Si rimanda per questi aspetti alla "Guida Operativa..."

Nella definizione delle specifiche tecnologiche ed in particolare nella determinazione delle caratteristiche di accentramento/distribuzione del sistema non si parte in generale da zero ma esistono scelte architetturali complessive dell'amministrazione (derivanti dalla "visione" tecnologica definita) a cui fare riferimento.

Il problema si pone, come già affermato nel paragrafo dedicato all'esame delle alternative, nel caso in cui non esista una specifica "visione" e soprattutto nei casi in cui il progetto si collochi in un contesto già caratterizzato dalla presenza di soluzioni architetturali date. In questo caso si dovranno esaminare e valutare compiutamente le alternative tecnologiche essenziali, attraverso una comparazione basata sul rapporto costi-benefici, ed arrivando ad una scelta univoca.

Questo implica la necessità di sviluppare la descrizione delle diverse ipotesi fino al livello necessario per poter arrivare ad un confronto in termini funzionali ed economici e quindi consentire una sia pur sommaria stima dei costi.

Nel caso di valutazione delle alternative è necessario esplicitare i criteri con cui verranno esaminate le varie ipotesi al fine della scelta tra di esse.

Questa esplicitazione dovrà distinguere tra criteri di qualità e criteri economici.

I criteri di qualità dovranno essere formulati in maniera rigorosa e non ambigua, al fine di poter valutare le alternative in maniera chiara e trasparente, e dovrà esser loro attribuito un peso in maniera da poter esprimere una scelta anche tra due soluzioni che hanno rispettivamente un maggior grado di qualità e un minor costo.

I criteri di economicità sono concettualmente ovvi, in quanto è naturalmente da preferire l'ipotesi a costo minore.

Si dovrà poi evidenziare nel documento, sia nel testo che attraverso tabelle di riepilogo utili alla immediata comprensione, i costi e le valutazioni di qualità relativi alle varie alternative.

Per ognuna di esse pertanto sarà necessario:

• esplicitare le valutazioni funzionali e di qualità effettuate e motivare la valutazione data, che dovrà essere espressa attraverso un semplice sistema di punteggi che consenta un confronto agevole;
• descrivere i criteri di stima adottati per arrivare alle ipotesi di costo evidenziate. Nella determinazione dei costi è importante porre attenzione al fatto che si dovranno esplicitare e confrontare i costi complessivi delle varie alternative, ossia sia i costi di realizzazione che i costi di gestione, per i quali sarà necessario fare riferimento allo stesso periodo (in genere tre anni) che sarà poi utilizzato per la valutazione costi-benefici.

Infine sarà necessario il riepilogo finale e l'esplicitazione della scelta proposta.

E' evidente peraltro che la comparazione economica non riguarderà l'insieme del progetto ma soltanto la componente su cui si è individuata la possibilità di ipotesi differenti e le componenti di costo da essa influenzate.

Come già affermato all'inizio del paragrafo, la valutazione delle alternative ha senso solo per quelle specifiche che incidono pesantemente sulla natura stessa della soluzione e sulle quali è importante acquisire elementi a supporto della scelta che dovrà inevitabilmente essere operata dall'amministrazione.

In questa sezione del documento si definiranno le principali modalità realizzative da adottare, ossia sostanzialmente le scelte di realizzazione ex-novo di un sistema applicativo ad hoc piuttosto che l'acquisizione di pacchetti presenti sul mercato o disponibili presso altre amministrazioni ("make or buy") e le scelte in ordine al riuso di componenti esistenti.

Una prima accezione dell'alternativa "make or buy" consiste nella scelta tra l'acquisizione di pacchetti standard (o addirittura di applicazioni ad hoc già sviluppate e funzionanti in altre situazioni) e lo sviluppo ex-novo.

La disponibilità di pacchetti standard o addirittura la possibilità di acquisire applicazioni che coprono funzionalità identiche o simili sviluppate per altre amministrazioni rappresenta una opportunità in termini di risparmio e di accorciamento dei tempi di realizzazione senz'altro colta in maniera non adeguata dalle amministrazioni.

Nei casi di progetti relativi alla realizzazione o reingegnerizzazione di sistemi applicativi che riguardano processi standard (tipicamente le procedure informatiche a supporto dei processi di auto-amministrazione), uno dei compiti essenziali dello studio di fattibilità è invece proprio quello di esaminare queste opportunità e di valutarne la convenienza.

Il gruppo di lavoro che conduce lo studio di fattibilità dovrà pertanto, una volta definiti i requisiti del sistema che si deve realizzare, procedere ad un esame dei sistemi eventualmente disponibili presso altre amministrazioni e/o presenti nell'offerta di mercato e alla valutazione comparata di queste possibilità con la realizzazione ex-novo.

La valutazione dovrà tener conto sia degli aspetti funzionali, che degli aspetti tecnici, oltre naturalmente, all'aspetto economico.

Dal punto di vista funzionale dovrà essere fatta una mappatura delle funzioni offerte dalle soluzioni disponibili con i requisiti espressi in precedenza, mentre dal punto di vista tecnico si dovrà mappare la coerenza dell'ambiente tecnologico utilizzato con il contesto tecnico dell'amministrazione.

Per poter considerare valida la possibile adozione del sistema o del pacchetto non è ovviamente necessaria una rispondenza completa ai requisiti (estremamente rara) e una totale coerenza tecnica ma sarà sufficiente una corrispondenza di fondo, il che significa che non sarà particolarmente pesante la necessaria attività di personalizzazione.

Dal punto di vista economico occorrerà considerare i costi di acquisizione e di manutenzione dei pacchetti ed effettuare una stima di massima dell'impegno di personalizzazione. Questi costi dovranno essere comparati con la stima relativa alla realizzazione ex-novo, tenendo conto che sarà sufficiente arrivare a stime di larga massima, dato che in generale il risparmio economico di queste soluzioni rispetto al nuovo sviluppo è considerevole.

Se lo studio di fattibilità ravvisa la possibilità di percorrere la strada dell'acquisizione dell'applicazione da un'altra amministrazione, questa soluzione potrà essere direttamente perseguita attivando immediatamente la disamina di dettaglio tesa alla definizione dell'attività di personalizzazione.

Se lo studio di fattibilità invece evidenzia l'opportunità di ricorrere a pacchetti presenti sul mercato, la soluzione più conveniente è quella di selezionare un numero limitato di possibili fornitori, quelli che più si avvicinano ai requisiti espressi, allo scopo di arrivare ad una gara relativa all'acquisizione del pacchetto e alla sua personalizzazione, da condursi con l'opportuna procedura di approvvigionamento, che preveda uno spettro limitato di offerte. In questo caso diventa importante che lo nello studio di fattibilità si dedichino risorse e tempo sufficienti ad una vasta disamina dell'offerta del mercato.

Si rimanda alla "Guida Operativa..." per più dettagliate indicazioni sull'esame dell'offerta di mercato e sulle modalità di mappatura tecnica e funzionale.

Una seconda accezione dell'alternativa "make or buy" è rappresentata dalla scelta fra l'utilizzo di risorse interne ed il ricorso al mercato, relativamente alla realizzazione di uno specifico prodotto (ad es. un sistema applicativo) o all'acquisizione di uno specifico servizio (ad es. manutenzione software, assistenza utenti, data entry..).

Questa scelta fa in genere capo a strategie già definite in una amministrazione e pertanto non è oggetto di esame in uno studio di fattibilità, in quanto risolta a monte. Possono peraltro darsi dei casi di incertezza relativa ad uno specifico progetto, specie nelle amministrazioni in cui convivono entrambe le modalità realizzative.

In questo caso è legittimo che lo studio di fattibilità affronti la questione sulla base di un confronto in termini economici e di qualità del prodotto/servizio.

Un discorso specifico va fatto per i progetti tesi all'affidamento all'esterno delle attività di conduzione, gestione e manutenzione dei sistemi informativi delle amministrazioni, comunemente note come "outsourcing".

In questo caso quindi i contenuti essenziali dello studio saranno:

• la definizione dei requisiti in termini di servizi informatici che dovranno essere acquisiti;
• la descrizione delle specifiche generali di questi servizi;
• la determinazione dei costi della situazione attuale;
• la stima dei costi della soluzione ipotizzata;
• la individuazione e valutazione dei benefici, con particolare riguardo alla determinazione dell'ammontare del risparmio in termini di personale;
• l'analisi dei rischi (in genere rilevanti) dell'operazione;
• la valutazione dell'alternativa tra affidamento all'esterno e mantenimento della gestione in proprio

ed è proprio quest'ultimo aspetto che rappresenta il punto focale dello studio, per la cui risoluzione si effettuano tutte le attività precedenti.

E' quindi ovvio che in tale situazione è proprio questa parte dello studio che dovrà essere curata con particolare attenzione.

A conclusione dello studio, se verrà presa dall'amministrazione la decisione di procedere all'esternalizzazione, requisiti e specifiche dei servizi forniranno la base su cui costruire il capitolato di gara.

Un altro punto essenziale che lo studio di fattibilità deve risolvere è quello relativo al riuso o meno di componenti esistenti, specie nei casi di progetti tesi alla reingegnerizzazione di sistemi applicativi o di infrastrutture tecnologiche.

La problematica del riuso riguarda in rari casi le apparecchiature, quasi sempre i dati (per i quali è da prevedere la migrazione nel nuovo sistema) ed in certi casi il software applicativo.

Per quanto riguarda le apparecchiature il problema è minore in quanto si presenta raramente e si risolve attraverso una analisi della rispondenza delle apparecchiature stesse ai requisiti e alle specifiche dell'architettura tecnologica prevista.

Per quanto riguarda i dati la questione è nota e consiste nella determinazione delle modalità di migrazione delle informazioni nel nuovo sistema.

E' quindi indispensabile che lo studio di fattibilità affronti questo aspetto con il dovuto approfondimento individuando soluzioni tecniche, modalità operative, tempistica e stimando l'impegno ed il costo necessario, dato che questa migrazione rappresenta una componente critica del progetto e talvolta di costo e difficoltà non indifferente.

Infatti la necessità di migrazione mette in luce problemi già presenti e spesso irrisolti di qualità ed integrità delle informazioni attualmente possedute dall'amministrazione, tanto che in certe situazione lo studio di fattibilità dovrà valutare la possibilità di introdurre nel progetto specifiche attività di recupero della qualità dei dati, che dovranno essere convenientemente definite e stimate.

Il punto più critico riguarda però il riuso delle componenti software. In questo caso lo studio di fattibilità dovrà approfondire con un dettaglio sufficiente a portare ad una scelta ragionata lo stato delle applicazioni che è possibile incorporare nel nuovo sistema. Si tratta pertanto di una necessità di valutazione delle alternative.

Nel corso dello studio di fattibilità si dovrà pertanto esaminare e valutare il software esistente, in particolare le componenti software più specializzate ed onerose, allo scopo di arrivare ad una loro valutazione funzionale e tecnica che consenta di definire la scelta più opportuna tra le possibilità di:

• completo abbandono con riprogettazione integrale;
• utilizzo "as-is" attraverso operazioni di incapsulamento;
• standardizzazione dei nomi;
• riformattazione (intervento solo sull'aspetto esterno del codice a fini di ridocumentazione);
• ridocumentazione completa;
• ristrutturazione del codice (da non strutturato a strutturato con eliminazione codice ridondante ecc.);
• modularizzazione;
• migrazione;
• reingegnerizzazione completa (riscrittura ricavando requisiti da esistente).

E' opportuno in questa operazione ripercorrere i passi già previsti nell'esame di altre alternative (mappatura requisiti, valutazione funzionale e tecnica dell'esistente, stima dell'impegno comparata con l'ipotesi di riferimento che in questo caso è costituita dalla riprogettazione completa.

In queste valutazioni occorre verificare la possibilità di fare ricorso a strumenti automatici.

In questa sezione dello studio si dovranno esaminare le problematiche relative alla messa in produzione e all'avvio del nuovo sistema.

Qualora le problematiche di avvio assumano un peso significativo questa parte dovrà essere particolarmente curata esaminando in dettaglio le problematiche di installazione e di diffusione del nuovo sistema informativo, problematiche spesso trascurate e causa di rilevanti problemi per il buon andamento dei progetti.

Tra queste problematiche si annoverano quelle relative alla transizione tra situazione informatica attuale e situazione futura, con particolare riferimento alle necessità di gestire un periodo di parallelo tra vecchio e nuovo sistema e ai problemi di allineamento che questo comporta.

Le attività di messa in produzione ed avvio del nuovo sistema dovranno poi trovare una loro collocazione precisa nel piano di progetto e prevedere il coinvolgimento e l'assunzione di responsabilità di molteplici figure (settore informatico dell'amministrazione, fornitore, responsabili utenti).

In alcuni casi la rilevanza (ed il rischio) di queste attività di avvio è tale che lo studio di fattibilità potrà definire l'opportunità di spezzare il progetto in due parti, una relativa alla sola realizzazione ed una relativa all'installazione, diffusione e avvio (vedi il paragrafo relativo alla segmentazione dei progetti e le specificazioni sulla specifica tipologia di progetti di installazione e diffusione).

In questa sezione del documento andranno evidenziate le necessità di manutenzione del sistema e quindi di tutte le sue componenti, individuandone contestualmente i requisiti, le modalità operative, gli impegni necessari.

Questa parte dovrà essere curata con particolare attenzione data la sua rilevanza ai fini della esatta determinazione dei costi del progetto.

Allo scopo di minimizzare i pur necessari costi di manutenzione dovranno essere esaminate le possibilità di ottenere garanzie sul sistema nel suo complesso e sulle sue specifiche componenti e valutata l'alternativa "make or buy".

E' infine necessario che in questa sezione del documento si evidenzino le future necessarie attività per la conduzione del sistema, individuando attività, compiti e risorse necessarie, base indispensabile per la successiva determinazione dei relativi costi. Anche rispetto a queste attività dovrà essere esaminata l'eventuale alternativa in termini di "make or buy", ossia la convenienza o meno di esternalizzare l'attività di conduzione, alternativa che dovrà peraltro essere inquadrata nelle strategie complessive dell'amministrazione in questo campo.

In questa parte del documento si evidenzieranno le necessità di formazione necessarie all'attivazione del sistema, formazione che si dovrà rivolgere in maniera differenziata ai dirigenti, agli utenti e al personale informatico.

Si dovrà pertanto delineare un piano di formazione per tutte queste tipologie di personale, indicandone i fruitori, i contenuti di massima, la durata, le modalità di erogazione, gli impegni necessari.

E' inoltre essenziale progettare contenuti e modalità dell'assistenza che si prevede di fornire agli utenti, specialmente nelle prime fasi di esercizio del nuovo sistema.

Dal punto di vista dei contenuti sarà necessario distinguere l'assistenza di tipo specificatamente tecnologico da quella di tipo applicativo, individuando per ognuna l'ambito e la responsabilità,.