2.3 Valutazioni comparative e acquisizioni

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "2.3 Valutazioni comparative e acquisizioni"

Transcript

1 2.3 Valutazioni comparative e acquisizioni Una volta effettuata la valutazione strategica di cui al punto 2.2, attraverso la quale la singola P.A. avrà la consapevolezza di come il software OS possa essere adottato con risultati vantaggiosi, i progetti esecutivi dovranno tenere conto della normativa in vigore. Il Codice dell Amministrazione digitale stabilisce che l analisi delle soluzioni informatiche nella PA debba avvenire mettendo sullo stesso piano soluzioni Open Source con soluzioni proprietarie o miste, effettuando confronti comparativi che non discriminino a priori le soluzioni valutate. Le valutazioni comparative tengono conto di una serie di considerazioni di natura generale che vedono i sei punti seguenti come importanti elementi di valutazione: 1) TCO (costo totale di possesso) della singola soluzione (il TCO deve essere calcolato su di un arco temporale ampio affinché possa essere fatta un adeguata valutazione del rapporto tra gli investimenti fatti ed il ritorno degli stessi); 2) Costo di uscita dalla soluzione (Occorre che venga valutato il costo di uscita da una soluzione in termini sia tecnologici che di formazione degli utilizzatori); 3) Valorizzazione delle competenze tecniche possedute dall amministrazione ( valutazione di come la soluzione aumenta le competenze interne ); 4) Interoperabilità intesa per la PA nel suo complesso (Utilizzo di formati aperti e standard, piattaforme multiple); 5) Valutazione dell interesse di altre amministrazioni al riuso dell applicazione da realizzare e/o acquistare (Attenzione al riuso e quindi in caso di sviluppo di nuove soluzioni, indicazione di caratteristiche atte alla portabilità e alla fruibilità da parte di altri utilizzatori); 6) Valore sociale della soluzione (Analisi di quanto la soluzione porta eventuali benefici alla comunità in termini di attività orientata all erogazione di servizi); Nella individuazione delle soluzioni da adottare, facendo particolare riferimento alla riusabilità di SW esistente alla quale tutte le PA centrali e locali devono tendere, occorre che la rispondenza alle proprie esigenze venga effettuata attraverso un analisi delle possibili soluzioni tra le seguenti possibilità e secondo l ordine indicato: a) riuso di programmi informatici sviluppati ad hoc per altre amministrazioni con verifica sul sito del CNIPA della presenza di programmi idonei; b) sviluppo di programmi informatici ad hoc, sulla scorta dei requisiti indicati dalla stessa amministrazione committente, la quale rilascerà il prodotto con codice sorgente aperto con la licenza OS che riterrà più idonea mettendo a disposizione pubblica i sorgenti; c) acquisizione di programmi informatici a codice sorgente aperto; d) acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d'uso;

2 e) acquisizione mediante combinazione delle modalità di cui alle lettere precedenti. Pertanto assume un ruolo fondamentale il catalogo (archivio elettronico visibile e consultabile datta rete) mantenuto dal CNIPA come riferimento per le PA, fungendo da elemento catalizzatore delle soluzioni adottate dalle PA centrali e locali e favorendo il confronto con le proposte che il mercato può offrire. Attraverso il catalogo possono essere messe a disposizione Best Pratice ed i sorgenti SW che possono preferibilmente essere depositati sul sito del CNIPA (Ambiente di sviluppo cooperativo) oppure su altri repository verso i quali vengono resi disponibili i link di collegamento. L individuazione di Best Pratice può favorire un incentivo alle PA nelle loro componenti politiche e tecniche per adottare soluzioni che possano essere prese a riferimento da altre amministrazioni per qualità ed economicità, evitando il proliferare di soluzioni duplicate che potrebbero richiedere investimenti ex novo per la soluzione di problemi già risolti altrove. Allegati: A) Valutazioni comparative e acquisizioni B) Linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA

3 Allegato A) Valutazioni comparative e acquisizioni Analisi comparativa delle soluzioni. 1. Le pubbliche amministrazioni, nel rispetto della legge 7 agosto 1990, n. 241 e del decreto legislativo 12 febbraio 1993, n. 39, acquisiscono programmi informatici a seguito di una valutazione comparativa tra le diverse soluzioni disponibili sul mercato. 2. In particolare, valutano la rispondenza alle proprie esigenze di ciascuna delle seguenti soluzioni tecniche attraverso un percorso nell ambito dell ordine con cui sono esposti i punti: a) riuso di programmi informatici sviluppati ad hoc per altre amministrazioni con verifica sul sito del CNIPA della presenza di programmi idonei; b) sviluppo di programmi informatici ad hoc, sulla scorta dei requisiti indicati dalla stessa amministrazione committente facendosi rilasciare il prodotto con codice sorgente aperto nella modalità GPL, L-GPL, altro che ne consenta la messa a disposizione pubblica dei sorgenti; c) acquisizione di programmi informatici a codice sorgente aperto; d) acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d'uso; e) acquisizione mediante combinazione delle modalità di cui alle lettere precedenti. 3. Le pubbliche amministrazioni valutano quale soluzione, tra le disponibili, risulta più adeguata alle proprie esigenze mediante comparazioni di tipo tecnico ed economico, tenendo conto anche del costo totale di possesso delle singole soluzioni e del costo di uscita. In sede di scelta della migliore soluzione si tiene altresì conto del potenziale interesse di altre amministrazioni al riuso dei programmi informatici, dalla valorizzazione delle competenze tecniche acquisite, della più agevole interoperabilità. La prospettazione degli elementi di cui sopra è peraltro oggetto di valutazione da parte del Centro nazionale per l'informatica nella pubblica amministrazione CNIPA in sede di rilascio del parere di cui all'art. 8 del decreto legislativo 12 febbraio 1993, n. 39. La suindicata valutazione va inclusa nell'ambito dello studio di fattibilità prescritto dall'art. 13 del decreto legislativo 12 febbraio 1993, n. 39, allorché si tratti di contratti di grande rilievo. Altresì deve trovare spazio tra i criteri di valutazione della convenienza, il valore sociale che porta la soluzione. E noto che le soluzioni a sorgente aperto Open Source hanno un indotto di tipo sociale che si connota con il passaggio da spesa per l acquisizione di licenze d uso ad acquisto di servizi di implementazione e personalizzazione. Questo implica un utilizzo delle risporse della PA a favore dello sviluppo delle professionalità locali, talvolta prossime all amministrazione utilizzatrice con un beneficio di tipo sociale. Criteri tecnici di comparazione. Le pubbliche amministrazioni, nella predisposizione o nell'acquisizione dei programmi informatici, privilegiano le soluzioni che presentino le seguenti caratteristiche: a) soluzioni informatiche che, basandosi su formati dei dati e interfacce aperte e standard, assicurino 1'interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione centrale e locale, salvo che ricorrano peculiari ed eccezionali esigenze di sicurezza e segreto; b) soluzioni informatiche che, in assenza di specifiche ragioni contrarie, rendano i sistemi informatici non dipendenti da un unico fornitore o da un'unica tecnologia proprietaria; la dipendenza è valutata tenendo conto dell'intera soluzione; c) soluzioni informatiche che, in assenza di specifiche e motivate ragioni contrarie, garantiscano la disponibilità del codice sorgente ai fini del riuso da parte delle pubbliche amministrazioni, fatti salvi i diritti di proprietà intellettuale;

4 d) programmi informatici che esportino dati e documenti in più formati, di cui almeno uno di tipo aperto. Riuso. 1. Al fine di favorire il riuso dei programmi informatici di proprietà delle amministrazioni, nei capitolati o nelle specifiche di progetto dovrà essere previsto, ove possibile, che i programmi sviluppati ad hoc non utilizzino piattaforme di tipo proprietario e che i sorgenti vengano depositati sull apposito sito del CNIPA che funge da repository o rimanda a specifici repository nei quali trovare i programmi sorgenti. Studio di fattibilità Onde effettuare una scelta occorre predisporre uno studio di fattibilità nel quale saranno inserite le varie alternative. Lo studio di fattibilità dovrà essere affrontato per soluzioni che superino in valore la soglia che determina l accesso a gara europea. Le alternative da considerare debbono essere situate all interno dei requisiti definiti, ossia debbono essere alternative comunque efficaci, altrimenti è inutile valutarle. Una volta esaminate e valutate le alternative, la scelta operata diventa requisito vincolante del progetto. È da considerarsi eccezionale una valutazione di alternative diverse che porti solo alla indicazione di una generica preferenza, magari da utilizzare come elemento di valutazione delle offerte. L esame delle alternative si deve concentrare solo su aspetti effettivamente essenziali e determinanti la natura della soluzione individuata. Lo studio di fattibilità dovrà esaminare e valutare compiutamente le alternative tecnologiche, attraverso una comparazione basata sul rapporto costi-benefici. Esiste poi una ovvia possibilità di alternativa in termini di modalità e specifiche realizzative. In questa area è necessario fare una distinzione tra scelte di tipo strategico, che modificano in maniera significativa la natura della soluzione che si sta definendo, e scelte che non incidono in maniera sostanziale nella definizione della soluzione, ma rappresentano soltanto diversi modi di realizzare la medesima soluzione. Rientrano tipicamente nel primo gruppo ad esempio sia le scelte relative al MAKE OR BUY, sia le scelte sull opportunità di recuperare o meno componenti del sistema esistente, magari con operazioni di incapsulamento o reingegnerizzazione. Fanno parte tendenzialmente del secondo gruppo le scelte relative a strumenti e ambienti di sviluppo, le scelte relative all interfaccia utente, le scelte relative alle modalità di interconnessione ecc. Lo studio di fattibilità si deve concentrare solo sulle alternative di tipo strategico, quelle che, modificando la natura della soluzione, incidono su costi, tempi, caratteristiche essenziali di qualità del sistema che si vuole realizzare nonché, indirettamente, anche sui benefici. Le varie modalità e specifiche realizzative, quando non incidono sostanzialmente sulla natura della soluzione stessa, non debbono quindi essere trattate come alternative, ma demandate sostanzialmente all offerta dei possibili fornitori. È infatti importante che si dia la possibilità ai fornitori di esprimere compiutamente nelle offerte la propria capacità progettuale, senza vincolarle in limiti angusti e non necessari. La proposizione dei fornitori, ovviamente principalmente in caso di progetti complessi e di forniture composite, rappresenta un patrimonio di conoscenza e di approfondimento a cui non si deve rinunciare in caso di gara, dato che può portare alla proposta di soluzioni che aggiungono qualità al sistema che si vuole realizzare.

