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 =

DigitPA LINEE GUIDA. Centro di competenza del riuso. DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 140

DigitPA LINEE GUIDA. Centro di competenza del riuso. DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 140 LINEE GUIDA PER L INSERIMENTO ED IL RIUSO DI PROGRAMMI INFORMATICI O PARTI DI ESSI PUBBLICATI NELLA BANCA DATI DEI PROGRAMMI INFORMATICI RIUTILIZZABILI DI DIGITPA DigitPA 00137 Roma - viale Marx, 43 Pagina

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI

Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI Forniamo in questo articolo le risposte ai 53 quesiti ricevuti

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

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

PROGRAMMA PER LA TRASPARENZA DECRETO LEGISLATIVO 14 MARZO 2013 N. 33

PROGRAMMA PER LA TRASPARENZA DECRETO LEGISLATIVO 14 MARZO 2013 N. 33 Settore Segreteria e Direzione generale Ufficio Trasparenza e Comunicazione PROGRAMMA PER LA TRASPARENZA DECRETO LEGISLATIVO 14 MARZO 2013 N. 33 Relazione anno 2014 a cura del Segretario Generale e della

Dettagli

Carta di servizi per il Protocollo Informatico

Carta di servizi per il Protocollo Informatico Carta di servizi per il Protocollo Informatico Codice progetto: Descrizione: PI-RM3 Implementazione del Protocollo informatico nell'ateneo Roma Tre Indice ARTICOLO 1 - SCOPO DEL CARTA DI SERVIZI...2 ARTICOLO

Dettagli

Guida alle offerte di finanziamento per le medie imprese

Guida alle offerte di finanziamento per le medie imprese IBM Global Financing Guida alle offerte di finanziamento per le medie imprese Realizzata da IBM Global Financing ibm.com/financing/it Guida alle offerte di finanziamento per le medie imprese La gestione

Dettagli

Corso Base ITIL V3 2008

Corso Base ITIL V3 2008 Corso Base ITIL V3 2008 PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it L informazione come risorsa strategica Nelle aziende moderne l informazione

Dettagli

Milano, Settembre 2009 BIOSS Consulting

Milano, Settembre 2009 BIOSS Consulting Milano, Settembre 2009 BIOSS Consulting Presentazione della società Agenda Chi siamo 3 Cosa facciamo 4-13 San Donato Milanese, 26 maggio 2008 Come lo facciamo 14-20 Case Studies 21-28 Prodotti utilizzati

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 5 Marco Fusaro KPMG S.p.A. 1 CobiT: strumento per la comprensione di una

Dettagli

Circolare n. 64 del 15 gennaio 2014

Circolare n. 64 del 15 gennaio 2014 Circolare n. 64 del 15 gennaio 2014 Ordinativo informatico locale - Revisione e normalizzazione del protocollo sulle regole tecniche ed obbligatorietà dell utilizzo nei servizi di tesoreria PREMESSA L

Dettagli

Esperienze e soluzioni realizzate nell ambito del Progetto S.I.MO.NE

Esperienze e soluzioni realizzate nell ambito del Progetto S.I.MO.NE Programma Enti Locali Innovazione di Sistema Esperienze e soluzioni realizzate nell ambito del Progetto S.I.MO.NE 1 Premessa Il presente documento ha lo scopo di facilitare la disseminazione e il riuso

Dettagli

RELAZIONI TRA SERVIZI PER L IMPIEGO

RELAZIONI TRA SERVIZI PER L IMPIEGO RELAZIONI TRA SERVIZI PER L IMPIEGO E AZIENDE-UTENTI L IMPATTO DELLE PROCEDURE INFORMATIZZATE a cura di Germana Di Domenico Elaborazione grafica di ANNA NARDONE Monografie sul Mercato del lavoro e le politiche

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto Scheda descrittiva del programma Open-DAI ceduto in riuso CSI-Piemonte in rappresentanza del Consorzio di progetto Agenzia per l Italia Digitale - Via Liszt 21-00144 Roma Pagina 1 di 19 1 SEZIONE 1 CONTESTO

Dettagli

9 Forum Risk Management in Sanità. Progetto e Health. Arezzo, 27 novembre 2014

