• Save
Focus Group Open Source 22.11.2011 Sebastiano Lomuscio
Upcoming SlideShare
Loading in...5
×
 

Focus Group Open Source 22.11.2011 Sebastiano Lomuscio

on

  • 657 views

 

Statistics

Views

Total Views
657
Views on SlideShare
584
Embed Views
73

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 73

http://focusgroupopensource.wordpress.com 73

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Focus Group Open Source 22.11.2011 Sebastiano Lomuscio Focus Group Open Source 22.11.2011 Sebastiano Lomuscio Presentation Transcript

  • Il ciclo di vita dei progetti IT in stack Open Source Sebastiano Lomuscio Roma, 22 Novembre 2011
    • Il Contesto attuale
    • Perchè Open source?
    • Gli stack di software Open source
    • Il ciclo di vita dei progetti
    Agenda
  • 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
  • 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
  • Lo stack Open source (un esempio) Applicazioni Custom Infrastruttura Utente
  • 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
  • Il ciclo di vita (dal punto di vista della PA) Requisiti Analisi Sourcing Realizzazione Supporto Evoluzione
  • 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?
  • 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?
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Il supporto (professionale) Applicazioni Custom Disponibilità ampia sul mercato Disponibilità media sul mercato Nicchia di mercato Community Community
  • 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.
  • 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.
    • 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