5 La valutazione dovrà tener conto sia degli aspetti funzionali che degli aspetti tecnici, oltre naturalmente all aspetto economico e sociale. Dal punto di vista funzionale dovrà essere fatta una mappatura delle funzioni offerte dalle soluzioni disponibili con i requisiti, mentre dal punto di vista tecnico si dovrà mappare la coerenza dell ambiente tecnologico previsto dalla soluzione con il contesto tecnico dell amministrazione. È 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. PROCEDURE DI ACQUISIZIONE Le amministrazioni che intendano dotarsi di un sistema informatico dovranno effettuare (e riportare nello Studio di Fattibilità) una comparazione tra le soluzioni disponibili, sulla base anche dei seguenti elementi: Schema di riferimento Lo schema di riferimento per la valutazione dei prodotti è rappresentato nella tabella seguente. Elemento Punteggio assoluto Peso Punteggio pesato Generale X1 P1 Y1 Software X2 P2 Y2 Supporto X3 P3 Y3 Documentazione X4 P4 Y4 Addestramento X5 P5 Y5 Integrazione X6 P6 Y6 Servizi professionali X7 P7 Y7 TOTALE <=70 =10 <=100 Tab.1 Schema di assegnazione del punteggio Elementi di tipo Generale 1) TCO (costo totale di possesso) della singola soluzione; N.B. Il calcolo del TCO dovrà essere effettuato su di un arco temporale di almeno cinque anni in quanto periodi inferiori non consentono di valutare adeguatamente il rapporto tra gli investimenti ed il ritorno degli stessi. 2) costo di uscita dalla stessa; 3) valorizzazione delle competenze tecniche possedute dall amministrazione; 4) interoperabilità intesa per la PA nel suo complesso (dunque uso di formati dei dati e interfacce aperte e standard); 5) interesse di altre amministrazioni al riuso dell applicazione da realizzare e/o acquistare; 6) valore sociale della soluzione. Il punteggio totale assoluto attribuibile alla voce Generali sarà pari a 10

6 Gli elementi da valutare separatamente rispetto al Software sono 6: 1. le caratteristiche del prodotto in quanto tale; 2. il livello di supporto tecnico disponibile; 3. la documentazione disponibile; 4. le possibilità di addestramento; 5. l integrazione del prodotto in ambienti esistenti; 6. la disponibilità di servizi professionali. Per ognuno di questi elementi si deve assegnare un punteggio assoluto da 1 a 10 (X1, X6), in modo che la somma sia inferiore o al massimo uguale a 60. Si deve inoltre assegnare ad ogni elemento un peso relativo, mediante un numero da 0 a 10 (P1, P6), in base all importanza che l elemento stesso ha nel contesto di riferimento della valutazione. E necessario che la somma dei pesi sia uguale a 10. Si calcolano quindi i punteggi pesati (Y1, Y6), come prodotto di ogni punteggio assoluto per il peso relativo (X1 * P1,, X6 * P6); la somma dei punteggi pesati sarà un numero il cui valore massimo è 100. Nella tabella seguente sono riportati i valori di riferimento suggeriti per i pesi da assegnare ai diversi elementi; viene data grande importanza alle caratteristiche del software e, in secondo luogo, al supporto disponibile, mentre sono considerati alla pari e ad un livello basso di importanza gli altri fattori. E comunque opportuno adattare tali valori alle proprie esigenze specifiche, privilegiando alcuni fattori rispetto ad altri; i pesi possono essere variati anche per frazioni decimali, purché la somma sia sempre pari a 10. Elemento Peso Generale 1 Software 3 Supporto 2 Documentazione 1 Addestramento 1 Integrazione 1 Servizi professionali 1 TOTALE 10 Tab.2 Pesi di riferimento Il punteggio finale sarà tanto più elevato quanto più gli elementi di valutazione hanno avuto un riscontro positivo; per considerare un prodotto maturo è quindi necessario che il punteggio complessivo sia superiore ad una soglia definita, e la definizione di tale soglia è il punto più delicato di tutto il procedimento. La raccomandazione generale è quella di adottare come valori minimi accettabili quelli riportati nella tabella seguente, che derivano da una conoscenza di ampio respiro del mondo open source; tali valori sono comunque da considerare come riferimento, e possono essere modificati in base all esperienza o alle esigenze specifiche.

7 Tipologia di progetto Propensione al rischio Alto Basso Sperimentale Pilota Produzione Tab.3 Soglie di punteggio accettabili La matrice suddetta considera la propensione al rischio e la tipologia di progetto. La propensione al rischio si manifesta in due tendenze: alto, quando i vantaggi derivanti dall adozione precoce di una tecnologia non ancora matura giustificano i rischi legati all immaturità stessa e ai potenziali inconvenienti; è il caso, per esempio, di aziende che operano in campi altamente competitivi, in cui la fornitura di servizi innovativi e il time to market sono elementi fondamentali; basso, quando l interesse dell azienda è focalizzato ad utilizzare prodotti con caratteristiche di stabilità, di alta qualità e con funzioni complete, che presentino inoltre facilità gestionale, una ricca documentazione, ecc. La tipologia di progetto viene classificata in tre aree: sperimentale, quando lo scopo del progetto è fondamentalmente quello di acquisire dimestichezza con la tecnologia, ma non c è nell immediato l intenzione di avviare una fase di produzione; pilota, quando la tecnologia si applica ad un ambito di produzione circoscritto, per il quale non è problematica l eventualità di intervenire per aggiustamenti in corsa ; produzione, quando il sistema è la base di un importante attività di business, deve essere pienamente funzionante e garantire i necessari livelli di servizio. Nella tabella successiva è riportato un esempio generico di calcolo dei punteggi, utilizzando i pesi di default. Elemento Punteggio assoluto Peso Punteggio pesato Generale Software Supporto Documentazione Addestramento Integrazione Servizi professionali TOTALE

8 Tab.4 esempio di calcolo del punteggio

9 Elementi di valutazione Nei paragrafi successivi vengono forniti i criteri generali da considerare quando si deve esprimere una valutazione sui singoli elementi che concorrono a definire la maturità di un prodotto; da tali valutazioni scaturiscono quindi i punteggi assoluti da assegnare al prodotto stesso. Software Il primo e più importante elemento di valutazione riguarda il prodotto in quanto tale, da esaminare sotto dieci punti di vista: 1. le funzioni disponibili; 2. la qualità del software; 3. la longevità del prodotto; 4. il team di sviluppo; 5. presenza di una Comunity; 6. supporto tecnico; 7. documentazione; 8. addestramento; 9. integrazione, 10. servizi professionali. 1. Funzioni disponibili Il primo aspetto da considerare è quello delle funzionalità disponibili; queste sono in genere descritte nella documentazione del prodotto stesso, anche se a volte la documentazione può essere carente da questo punto di vista: nei prodotti commerciali, infatti, è consuetudine pubblicare documenti introduttivi, che descrivono in generale le funzioni e l architettura dei prodotti; tali documenti sono specificamente realizzati per clienti che devono operare un acquisto. Nel mondo open source, invece, è più comune la disponibilità di reference guide che sono utilizzati da utenti già esperti del prodotto. Un importante ausilio deriva dall aderenza del prodotto ad uno standard, poiché in questo caso le caratteristiche di base possono essere ricavate dalle specifiche dello standard stesso. Ulteriori possibilità di conoscenza derivano dall interazione con il team di sviluppo, che può essere disponibile a rispondere a quesiti specifici, oppure dalla presenze nel web di comunità di utenti e di mailing list che costituiscono centri di discussione e di scambio di conoscenze. 2. Qualità del software La qualità del software è un fattore molto importante per garantire che i rischi di malfunzionamento siano ridotti al minimo. Contrariamente ai prodotti commerciali, che da questo punto di vista si presentano come una scatola nera, nel mondo open source c è molta più trasparenza relativamente a questo aspetto.

10 Il primo e più immediato elemento di valutazione consiste nell esaminare il codice sorgente del prodotto, disponibile per definizione. L esame del codice sorgente può dare indicazioni significative: se il codice è scritto secondo uno stile uniforme in ogni sua parte, significa che è stato sviluppato in modo coordinato e coerente; se i programmi sono scritti in modo chiaro e comprensibile, con ricchezza di commenti, c è più confidenza che gli sviluppi avverranno con meno problemi. Un secondo elemento da considerare è la disponibilità di documentazione sui test effettuati; un buon indicatore della qualità di un prodotto è la presenza di numerosi casi di test, con un elevato grado di copertura sul codice sviluppato. Un terzo fattore determinante è il livello di attività intorno al prodotto; dai siti internet (p.es. SourceForge) è possibile ricavare informazioni statistiche sulle modifiche che il prodotto subisce nel tempo: quante modifiche vengono effettuate e con quale frequenza, quanti problemi sono evidenziati e in quanto tempo mediamente vengono risolti, ecc.. Un attività vivace con rapida apertura e chiusura dei task è indice di una buona maturità. 3. Longevità La longevità di un prodotto è un elemento indicativo della maturità del prodotto stesso. In generale, un prodotto è tanto più maturo e affidabile quanto più è stato utilizzato, poiché si presuppone che i difetti di gioventù vengano corretti man mano che il prodotto viene testato in condizioni reali. Da questo punto di vista, quindi, gli elementi da considerare sono: 1. da quanto tempo il prodotto è disponibile; 2. il numero di versione attualmente disponibile; 3. il numero complessivo di copie distribuite agli utenti. Riguardo il secondo punto, va considerato che, nel mondo open source, l aggiornamento delle versioni non segue la logica dei prodotti commerciali: per questi, infatti, la continua disponibilità di nuove versioni è un elemento di competizione sul mercato, mentre per i prodotti open source questo è un fattore meno pressante. Non è sempre detto, quindi, che un numero di versione basso sia sinonimo di giovinezza. Per quanto riguarda il terzo punto, invece, va tenuto presente che molti prodotti sono scaricati da internet; per questi si può ipotizzare che circa il 10 o 20 per cento delle copie scaricate siano effettivamente utilizzate in ambito di produzione. Se si dispone del dato relativo al numero totale dei download, questo numero va opportunamente ridimensionato. 4. Team di sviluppo Per i prodotti open source è comune la possibilità di individuare il team di persone che sviluppano un prodotto. Questa possibilità, unita alla possibilità di avere una comunicazione diretta con essi, è già un fattore positivo nel fugare il timore di dipendere da un team di volontari non meglio identificati.