9 Forum Risk Management in Sanità. Progetto e Health. Arezzo, 27 novembre 2014 9 Forum Risk Management in Sanità Tavolo interassociativo Assinform Progetto e Health Arezzo, 27 novembre 2014 1 Megatrend di mercato per una Sanità digitale Cloud Social Mobile health Big data IoT Fonte:

Dettagli

REGOLAMENTO IMPRESA IN AZIONE

REGOLAMENTO IMPRESA IN AZIONE REGOLAMENTO IMPRESA IN AZIONE Premessa Impresa in azione è il programma didattico dedicato agli studenti degli ultimi anni della Scuola Superiore e pensato per valorizzare la creatività e lo spirito imprenditoriale

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

CONDIVISIONE DI SOFTWARE A CODICE SORGENTE APERTO

CONDIVISIONE DI SOFTWARE A CODICE SORGENTE APERTO CONDIVISIONE DI SOFTWARE A CODICE SORGENTE APERTO Studio di fattibilità IDA (Interchange of Data between Administrations - Scambio di dati fra amministrazioni) Commissione europea, DG Imprese Autori: Patrice-Emmanuel

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi

L evoluzione del software per l azienda moderna. Gestirsi / Capirsi / Migliorarsi IL GESTIONALE DEL FUTURO L evoluzione del software per l azienda moderna Gestirsi / Capirsi / Migliorarsi IL MERCATO ITALIANO L Italia è rappresentata da un numero elevato di piccole e medie aziende che

Dettagli

Classificazioni dei sistemi di produzione

Classificazioni dei sistemi di produzione Classificazioni dei sistemi di produzione Sistemi di produzione 1 Premessa Sono possibili diverse modalità di classificazione dei sistemi di produzione. Esse dipendono dallo scopo per cui tale classificazione

Dettagli

Metadati e Modellazione. standard P_META

Metadati e Modellazione. standard P_META Metadati e Modellazione Lo standard Parte I ing. Laurent Boch, ing. Roberto Del Pero Rai Centro Ricerche e Innovazione Tecnologica Torino 1. Introduzione 1.1 Scopo dell articolo Questo articolo prosegue

Dettagli

1. Premessa. Il contesto generale.

1. Premessa. Il contesto generale. Linee di indirizzo del Comitato interministeriale (d.p.c.m. 16 gennaio 2013) per la predisposizione, da parte del Dipartimento della funzione pubblica, del PIANO NAZIONALE ANTICORRUZIONE di cui alla legge

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

COME NASCE L IDEA IMPRENDITORIALE E COME SI SVILUPPA IL PROGETTO D IMPRESA: IL BUSINESS PLAN

COME NASCE L IDEA IMPRENDITORIALE E COME SI SVILUPPA IL PROGETTO D IMPRESA: IL BUSINESS PLAN COME NASCE L IDEA IMPRENDITORIALE E COME SI SVILUPPA IL PROGETTO D IMPRESA: IL BUSINESS PLAN La nuova impresa nasce da un idea, da un intuizione: la scoperta di una nuova tecnologia, l espansione della

Dettagli

8. Le scelte che determinano impatti sui costi

8. Le scelte che determinano impatti sui costi 8. Le scelte che determinano impatti sui costi 8.1 INTRODUZIONE Per valutare e controllare i costi di una soluzione e-learning è necessario conoscere in maniera approfondita i fattori da cui dipendono

Dettagli

MARKETING INTELLIGENCE SUL WEB:

MARKETING INTELLIGENCE SUL WEB: Via Durini, 23-20122 Milano (MI) Tel.+39.02.77.88.931 Fax +39.02.76.31.33.84 Piazza Marconi,15-00144 Roma Tel.+39.06.32.80.37.33 Fax +39.06.32.80.36.00 www.valuelab.it valuelab@valuelab.it MARKETING INTELLIGENCE

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

Ottimizzare gli sconti per incrementare i profitti

Ottimizzare gli sconti per incrementare i profitti Ottimizzare gli sconti per incrementare i profitti Come gestire la scontistica per massimizzare la marginalità di Danilo Zatta www.simon-kucher.com 1 Il profitto aziendale è dato da tre leve: prezzo per

