Tabella 2 - Indice di massima della Sezione seconda - Progetto di massima
Il progetto di massima contenuto nello studio di fattibilità consiste in una descrizione del sistema informativo previsto che si compone della definizione dei requisiti, ossia delle condizioni che il sistema considerato deve soddisfare, delle specificazioni del sistema, ossia di una descrizione del sistema proposto in termini di proprietà e delle principali modalità di realizzazione..
Poiché l’elaborazione del progetto di massima all’interno dello studio di fattibilità risponde principalmente all’esigenza di verificare la fattibilità del progetto e di stimarne costi, benefici e tempi, la descrizione del progetto che scaturisce dallo studio di fattibilità sarà necessariamente ad uno stadio di definizione non esaustivo, principalmente in termini di dettaglio e di completezza.
Dal punto di vista del dettaglio si avrà un grado di definizione del progetto caratterizzato da un elevato livello di aggregazione e generalizzazione.
Elevato livello di aggregazione significa che non tutte le componenti del sistema informativo che si intende sviluppare sono completamente scomposte e descritte e che quindi, per arrivare ad una definitiva descrizione del sistema, occorrerà procedere ad ulteriori passi di scomposizione e descrizione. Ad esempio si potrà aver individuato e descritto un sotto-sistema, ma non tutte le funzioni applicative che lo compongono.
Elevato livello di generalizzazione significa che non sono stati individuati e descritti tutti i sotto-tipi e tutte le specializzazioni delle componenti del sistema ma che ci si è limitati all’esame dei casi normali o generali. Ad esempio si potrà aver individuato e descritto la modalità standard di trattamento di una pratica ma non aver analizzato e descritto la gestione delle eccezioni.
Dal punto della completezza si avrà un grado di definizione del progetto caratterizzato da una estensione parziale e non totale, ossia dal fatto che la descrizione delle componenti del sistema informativo (secondo i vari punti di vista) potrà coprire solo una porzione del sistema. Si potrà ad esempio aver definito compiutamente le modalità di interfaccia utente per la componente principale del sistema applicativo ma aver tralasciato quelle di altre componenti di secondaria importanza.
Questo vale prima di tutto per le specificazione del sistema, per le quali si avrà in genere sia una assenza di completezza, sia la presenza di notevole generalizzazione.
1.3.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. E' importante che lo studio di fattibilità arrivi ad individuare e descrivere tutti i requisiti (estensione totale), anche se ad un livello di dettaglio magari incompleto. Facendo l’esempio di un sistema applicativo che deve integrarsi con altri sistemi, lo studio di fattibilità dovrà:
1.3.2.2 Dettaglio del processo previsto (dopo l'intervento)
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.
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).
1.3.2.3 Interventi previsti sulle componenti non informative del processo
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.
1.3.2.4 Necessità di modifica della normativa
Nel contesto della Pubblica Amministrazione assume particolare importanza l'esplicitazione delle modifiche normative che si ravvisano come necessarie e dei passaggi previsti per la loro attuazione.
1.3.2.5 Requisiti del sistema informativo da realizzare
Questa parte dello studio di fattibilità consiste nella individuazione e rappresentazione dei requisiti essenziali a cui il nuovo sistema informativo dovrà rispondere.
Informazioni trattate 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.
Funzioni informatizzate La descrizione delle funzionalità è indispensabile per tutti i progetti che riguardano sistemi applicativi, per i quali è essenziale individuare i principali sottosistemi funzionali che costituiranno il sistema e le relazioni che intercorrono tra di loro, in termini di flussi informativi.
Modalità di lavoro 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.
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. Requisiti architetturali Il sistema che si intende realizzare si dovrà comunque collocare, nella generalità dei casi, all’interno di una più complessiva struttura informatica, con inevitabili necessità di interfaccia con altri sotto-sistemi e dovrà pertanto essere coerente con la una visione architetturale spesso già data. Inoltre, si può porre un problema di interfaccia con sistemi esterni (per la PA ad es. di altre amministrazioni). Da queste considerazioni scaturisce la possibilità di definire specifici requisiti in ordine all’architettura tecnologica del sistema applicativo o dell’infrastruttura tecnologica da realizzare, per garantire coerenza nell'utilizzo delle tecnologie e integrazione con l’ambiente circostante.
Requisiti di qualità 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.
Il punto centrale dei requisiti di qualità che lo studio di fattibilità deve esprimere riguarda però i requisiti di qualità del prodotto/servizio erogato. Per questi è 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. 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 "ISO 9004-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.
1.3.2.6 Specifiche generali del sistema
In questa parte dello studio di fattibilità si debbono evidenziare le specifiche generali del sistema informativo da realizzare o modificare, ossia quelle caratteristiche o proprietà essenziali per rispondere alle esigenze e ai requisiti individuati. In particolare dovranno essere recepite nello studio le specifiche necessarie a ché il nuovo sistema si integri nel complesso del sistema informativo esistente e risponda alle scelte architetturali e agli standard vigenti.
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.
1.3.2.7 Specifiche applicative
Le specifiche applicative riguardano 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.
In quest’area un elemento essenziale consiste nella necessità di definire la distribuzione di dati e applicazioni, all’interno di un’ottica client-server. In quest'area si potranno 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.
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.
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.
1.3.2.8 Specifiche tecnologiche
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 questa sezione che si colloca la già citata questione delle alternative architetturali. Nel caso si ponga una questione di alternative, sorge 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.
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 dovranno poi evidenziare nel documento, anche con tabelle di riepilogo utili alla immediata comprensione, i costi e le valutazioni di qualità relativi alle varie alternative.
1.3.2.9 Modalità di realizzazione
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.
1.3.2.10 "Make or buy"
"Make or buy" -1 - Nuovo sviluppo vs. pacchetti standard o applicazioni 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.
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 dell'offerta di mercato (e, se possibile, dei sistemi analoghi presenti in situazioni simili) alla valutazione comparata di queste possibilità con la realizzazione ex-novo.
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.
Se lo studio di fattibilità evidenzia l’opportunità di ricorrere a pacchetti presenti sul mercato, la soluzione più conveniente è in genere 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 nello studio di fattibilità si dedichino risorse e tempo sufficienti ad una vasta disamina dell’offerta del mercato.
"Make or buy" - 2 - Utilizzo risorse interne o ricorso al mercato 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..).
"Make or buy" - 3 - Esternalizzazione o meno delle attività di conduzione, gestione e manutenzione dei sistemi informativi delle amministrazioni 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". Per questi progetti tutto il problema ruota intorno all’alternativa "make or buy" e quindi all’esame delle alternative. In questo caso quindi i contenuti essenziali dello studio saranno:
1.3.2.11 Riuso di componenti esistenti
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 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.
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.
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.
1.3.2.12 Avvio del nuovo sistema
In questa sezione dello studio si dovranno esaminare le problematiche relative alla messa in produzione e all’avvio del nuovo sistema, con specifica attenzione all'installazione e alla diffusione del nuovo sistema, spesso trascurate e causa di rilevanti problemi per il buon andamento dei progetti, specie nel caso di molteplicità di siti. Un'altra classica questione riguarda la transizione tra situazione 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 dovranno trovare una loro collocazione 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, come già evidenziato nel paragrafo relativo alla segmentazione dei progetti.
1.3.2.13 Esercizio e manutenzione del sistema
In questa sezione del documento andranno evidenziate le necessità di manutenzione del sistema in tutte le sue componenti, individuandone i requisiti, le modalità operative, gli impegni necessari.
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.
1.3.2.14 Formazione e assistenza utenti
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.
In questa parte dello studio 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.
Su tutti questi elementi si rimanda al capitolo relativo alla reingegnerizzazione dei processi, ribadendo la necessità che lo studio di fattibilità consideri tutte le dimensioni del processo di servizio, evitando di privilegiare la sola dimensione tecnologica.
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.
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:
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 non vengono qui compiutamente trattate e si propone solo 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.
E’ poi importante, specie in determinati contesti, correlare al modello le informazioni relative alla dimensione della base informativa, alle specifiche necessità di sicurezza e alla evoluzione degli elementi informativi in termini di cambiamento di stato.
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, gli eventi di attivazione, la specificazione delle eventuali necessità di interfaccia tra sottosistemi e con altri sistemi applicativi, la matrice di relazione tra informazioni e sotto-sistemi.
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:
In una organizzazione le scelte di fondo su decentramento/accentramento, sulle esigenze di connettività, interoperabilità e portabilità, sulla condivisione delle basi di dati ecc., non saranno in discussione in ogni specifica realizzazione e potranno quindi essere definite dallo studio di fattibilità. 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.
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:
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.
Per una trattazione più completa delle problematiche di qualità si rimanda comunque ad un apposito capitolo.
Lo studio di fattibilità non dovrà evidenziare specifiche di dettaglio, che potranno essere definite solo in successive fasi di progettazione (sia applicativa che tecnica) e si concentrerà soltanto su quelle specifiche che incidono sulla natura stessa della soluzione.
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.
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.
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 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.
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 aziendali, 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.
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 Management.
Nello stesso tempo è necessario che lo studio espliciti i criteri con cui verranno valutate le varie alternative, distinguendo tra criteri di qualità e criteri economici.
Per ognuna di esse sarà quindi necessario:
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.
La disponibilità di pacchetti standard o addirittura la possibilità di acquisire applicazioni che coprono funzionalità identiche o simili sviluppate per altre situazioni rappresentano opportunità in termini di risparmio e di accorciamento dei tempi di realizzazione che lo studio di fattibilità deve di esaminare e valutare. Quando pertinente, l'esame di questa tipologia di alternativa è uno degli adempimenti essenziali dello studio.
La valutazione dovrà tener conto sia degli aspetti funzionali, che degli aspetti tecnici, oltre naturalmente, all’aspetto economico.
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.
Questa scelta fa in genere capo a strategie già definite in una amministrazione e pertanto è raramente 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.
ed è proprio quest’ultimo aspetto che rappresenta il punto focale dello studio, per la cui risoluzione si effettuano tutte le attività precedenti. 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.
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.
Si dovrà pertanto esaminare e valutare il software esistente, in particolare le componenti 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:
In queste valutazioni occorre verificare la possibilità di fare ricorso a strumenti automatici.
Questa parte dovrà essere curata con particolare attenzione data la sua rilevanza ai fini della esatta determinazione dei costi del progetto e, 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".
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à,.
Dal punto di vista delle modalità di erogazione si dovrà definire l’insieme di strumenti da utilizzare (help-desk, creazione di figure che assumono un ruolo di "focal point", diffusione della documentazione, utilizzo di strumenti elettronici quali posta elettronica, bacheca elettronica ecc., eventuale definizione di assistenza di primo e secondo livello..), nonché definire ruoli, responsabilità, procedure.
segue: 1.3.3 Analisi del rischio
inizio: Lo studio di fattibilità
home: Lo studio di fattibilità