11 Una valutazione necessaria sul team di sviluppo è quindi legata ai seguenti fattori: 1. il team corrisponde ad una ragione sociale che raggruppa gli sviluppatori e garantisce contrattualmente il committente rispondendo a livelli di servizio ed al pagamento di penali per il mancato raggiungimento degli obiettivi e del rispetto dei tempi; 2. il team è numericamente adeguato al tipo di prodotto in esame (non è detto che la valutazione sia tanto più positiva quante più persone lavorano al progetto: un team più ridotto può essere più efficiente, p.es. dal punto di vista della qualità); 3. il team è composto da persone con skill ed esperienza adeguate; l esperienza media, secondo indagini statistiche, è di circa 11 anni, ma è comune la presenza di persone con livelli di esperienza diversi, che si occupano di diversi aspetti dello sviluppo 5. Comunity La presenza di una Comunità di riferimento o le condizioni per la costituzione di una Comunità di interesse costituita da singoli, software house, altre PA interessati allo sviluppo del progetto o alla adesione allo stesso costituiscono elemento da valutare positivamente 6. Supporto tecnico Il primo problema relativo al supporto tecnico è la necessità di garantirsi contro potenziali malfunzionamenti del prodotto; tali eventi, anche se non frequenti, possono avere effetti catastrofici e vanno gestiti correttamente. Prima di introdurre un prodotto software in un ambiente di produzione è quindi indispensabile definire chi assumerà la responsabilità di intervenire nei casi in cui il prodotto stesso presenti dei difetti, rispondendo in tempi definiti e fornendo le correzioni necessarie. Per i prodotti commerciali questo è regolato dal contratto con il fornitore del prodotto, mentre per i prodotti open source ciò non è generalmente possibile. Escludendo l ipotesi di modificare in proprio i sorgenti del prodotto, la soluzione a questo problema è stipulare un contratto con un soggetto che fornisca il supporto tecnico necessario, sia esso accompagnato dalla fornitura del software o meno. La maturità di un prodotto, da questo punto di vista, si valuta verificando le capacità tecniche e organizzative dei soggetti potenziali fornitori, nonché il livello di copertura che è possibile stabilire contrattualmente. L utilità di un supporto tecnico non si esaurisce comunque nel risolvere i malfunzionamenti del prodotto; la maggior parte delle chiamate che segnalano malfunzionamenti ai centri di supporto, infatti, si risolvono generalmente con discussioni sulla configurazione e l utilizzo dei prodotti stessi. Questo tipo di supporto è utile per i problemi del tipo il prodotto dovrebbe fare questo ma non so perché non funziona e in una certa misura sconfinano nel campo della documentazione e dei servizi professionali (vedi più avanti). Esistono due modalità per usufruire di questo secondo tipo di supporto tecnico sui prodotti open source: la prima prevede la possibilità di sfruttare la comunità degli utenti del prodotto, interagendo con essa attraverso le mailing list disponibili e i forum di discussione; il prodotto sarà considerato tanto più maturo quanto più elevato è il numero di mailing list e di utenti che interagiscono in rete, e quanto elevata è la rapidità e la qualità delle risposte ai quesiti posti.

12 La seconda modalità prevede invece di sfruttare competenze già presenti in casa: queste saranno disponibili se la tecnologia è diffusa e consolidata, non dipendendo cioè dalle competenze specialistiche di singoli individui; in questo caso, più articolato è il team disponibile, maggiori sono le prospettive di successo. In sintesi, la maturità di un prodotto, dal punto di vista del supporto tecnico, si può determinare considerando i seguenti fattori: 1. disponibilità di fornitori e livello di copertura offerto; 2. disponibilità di mailing list e forum di discussione; 3. disponibilità di competenze tecniche in casa. 7. Documentazione Una documentazione ampia e approfondita dei prodotti software è un fattore importante per la riuscita di ogni progetto. Si evita infatti il rischio di incontrare problemi in fase di progetto e di non sapere come affrontarli per mancanza di conoscenze. Il tipo di documenti disponibili può essere di varia natura, in base al target a cui si rivolge: possono quindi esistere manuali d uso, reference guides, ecc. Per un prodotto open source le fonti di documentazione possono essere di tre tipi: 1. il team di sviluppo; 2. la comunità degli utenti; 3. pubblicazioni commerciali. Il team di sviluppo è comunemente la prima fonte di documentazione: chi sviluppa il software infatti si preoccupa quasi sempre di fornire anche i manuali relativi. Questi manuali possono comunque avere delle caratteristiche negative, legate ai seguenti fattori: chi sviluppa il software ha elevate competenze e può dare per scontate informazioni che invece non lo sono per gli utenti comuni; con la stessa logica, la documentazione può essere focalizzata su reference guide per gli addetti ai lavori ed essere carente per quanto riguarda i manuali d uso. Bisogna quindi verificare che questo tipo di documentazione sia completa, chiaramente comprensibile e di ausilio per tutti i tipi di utenti. Una seconda fonte di documentazione è reperibile nella rete, dove la comunità degli utenti generalmente pubblica le proprie esperienze relative ad argomenti specifici, relativi ad esempio a particolari funzioni, configurazioni o modalità d uso. Questo tipo di documentazione è ovviamente dispersivo e non certificato, e va quindi utilizzato come integrazione e non certo come fonte primaria di conoscenza. Tuttavia, la presenza di un elevato numero di pubblicazioni su un determinato prodotto è sintomo di una comunità numerosa e quindi di una buona maturità del prodotto. La terza fonte di documentazione è relativa alle pubblicazioni disponibili a pagamento. Esistono numerose organizzazioni che fondano un business sulla vendita di libri e manuali tecnici; questi sono tipicamente prodotti da persone non solo esperte tecnicamente, ma anche competenti dal punto di vista della comunicazione. Inoltre, il semplice fatto che qualcuno abbia individuato una fonte di guadagno nella vendita di documentazione su un certo prodotto, significa che quel prodotto è largamente diffuso e utilizzato. La disponibilità di questo tipo di documentazione è quindi anch essa sintomo di una notevole maturità dei prodotti.

13 In sintesi, la maturità di un prodotto, dal punto di vista della documentazione, si può determinare considerando i seguenti fattori: 1. disponibilità di pubblicazioni dal team di sviluppo; 2. disponibilità di pubblicazioni su internet; 3. disponibilità di pubblicazioni a pagamento. 8. Addestramento L addestramento su un prodotto è da valutare in relazione al tipo di competenza richiesto, potendo essere focalizzato sull utente finale di un applicazione, oppure sul personale tecnico coinvolto nel progetto. La più importante fonte di addestramento è costituita dai classici corsi in aula tenuti da personale qualificato, non solo esperto della materia, ma anche con buone doti di comunicazione. Se per un prodotto open source sono disponibili corsi a pagamento di questo tipo, organizzati da soggetti riconosciuti come affidabili, ciò è indubbiamente sinonimo di maturità del prodotto stesso, poiché indica che il prodotto è utilizzato in modo diffuso in ambito produttivo. Un alternativa al classico addestramento in aula è costituito dai tutorial di autoaddestramento disponibili online, organizzati in lezioni che guidano l utente nei diversi passi di apprendimento. Anche in questo caso, la ricchezza di materiale disponibile è il fattore da valutare; in genere, questa è più elevata se la fonte dei tutorial è un ente commerciale riconosciuto che fornisce il materiale a pagamento; maggiore attenzione va posta invece se i tutorial hanno origine nella comunità degli utenti, come può essere ad esempio un istituzione universitaria che pubblica il materiale per i propri studenti. In sintesi, la maturità di un prodotto, dal punto di vista dell addestramento, si può determinare considerando i seguenti fattori: 1. disponibilità di corsi tradizionali in aula; 2. disponibilità di corsi di autoaddestramento on-line; 9. Integrazione I prodotti software non vengono mai utilizzati isolatamente, ma piuttosto sono componenti di un architettura complessa, in cui ogni componente richiede servizi da componenti di livello più basso e fornisce servizi a componenti di livello più alto. Ogni prodotto, quindi, si inserisce in uno stack di componenti specializzati e deve integrarsi con essi. Questa integrazione, di facile approccio nei casi in cui si adottano soluzioni single vendor, è invece un elemento più critico nei casi in cui l approccio sia di tipo best-of-breed, in cui si assemblano componenti di vendor diversi; per i prodotti commerciali, l integrazione è in genere guidata da accordi tra le aziende produttrici; per la natura non commerciale dei prodotti open source, invece, questa assume una connotazione specifica. Nel caso di un prodotto open source che fornisce servizi ad altri componenti nello stack, sono i prodotti commerciali degli strati superiori che devono integrarsi con esso, e in questo caso va valutata la propensione delle aziende a sviluppare tale integrazione; poiché queste sono guidate dalle opportunità di business, un ampia integrazione di un prodotto open source in un contesto di prodotti commerciali è sintomo di elevata maturità del prodotto stesso.

14 Una particolare forma di integrazione, che ha aperto la strada alla cooperazione fra prodotti software (open source o commerciali che siano) è la presenza di protocolli standard di comunicazione; tipico è il caso del protocollo XML, su cui si è sviluppata l interazione via web services: in questo caso, l integrazione tra prodotti di mercato e prodotti open source è garantita dall aderenza allo standard, senza la necessità di sviluppi mirati. In sintesi, la maturità di un prodotto, dal punto di vista dell integrazione, si può determinare considerando i seguenti fattori: 1. disponibilità di standard di integrazione nel prodotto open source; 2. disponibilità di meccanismi di integrazione o aderenza agli standard nei prodotti commerciali; 10. Servizi professionali La tendenza a sfruttare servizi esterni, piuttosto che sviluppare in casa i team con le competenze tecniche necessarie, è largamente diffusa nelle aziende. Una prassi comune è quella di rivolgersi a società di consulenza generaliste, che mettono a disposizione personale specializzato nei più diversi campi. Queste società, dal canto loro, investono nella formazione delle risorse umane per quegli ambiti tecnologici che hanno un vasto mercato e che quindi possono garantire ritorni economici certi. La disponibilità di competenze tecniche specialistiche è quindi più probabile per i prodotti open source maturi (p.es. Linux), la cui presenza in ambito produttivo è ormai consolidata, mentre potrebbe non esserlo per prodotti di nicchia o poco diffusi; questo aspetto va valutato in anticipo, richiedendo eventualmente informazioni sull argomento. In alcuni casi è probabile che piccole società, orientate ad una tecnologia specifica, siano tecnicamente più competenti e più convenienti rispetto a società grandi; le prime si rivolgono tipicamente ad un mercato di piccole aziende che, per problemi di budget, tendono ad usare prodotti open source in misura significativa. In questi casi vanno però considerati anche altri fattori, quali la disponibiltà di sufficienti risorse umane e la propensione a lavorare per progetti anche complessi. In sintesi, la maturità di un prodotto, dal punto di vista dei servizi professionali, si può determinare considerando i seguenti fattori: 1. numero e dimensioni delle aziende che offrono i servizi professionali; 2. risorse umane disponibili e competenze tecniche fornite; 3. orientamento delle aziende a lavorare per progetti. Processo di valutazione Per tradurre in pratica le considerazioni teoriche fin qui esposte, è necessario definire un processo strutturato, che porti alla valutazione finale sulla maturità di un prodotto attraverso una serie di attività definite e documentate.