Dettagli

CRITERI PER L ASSEGNAZIONE DI CREDITI ALLE ATTIVITA ECM

CRITERI PER L ASSEGNAZIONE DI CREDITI ALLE ATTIVITA ECM CRITERI PER L ASSEGNAZIONE DI CREDITI ALLE ATTIVITA ECM 1. Introduzione 2. Pianificazione dell attività formativa ECM 3. Criteri per l assegnazione dei crediti nelle diverse tipologie di formazione ECM

Dettagli

Documento di accompagnamento: mediane dei settori non bibliometrici

Documento di accompagnamento: mediane dei settori non bibliometrici Documento di accompagnamento: mediane dei settori non bibliometrici 1. Introduzione Vengono oggi pubblicate sul sito dell ANVUR e 3 tabelle relative alle procedure dell abilitazione scientifica nazionale

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

Dettagli

I N F I N I T Y Z U C C H E T T I WORKFLOW HR

I N F I N I T Y Z U C C H E T T I WORKFLOW HR I N F I N I T Y Z U C C H E T T I WORKFLOW HR WORKFLOW HR Zucchetti, nell ambito delle proprie soluzioni per la gestione del personale, ha realizzato una serie di moduli di Workflow in grado di informatizzare

Dettagli

2.0 DAL WEB. social. tecnologico, 2006. Reply www.reply.eu

2.0 DAL WEB. social. tecnologico, 2006. Reply www.reply.eu ALL INTERNO DEL FIREWALL: ENI 2.0 Il modo di lavorare è soggetto a rapidi cambiamenti; pertanto le aziende che adottano nuovi tool che consentono uno scambio di informazioni contestuale, rapido e semplificato

Dettagli

(Atti non legislativi) REGOLAMENTI

(Atti non legislativi) REGOLAMENTI 24.12.2013 Gazzetta ufficiale dell Unione europea L 352/1 II (Atti non legislativi) REGOLAMENTI REGOLAMENTO (UE) N. 1407/2013 DELLA COMMISSIONE del 18 dicembre 2013 relativo all applicazione degli articoli

Dettagli

Le novità per gli appalti pubblici

Le novità per gli appalti pubblici Le novità per gli appalti pubblici La legge 98/2013 contiene disposizioni urgenti per il rilancio dell economia del Paese e, fra queste, assumono particolare rilievo quelle in materia di appalti pubblici.

Dettagli

Completezza funzionale KEY FACTORS Qualità del dato Semplicità d'uso e controllo Tecnologie all avanguardia e stabilità Integrabilità

Completezza funzionale KEY FACTORS Qualità del dato Semplicità d'uso e controllo Tecnologie all avanguardia e stabilità Integrabilità Armundia Group è un azienda specializzata nella progettazione e fornitura di soluzioni software e consulenza specialistica per i settori dell ICT bancario, finanziario ed assicurativo. Presente in Italia

Dettagli

Struttura di un PEC: dal piano energetico di riferimento alle azioni di piano

Struttura di un PEC: dal piano energetico di riferimento alle azioni di piano Enti locali per Kyoto Struttura di un PEC: dal piano energetico di riferimento alle azioni di piano Rodolfo Pasinetti Ambiente Italia srl Milano, 15 dicembre 2006 Contesto Politiche energetiche Nel passato

Dettagli

MANUALE OPERATIVO INTRODUZIONE. Manuale Operativo

MANUALE OPERATIVO INTRODUZIONE. Manuale Operativo Pagina 1 di 24 INTRODUZIONE SEZ 0 Manuale Operativo DOCUMENTO TECNICO PER LA CERTIFICAZIONE DEL PROCESSO DI VENDITA DEGLI AGENTI E RAPPRESENTANTI DI COMMERCIO OPERANTI PRESSO UN AGENZIA DI RAPPRESENTANZA:

Dettagli

STS. Profilo della società

STS. Profilo della società STS Profilo della società STS, Your ICT Partner Con un solido background accademico, regolari confronti con il mondo della ricerca ed esperienza sia nel settore pubblico che privato, STS è da oltre 20

Dettagli

G.U. 11 luglio 2002, n. 161 IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI

G.U. 11 luglio 2002, n. 161 IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI Direttiva del Presidente del Consiglio dei Ministri 30 maggio 2002 Conoscenza e uso del dominio internet ".gov.it" e l'efficace interazione del portale nazionale "italia.gov.it" con le IL PRESIDENTE DEL

Dettagli

Questionario di valutazione: la preparazione di un istituzione

Questionario di valutazione: la preparazione di un istituzione Questionario di valutazione: la preparazione di un istituzione Abbiamo creato questo questionario per aiutarti a prepararti per il workshop e per farti pensare ai diversi aspetti delle collezioni digitali

Dettagli

Indice. La Missione 3. La Storia 4. I Valori 5. I Clienti 7. I Numeri 8. I Servizi 10

Indice. La Missione 3. La Storia 4. I Valori 5. I Clienti 7. I Numeri 8. I Servizi 10 Indice La Missione 3 La Storia 4 I Valori 5 I Clienti 7 I Numeri 8 I Servizi 10 La Missione REVALO: un partner operativo insostituibile sul territorio. REVALO ha come scopo il mantenimento e l incremento

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

PLM Software. Answers for industry. Siemens PLM Software

PLM Software. Answers for industry. Siemens PLM Software Siemens PLM Software Monitoraggio e reporting delle prestazioni di prodotti e programmi Sfruttare le funzionalità di reporting e analisi delle soluzioni PLM per gestire in modo più efficace i complessi

Dettagli

1. QUAL È LO SCOPO DI QUESTO MODULO?

1. QUAL È LO SCOPO DI QUESTO MODULO? Percorso B. Modulo 4 Ambienti di Apprendimento e TIC Guida sintetica agli Elementi Essenziali e Approfondimenti (di Antonio Ecca), e slide per i formatori. A cura di Alberto Pian (alberto.pian@fastwebnet.it)

Dettagli

IL PROGETTO MINDSH@RE

IL PROGETTO MINDSH@RE IL PROGETTO MINDSH@RE Gruppo Finmeccanica Attilio Di Giovanni V.P.Technology Innovation & IP Mngt L'innovazione e la Ricerca sono due dei punti di eccellenza di Finmeccanica. Lo scorso anno il Gruppo ha

Dettagli

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto LA PROGETTAZIONE 1 LA PROGETTAZIONE Oggi il raggiungimento di un obiettivo passa per la predisposizione di un progetto. Dal mercato al terzo settore passando per lo Stato: aziende, imprese, organizzazioni,

Dettagli

Asset sotto controllo... in un TAC. Latitudo Total Asset Control

Asset sotto controllo... in un TAC. Latitudo Total Asset Control Asset sotto controllo... in un TAC Latitudo Total Asset Control Le organizzazioni che hanno implementato e sviluppato sistemi e processi di Asset Management hanno dimostrato un significativo risparmio

Dettagli

PROCESSO ALLE PROMOZIONI IL GIOCO VALE LA CANDELA?

PROCESSO ALLE PROMOZIONI IL GIOCO VALE LA CANDELA? PROCESSO ALLE PROMOZIONI IL GIOCO VALE LA CANDELA? La maggior parte dei Retailer effettua notevoli investimenti in attività promozionali. Non è raro che un Retailer decida di rinunciare al 5-10% dei ricavi

Dettagli

L analisi economico finanziaria dei progetti

L analisi economico finanziaria dei progetti PROVINCIA di FROSINONE CIOCIARIA SVILUPPO S.c.p.a. LABORATORI PER LO SVILUPPO LOCALE L analisi economico finanziaria dei progetti Azione n. 2 Progetti per lo sviluppo locale LA FINANZA DI PROGETTO Frosinone,

Dettagli

Scheda descrittiva del progetto

Scheda descrittiva del progetto Scheda descrittiva del progetto 1. Anagrafica di progetto Titolo Banda ultralarga Acronimo (se esiste) UltraNet Data Inizio Data Fine 01/09/2011 31/12/2014 Budget totale (migliaia di euro) 60,50k Responsabile

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

