Risultati
339 risultati
-
italia
2.3. Valutazione comparativa
Vista l’eterogeneità delle soluzioni e la difficoltà ad effettuare comparazioni quantitative omogenee, come in caso di confronto tra una soluzione dalla quale possano essere ricavati costi certi (soluzione proprietaria in modalità on premise o in modalità cloud computing) e una soluzione da realizzare ex novo - per la quale si disponga soltanto dello studio di fattibilità - si è preferito indicare un processo decisionale attraverso la descrizione di Fasi e la loro organizzazione in Macro fasi. La seguente immagine riporta le Macro fasi che caratterizzano il processo decisionale per dare seguito alla valutazione comparativa prevista all’articolo 68 del CAD. Le Macro fasi individuate sono:. MACRO FASE 1:. Ha l’obiettivo di definire le esigenze specificando i bisogni e i vincoli (organizzativi ed economici) che condizionano le scelte per l’identificazione di una soluzione adeguata alle esigenze dell’amministrazione;. MACRO FASE 2:. Qui la pubblica amministrazione accerta la possibilità di soddisfare le proprie esigenze utilizzando una soluzione già in uso presso altre amministrazioni (di seguito «soluzioni a riuso delle PA») o a software libero o codice sorgente aperto (di seguito «soluzioni Open Source»). MACRO FASE 3:. Ove la Macro fase 2 non permetta di rispondere alle esigenze della Pubblica amministrazione, si persegue il soddisfacimento delle stesse attraverso il ricorso a programmi informatici di tipo proprietario, mediante ricorso a licenza d’uso e/o a realizzazioni ex novo. In quanto segue le Macro fasi individuate sono suddivise in Fasi, descrivendo le attività da realizzare in termini di criteri e metodologie da adottare ...
-
italia
2.1. Introduzione e contesto normativo
Per le Pubbliche amministrazioni il Codice dell’Amministrazione Digitale, di seguito denominato CAD, disciplina il riuso delle soluzioni e standard aperti. Gli articoli 68 e 69, che le presenti Linee guida hanno l’obiettivo di attuare, trattano nel medesimo contesto i temi del riuso, della titolarità del software e del codice sorgente aperto per le PPAA. Gli articoli richiamati sono stati modificati sia dal d.lgs. 26 agosto 2016 n. 179 sia dal d.lgs. 12 gennaio 2017 n. 217. L’ultimo aggiornamento ha comportato:. la riformulazione dell’art. 69, comma 2;. l’introduzione del comma 2 bis dell’art. 69;. l’abrogazione dell’articolo 70 rubricato banca dati dei programmi informatici riutilizzabili. Il testo dell’art. 68 è rimasto immutato, eccezion fatta per l’aggiornamento del riferimento normativo al D.Lgs. 50/2016 [1] in luogo del richiamo alla precedente normativa in materia di appalti. Fino alla modifica apportata dal D.Lgs. 217/2017, nell’acquisizione di software da parte delle pubbliche amministrazioni svolgevano un ruolo:. le convenzioni quadro e gli accordi quadro stipulati, ai sensi della normativa vigente, da CONSIP e dai soggetti aggregatori;. il Catalogo nazionale programmi riutilizzabili gestito dall’AgID. I primi due continuano a svolgere la funzione, mentre le funzioni del catalogo, abrogato in quanto tale dal CAD, sono assunte dal portale Developers Italia (https://developers.italia.it), che assume il ruolo di «piattaforma», rectius repertorio - secondo la dizione dell’art. 69 co. 1 -, e delle piattaforme di cui all’art. 69 co. 2bis. Il presente documento ribadisce che i «principi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica» (comma 1 dell’art. 68 del CAD [2]) si raggiungono attuando quanto previsto dal comma 2 dell’art. 69 del CAD [3]: «il riuso dei programmi informatici di proprietà delle pubbliche amministrazioni» garantendo che queste ultime, oltre ad essere titolari del software, rendano il software Open Source attraverso l’apposizione di una licenza aperta. http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2016-04-18;50!vig=. http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=~art68. http://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2005-03-07;82!vig=~art69 ...
-
italia
2.6. Macro fase 3: Analisi delle altre soluzioni
A seguito della precedente fase 3.3 l’amministrazione ha determinato una soluzione, con licenza proprietaria o da realizzarsi ex novo, che soddisfa le sue esigenze e provvede all’approvvigionamento della stessa secondo le procedure previste dal Codice dei contratti pubblici. Nel caso in cui si opti per la realizzazione ex novo, considerando i commi 1 e 2 dell’Articolo 69 che disciplinano la messa a riuso del software che verrà realizzato, si rimanda a Sviluppo di software ex novo per le informazioni su come progettare questa realizzazione per adempiere ai commi citati e metterlo così a riuso. Nel caso che si proceda ad una acquisizione di software proprietario sotto licenza, si ricorda che l’Amministrazione deve ove possibile acquisire la titolarità del codice sviluppato (come spiegato in Titolarità), per metterlo a riuso. La valutazione comparativa si considera conclusa. [1]. Analisi di Fattibilità per l’acquisizione delle forniture ICT ...
-
italia
2.7. Total Cost of Ownership (TCO)
Le valutazioni comparative economiche sono effettuate attraverso l’utilizzo di strumenti economico/finanziari quali il TCO (Total Cost of Ownership), che rappresenta il costo globale di un bene durante il suo ciclo di vita. Il TCO prende in considerazione sia i costi diretti che i costi indiretti, rappresentando il metodo consigliato sia per misurare i costi totali (attraverso l’identificazione di tutte le spese, in termini chiari e facilmente misurabili), sia per effettuare la suddetta valutazione comparativa durante la fase 3. Per eseguire correttamente un TCO, è necessario calcolare i costi dell’intero ciclo di vita del software e non solo quelli meramente necessari alla sua acquisizione, come per esempio:. Costi per la personalizzazione del software;. Costi di manutenzione (correttiva e evolutiva);. Costi di formazione del personale;. Costi di migrazione dei dati da precedenti soluzioni. In questa linea guida, è stato indicato di utilizzare il TCO in due diversi fasi: durante la Macro Fase 2 (come strumento per stimare il costo relativo all’acquisizione di un software open source), e durante la Macro Fase 3 (come strumento per valutare una eventuale scelta tra la realizzazione ex-novo e l’acquisizione di software proprietario). Ai fini dell’adempimento a questa Linea Guida, quindi, si richiede che in fase di analisi comparativa l’amministrazione effettui una stima dei costi secondo il modello qui delineato, tenendo sempre conto di tutto il ciclo di vita. Questa analisi dovrà essere tanto più accurata quanto grossa è l’acquisizione necessaria. Fornire modelli di calcolo del TCO per le esigenze delle amministrazioni va oltre gli obiettivi di questa Linee Guida, poiché le esigenze sono le più differenti. AgID potrà, in futuro, pubblicare dei modelli facoltativi, pronti all’uso, all’interno della piattaforma Developers Italia ...
-
italia
2.2. Oggetto della valutazione
La valutazione comparativa deve essere svolta quando le pubbliche amministrazioni intendano acquisire «programmi informatici o parti di essi». L’oggetto della valutazione quindi è un software (come identificato in 1.2. software oggetto di queste linee guida) che risponda a specifiche esigenze funzionali dell’amministrazione. A titolo esemplificativo, rimane all’esterno del perimetro di questo documento l’acquisizione di sole componenti hardware dei sistemi informativi (server, postazioni di lavoro, stampanti, ecc.). Ulteriori situazioni dove non è applicabile il percorso decisionale proposto in questo Capitolo 2 possono riguardare ad esempio:. accordi quadro, in quanto strumenti che definiscono esclusivamente le clausole generali che, in un determinato periodo temporale, regolano i contratti da stipulare (le caratteristiche specifiche della singola fornitura vengono successivamente definite in appositi Appalti Specifici);. completamento di progetti o realizzazioni per le quali la valutazione comparativa sia già stata effettuata preliminarmente all’acquisizione iniziale;. gare che abbiano come oggetto l’outsourcing completo dei sistemi informativi, in quanto la scelta dell’esternalizzazione riguarda un ambito strategico che esula dallo specifico contesto delle presenti Linee guida e risponde a scelte di governance dell’amministrazione e a obiettivi di carattere strategico di ordine più generale. Si noti che nei casi qui elencati si devono comunque applicare le Linee Guida sul riuso del Software descritte nel Capitolo 3 ...
-
italia
2.8. Scelta della modalità di erogazione del software
Nel caso in cui il software (a riuso, open source o proprietario) debba essere installato su server, l’amministrazione si potrebbe trovare a valutare la modalità di erogazione tra le seguenti opzioni:. installazione su un server nella disponibilità diretta dell’amministrazione. La scelta tra queste opzioni deve avvenire tramite il calcolo del Total Cost of Ownership come descritto nella sezione 2.7. Total Cost of Ownership (TCO). Secondo quanto disciplinato nel capitolo 3 del Piano Triennale per l’Informatica nella PA, ai fini dell’installazione su server nella propria disponibilità l’Amministrazione deve ricorrere all’utilizzo del cosiddetto Cloud della PA, scegliendo una delle seguenti opzioni di tipo IaaS:. installazione in Cloud SPC Lotto 1;. installazione in Cloud Service Provider Qualificati ai sensi della circolare AGID «Criteri per la qualificazione dei Cloud Service Provider per la PA» ...
-
italia
2.4. Macro fase 1: Individuazione delle esigenze
L’amministrazione redige il documento descrittivo delle esigenze da utilizzarsi nelle fasi successive della valutazione comparativa. Le attività previste in questa fase sono:. redazione del documento descrittivo delle esigenze che contiene le evidenze delle precedenti fasi 1.1 e 1.2. La presente fase si conclude con la:. disponibilità del documento descrittivo delle esigenze ...
-
italia
2.5. Macro fase 2: Analisi delle soluzioni a riuso delle PA e delle soluzioni Open Source
Nel caso in cui sia accertata l’impossibilità di individuare una soluzione che soddisfi almeno in larga misura le esigenze dell’amministrazione tra le «soluzioni a riuso della PA» e le «soluzioni Open Source», si procede alla redazione di un documento (senza vincoli di forma) che motivi le ragioni dell’accertata impossibilità, da conservare agli atti del procedimento. La pubblica amministrazione prosegue la valutazione comparativa dando seguito alle Fasi previste nella successiva Macro fase 3 ...
-
italia
1.5. Titolarità
Ai sensi dell’articolo 69 del CAD in materia di riuso, un’amministrazione deve considerarsi titolare di un software realizzato su proprie specifiche indicazioni ogni qualvolta che:. il software sia stato realizzato da risorse interne all’amministrazione stessa. Ogni amministrazione deve, in sede di negoziazione di un contratto volto a commissionare lo sviluppo di un software, garantirsi, all’esito dell’esecuzione del contratto, la piena ed esclusiva titolarità di tutti i diritti sul software oggetto di sviluppo, salvo che questo risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico (dal comma 2 dell’articolo 69 del CAD). Per software oggetto di sviluppo, si intendono le parti di software effettivamente sviluppate in esecuzione del contratto; resta inteso che lo sviluppo potrebbe basarsi sull’utilizzo di componenti software già esistenti (es: librerie e framework open source di terzi) per le quali non è necessario acquisire titolarità ma solo licenza d’uso (che dev’essere compatibile con le finalità di riuso). La mancata acquisizione della titolarità dell’opera non può essere utilizzata per ottenere condizioni economiche più vantaggiose, poiché non costituisce comprovata ragione di carattere tecnico-economico ai sensi dell’articolo 69 comma 2 del CAD. Un’amministrazione, ai sensi dell’articolo 69, deve egualmente acquisire la totalità dei diritti di proprietà intellettuale e industriale su eventuali personalizzazioni o moduli software destinati a integrarsi o interfacciarsi con un software proprietario. In tal caso, l’obbligo di cui all’art. 69 avrà ad oggetto esclusivamente il modulo o la parte del software oggetto di sviluppo; tale modulo dovrà quindi essere separato dal resto del software e rilasciato secondo le modalità indicate in Sviluppo di software ex novo), avendo cura di indicare la necessaria dipendenza proprietaria nella documentazione. Ad esempio, espressioni come quelle che seguono, ove presenti nei contratti per lo sviluppo di software consentono di ritenere che l’amministrazione sia titolare dei diritti nel senso richiesto dall’articolo 69 del CAD:. «la proprietà della soluzione informatica oggetto del contratto farà capo al committente o all’Amministrazione»;. «al termine del contratto la proprietà intellettuale sulla soluzione informatica oggetto di sviluppo competerà all’amministrazione committente»;. «tutti i diritti d’autore sul software sviluppato verranno trasferiti, a seguito del completamento dell’opera, all’amministrazione committente che ne diverrà titolare»;. «tutti i diritti di sfruttamento economico sul software oggetto del contratto competono all’amministrazione committente» ...
-
italia
1.7. Glossario
Sottoprodotto realizzato durante lo sviluppo del software che aiuta a descrivere funzioni, architettura, progettazione e messa in esercizio; a solo titolo di esempio: requisiti funzionali, descrizione delle basi dati e dei processi, il set di test. Code Hosting (strumento di). Una piattaforma che consente la pubblicazione di codice sorgente, organizzato in più repository. Gli strumenti di code hosting offrono spesso anche funzionalità legate all’evoluzione di un software quali sistemi di ticketing, processi per la contribuzione di codice da parte di terzi, area per il download dei rilasci, ecc. Nell’ambito delle presenti Linee Guida, gli strumenti scelti dalle amministrazioni devono avere dei requisiti minimi in termini di funzionalità (Scelta di uno strumento di code hosting). Codice sorgente. Il codice sorgente (spesso detto semplicemente «sorgente») è il testo di un programma scritto in un linguaggio di programmazione (es. C o Visual Basic) dal quale si deriva il programma finale che l’utente usa. L’accesso al codice sorgente è essenziale per poter modificare un programma. Community. Aggregazione di persone, fisiche e giuridiche, e risorse (ad esempio forum, chat e tecnologie per riunirsi e interagire in una località virtuale), dotata di regole e di una struttura, finalizzata alla realizzazione e/o gestione di un progetto comune. Formato aperto (di dato). È un formato di dato pubblico, versionato, documentato esaustivamente e senza vincoli all’implementazione. Un formato aperto è un formato riconosciuto da un ente di standardizzazione e mantenuto in modo condiviso tra più enti che forniscono implementazioni concorrenti, con un processo trasparente. Il formato deve rimanere consistente con la versione dichiarata. Formato di dato. Modalità di rappresentazione del dato. Interoperabilità. In ambito informatico, la capacità di sistemi differenti e autonomi di cooperare e di scambiare informazioni in maniera automatica, sulla base di regole condivise. Licenza. In ambito informatico, il testo legale con il quale si concedono determinati diritti sul software e sui dati distribuiti, che altrimenti sarebbero riservati da diritti di privativa. Lock-in. Fenomeno di natura tecnica ed economica in cui un generico utente non riesce a svincolarsi da una scelta tecnologica precedentemente effettuata. Tale incapacità è tipicamente causata degli elevati costi legati al cambio di tecnologia ma, in molti casi, può anche dipendere dall’adozione di soluzioni proprietarie che impediscono di effettuare migrazioni. L’utilizzo di formati aperti per il salvataggio dei dati, e l’accesso libero a questi dati (soprattutto nel caso di soluzioni SaaS) sono prerequisiti per evitare fenomeni di lock-in. Open Source. È una modalità con cui il software può essere concesso in licenza. Si realizza attraverso la concessione al pubblico, dei diritti di uso, copia, modifica, distribuzione di copie anche modificate, del software; per fare ciò, è necessario anche che il codice sorgente sia liberamente disponibile. Altrimenti detto «software libero», «software aperto» o «software rilasciato sotto licenza aperta». L’ente certificatore delle licenze software corrispondenti a questa definizione è Open Source Initiative (OSI). Repertorio o Repository. All’interno di uno strumento di code-hosting, un repository è l’unità minima di contenimento del codice sorgente di un software. Il termine «repertorio» è la sua traduzione italiana (usata per esempio nel CAD Art 69, comma 1). Riuso. Nel contesto di queste Linee Guida, si intende il processo delineato dal CAD (art. 69) con il quale una amministrazione distribuisce («mettere a riuso») un software di cui ha titolarità in Open Source, a favore di altre amministrazioni che possano utilizzarlo («prendere a riuso»). Tutto il software a riuso è Open Source, ma non tutto il software Open Source è a riuso (poiché non tutto il software Open Source è di titolarità di una amministrazione). SaaS. software as a Service. Indica una modalità di distribuzione del software che non viene installato sulle postazioni degli operatori, ma che avviene attraverso l’accesso remoto a un server, per esempio collegandosi con un browser ad un indirizzo. Wikipedia, per esempio, è un software distribuito in modalità software as a Service. Software proprietario. software che ha restrizioni sul suo utilizzo, sulla sua modifica, riproduzione o ridistribuzione, imposti dal titolare dei diritti di sfruttamento economico, cioè l’autore o - in caso di cessione dei diritti patrimoniali - il cessionario dei diritti in questione. TCO. Total Cost of Ownership: Approccio utilizzato per valutare tutti i costi del ciclo di vita di una risorsa IT calcolato su una finestra temporale adeguata al contesto della valutazione e che include il costo di migrazione verso altra soluzione (eg., acquisto, installazione, gestione, manutenzione e smantellamento). L’approccio TCO è basato sulla considerazione che il costo totale di utilizzo di risorsa IT non dipende solo dai costi di acquisto, ma anche da tutti i costi che intervengono durante l’intera vita di esercizio della risorsa stessa ...
-
italia
1.3. Riuso del software
Si intende come «riuso» di un software il complesso di attività svolte per poterlo utilizzare in un contesto diverso da quello per il quale è stato originariamente realizzato, al fine di soddisfare esigenze similari a quelle che portarono al suo primo sviluppo. Il prodotto originario viene «trasportato» nel nuovo contesto arricchendolo, se necessario, di ulteriori funzionalità e caratteristiche tecniche che possono rappresentare un «valore aggiunto» per i suoi utilizzatori. Dal combinato disposto degli articoli 68 e 69 del CAD, il software in riuso è esclusivamente quello rilasciato sotto licenza aperta da una pubblica amministrazione. Questo è dunque un sottoinsieme di tutto il software open source disponibile per l’acquisizione. Le presenti linee guida distinguono, ove necessario, le modalità di acquisizione di software di pubbliche amministrazioni assoggettato a licenza aperta rispetto a software open source di terzi. Un aspetto fondamentale del riuso nel contesto della Pubblica Amministrazione è che l’Amministrazione che «riusa» riceve il software gratuitamente dall’Amministrazione cedente, e lo acquisisce sostenendo solo le spese di suo adattamento, ma non quelle di progettazione e realizzazione ...
-
italia
1.6. Conformità del software alla normativa
Il riuso del software è un canale di amplificazione di ogni scelta in ambito informatico ed è completamente neutro rispetto alla bontà o erroneità di tali scelte. Esso può agire da moltiplicatore dell’impatto delle buone prassi o, allo stesso modo, da moltiplicatore di scelte erronee la cui diffusione non è auspicabile. Nel promuovere il riuso e la diffusione del software sul quale insistono diritti di proprietà intellettuale di un’amministrazione, con un importante vantaggio economico e in termini di efficienza, è importante richiamare l’attenzione delle singole Amministrazioni sull’importanza che il software posto in riuso - come d’altra parte l’intero parco software in uso a ogni amministrazione - sia conforme alla disciplina vigente. Poiché il processo di acquisizione di un software in riuso spesso comprende personalizzazioni e aggregazioni di diverse componenti, alcune delle quali potrebbero non essere più in uso o rilasciate anche anni prima, è importante ricordare che la verifica della piena conformità ai contesti normativi rimane in capo all’amministrazione che prenda in riuso un software, poiché solo ad essa compete la responsabilità delle decisioni assunte nell’ambito dei margini di discrezionalità assegnati e nel rispetto dei principi costituzionali di buon andamento ...