Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Il ciclo di vita dei progetti IT    in stack Open Source  Sebastiano Lomuscio Roma, 22 Novembre 2011
<ul><li>Il Contesto attuale  </li></ul><ul><li>Perchè Open source? </li></ul><ul><li>Gli stack di software Open source </l...
Contesto attuale: la PA  <ul><li>Forte spinta alla dematerializzazione dei documenti e all'automazione nei processi  ammin...
Contesto attuale: uno sguardo alle acquisizioni <ul><li>La Centrale acquisti di Consip effettua il monitoraggio della spes...
Lo stack Open source (un esempio) Applicazioni  Custom Infrastruttura Utente
Perché Open source? <ul><li>Abbattimento del costo delle licenze </li></ul><ul><li>Indipendenza dai vendor  </li></ul><ul>...
Il ciclo di vita (dal punto di vista della PA)  Requisiti Analisi Sourcing Realizzazione Supporto Evoluzione
La raccolta dei requisiti <ul><li>Come farla: i punti di attenzione </li></ul><ul><li>Focalizzare la propria attenzione su...
L'analisi di fattibilità <ul><li>La fattibilità: l'applicazione, l'infrastruttura ed il contesto </li></ul><ul><li>Quale a...
Il sourcing (1) <ul><li>Chi realizza questo progetto? </li></ul><ul><li>L'organizzazione ha le competenze per seguire da v...
Il sourcing (2) <ul><li>Chi realizza questo progetto:  </li></ul><ul><li>L'organizzazione ha competenze di governo di prog...
Il sourcing (3) <ul><li>Chi realizza questo progetto : </li></ul><ul><li>L'organizzazione non ha particolari competenze di...
La realizzazione (1) <ul><li>Come fare se c'è di mezzo l'Open source?  </li></ul><ul><li>L'organizzazione ha risorse con e...
La realizzazione (2) <ul><li>Come fare se c'è di mezzo l'Open source?  </li></ul><ul><li>L'organizzazione  ha competenze d...
La realizzazione (3) <ul><li>Come fare se non ho mai avuto esperienze sull'Open source: </li></ul><ul><li>L'organizzazione...
Il supporto (professionale) Applicazioni  Custom Disponibilità ampia  sul mercato Disponibilità media sul mercato Nicchia ...
L'evoluzione <ul><li>Devo evolvere il mio sistema: </li></ul><ul><li>L'organizzazione ha le competenze per seguire da vici...
Conclusioni <ul><li>La competenza tecnica o di governo dell'IT dell'organizzazione sono un fattore critico di successo nei...
<ul><li>GAETANO SANTUCCI </li></ul><ul><li>Direzione Infrastrutture IT – Responsabile Competence Center </li></ul><ul><li>...
Prochain SlideShare
Chargement dans…5
×

Focus Group Open Source 22.11.2011 Sebastiano Lomuscio

972 vues