15 Il primo passo è quello di assegnare il task di valutazione ad un piccolo gruppo (anche due o tre persone), in modo che diverse sensibilità e punti di vista si possano confrontare per dare una valutazione il più possibile oggettiva. Il task si sviluppa quindi in una serie di fasi, che, come descritto in dettaglio in precedenza, comprendono: 1. definizione dei requisiti; 2. individuazione delle fonti; 3. analisi dei singoli elementi: a. funzioni disponibili; b. software; c. longevità del prodotto; d. team di sviluppo; e. presenza di una Comunity; f. supporto tecnico; g. documentazione; h. addestramento; i. integrazione; j. servizi professionali; 4. assegnazione dei punteggi assoluti; 5. definizione dei pesi di riferimento; 6. calcolo del punteggio complessivo; 7. individuazione del valore di soglia accettabile nel contesto; 8. giudizio finale. La fase 1 è quella in cui si definiscono lo scopo e il contesto dell analisi; le valutazioni su un prodotto possono essere infatti molto diverse in base all utilizzo per il quale è destinato. La fase 2 può essere più o meno complessa, ed è quella che distingue i prodotti open source da quelli commerciali, per i quali la fonte è univoca. La fase 3 è quella in cui si sviluppano le valutazioni di dettaglio; nella seguente tabella si riassumono gli elementi da tenere in considerazione. Generale TCO della singola soluzione calcolato su almeno 5 anni Costo di uscita dalla stessa; Valorizzazione delle competenze tecniche possedute dall amministrazione; Interoperabilità intesa per la PA nel suo complesso (dunque uso di formati dei dati e interfacce aperte e standard); Riusabilità interesse di altre amministrazioni al riuso dell applicazione da realizzare e/o acquistare Valore sociale della soluzione Software Funzionalità disponibili Qualità del software (codifica interna, dati sui test) Longevità del prodotto (durata, versioni, copie distribuite)

16 Team di sviluppo (numerosità, composizione, skill ed esperienza) Presenza di una Comunity Supporto tecnico Disponibilità di fornitori e livello di copertura offerto Disponibilità di mailing list e forum di discussione Disponibilità di competenze tecniche in casa Documentazione Disponibilità di pubblicazioni dal team di sviluppo Disponibilità di pubblicazioni su internet Disponibilità di pubblicazioni a pagamento Addestramento Disponibilità di corsi tradizionali in aula Disponibilità di corsi di autoaddestramento on-line Integrazione Standard di integrazione nel prodotto open source Meccanismi di integrazione o aderenza agli standard nei prodotti commerciali Servizi Professionali Numero e dimensioni delle aziende che offrono i servizi professionali Risorse umane disponibili e competenze tecniche fornite Orientamento delle aziende a lavorare per progetti Tab.5 sintesi degli elementi di valutazione. Le fasi da 4 a 8 sono quelle, più delicate, in cui è richiesto di tradurre in numeri, ovvero in giudizi oggettivi, le valutazioni espresse nella fase precedente; in questo ambito, è importante quindi il confronto dialettico tra i soggetti coinvolti. Tutte le considerazioni espresse durante l attività vengono registrate, in modo da produrre come output un documento di sintesi che accompagna e rende esplicito il giudizio finale espresso.

17 Allegato B) Dal Quaderno CNIPA 31/2 "Linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA" Relativamente al Riuso Si hanno fondamentalmente tre tipologie: cessione del software semplice: l'amministrazione A cede il software all'amministrazione B, che si fa carico autonomamente di tutti i successivi interventi evolutivi sul software cessione del software associata a forme di cooperazione: più Amministrazioni cooperano nelle attività di gestione, manutenzione ed evoluzione dell'applicativo. Oltre a quelli economici si presentano altri vantaggi legati alla standardizzazione dell'analisi funzionale. cessione del software e attivazione di un servizio ASP: l'amministrazione cedente, oltre a rilasciare l'applicativo, ne garantisce un servizio di manutenzione, evoluzione ed esercizio. I principali vantaggi del riuso risiedono nella ridotta attività di sviluppo, di analisi e di test; controbilanciate però da un incremento della fase preliminare di valutazione delle diverse opzioni. Un altro vantaggio risiede nel minore rischio del progetto, poiché si utilizza un applicativo che ha già mostrato la sua validità sul campo. Dal lato dei fornitori, il Riuso incentiva il passaggio da un mercato basato sui volumi di vendita (un fornitore ha ridotte possibilità di vendere il medesimo applicativo a più Amministrazioni) ad un mercato basato su servizi di specializzazione (evoluzioni, modifiche, integrazioni, adattamenti, etc). Relativamente software Open Source Il modello Open Source (OS) non è alternativo al software commerciale, ad essere alternativo è solamente il modello di licenza adottata. Solo uno studio di fattibilità può evidenziare, per ogni singolo caso, quale sia la soluzione più adatta (OS e commerciale). Tra i vantaggi dell'os: basso costo iniziale e maggior controllo sul TCO (includendo servizi di supporto, formazione, manutenzione, evoluzione) maggiore indipendenza dai fornitori maggiore trasparenza derivante dall'accesso al codice sorgente maggiore flessibilità (derivante dalla modificabilità del codice) maggiore interoperabilità e utilizzo di standard aperti rispetto al software commerciale Tra i potenziali svantaggi: bassa interoperabilità con software commerciali, che spesso costituiscono standard "de facto" nessuna garanzia sulla disponibilità di supporto scalabilità e portabilità non sempre garantita carenza di drivers industriali Sulla scelta del prodotto Open Source