INDICAZIONI OPERATIVE ALLE COMMISSIONI DI ESPERTI DELLA VALUTAZIONE PER L ACCREDITAMENTO PERIODICO DELLE SEDI E DEI CORSI DI STUDIO

INDICAZIONI OPERATIVE ALLE COMMISSIONI DI ESPERTI DELLA VALUTAZIONE PER L ACCREDITAMENTO PERIODICO DELLE SEDI E DEI CORSI DI STUDIO INDICAZIONI OPERATIVE ALLE COMMISSIONI DI ESPERTI DELLA VALUTAZIONE PER L ACCREDITAMENTO PERIODICO DELLE SEDI E DEI CORSI DI STUDIO 1. Attività di valutazione delle Commissioni di Esperti della Valutazione

Dettagli

Che cos è un focus-group?

Che cos è un focus-group? Che cos è un focus-group? Si tratta di interviste di tipo qualitativo condotte su un ristretto numero di persone, accuratamente selezionate, che vengono riunite per discutere degli argomenti più svariati,

Dettagli

IT Club FVG Ditedi CMDBuild: case study di un progetto open source www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com

IT Club FVG Ditedi CMDBuild: case study di un progetto open source www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com IT Club FVG Ditedi CMDBuild: case study di un progetto open source www.cmdbuild.org Fabio Bottega f.bottega@tecnoteca.com 2 Tecnoteca è nata nel 2000 con sede a Tavagnacco ha scelto da subito di lavorare

Dettagli

agility made possible

agility made possible SOLUTION BRIEF CA IT Asset Manager Come gestire il ciclo di vita degli asset, massimizzare il valore degli investimenti IT e ottenere una vista a portfolio di tutti gli asset? agility made possible contribuisce

Dettagli

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE Roma, dicembre 1999 Analisi dei rischi in un progetto di sviluppo sw RISCHIO = potenziale difetto il cui verificarsi comporta dei danni Danno Non

Dettagli

Nel processo di valutazione dei dirigenti sono principalmente coinvolti i seguenti ruoli:

Nel processo di valutazione dei dirigenti sono principalmente coinvolti i seguenti ruoli: 2. IL PROCESSO DI VALUTAZIONE 2.1. Gli attori del processo di valutazione Nel processo di valutazione dei dirigenti sono principalmente coinvolti i seguenti ruoli: Direttore dell Agenzia delle Entrate.

Dettagli

progettiamo e realizziamo architetture informatiche Company Profile

progettiamo e realizziamo architetture informatiche Company Profile Company Profile Chi siamo Kammatech Consulting S.r.l. nasce nel 2000 con l'obiettivo di operare nel settore I.C.T., fornendo servizi di progettazione, realizzazione e manutenzione di reti aziendali. Nel

Dettagli

Prot.n. 39056 Brescia, 16.9.2002 DETERMINAZIONE N. 273/SG : CRITERI GENERALI PER LA DISCIPLINA DEL RAPPORTO DI LAVORO A TEMPO PARZIALE.

Prot.n. 39056 Brescia, 16.9.2002 DETERMINAZIONE N. 273/SG : CRITERI GENERALI PER LA DISCIPLINA DEL RAPPORTO DI LAVORO A TEMPO PARZIALE. Prot.n. 39056 Brescia, 16.9.2002 DETERMINAZIONE N. 273/SG : CRITERI GENERALI PER LA DISCIPLINA DEL RAPPORTO DI LAVORO A TEMPO PARZIALE. IL SEGRETARIO GENERALE con la capacità e con i poteri del privato

Dettagli

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana Storie di successo Microsoft per le Imprese Scenario: Software e Development Settore: Servizi In collaborazione con Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci

Dettagli

Detrazione Fiscale e Scambio sul Posto

Detrazione Fiscale e Scambio sul Posto Gentile Cliente, il momento storico della fine del Conto Energia in Italia è arrivato lo scorso 6 luglio ed ha rappresentato un punto di svolta per tutti gli operatori del solare. La tanto discussa grid

Dettagli

Circolare 6 dicembre 2013 n.63

Circolare 6 dicembre 2013 n.63 Allegato alla determinazione commissariale n. 193/2013DIG del 6 dicembre 2013 Circolare 6 dicembre 2013 n.63 Linee guida per la valutazione comparativa prevista dall art. 68 del D.Lgs. 7 marzo 2005, n.