Publié le

  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Focus Group Open Source 22.11.2011 Sebastiano Lomuscio

  1. 1. Il ciclo di vita dei progetti IT in stack Open Source Sebastiano Lomuscio Roma, 22 Novembre 2011
  2. 2. <ul><li>Il Contesto attuale </li></ul><ul><li>Perchè Open source? </li></ul><ul><li>Gli stack di software Open source </li></ul><ul><li>Il ciclo di vita dei progetti </li></ul>Agenda
  3. 3. Contesto attuale: la PA <ul><li>Forte spinta alla dematerializzazione dei documenti e all'automazione nei processi amministrativi </li></ul><ul><li>Necessità di sviluppare il piano di E-Government con una forte crescita dei servizi online al cittadino </li></ul><ul><li>Riduzione della disponibilità di budget per IT: 20% del budget necessario al piano di E-government (Rapporto IT per lo sviluppo di Assinform 2010) </li></ul><ul><li>Mercato IT inizia a proporre soluzioni e servizi strutturati e basati su soluzioni Open source </li></ul>
  4. 4. Contesto attuale: uno sguardo alle acquisizioni <ul><li>La Centrale acquisti di Consip effettua il monitoraggio della spesa IT della PA Centrale e locale sulle convenzioni attive </li></ul><ul><li>Le convenzioni IT attive sul sito Acquistinretepa.it contemplano la possibilità di acquisire soluzioni e servizi Open source accanto alle classiche </li></ul><ul><li>Nel 2010 si sono registrati i seguenti dati di acquisto: </li></ul>Know How Adozione
  5. 5. Lo stack Open source (un esempio) Applicazioni Custom Infrastruttura Utente
  6. 6. Perché Open source? <ul><li>Abbattimento del costo delle licenze </li></ul><ul><li>Indipendenza dai vendor </li></ul><ul><li>Sinergia e cooperazione nello sviluppo </li></ul><ul><li>Riuso, standard aperti e interoperabilità </li></ul><ul><li>Sicurezza e trasparenza (controllo completo del codice) </li></ul><ul><li>Scarsa conoscenza e consapevolezza (diffidenza) </li></ul><ul><li>Immaturità o carenza di garanzie </li></ul><ul><li>Difficoltà ad operare e motivare le scelte (responsabilità) </li></ul><ul><li>Resistenza all’utilizzo da parte degli utenti finali </li></ul><ul><li>Nuovi paradigmi legali, commerciali e contrattuali </li></ul>Sistemi Operativi Middleware Software di base 1 2 informatica individuale (Browser, Posta elettronica, strumenti Office) OS orientato all’utente IT professional (back office tool) 3 4 OS da integrare in soluzioni applicativo/gestionali per l’utente business Tipi di OS Perché si? Perché no? 2 1 3 4 2 1 3 4 2 1 3 4 3 4 3 4 1 4 2 1 4 2 1 2 3 4
  7. 7. Il ciclo di vita (dal punto di vista della PA) Requisiti Analisi Sourcing Realizzazione Supporto Evoluzione
  8. 8. La raccolta dei requisiti <ul><li>Come farla: i punti di attenzione </li></ul><ul><li>Focalizzare la propria attenzione sulle funzioni e non sui prodotti! </li></ul><ul><li>Verificare la presenza di vincoli infrastrutturali quali: </li></ul><ul><ul><li>Integrazione obbligata con pacchetti closed </li></ul></ul><ul><ul><li>Compatibilità con le postazioni client (Obbligo di IE??) </li></ul></ul><ul><ul><li>Obbligo di impiego di sistemi/infrastrutture preesistenti </li></ul></ul><ul><li>Identificare i vincoli di contesto </li></ul><ul><ul><li>Sono presenti le competenze tecniche nell'organizzazione? </li></ul></ul><ul><ul><li>Vi sono esperienze pregresse in progetti con prodotti OS? </li></ul></ul><ul><ul><li>L'amministrazione è aperta ad adottare prodotti OS? </li></ul></ul><ul><ul><li>E' presente un'adeguata sponsorship? </li></ul></ul>
  9. 9. L'analisi di fattibilità <ul><li>La fattibilità: l'applicazione, l'infrastruttura ed il contesto </li></ul><ul><li>Quale applicazione? </li></ul><ul><ul><li>Esistono prodotti OS in grado di svolgere almeno il 70/80% delle funzioni richieste? </li></ul></ul><ul><ul><li>E' possibile adattare / integrare uno o più prodotti OS per realizzare le funzioni richieste? </li></ul></ul><ul><li>Quale infrastruttura? </li></ul><ul><ul><li>Posso utilizzare prodotti OS a livello infrastrutturale? </li></ul></ul><ul><li>Quale supporto? </li></ul><ul><ul><li>I prodotti OS individuati sono supportati da un'ampia comunità? </li></ul></ul><ul><ul><li>Esistono aziende di adeguata dimensione e capacità tecnica in grado di fornirmi supporto? </li></ul></ul><ul><ul><li>Sto davvero scegliendo un pacchetto o un prodotto Open? </li></ul></ul>
  10. 10. Il sourcing (1) <ul><li>Chi realizza questo progetto? </li></ul><ul><li>L'organizzazione ha le competenze per seguire da vicino lo sviluppo </li></ul><ul><ul><li>Capitolato di gara per il sourcing di sviluppatori/integratori/sistemisti con adeguato livello di competenza nel mondo OS (man power!) </li></ul></ul><ul><ul><li>L'organizzazione deve designare alcune risorse a rapportarsi/ iscriversi alla community dei prodotti OS adottati </li></ul></ul><ul><ul><li>L'organizzazione sarà responsabile della guida dei gruppi di sviluppo esterni e del successo del progetto: sono richieste risorse tecniche con elevati livelli di competenza di project management, applicativa e sistemistica con significative esperienze con il mondo Open source </li></ul></ul><ul><ul><li>Rischi elevati; Costi ridotti (se il progetto è ben governato). </li></ul></ul>
  11. 11. Il sourcing (2) <ul><li>Chi realizza questo progetto: </li></ul><ul><li>L'organizzazione ha competenze di governo di progetti IT </li></ul><ul><ul><li>Capitolato di gara per la realizzazione del progetto con indicazione dei prodotti OS da adottare e dei livelli di qualità/supporto attesi </li></ul></ul><ul><ul><li>E' utile vincolare il fornitore ad aderire alle community OS per il supporto e la collaboration imposta dalle licenze dei prodotti OS </li></ul></ul><ul><ul><li>Devono essere richieste al fornitore competenze ed esperienze specifiche nella realizzazione di progetti con componenti OS </li></ul></ul><ul><ul><li>Sono necessarie risorse interne con buona esperienza di project management ed esperienza applicativa </li></ul></ul><ul><ul><li>L'organizzazione ha il compito di governare il contratto, eseguire i test sui prodotti intermedi, verificare i livelli di qualità e di supporto </li></ul></ul><ul><ul><li>Rischi: medi, Costi: medi. </li></ul></ul>
  12. 12. Il sourcing (3) <ul><li>Chi realizza questo progetto : </li></ul><ul><li>L'organizzazione non ha particolari competenze di governo di progetti IT </li></ul><ul><ul><li>Capitolato di gara con la declinazione delle funzionalità del sistema da realizzare e con una specifica apertura alla adozione di prodotti Open per la realizzazione del sistema richiesto </li></ul></ul><ul><ul><li>Devono essere richieste al fornitore competenze ed esperienze specifiche nella realizzazione di sistemi analoghi </li></ul></ul><ul><ul><li>Il sistema verrà fornito in modalità “chiavi in mano” è potrà (o meno) adottare prodotti/componenti Open source </li></ul></ul><ul><ul><li>L'organizzazione ha il compito di governare il contratto ed eseguire il collaudo del sistema fornito (fornitura black box) </li></ul></ul><ul><ul><li>Rischi: bassi, costi alti. </li></ul></ul>
  13. 13. La realizzazione (1) <ul><li>Come fare se c'è di mezzo l'Open source? </li></ul><ul><li>L'organizzazione ha risorse con elevate competenze tecniche </li></ul><ul><ul><li>La predisposizione dell'infrastruttura è a carico delle risorse interne eventualmente supportate dal fornitore aggiudicatario in specifiche aree di competenza tecnica </li></ul></ul><ul><ul><li>L'integrazione del sistema realizzato con le infrastrutture IT è solitamente a carico dell'organizzazione committente </li></ul></ul><ul><ul><li>L'interazione con la community è sostanzialmente deputata a risorse interne dell'organizzazione con il supporto tecnico (eventuale) del fornitore aggiudicatario </li></ul></ul><ul><ul><li>Le risorse tecniche dell'organizzazione hanno un elevato livello di conoscenza su tutto lo stack di prodotti Open adottati/adattati </li></ul></ul><ul><ul><li>E' richiesto un impegno significativo e continuo delle risorse tecniche dell'organizzazione </li></ul></ul><ul><ul><li>Il fornitore è facilmente intercambiabile. </li></ul></ul>
  14. 14. La realizzazione (2) <ul><li>Come fare se c'è di mezzo l'Open source? </li></ul><ul><li>L'organizzazione ha competenze di governo di progetti IT </li></ul><ul><ul><li>La predisposizione dell'infrastruttura è solitamente a carico del fornitore aggiudicatario o di altro fornitore </li></ul></ul><ul><ul><li>L'integrazione del sistema realizzato con le infrastrutture IT è solitamente a carico dell'organizzazione committente con il supporto del fornitore aggiudicatario o del fornitore di servizi sistemistici </li></ul></ul><ul><ul><li>L'interazione con la community è demandata al fornitore aggiudicatario. L'organizzazione controlla il livello e la qualità della interazione con la community finalizzata ad evitare fork dei prodotti evoluti/adattati/adottati </li></ul></ul><ul><ul><li>Le risorse tecniche dell'organizzazione interagiscono con il fornitore nell'analisi e partecipano attivamente ai collaudi delle singole componenti realizzate </li></ul></ul><ul><ul><li>Il fornitore è mediamente intercambiabile. </li></ul></ul>
  15. 15. La realizzazione (3) <ul><li>Come fare se non ho mai avuto esperienze sull'Open source: </li></ul><ul><li>L'organizzazione non ha competenze nel governo di progetti IT </li></ul><ul><ul><li>La predisposizione dell'infrastruttura è a carico del fornitore aggiudicatario (auspicabilmente) o di altro fornitore responsabile delle infrastrutture </li></ul></ul><ul><ul><li>L'integrazione del sistema realizzato con le infrastrutture IT è a carico del fornitore (importante inserire la declinazione di questi servizi nel capitolato di gara) </li></ul></ul><ul><ul><li>L'interazione con la community non è sentita come esigenza dall'organizzazione ed è eventualmente a totale carico del fornitore. Il rischio di fork dei prodotti open adottati/adattati è significativo </li></ul></ul><ul><ul><li>Le risorse dell'organizzazione partecipano ai collaudi con il fornitore ed alle successive (necessarie) fasi di formazione </li></ul></ul><ul><ul><li>Il fornitore è difficilmente intercambiabile. </li></ul></ul>
  16. 16. Il supporto (professionale) Applicazioni Custom Disponibilità ampia sul mercato Disponibilità media sul mercato Nicchia di mercato Community Community
  17. 17. L'evoluzione <ul><li>Devo evolvere il mio sistema: </li></ul><ul><li>L'organizzazione ha le competenze per seguire da vicino lo sviluppo </li></ul><ul><ul><li>La conoscenza del sistema da evolvere è all'interno dell'organizzazione. E' semplice reperire sul mercato un nuovo fornitore in quanto dovrà fornire solo man power. </li></ul></ul><ul><li>L'organizzazione ha competenze di governo di progetti IT </li></ul><ul><ul><li>La conoscenza del sistema è nella documentazione rilasciata. La qualità della fornitura precedente diviene un aspetto critico per l'evoluzione. L'individuazione del fornitore è mediamente complessa (attenzione nella stesura del capitolato di gara) </li></ul></ul><ul><li>L'organizzazione non ha competenze nel governo di progetti IT </li></ul><ul><ul><li>La conoscenza “dovrebbe” essere nella documentazione del prodotto. Il capitolato di gara tenderà a premiare maggiormente le esperienze in sistemi simili o uguali rendendo più probabile il rinnovo del contratto al precedente aggiudicatario. </li></ul></ul>
  18. 18. Conclusioni <ul><li>La competenza tecnica o di governo dell'IT dell'organizzazione sono un fattore critico di successo nei progetti con stack Open source </li></ul><ul><li>Il miglior rapporto rischi/benefici si ottiene quando l'organizzazione ha capacità di governo di progetti IT ed un partner tecnologico con esperienze significative nel mondo “Open” </li></ul><ul><li>Occorre porre molta attenzione al presidio delle community per contribuire con nuove componenti ed evitare i fork </li></ul><ul><li>L'adozione dell'open nei progetti IT può portare un sicuro vantaggio economico a fronte di rischi contenuti a patto di adottare la corretta strategia di acquisizione. </li></ul>
  19. 19. <ul><li>GAETANO SANTUCCI </li></ul><ul><li>Direzione Infrastrutture IT – Responsabile Competence Center </li></ul><ul><li>Mobile 3357749119 gaetano.santucci@tesoro.it </li></ul><ul><li>MARIA STELLA MAROTTA </li></ul><ul><li>Direzione Infrastrutture IT – Competence Center </li></ul><ul><li>Mobile 3294106344 [email_address] </li></ul><ul><li>SEBASTIANO LOMUSCIO </li></ul><ul><li>Direzione Infrastrutture IT – System Solution </li></ul><ul><li>Mobile 3294106310 sebastiano.lomuscio@tesoro.it </li></ul>I nostri riferimenti

×