18 Generalmente si ritiene il software OS (OSS) come un artefatto su cui è difficile ottenere "garanzie" di funzionamento, di integrazione e di estensibilità dal momento che - spesso - non esiste un unico soggetto (giuridico) responsabile del software in questione. Benché l'amministrazione dovrebbe lasciare ai fornitori la scelta delle componenti software utilizzate, con la relativa motivazione, riteniamo utile suggerire una serie di "linee guida" per valutare se un determinato prodotto OSS sia sufficientemente maturo per le esigenze dell'amministrazione stessa. Ovviamente l'approccio proposto non è vincolante, ma vuole solamente fornire un esempio di modello di valutazione di un prodotto/progetto OS. Altri modelli sono presenti in letteratura (e mostrano molti aspetti in comune), tra i quali citiamo: Open Business Readiness Model (OpenBRR): modello aperto per il rating del software OS sponsorizzato da Carnegie Mellon University, O Reilly, SpikeSource ed Intel (http://www.openbrr.org) CapGemini: Frans-Willem Duijnhouwer e Chris Widdows Open Source Maturity Model 1.5.3, agosto 2003, (Expert Letter) Navica: Bernard Golden Succeding with Open Source, Addison-Wesley, 2005 W. Wheeler How to evaluate Open Source/Free software program - Partiamo dall'assunto che venga effettuata un analisi dei requisiti e che da questa vengano selezionate alcune alternative OS (tramite un'associazione alle desiderate funzionalità del prodotto). Il passo successivo consiste nel valutare quale, tra le alternative (pre)selezionate, sia la più matura. Si vuole stimare la maturità su tre dimensioni: prodotto: capire se un determinato prodotto OS è sufficiente maturo per l'esigenze dell'amministrazione utilizzo: capire quanto effort occorre per installare ed utilizzare il prodotto in questione integrazione: capire quanto effort occorre per integrare il prodotto nell'ambiente informativo esistente nell'amministrazione Per ognuna delle precedenti dimensioni abbiamo diversi criteri, per ognuno dei quali viene dato un punteggio (su una scala da 1 a 3): punteggio descrizione 1 (non maturo) il prodotto ha delle mancanze in diverse aree ritenute critiche. La sua adozione in un contento mission critical è altamente sconsigliata 2 (sufficientemente maturo) il prodotto ha una buona base di installato, diversi casi di adozione in contesti simili a quelli dell'amministrazione e una solida base di utenti/sviluppatori 3 (molto maturo) il prodotto ha una vasta base di installato, esempi eccellenti in letteratura ed una community di sviluppatori molto attiva Ovviamente la precedente scala può benissimo essere resa più fine (es: da 1 a 5) a seconda delle esigenze dell'amministrazione. Elenchiamo nel seguito i criteri per ciascuna dimensione, unitamente alla descrizione per un attribuzione del relativo punteggio.

19 Dimensione prodotto : età criterio descrizione punteggio Tra i prodotti OS esiste un elevata < 6 mesi 6 mesi - 2 anni > 2 anni mortalità infantile. Prodotti troppo giovani possono comportare dei rischi dal momento che la sottostante community potrebbe non essere sufficientemente solida Prodotti che lavorano su uno o 1 piattaforma più piattaforme poche piattaforme denunciano la similari scarsa eterogeneità di competenze all interno della community di sviluppo supporto multipiattaforma slancio ( momentum ) popolarità qualità della progettazione Dimensione uso : effort per il setup Il numero di release è un buon indicatore della vitalità del prodotto Prodotti popolari sono generalmente ben testati e presentano un ragionevole grado interoperabilità con altri prodotti Applicazioni modulari permettono una migliore e più facile modifica e adattabilità alle esigenze dell Amministrazione nessuna nuova release nei precedenti 6 mesi prodotto poco noto applicazione monolitica meno di 2 release nello scorso anno il prodotto presenta diverse alternative applicazione basata su più componenti più piattaforme eterogenee release regolari (e pianificate) leader nella propria categoria presenza di API ben definite criterio descrizione punteggio Un prodotto sufficientemente maturo richiede un setup che va da qualche ora ad un massimo di pochi giorni. effort per l utilizzo supporto all utente finale Un prodotto maturo deve presentare un livello di usabilità (compatibilmente con i propri scopi) ragionevole In un prodotto maturo il supporto, attraverso la community e non solo, all utente finale è di grande importanza. processo di installazione poco documentato, scarsa documentazion e in generale, supporto fruibile attraverso gli sviluppatori scarsa o nulla documentazion e, supporto fruibile esclusivamente attraverso gli sviluppatori nessun forum e/o mailing-list disponibile processo di installazione ben documentato, documentazione di ragionevole qualità, supporto disponibile anche attraverso forum presenza di manuali utente, tutorial, supporto disponibile attraverso forum qualche forum e/ o mailing-list disponibile presenza di script per l installazione, presenza di servizi di terze parti per l installazione presenze di servizi di formazione forniti da terze parti forum e mailing-list attivi, con archivi storici e possibilità di ricerca, servizi di supporto offerti da terze

20 parti Dimensione integrazione : criterio descrizione punteggio modularità Un prodotto modulare e con una solida architettura sarà più facile da studiare, estendere ed integrare con altri prodotti struttura monolitica, ridotta estensibilità più moduli più moduli, insieme di API ben definite, facilità di collaborazioni con altri prodotti adesione a standards supporto per lo sviluppo Un prodotto la cui community abbia avviato collaborazione con altri prodotti/progetti (siano essi OS o meno) indica, oltre ad un vasto uso, un buon livello di integrabilità Un prodotto aderente a diversi standard indica una buona integrabilità. Un prodotto la cui community di sviluppo non appare chiusa alle richieste (anche solo sporadiche e/o temporanee) di sviluppatori esterni sarà più facilmente integrabile sconosciuta sconosciuta nessun forum e/o mailing-list per gli sviluppatori alcuni casi di integrazione adesioni ad alcuni standard presenza di qualche forum e mailing-list estensibilità diversi casi di integrazione (possibilmente ben documentati) adesioni a correnti standard de facto presenza di forum e mailinglist, con possibilità di ricerca negli storici; servizi di formazione offerti da terze parti A questo punto possiamo definire il punteggio per ogni dimensione semplicemente come la somma dei punteggi relativi ai criteri presenti nella dimensione stessa: C P = somma punteggi criteri prodotto C U = somma punteggi criteri uso C I = somma punteggi criteri integrazione E definire il punteggio finale come: P = W P *C P + W U *C U + W I *C I Dove abbiamo indicato con W j il peso di ciascuna dimensione 1. E importante che la somma dei W j dia 1. Vediamo un esempio di applicazione del precedente modello nella scelta fra tre prodotti OS: Prodotto 1 Prodotto 2 Prodotto 3 C P C U C I Dando uguale importanza ad ogni dimensione, otteniamo: 1 Ovviamente in prima approssimazione possiamo considerare le tre dimensioni come ugualmente importanti: W P = W U = W I =

Direttiva 19 dicembre 2003 Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni. G.U. 7 febbraio 2004, n.

Direttiva 19 dicembre 2003 Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni. G.U. 7 febbraio 2004, n. www.cnipa.gov.it 1/5 Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni. IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE - Visto il regio decreto 18 novembre 1923,

Dettagli

La normativa sul riuso del software nella P. A. e l esperienza Toscana

La normativa sul riuso del software nella P. A. e l esperienza Toscana La normativa sul riuso del software nella P. A. e l esperienza Toscana Caterina Flick Linux Day Grosseto, 27 ottobre 2007 1/13 P.A. e acquisizione di software Secondo la normativa vigente le amministrazioni

Dettagli

Questi sistemi hanno le tipiche caratteristiche di tutti i sistemi software custom:

Questi sistemi hanno le tipiche caratteristiche di tutti i sistemi software custom: 3.9 NORMATIVA SUL RIUSO DEL SOFTWARE NELLA PA La Commissione propone che la commmissione tecnico-giuridica che studi la revisione della normativa, di cui alla proposta n. 3.1, valuti anche la problematica

Dettagli

Sviluppo, Acquisizione e Riuso

Sviluppo, Acquisizione e Riuso Bari, 24 Luglio 2006 Dati delle Pubbliche Amministrazioni e servizi in rete Sviluppo, Acquisizione e Riuso Codice dell Amministrazione Digitale Capo VI, artt. 67-70 1 Art. 67: Modalità di sviluppo e acquisizione

Dettagli

LE GARE PER L AGGIUDICAZIONE DI CONTRATTI DI APPALTO RELATIVI A LAVORI, SERVIZI E FORNITURE DI ALTA TECNOLOGIA E DIGITALI. L ACQUISIZIONE DI SOFTWARE

LE GARE PER L AGGIUDICAZIONE DI CONTRATTI DI APPALTO RELATIVI A LAVORI, SERVIZI E FORNITURE DI ALTA TECNOLOGIA E DIGITALI. L ACQUISIZIONE DI SOFTWARE STEFANO D ANCONA LE GARE PER L AGGIUDICAZIONE DI CONTRATTI DI APPALTO RELATIVI A LAVORI, SERVIZI E FORNITURE DI ALTA TECNOLOGIA E DIGITALI. L ACQUISIZIONE DI SOFTWARE DA PARTE DELLE PUBBLICHE AMMINISTRAZIONI.

Dettagli

Valutazione tecnico economica dell acquisizione del software

Valutazione tecnico economica dell acquisizione del software Valutazione tecnico economica dell acquisizione del software un possibile approccio Pierluigi Mazzuca Direttore Customer & Partner experience Microsoft Italia Agenda La normativa corrente in materia di

Dettagli

Le fattispecie di riuso

Le fattispecie di riuso Le fattispecie di riuso Indice 1. PREMESSA...3 2. RIUSO IN CESSIONE SEMPLICE...4 3. RIUSO CON GESTIONE A CARICO DEL CEDENTE...5 4. RIUSO IN FACILITY MANAGEMENT...6 5. RIUSO IN ASP...7 1. Premessa Poiché

Dettagli

L Open Source nella Pubblica

L Open Source nella Pubblica L Open Source nella Pubblica Amministrazione Vittorio Pagani Responsabile Osservatorio Open Source - CNIPA 1 Riflessioni su alcune caratteristiche del software OS disponibilità del codice sorgente: possibilità

Dettagli

Check list per la valutazione di adeguatezza e Indice di adeguatezza

Check list per la valutazione di adeguatezza e Indice di adeguatezza Check list per la valutazione di adeguatezza e Indice di adeguatezza DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 16 Indice 1. PREMESSA... 3 2. ELEMENTI DI VALUTAZIONE DELL ADEGUATEZZA DELLA SOLUZIONE...

Dettagli

PIANO TRIENNALE PER L ICT 2009-2011 GUIDA ALLA COMPILAZIONE DELLE BOZZE DI PIANO DA PARTE DELLE AMMINISTRAZIONI

PIANO TRIENNALE PER L ICT 2009-2011 GUIDA ALLA COMPILAZIONE DELLE BOZZE DI PIANO DA PARTE DELLE AMMINISTRAZIONI Centro nazionale per l informatica nella pubblica amministrazione Area Amministrazioni centrali PIANO TRIENNALE PER L ICT 2009-2011 GUIDA ALLA COMPILAZIONE DELLE BOZZE DI PIANO DA PARTE DELLE AMMINISTRAZIONI

Dettagli

Il mercato italiano Open Source: domanda e offerta 1

Il mercato italiano Open Source: domanda e offerta 1 Il mercato italiano Open Source: domanda e offerta 1 Oltre il 12% delle aziende italiane usa soluzioni Open Source.(Istat 2007). Sarebbero molte di più se ci fosse una sufficiente diffusione della conoscenza

Dettagli

Tavolo di Sanità Elettronica. Riuso delle componenti realizzate nel progetto "Rete dei centri di prenotazione - Cup on line"

Tavolo di Sanità Elettronica. Riuso delle componenti realizzate nel progetto Rete dei centri di prenotazione - Cup on line Tavolo di Sanità Elettronica Riuso delle componenti realizzate nel progetto "Rete dei centri di prenotazione - Cup on line" Roma, 14 Dicembre 2011 IL RIUSO Mettersi insieme è un inizio, rimanere insieme

Dettagli

The new outsourcing wave: multisourcing

The new outsourcing wave: multisourcing EVOLUZIONE DEI MODELLI DI OUTSOURCING La pratica dell outsourcing, cioè del trasferire all esterno dell azienda singole attività, processi o infrastrutture è in voga da tempo, e negli anni ha dimostrato

Dettagli

CAPITOLATO TECNICO PER LA COSTRUZIONE, GESTIONE E MANUTENZIONE SITO WEB ISTITUZIONALE DELL UNIONE DEI COMUNI DELL APPENNINO BOLOGNESE.

CAPITOLATO TECNICO PER LA COSTRUZIONE, GESTIONE E MANUTENZIONE SITO WEB ISTITUZIONALE DELL UNIONE DEI COMUNI DELL APPENNINO BOLOGNESE. CAPITOLATO TECNICO PER LA COSTRUZIONE, GESTIONE E MANUTENZIONE SITO WEB ISTITUZIONALE DELL UNIONE DEI COMUNI DELL APPENNINO BOLOGNESE. Articolo 1 Oggetto dell appalto 1. L appalto ha per oggetto la progettazione,

Dettagli

La Pubblica Amministrazione consumatore di software Open Source

La Pubblica Amministrazione consumatore di software Open Source La Pubblica Amministrazione consumatore di software Open Source Dipartimento per l Innovazione e le Tecnologie Paola Tarquini Sommario Iniziative in atto Una possibile strategia per la diffusione del Software

Dettagli

Indice strutturato dello studio di fattibilità

Indice strutturato dello studio di fattibilità Indice strutturato dello studio di fattibilità DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 10 Indice 1 2 SPECIFICITÀ DELLO STUDIO DI FATTIBILITÀ IN UN PROGETTO DI RIUSO... 3 INDICE STRUTTURATO DELLO

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

OS E PA. Open source e Pubblica Amministrazione a che punto siamo? Paolo Coppola Assessore all Innovazione ed e-government Comune di Udine

OS E PA. Open source e Pubblica Amministrazione a che punto siamo? Paolo Coppola Assessore all Innovazione ed e-government Comune di Udine OS E PA Open source e Pubblica Amministrazione a che punto siamo? Paolo Coppola Assessore all Innovazione ed e-government Comune di Udine CODICE DELL'AMMINISTRAZIONE DIGITALE Decreto legislativo 7 marzo

Dettagli

Linee guida per il riuso delle applicazioni informatiche nelle Amministrazioni pubbliche Parte 1 Riuso di applicazioni esistenti

Linee guida per il riuso delle applicazioni informatiche nelle Amministrazioni pubbliche Parte 1 Riuso di applicazioni esistenti Linee guida per il riuso delle applicazioni informatiche nelle Amministrazioni pubbliche Parte 1 Riuso di applicazioni esistenti Pagina 1 Documento a cura di: Paola Minasi (CNIPA) Pagina 2 INDICE 1. INTRODUZIONE------------------------------------------------------------------------------------------

Dettagli

Allegato 15 Modello offerta tecnica

Allegato 15 Modello offerta tecnica Allegato 15 Modello offerta tecnica Sommario 1 PREMESSA... 4 1.1 Scopo del documento... 4 2 La soluzione progettuale e la relativa architettura... 4 2.1 Requisiti generali della soluzione offerta... 4

Dettagli

JUNAK3 SISTEMA GESTIONE AZIENDALE

JUNAK3 SISTEMA GESTIONE AZIENDALE JUNAK3 SISTEMA GESTIONE AZIENDALE Modulo di Gestione Magazzino www.kisar.it JUNAK3 - SISTEMA DI GESTIONE AZIENDALE Il Sistema di Gestione Aziendale JUNAK3 è una piattaforma realizzata in ambiente Windows,

Dettagli

INDIRIZZO Informatica e Telecomunicazioni

INDIRIZZO Informatica e Telecomunicazioni ISTRUZIONE TECNICA INDIRIZZO Informatica e Telecomunicazioni L indirizzo Informatica e Telecomunicazioni ha lo scopo di far acquisire allo studente, al termine del percorso quinquennale, specifiche competenze

Dettagli

Commissione indipendente per la Valutazione, la Trasparenza e l Integritàdelle amministrazioni pubbliche Autorità Nazionale Anticorruzione

Commissione indipendente per la Valutazione, la Trasparenza e l Integritàdelle amministrazioni pubbliche Autorità Nazionale Anticorruzione Commissione indipendente per la Valutazione, la Trasparenza e l Integritàdelle amministrazioni pubbliche Autorità Nazionale Anticorruzione Testo revisionato e approvato dalla Commissione il 29/05/2013

Dettagli

Comune di Spoleto QUESITI E RISPOSTE

Comune di Spoleto QUESITI E RISPOSTE Procedura aperta per fornitura chiavi in mano di una suite applicativa gestionale Web based completamente integrata e comprensiva dei relativi servizi di assistenza e manutenzione QUESITI E RISPOSTE Quesito

Dettagli

Valutare gli ambienti digitali e valutare negli ambienti digitali. E-learning, valutazione e università.

Valutare gli ambienti digitali e valutare negli ambienti digitali. E-learning, valutazione e università. Valutare gli ambienti digitali e valutare negli ambienti digitali. E-learning, valutazione e università. Luciano Cecconi Professore associato di Pedagogia sperimentale Facoltà di Scienze della Formazione

Dettagli

gestione documentale dalla dematerializzazione dei documenti alla digitalizzazione dei processi fino all azienda digitale

gestione documentale dalla dematerializzazione dei documenti alla digitalizzazione dei processi fino all azienda digitale gestione documentale dalla dematerializzazione dei documenti alla digitalizzazione dei processi fino all azienda digitale Gestione documentale Gestione documentale Dalla dematerializzazione dei documenti

Dettagli

BOZZA DEL 06/09/2011

BOZZA DEL 06/09/2011 ARTICOLAZIONE: INFORMATICA Disciplina: COMPLEMENTI DI MATEMATICA (C4) Il docente di Complementi di matematica concorre a far conseguire allo studente, al termine del percorso quinquennale, i seguenti risultati

Dettagli

Docente di Impianti di Elaborazione presso il Politecnico di Milano e ricercatore di Politecnico Innovazione

Docente di Impianti di Elaborazione presso il Politecnico di Milano e ricercatore di Politecnico Innovazione I sistemi gestionali e le Piccole Medie Imprese A cura di Fabrizio Amarilli Docente di Impianti di Elaborazione presso il Politecnico di Milano e ricercatore di Politecnico Innovazione Articoli Sono noti

Dettagli

Il Software Libero in FVG: Esperienze e prospettive per lo sviluppo del mercato ICT

Il Software Libero in FVG: Esperienze e prospettive per lo sviluppo del mercato ICT 1 1 Udine, 7 febbraio 2008 Il Software Libero in FVG: Esperienze e prospettive per lo sviluppo del mercato ICT TECNOTECA: la testimonianza di un operatore del mercato Fabio Bottega - f.bottega@tecnoteca.it

Dettagli

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL Estratto dell'agenda dell'innovazione Smau Milano 2011 Speciale: I casi Introduzione dell'area tematica Il caso INCA CGIL Innovare e competere con le ICT - PARTE I Cap.1 L innovazione nella gestione dei

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Linee Guida per l adozione di Insegnamenti Integrativi sulla Proprietà Intellettuale nelle Facoltà Scientifiche delle Università italiane 1

Linee Guida per l adozione di Insegnamenti Integrativi sulla Proprietà Intellettuale nelle Facoltà Scientifiche delle Università italiane 1 Linee Guida per l adozione di Insegnamenti Integrativi sulla Proprietà Intellettuale nelle Facoltà Scientifiche delle Università italiane 1 1. Premessa. Contesto e motivazione Nell attuale economia della

Dettagli

Open source e Pubblica Amministrazione: ha ancora senso parlarne? Flavia Marzano

Open source e Pubblica Amministrazione: ha ancora senso parlarne? Flavia Marzano Open source e Pubblica Amministrazione: ha ancora senso parlarne? Flavia Marzano Le 4 libertà Libertà 0: Libertà di eseguire il programma per qualsiasi scopo. Libertà 1: Libertà di studiare il programma

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Il processo di produzione dell informazione statistica e l opzione open source

Il processo di produzione dell informazione statistica e l opzione open source Il processo di produzione dell informazione statistica e l opzione Roma, 4 marzo 2008 Giulio Barcaroli 1 Il processo di produzione dell informazione statistica e l opzione All interno dell ISTAT da alcuni

Dettagli

Comune di Empoli. Progetto Sistema Informativo Documentale Gestione Atti Amministrativi

Comune di Empoli. Progetto Sistema Informativo Documentale Gestione Atti Amministrativi Comune di Empoli Progetto Sistema Informativo Documentale Gestione Atti Amministrativi Offerta /P/2014 Vers. 1.0 Data: 17 Luglio 2014 INTRODUZIONE... 4 SCOPO DEL DOCUMENTO... 4 SCOPO DEL DOCUMENTO... 4

Dettagli

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 SECONDO BIENNIO Disciplina: INFORMATICA La disciplina Informatica concorre a far conseguire allo

Dettagli

EGOVERNMENT ED EGOVERNANCE

EGOVERNMENT ED EGOVERNANCE Prot. 13/2011 del 25/01/2011 Pag. 0 di 11 ADMINISTRA COMUNE DI NAPOLI Il progetto Administra nasce dall esigenza del Comune di Napoli di disporre di un unica infrastruttura tecnologica permanente di servizi

Dettagli

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata COD. PROD. D.6.3 1 Indice Considerazioni sulla virtualizzazione... 3 Vantaggi della virtualizzazione:... 3 Piattaforma di virtualizzazione...

Dettagli

CAPITOLATO TECNICO. Versione Data di rilascio Commenti 1.0 12.06.2012 Capitolato tecnico

CAPITOLATO TECNICO. Versione Data di rilascio Commenti 1.0 12.06.2012 Capitolato tecnico CAPITOLATO TECNICO PER L ACQUISIZIONE DI SERVIZI PROFESSIONALI PER LA PROGETTAZIONE E LO SVILUPPO SOFTWARE DI COMPONENTI DELLA BASE DI CONOSCENZA PUBBLICITÀ LEGALE ONLINE DEL PROGETTO PORTALE DELLA PUBBLICITÀ

Dettagli

Veronica Mobilio - CNIPA. Scegliere una piattaforma

Veronica Mobilio - CNIPA. Scegliere una piattaforma L Open Source per l elearningl ATutor vs Moodle Veronica Mobilio - CNIPA Scegliere una piattaforma Le PA che decidono di erogare progetti formativi in modalità elearning si trovano di fronte alla necessità

Dettagli

ALLEGATO 2 MODELLO DI OFFERTA TECNICA

ALLEGATO 2 MODELLO DI OFFERTA TECNICA ALLEGATO 2 MODELLO DI OFFERTA TECNICA Allegato 2 Modello di offerta tecnica Pagina 1 di 23 Premessa Nella redazione dell Offerta tecnica il concorrente deve seguire lo schema del modello proposto in questo

Dettagli

INTRODUZIONE: ALL INCLUSIVE

INTRODUZIONE: ALL INCLUSIVE INTRODUZIONE: ALL INCLUSIVE è l insieme di servizi, strumenti e tecniche che rendono un sito web accessibile e ottimizzato per assicurare che venga rinvenuto nelle prime posizioni sui motori di ricerca.

Dettagli

1. FINALITÀ E DEFINIZIONE DELLE SPECIFICHE TECNICHE E FUNZIONALI

1. FINALITÀ E DEFINIZIONE DELLE SPECIFICHE TECNICHE E FUNZIONALI 1. FINALITÀ E DEFINIZIONE DELLE SPECIFICHE TECNICHE E FUNZIONALI Per implementare una piattaforma di e-learning occorre considerare diversi aspetti organizzativi, gestionali e tecnici legati essenzialmente

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

Analisi di esperienze Open Source in ambito PA

Analisi di esperienze Open Source in ambito PA Analisi di esperienze Open Source in ambito PA Andrea Montemaggio Concreta-Mente a.montemaggio@gmail.com www.concreta-mente.it OSPA 2009 in sintesi Il concetto Open Source (Studies) nella Pubblica Amministrazione

Dettagli

Fase di offerta. Realizzazione del progetto

Fase di offerta. Realizzazione del progetto Linee guida per un buon progetto Commissione dell informazione e dei Sistemi di Automazione Civili e Industriali CONTENUTI A) Studio di fattibilità B) Progetto di massima della soluzione C) Definizione