Dettagli

RISOLUZIONE N. 25/E QUESITO

RISOLUZIONE N. 25/E QUESITO RISOLUZIONE N. 25/E Direzione Centrale Normativa Roma, 6 marzo 2015 OGGETTO: Consulenza giuridica - Centro di assistenza fiscale per gli artigiani e le piccole imprese Fornitura di beni significativi nell

Dettagli

PROCEDURA PER OPERAZIONI CON PARTI CORRELATE

PROCEDURA PER OPERAZIONI CON PARTI CORRELATE PROCEDURA PER OPERAZIONI CON PARTI CORRELATE (ai sensi dell art. 4 del Regolamento adottato da Consob con delibera n. 17221 del 12 marzo 2010, come successivamente modificato ed integrato) INDICE 1. OBIETTIVI

Dettagli

L ADOZIONE DEI LIBRI DI TESTO NELLE SCUOLE EUROPEE

L ADOZIONE DEI LIBRI DI TESTO NELLE SCUOLE EUROPEE L ADOZIONE DEI LIBRI DI TESTO NELLE SCUOLE EUROPEE I rapporti di Eurydice PREMESSA Questo breve rapporto sull adozione dei libri di testo è nato in seguito a una specifica richiesta all unità italiana

Dettagli

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI Prefazione Autori XIII XVII Capitolo 1 Sistemi informativi aziendali 1 1.1 Introduzione 1 1.2 Modello organizzativo 3 1.2.1 Sistemi informativi

Dettagli

COMUNE DI CALCIANO Provincia di Matera

COMUNE DI CALCIANO Provincia di Matera COMUNE DI CALCIANO Provincia di Matera Cap. 75010 Via Sandro Pertini, 11 Tel. 0835672016 Fax 0835672039 Cod. fiscale 80001220773 REGOLAMENTO COMUNALE RECANTE NORME PER LA RIPARTIZIONE DELL INCENTIVO DI

Dettagli

Capo 1. Art.1 - (Definizione dell istituto dell indennità di posizione della categoria EP)

Capo 1. Art.1 - (Definizione dell istituto dell indennità di posizione della categoria EP) REGOLAMENTO DISCIPLINANTE L APPLICAZIONE DEGLI ARTT.75 CONFERIMENTO E REVOCA DI INCARICHI AL PERSONALE DELLA CATEGORIA EP E 76 RETRIBUZIONE DI POSIZIONE E RETRIBUZIONE DI RISULTATO DEL CCNL 16.10.2008

Dettagli

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Release Management Obiettivi Obiettivo del Release Management è di raggiungere una visione d insieme del cambiamento nei servizi IT e accertarsi che tutti gli aspetti di una release (tecnici e non) siano

Dettagli

OIC 23 - Lavori in corso su ordinazione

OIC 23 - Lavori in corso su ordinazione Luca Bilancini (Commercialista, Pubblicista, coordinatore scientifico MAP) OIC 23 - Lavori in corso su ordinazione 1 OIC 23 - Principali novità Non ci sono più i paragrafi relativi alle commesse in valuta

Dettagli

Orientamenti ABE in materia di. valore a rischio in condizioni di stress (VaR in condizioni di stress) EBA/GL/2012/2

Orientamenti ABE in materia di. valore a rischio in condizioni di stress (VaR in condizioni di stress) EBA/GL/2012/2 Orientamenti ABE in materia di valore a rischio in condizioni di stress (VaR in condizioni di stress) EBA/GL/2012/2 Londra, 16.05.2012 1 Oggetto degli orientamenti 1. Il presente documento contiene una

Dettagli

MODULO MONITORAGGIO E VALUTAZIONE. Gli indicatori. G. VECCHI esperto del team scientifico di supporto del Centro Risorse Nazionale CAF 1

MODULO MONITORAGGIO E VALUTAZIONE. Gli indicatori. G. VECCHI esperto del team scientifico di supporto del Centro Risorse Nazionale CAF 1 MODULO MONITORAGGIO E VALUTAZIONE 4. Gli indicatori G. VECCHI esperto del team scientifico di supporto del Centro Risorse Nazionale CAF 1 Cosa sono gli indicatori Gli indicatori sono strumenti in grado

