Your SlideShare is downloading. ×
Focus Group Open Source 22.11.2011 Sebastiano Lomuscio
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Focus Group Open Source 22.11.2011 Sebastiano Lomuscio

516
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
516
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×