Dettagli

Osservatorio Open Source del CNIPA: attività e prospettive Vittorio Pagani (resp. Osservatorio Open Source)

Osservatorio Open Source del CNIPA: attività e prospettive Vittorio Pagani (resp. Osservatorio Open Source) Osservatorio Open Source del CNIPA: attività e prospettive Vittorio Pagani ( Source (resp. Osservatorio Open Sommario Finanziaria 2007 e Commissione OS Uso dell Open Source per la PA L Osservatorio Open

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

Orientamenti. Orientamenti su alcuni aspetti dei requisiti di adeguatezza della direttiva MiFID. 25 giugno 2012 ESMA/2012/387

Orientamenti. Orientamenti su alcuni aspetti dei requisiti di adeguatezza della direttiva MiFID. 25 giugno 2012 ESMA/2012/387 Orientamenti Orientamenti su alcuni aspetti dei requisiti di adeguatezza della direttiva MiFID 25 giugno 2012 ESMA/2012/387 Data: 25 giugno 2012 ESMA/2012/387 Sommario I. Ambito di applicazione 3 II. Definizioni

Dettagli

L impatto delle politiche di riuso sull open source

L impatto delle politiche di riuso sull open source L impatto delle politiche di riuso sull open source Andrea Corradini andrea@di.unipi.it Dipartimento di Informatica, Pisa Open Source e Riuso: giornata di discussione e confronto fra enti e aziende Pisa,

Dettagli

La conservazione dei documenti in ambiente digitale: opportunità e criticità

La conservazione dei documenti in ambiente digitale: opportunità e criticità La conservazione dei documenti in ambiente digitale: opportunità e criticità di Guglielmo Longobardi Premessa Dopo un lungo periodo di immobilismo legislativo, che vedeva ancora in vigore il regio decreto

Dettagli

ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN

ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN PORTALE WEB NELL AMBITO DELLA MISURA 2.6. DEL POI ENERGIA FESR 2007 2013

Dettagli

Il software Open Source e la Pubblica Amministrazione: un alternativa reale. Vittorio Pagani Responsabile dell Osservatorio Open Source CNIPA

Il software Open Source e la Pubblica Amministrazione: un alternativa reale. Vittorio Pagani Responsabile dell Osservatorio Open Source CNIPA Il software Open Source e la Pubblica Amministrazione: un alternativa reale Vittorio Pagani Responsabile dell Osservatorio Open Source CNIPA CNIPA 28 giugno 2005 (1) Seminario: Il software Open Source

Dettagli

piemonte Direzione Tributi PROGETTO DI ANAGRAFE TRIBUTARIA DEL PIEMONTE

piemonte Direzione Tributi PROGETTO DI ANAGRAFE TRIBUTARIA DEL PIEMONTE CSI piemonte Direzione Tributi PROGETTO DI ANAGRAFE TRIBUTARIA DEL PIEMONTE INDICE SCOPO DEL DOCUMENTO... 3 CAMPO DI APPLICAZIONE.... 3 RIFERIMENTI... 3 OBIETTIVI DELL ATP... 3 DESCRIZIONE DEL PROGETTO...

Dettagli

Insieme di condividere: un modello di coordinamento per lo sviluppo open per la PA - aspetti legali. Laura Garbati Luca Gioppo 11 novembre 2008

Insieme di condividere: un modello di coordinamento per lo sviluppo open per la PA - aspetti legali. Laura Garbati Luca Gioppo 11 novembre 2008 Insieme di condividere: un modello di coordinamento per lo sviluppo open per la PA - aspetti legali Laura Garbati Luca Gioppo 11 novembre 2008 CSI Consorzio per i Sistemi Informatici della Regione Piemonte

Dettagli

Allegato 2: Prospetto informativo generale

Allegato 2: Prospetto informativo generale Gara a procedura ristretta accelerata per l affidamento, mediante l utilizzo dell Accordo Quadro di cui all art. 59 del D.Lgs. n. 163/2006, di Servizi di Supporto in ambito ICT a InnovaPuglia S.p.A. Allegato

Dettagli

e.toscana Compliance visione d insieme

e.toscana Compliance visione d insieme Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Ingegneria dei Sistemi Informativi e della Comunicazione I.T.S.A.E. e.toscana Compliance visione d insieme Gennaio 2007 Versione

Dettagli

Sistemi di knowledge management per innovativi modelli di governance dei progetti pubblici

Sistemi di knowledge management per innovativi modelli di governance dei progetti pubblici Sistemi di knowledge management per innovativi modelli di governance dei progetti pubblici Marco Gentili Area Governo e Monitoraggio delle Forniture ICT 1 Area Governo e Monitoraggio Forniture ICT Governo

Dettagli

La metodologia di valutazione dei siti Web della Pubblica Amministrazione. La metodologia di valutazione

La metodologia di valutazione dei siti Web della Pubblica Amministrazione. La metodologia di valutazione La metodologia di valutazione dei siti Web della Pubblica Amministrazione P. Atzeni, P. Merialdo, P. Russo, G. Sindoni, G. Sissa Paolo Merialdo Dipartimento di Informatica e Automazione Università Roma

Dettagli

Psicologa, Psicoterapeuta, Antropologa Articolo scaricato da HT Psicologia PROJECT MANAGEMENT PROJECT MANAGEMENT: CARATTERISTICHE GENERALI

Psicologa, Psicoterapeuta, Antropologa Articolo scaricato da HT Psicologia PROJECT MANAGEMENT PROJECT MANAGEMENT: CARATTERISTICHE GENERALI Project management Pag. 1 di 5 PROJECT MANAGEMENT PROJECT MANAGEMENT: CARATTERISTICHE GENERALI I motivi per cui la metodologia di project management è attualmente ritenuta uno strumento vincente nella

Dettagli

Perché e per chi. Perché Lyra News? Sistema di Gestione Offerte e Organizzazione dell Attività Commerciale

Perché e per chi. Perché Lyra News? Sistema di Gestione Offerte e Organizzazione dell Attività Commerciale Sistema di Gestione Offerte e Organizzazione dell Attività Commerciale Perché e per chi. Il processo di interazione cliente azienda che porta alla predisposizione dell offerta di un mezzo di produzione

Dettagli

Silk Learning Content Management. Collaboration, content, people, innovation.

Silk Learning Content Management. Collaboration, content, people, innovation. Collaboration, content, people, innovation. The Need for a Learning Content Management System In un mercato in continua evoluzione, dominato da un crescente bisogno di efficienza, il capitale intellettuale

Dettagli

Vi auguriamo un esperienza proficua e positiva con Oracle Siebel CRM On Demand!

Vi auguriamo un esperienza proficua e positiva con Oracle Siebel CRM On Demand! Introduzione Qui di seguito vengono esposte le risposte alle domande più frequenti relative a Oracle Siebel CRM On Demand. Inoltre, il Solutions Launchpad che contiene il link a questo documento offre

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

GARA A PROCEDURA APERTA AI SENSI DEL D.LGS. 163/2006 E S.M.I. PER L AFFIDAMENTO DI SERVIZI DI MANUTENZIONE

GARA A PROCEDURA APERTA AI SENSI DEL D.LGS. 163/2006 E S.M.I. PER L AFFIDAMENTO DI SERVIZI DI MANUTENZIONE ALLEGATO 2 GARA A PROCEDURA APERTA AI SENSI DEL D.LGS. 163/2006 E S.M.I. PER L AFFIDAMENTO DI SERVIZI DI MANUTENZIONE EVOLUTIVA, GESTIONE APPLICATIVA, MANUTENZIONE ADEGUATIVA, ASSISTENZA AGLI UTENTI E

Dettagli

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP.

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. INTERVISTA 13 settembre 2012 ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. Intervista ad Ermanno Pappalardo, Lead Solution Consultant HP Software

Dettagli

Architettura del sistema

Architettura del sistema 18/06/15 I N D I C E 1 INTRODUZIONE... 2 2 DEFINIZIONE DEGLI OBIETTIVI... 2 3 PROGETTO DI MASSIMA... 3 3.1 REQUISITI DELLA SOLUZIONE... 4 4 LA SOLUZIONE... 4 4.1 IL NUCLEO CENTRALE... 5 4.1.1 La gestione

Dettagli

L iniziativa Cloud DT

L iniziativa Cloud DT L iniziativa Cloud DT Francesco Castanò Dipartimento del Tesoro Ufficio per il Coordinamento Informatico Dipartimentale (UCID) Roma, Luglio 2011 Il Cloud Computing Alcune definizioni Il Cloud Computing

Dettagli

I VANTAGGI. Flessibilità

I VANTAGGI. Flessibilità E-LEARNING E-LEARNING La proposta E-Learning della suite Agorà di Dedagroup A CHI SI RIVOLGE L OFFERTA fornisce al cliente un sistema complementare di formazione a distanza sui prodotti della suite Agorà

Dettagli

LA MISURA DEL SERVIZIO DI ASSISTENZA AGLI UTENTI

LA MISURA DEL SERVIZIO DI ASSISTENZA AGLI UTENTI LA MISURA DEL SERVIZIO DI ASSISTENZA AGLI UTENTI Gruppo di monitoraggio INAIL Abstract È illustrata l esperienza INAIL di monitoraggio di contratti di servizi informatici in cui è prevista l assistenza

Dettagli

1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO

1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO 1 IL SISTEMA DI AUTOMAZIONE E TELECONTROLLO Quello che generalmente viene chiamato sistema di automazione d edificio si compone di diverse parti molto eterogenee tra loro che concorrono, su diversi livelli

Dettagli

C O M U N E D I C A S T E N A S O Provincia di Bologna VERBALE DI DELIBERAZIONE DELLA GIUNTA COMUNALE

C O M U N E D I C A S T E N A S O Provincia di Bologna VERBALE DI DELIBERAZIONE DELLA GIUNTA COMUNALE C O M U N E D I C A S T E N A S O Provincia di Bologna VERBALE DI DELIBERAZIONE DELLA GIUNTA COMUNALE ATTO n. 153 del 26/11/2009 OGGETTO: LINEE DI INDIRIZZO PER L ADOZIONE DI SOLUZIONI SOFTWARE OPEN SOURCE

Dettagli

AFFIDAMENTO DI SERVIZI PROFESSIONALI PER LO SVILUPPO E LA GESTIONE DEL SISTEMA DI CRAWLING DEI SITI WEB DELLA P.A., NELL AMBITO DEL PROGETTO ITALIA

AFFIDAMENTO DI SERVIZI PROFESSIONALI PER LO SVILUPPO E LA GESTIONE DEL SISTEMA DI CRAWLING DEI SITI WEB DELLA P.A., NELL AMBITO DEL PROGETTO ITALIA CAPITOLATO TECNICO AFFIDAMENTO DI SERVIZI PROFESSIONALI PER LO SVILUPPO E LA GESTIONE DEL SISTEMA DI CRAWLING DEI SITI WEB DELLA P.A., NELL AMBITO DEL PROGETTO ITALIA.GOV.IT MOTORE DELL AMMINISTRAZIONE

Dettagli

L EVOLUZIONE DEL RAPPORTO BANCA - IMPRESA CON BASILEA II E IL RUOLO DEL FACTORING

L EVOLUZIONE DEL RAPPORTO BANCA - IMPRESA CON BASILEA II E IL RUOLO DEL FACTORING L EVOLUZIONE DEL RAPPORTO BANCA - IMPRESA CON BASILEA II E IL RUOLO DEL FACTORING Relatore : Marino Baratti Credemfactor spa Pag. 1/8 Il rapporto tra PMI e Sistema creditizio L applicazione della nuova

Dettagli

LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE

LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE ottobre 2010 SCOPO E CAMPO DI APPLICAZIONE Scopo delle

Dettagli

Autorità per l Informatica nella Pubblica Amministrazione. Linee guida per la realizzazione di. Studi di Fattibilità

Autorità per l Informatica nella Pubblica Amministrazione. Linee guida per la realizzazione di. Studi di Fattibilità Autorità per l Informatica nella Pubblica Amministrazione Linee guida per la realizzazione di Studi di Fattibilità Versione 1.0 marzo 1997 SCOPO Questo documento costituisce un insieme di indicazioni base

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

6.Scuola e ICT in Piemonte

6.Scuola e ICT in Piemonte 6.Scuola e ICT in Piemonte 6.1 Considerazioni introduttive Nel corso del 2011, il CRC Piemonte, avvalendosi della collaborazione dell Osservatorio ICT, ha impostato ed avviato un lavoro di ricognizione

Dettagli

REGISTRO DEI DATORI DI LAVORO SOCIALMENTE RESPONSABILI ai sensi dell art. 15 della L. R. n. 30/2007

REGISTRO DEI DATORI DI LAVORO SOCIALMENTE RESPONSABILI ai sensi dell art. 15 della L. R. n. 30/2007 Dipartimento Istruzione, Formazione e Lavoro Settore Politiche del Lavoro e delle Migrazioni UO MONITORAGGIO E ANALISI REGISTRO DEI DATORI DI LAVORO SOCIALMENTE RESPONSABILI ai sensi dell art. 15 della

Dettagli

Playing by the Rules: Optimizing Travel Policy and Compliance

Playing by the Rules: Optimizing Travel Policy and Compliance Playing by the Rules: Optimizing Travel Policy and Compliance A CWT White Paper Una panoramica sui temi della travel policy e compliance Carlson Wagonlit Travel (CWT), l azienda leader mondiale nel settore

Dettagli

CAPITOLATO TECNICO. di cui al. BANDO DI SELEZIONE PER IL REPERIMENTO DI UN ESPERTO INFORMATICO nei ruoli del personale della scuola

CAPITOLATO TECNICO. di cui al. BANDO DI SELEZIONE PER IL REPERIMENTO DI UN ESPERTO INFORMATICO nei ruoli del personale della scuola ALLEGATO CAPITOLATO TECNICO di cui al BANDO DI SELEZIONE PER IL REPERIMENTO DI UN ESPERTO INFORMATICO nei ruoli del personale della scuola 1 INDICE 1. Premessa... 3 2. Definizione della fornitura... 3

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

ENTERPRISE CLUB MICROSOFT B USINESS I NTELLIGENCE. Disponibile anche sul sito: www.microsoft.com/italy/eclub/

ENTERPRISE CLUB MICROSOFT B USINESS I NTELLIGENCE. Disponibile anche sul sito: www.microsoft.com/italy/eclub/ B USINESS I NTELLIGENCE MICROSOFT ENTERPRISE CLUB Disponibile anche sul sito: www.microsoft.com/italy/eclub/ I vantaggi del TCO di SQL Server In base all analisi di NerveWire, utilizzando SQL Server rispetto

Dettagli

1. Analisi della rilevanza dell idea-progetto e specificazione delle alternative progettuali

1. Analisi della rilevanza dell idea-progetto e specificazione delle alternative progettuali Studi di Fattibilità e Analisi Costi Benefici L esperienza maturata dalla Proind Srl nel supporto e nell assistenza tecnica alle Pubbliche Amministrazioni in materia di valutazione di investimenti pubblici,

Dettagli

per migliorare la distribuzione dei materiali con contenuti didattici di PTC University

per migliorare la distribuzione dei materiali con contenuti didattici di PTC University PTC adotta il proprio software Arbortext per migliorare la distribuzione dei materiali con contenuti didattici di PTC University Corsi di qualità superiore e cicli di sviluppo più veloci per i contenuti

Dettagli

CPS1 Linee guida per l uso dei sistemi di e- learning nella didattica

CPS1 Linee guida per l uso dei sistemi di e- learning nella didattica learning nella didattica Il presente documento propone la struttura e i contenuti di un possibile documento relativo alle linee guida sull uso dell elearning nell ambito delle attività didattiche con riferimento

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

La cultura della gestione della conoscenza è diventata

La cultura della gestione della conoscenza è diventata RAGONAMENT 41 La rete per insegnare D FABRZO EMER Tecnologie e modelli per l e-teaching La cultura della gestione della conoscenza è diventata il punto focale dell apprendimento. Questa innovazione comporta

Dettagli

CAPITOLATO TECNICO. Pag 1 di 14

CAPITOLATO TECNICO. Pag 1 di 14 GARA A PROCEDURA APERTA PER L AFFIDAMENTO DEI SERVIZI DI MONITORAGGIO, VERIFICA E SUPPORTO TECNICO AI PROGETTI REALIZZATI DALLE SCUOLE AMMESSE AL FINANZIAMENTO NELL AMBITO DELL INIZIATIVA E-INCLUSION.

Dettagli

Open City Platform OCP

Open City Platform OCP Open City Platform OCP Come rendere intelligente la città (un passo per volta)? Una piattaforma cloud aperta robusta, scalabile e flessibile per accelerare l attivazione digitale dei servizi della PA INFN

Dettagli

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA Il project management nella scuola superiore di Antonio e Martina Dell Anna 2 PARTE VII APPENDICE I CASI DI STUDIO Servizi pubblici territoriali online

Dettagli

L INNOVAZIONE TECNOLOGICA E L OPEN SOURCE AL SERVIZIO DELLA PA INAIL CONSULENZA PER L INNOVAZIONE TECNOLOGICA Alessandro Simonetta Guido Borsetti

L INNOVAZIONE TECNOLOGICA E L OPEN SOURCE AL SERVIZIO DELLA PA INAIL CONSULENZA PER L INNOVAZIONE TECNOLOGICA Alessandro Simonetta Guido Borsetti L INNOVAZIONE TECNOLOGICA E L OPEN SOURCE AL SERVIZIO DELLA PA INAIL CONSULENZA PER L INNOVAZIONE TECNOLOGICA Alessandro Simonetta Guido Borsetti Premessa Il rapporto tra open source e innovazione è un

Dettagli

Ai sensi del comma 3 bis dell art. 24 del D.L. 90/2014 convertito nella legge 11/08/2014 n. 114

Ai sensi del comma 3 bis dell art. 24 del D.L. 90/2014 convertito nella legge 11/08/2014 n. 114 Piano di informatizzazione delle procedure per la presentazione di istanze, dichiarazioni e segnalazioni che permetta la compilazione on line con procedure guidate accessibili tramite autenticazione con

Dettagli

Vademecum per la realizzazione di progetti formativi in modalità e-learning nelle P.A.

Vademecum per la realizzazione di progetti formativi in modalità e-learning nelle P.A. Vademecum per la realizzazione di progetti formativi in modalità e-learning nelle P.A. Seconda edizione Prof.ssa Mirella Schaerf - Dott.ssa Veronica Mobilio Gli argomenti Lo scenario L impatto organizzativo

Dettagli

L applicazione del Nuovo Soggettario in SBN

L applicazione del Nuovo Soggettario in SBN L applicazione del Nuovo Soggettario in SBN Introduzione L obiettivo del Gruppo è stato quello di individuare le modalità per rendere possibile la più ampia diffusione ed applicazione nella rete SBN del

Dettagli

LINEE GUIDA RIGUARDO LA SCELTA E L IMPIEGO DELLA FUNZIONALITA DI LOCALIZZAZIONE NELL AMBITO DELLA RETE RADIOMOBILE REGIONALE ERretre

LINEE GUIDA RIGUARDO LA SCELTA E L IMPIEGO DELLA FUNZIONALITA DI LOCALIZZAZIONE NELL AMBITO DELLA RETE RADIOMOBILE REGIONALE ERretre LINEE GUIDA RIGUARDO LA SCELTA E L IMPIEGO DELLA FUNZIONALITA DI LOCALIZZAZIONE NELL AMBITO DELLA RETE RADIOMOBILE REGIONALE ERretre Pagina 1 di 9 1.Introduzione. La rete Tetra ERretre permette di realizzare

Dettagli

La valutazione economico-tecnica del software contabile

La valutazione economico-tecnica del software contabile La valutazione economico-tecnica del software contabile fino a qualche tempo fa... hardware assorbe la maggiore quota dell investimento software predisposto internamente obiettivi nella valutazione degli

Dettagli

Osservazioni e proposte ANIGAS

Osservazioni e proposte ANIGAS DCO 25/08 ATTIVAZIONE DI UN SISTEMA DI RICERCA DELLE OFFERTE COMMERCIALI DELLE IMPRESE DI VENDITA DI ENERGIA ELETTRICA E DI GAS Documento per la consultazione Osservazioni e proposte ANIGAS Milano, 8 agosto

Dettagli