Dettagli

IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI

IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI dalla G.U. n. 59 del 12 marzo 2014 (s.o. n. 20) DECRETO DEL PRESIDENTE DEL CONSIGLIO DEI MINISTRI 3 dicembre 2013 Regole tecniche in materia di sistema di conservazione ai sensi degli articoli 20, commi

Dettagli

DELIBERAZIONE N. 30/7 DEL 29.7.2014

DELIBERAZIONE N. 30/7 DEL 29.7.2014 Oggetto: Assegnazione all Azienda ASL n. 8 di Cagliari dell espletamento della procedura per l affidamento del servizio di realizzazione del sistema informatico per la gestione dell accreditamento dei

Dettagli

ghd crea una comunità online professionale che si dedica all acconciatura. Grazie a hybris.

ghd crea una comunità online professionale che si dedica all acconciatura. Grazie a hybris. ghd crea una comunità online professionale che si dedica all acconciatura. Grazie a hybris. Sin dal lancio, avvenuto dieci anni fa, il marchio ghd è diventato sinonimo di prodotti di hair styling di fascia

Dettagli

AVVISO PER LA PRESENTAZIONE DEI PROGETTI DI INFOMOBILITÀ - ATTIVITÀ IV.4 DEL POR CREO 2007-2013. Giunta Regionale

AVVISO PER LA PRESENTAZIONE DEI PROGETTI DI INFOMOBILITÀ - ATTIVITÀ IV.4 DEL POR CREO 2007-2013. Giunta Regionale Giunta Regionale Direzione Generale delle Politiche Territoriali, Ambientali e per la Mobilità Area di Coordinamento Mobilità e Infrastrutture Settore Pianificazione del Sistema Integrato della Mobilità

Dettagli

Il presente documento è conforme all'originale contenuto negli archivi della Banca d'italia

Il presente documento è conforme all'originale contenuto negli archivi della Banca d'italia Il presente documento è conforme all'originale contenuto negli archivi della Banca d'italia Firmato digitalmente da Sede legale Via Nazionale, 91 - Casella Postale 2484-00100 Roma - Capitale versato Euro

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Parere: Assegnazione mansioni superiori

Parere: Assegnazione mansioni superiori Parere: Assegnazione mansioni superiori Fatto: Le Poste italiane S.p.a. affidano il conferimento temporaneo di mansioni superiori dal livello C a B, ai propri dipendenti, i quali, di conseguenza, sono

Dettagli

Linee guida per le Scuole 2.0

Linee guida per le Scuole 2.0 Linee guida per le Scuole 2.0 Premesse Il progetto Scuole 2.0 ha fra i suoi obiettivi principali quello di sperimentare e analizzare, in un numero limitato e controllabile di casi, come l introduzione

Dettagli

DAT@GON. Gestione Gare e Offerte

DAT@GON. Gestione Gare e Offerte DAT@GON Gestione Gare e Offerte DAT@GON partecipare e vincere nel settore pubblico La soluzione sviluppata da Revorg per il settore farmaceutico, diagnostico e di strumentazione medicale, copre l intero

Dettagli

Cosa significa Open Source? Cos'è il software libero? Applicazioni ai GIS

Cosa significa Open Source? Cos'è il software libero? Applicazioni ai GIS MondoGIS_59 29-03-2007 10:31 Pagina 62 Cosa significa Open Source? Cos'è il software libero? Applicazioni ai GIS OPEN SOURCE È UN TERMINE ORMAI DI MODA, ANCHE IN AMBITO GEOGRAFICO. I VANTAGGI DEL SOFTWARE

Dettagli

Comune di Grado Provincia di Gorizia

Comune di Grado Provincia di Gorizia Comune di Grado Provincia di Gorizia REGOLAMENTO PER LA DISCIPLINA DEGLI INCENTIVI PER LA PROGETTAZIONE E LA REALIZZAZIONE DI LAVORI PUBBLICI, AI SENSI DELL ART.11 DELLA LEGGE REGIONALE 31 MAGGIO 2002,

Dettagli