jump to navigation

Il SW, lo Stato e l’Esportazione in USA delle Tasse dei Cittadini venerdì 1 maggio 2020

Posted by andy in FLOSS, Information Security, Miglioramento, Pubblica Amministrazione, tecnologia.
Tags: , , , , , , , , , , ,
add a comment

Premessa

Penso che siano pochi (sempre che esistano!) i paesi in cui tutti i contribuenti siano felici di pagare le tasse nella misura in cui le pagano: sorgono sempre dubbi sulle capacità dello Stato di spendere al meglio le risorse raccolte.

Con questo mio pensiero provo a sollevare anch’io qualche dubbio, proponendo naturalmente anche una soluzione (mai lamentarsi se non si ha qualcosa di meglio da proporre!).

Mi concentrerò in questo post su come vengano spesi i soldi per l’acquisto di software commerciale da parte della PA, suggerendo delle ipotesi per impiegare meglio almeno parte di tali fondi.

Una stima della spesa per il SW da parte della PA

Prendiamo il tema degli acquisiti di software commerciale da parte della Pubblica Amministrazione, dove la parte dei leoni la fanno sempre i soliti grandi nomi (Microsoft, Oracle, VMware, Adobe, etc.)

Escludo quindi qualsiasi software ‘custom’ sviluppato ad hoc per la PA, nonché qualsiasi servizio di assistenza, configurazione, etc.

Al paragrafo 3.2.3 (La spesa ICT per macrovoci hardware e software, pag. 32) della relazione di AgID sulla spesa ICT nella PA italiana, possiamo osservare che la spesa effettiva dal 2016 in poi, e previsionale per il 2019, è sempre stata superiore ai 700 milioni di Euro (addirittura 850 nel 2018).

Stiamo parlando di circa 12 Euro per cittadino italiano (inclusi infanti e pensionati) e di circa 64 Euro per ogni contribuente (escludendo quindi infanti, pensionati, persone con reddito minimo non soggetto a tassazione, disoccupati, etc.).

Dove vanno a finire tutti questi soldi? nella maggioranza dei casi, negli Stati Uniti.

È davvero necessario esportare tutti questi capitali, impoverendo lo Stato ed i contribuenti?

A cosa serve tutto questo SW?

Intanto chiediamoci a cosa serve tutto questo software di cui acquistiamo licenze d’uso.

In generale, possiamo suddividere tutto questo software in tre categorie principali:

  • software ‘server side’, ovverosia sistemi di virtualizzazione (VMware, …), sistemi operativi server (Microsoft, e parzialmente RedHat, ora IBM), e motori di database (Oracle, Sybase, …);
  • sistemi operativi lato client (Microsoft);
  • software di office automation e programmi di utilità (Office, Skype, Teams della Microsoft, Acrobat Pro della Adobe, etc.)

È importante anche chiederci cosa effettivamente acquistiamo: si tratta di licenze d’uso, e non della proprietà dei prodotti: acquistiamo quindi la sola possibilità di utilizzare un prodotto, sottostando alle condizioni commerciali imposte dai fornitori.

 

Una stima della spesa per il SW da Parte della PA

Ho provato a cercare il numero di dipendenti pubblici in Italia, ed ho trovato varie stime, più o meno aggiornate, ma il numero supera sempre i 3.000.000 di persone.

Non so se quella che vado a fare sia una stima corretta, ma nell’era dell’informatizzazione ipotizzerò che circa 1.000.000 utilizzi un computer per svolgere almeno parte delle proprie attività; tenendo conto dei numeri dei ministeri, oltre a quelli delle regioni e dei comuni, credo che la stima possa essere considerata ragionevole.

Naturalmente non dispongo dei numeri effettivamente contrattati dalla PA, ma sono stime ragionevoli quelle di 84$/anno per Windows 10 Enterprise (volume licensing), mentre al dettaglio Office 2019 Professional viene 440$: farò una stima di 116$/anno con una licenza analoga a quella di Windows (tanto per fare una cifra tonda di 200$/anno).

Il tutto senza contare che molto spesso i computer vengono acquistati già dotati di una licenza Microsoft, a cui occorre aggiungere quella ministeriale acquistata nei contratti quadro tra PA e fornitore

L’importo non è esatto, ma certamente non si discosta molto dalla realtà; in ogni caso, se così fosse, 1.000.000 PC x 200$ / anno = 200 milioni di dollari all’anno per Microsoft.

Se ad ogni utente viene dato un PC con Windows ed Office, ed ipotizzando che CONSIP sia riuscita ad ottenere mediamente dei prezzi di mercato, una postazione di lavoro viene a costare, come software di base, circa 200$/anno – si vadano i conti precedenti.

Non entro nel merito dell’hardware, che purtroppo in alcuni contesti non viene aggiornato in relazione alle esigenze degli utenti, ma troppo spesso viene sostituito troppo presto nonostante la possibilità di funzionare egregiamente ancora per anni.

Le licenze server di Microsoft vengono al dettaglio circa 1.000$ / processore – ipotizziamo che per la PA vengano soltanto 600$/processore, che ripartite su un periodo di 3 anni fanno 200$/anno/processore.

Quanti server e quanti microprocessori avrà la PA? Ipotizziamo (e sto facendo l’ottimista) 10.000 server e 2 core ciascuno, per un totale di 20.000 core, e quindi 20.000 core x 200$/core/anno = 4.000.000$/anno.

Veniamo ora alla virtualizzazione: quante saranno le istanze di virtualizzazione attive in Italia? Al momento non sono riuscito a reperire (e penso che sia impossibile) un numero certo.

Utilizzerò come stima il valore di una istanza ogni 10 server, che dovrebbe ottimisticamente mediare tra le installazioni con un più elevato livello di consolidamento dei server e quelli ancora non virtualizzati (senza contare tutte le installazioni di disaster recovery, che di fatto raddoppiano il numero di istanze e quindi di licenze).

La licenza per un’istanza con il servizio di assistenza e supporto per tre anni viene circa 3.000€/anno, per un totale di circa 10.000 server / 10 x 3.000€/anno = 3.000.000€/anno.

E poi ci sono Oracle, RedHat ed altri software server side di produzione, con i relativi contratti di assistenza e supporto business.

Per Oracle, ipotizzando anche soltanto 1.000 installazioni in tutta Italia (in generale su sistemi con un discreto numero di processori), ipotizzando anche soltanto 10.000$/processore/anno e 4 processori/server, troviamo 1.000 x 4 x 10.000$/anno = 40.000.000$/anno.

Ed in quanto sopra riportato non sono stati conteggiati tutti i pacchetti e moduli software aggiuntivi per l’amministrazione, il monitoraggio, l’integrazione, l’alta affidabilità, etc. etc. etc.

Come potete vedere, facendo dei conti assolutamente conservativi, emergono rapidamente le centinaia di milioni di Euro all’anno, che regolarmente vengono trasferiti negli States.

Tutto questo software commerciale è realmente indispensabile?

Chiediamoci ora se realmente tutto il software di cui acquistiamo la licenza d’uso sia indispensabile, o se possa essere sostituito da altro più economico.

Per la parte server, esistono due tipi di sistemi: quelli cosiddetti ‘di produzione‘, e quelli di sviluppo, di test, o dedicato ad applicazioni non critiche.

Per la parte client (ovverosia il computer, fisso o portatile) assegnato agli utenti, occorre chiedersi quali siano le attività che vengono principalmente svolte dagli utenti, che sostanzialmente sono:

  • consultazione della posta elettronica;
  • navigazione su Internet mediante un browser;
  • condivisione di file tra utenti;
  • office automation (redazione di documenti, gestione dati mediante fogli elettronici, e qualche presentazione …)
  • comunicazioni e videoconferenze (questo è vero soprattutto da quando si è iniziato a fare smart working in seguito alla pandemia di Codiv-19).

Naturalmente gli usi sopra descritti sono riferibili soltanto alla grande maggioranza di utenti, e non a quelli che svolgono attività particolari).

È importante ora fare una considerazione: il pianeta (inteso come infrastrutture e servizi informatici) funziona sostanzialmente utilizzando software libero (libero nel senso di open source, e non di gratuito): il fatto che un software sia libero non esclude che si possano pagare servizi di assistenza e supporto:

Perché questa considerazione?

Perché la stragrande maggioranza delle esigenze delle aziende e degli utenti possono essere soddisfatte con software libero, sia lato server che lato client.

Ciò che conta, in un ambiente di produzione, non è il ‘possesso’ di un prodotto (o almeno del diritto di utilizzarlo), ma un servizio di supporto che supporti il cliente nella risoluzione dei problemi che si presentano (e naturalmente di una consulenza per progettare e far evolvere i propri sistemi informativi).

Se leggete le condizioni di licenza dei diversi prodotti commerciali citati, noterete che sono previsti due tipi di importi da pagare: uno (obbligatorio) per acquisire il diritto di utilizzare il prodotto (alle condizioni imposte dal produttore), e l’altro (facoltativo) per avere il diritto di chiamare qualcuno chiedendo aiuto se qualcosa va storto …

Ecco, il software libero vi libera dalla prima voce, lasciandovi naturalmente la libertà di decidere se pagare un servizio di supporto o no per le applicazioni che ritenete più critiche.

Un aspetto interessante è che mentre nel caso di software proprietario, sia il costo della licenza che quello per i contratti di supporto vanno al produttore, nel caso di software libero avete (appunto!) la libertà di rivolgervi a chiunque riteniate sufficientemente qualificato per gestire i vostri potenziali problemi.

Un altro aspetto, fondamentale, che differenzia il software libero da quello proprietario, è la sua apertura: non è possibile trovarsi in situazioni di ‘lock-in’, ovverosia di essere costretti a mantenere un prodotto o un fornitore, perché le modalità in cui il produttore ha implementato alcune funzioni rende il prodotto incompatibile o non interoperabile con altri prodotti, liberi o di altre parti (limitando persino la possibilità di sviluppare in house del software di adattamento).

E concludo questo paragrafo sintetizzando il fatto che non è indispensabile utilizzare software proprietario: naturalmente esistono prodotti commerciali che sono migliori di prodotti liberi (così come è vero il contrario!); per applicazioni specifiche, in cui si ritiene che un prodotto commerciale sia più appropriato, è corretto selezionarlo ed utilizzarlo.

Ma ciò non è vero nella stragrande maggioranza dei casi.

Sicurezza nazionale

A parte ogni considerazione sugli aspetti economici, è da considerare anche l’aspetto della sicurezza nazionale; infatti come può lo Stato essere certo che non vi siano backdoor all’interno del software acquistato (anzi: licenziato) e che non vi siano meccanismi che possono consentire a ‘qualcuno’ di bloccare il funzionamento del software?

Di fatto il solo meccanismo dell’attivazione del software è un meccanismo simile: se il software non viene riconosciuto come valido dalla casa produttrice (o da un suo sistema installato nelle reti aziendali), il software smette di funzionare.

E c’è di peggio: l’utilizzo sconsiderato che si è recentemente iniziato a fare in occasione dello smart working di tecnologie quali Skype, Teams, WebEx, GSuite, Google Drive, OneDrive, (Dropbox?), ha di fatto messo in mano ad aziende private statunitensi una quantità smodata di documenti e conversazioni riservate ad ogni livello istituzionale.

C’è qualcuno che ha fatto un’analisi dei rischi? Ritengo di no, altrimenti si sarebbero prese altre strade da molto tempo.

Adozione del software libero nella PA

Con il CAD, la PA si è imposta delle regole finalizzare a razionalizzare la spesa e ridurre gli sprechi (e, perché no? anche l’impoverimento dello Stato con esportazione continua di capitali all’estero), imponendo la predilezione del software libero, a meno di motivatissime e documentate ragioni.

Ulteriore aspetto fondamentale è che la PA si è imposta l’obbligo dell’adozione di standard aperti, che garantiscono l’interoperabilità tra piattaforme di qualsiasi tipo: ciò di fatto esclude ogni software proprietario che implementa funzioni, o formati di dati, o protocolli, non interoperabili con le omologhe implementate mediante standard aperti.

Quanto sopra porta al fatto che la PA deve utilizzare soltanto software libero, a meno di specifiche e giustificate ragioni, e che qualsiasi software sviluppato per la PA deve conformarsi soltanto a standard aperti (per i formati dei dati, dei file, per i protocolli di comunicazione, etc.), e deve essere rilasciato sotto licenza libera.

Limiti e problemi nell’adozione del software libero nella PA

Quanto esposto al punto precedente è un ideale (speriamo che non sia un’utopia).

Cosa limita la PA nel rispetto del CAD che essa stessa si è data?

Le ragioni sono tante, e non penso di riuscire ad identificarle tutte in questo post; tuttavia, tra le tante, vediamo:

  • mancanza di informazione: se ogni dipendente statale venisse informato sul costo del software che pretende di utilizzare al posto di quello libero, e di quanto soldi ogni anno gli vengono trattenuti sullo stipendio per le tasse, probabilmente accetterebbe più favorevolmente l’evoluzione;
  • disinformazione diffusa: troppo spesso gira la voce che il software libero non è all’altezza di quello libero, ma se gli utenti sapessero che i propri smartphone utilizzano software libero, così come FaceBook, Google ed il proprio router Internet di casa, probabilmente proverebbero a considerare la cosa con maggior obiettività;
  • direttori e dirigenti non sufficientemente competenti, responsabili e motivati, che spesso vedono in queste attività soltanto la fatica immediata, le seccature derivanti nel breve termine, e qualche responsabilità da assumersi con scelte a volte non comode;
  • mancanza di adeguate competenze di committenti e responsabili di sistema, e dell’eventuale supporto specialistico, senza le quali non è possibile preparare adeguati capitolati e specifiche di collaudo;
  • … e (perché no?) potenziali interessi (visti i numeri in gioco) che esulano da quelli dello Stato (come si dice, a pensar male si fa peccato, ma spesso ci si azzecca …).

Cosa si può (e lo Stato dovrebbe) fare …

Premetto che so che lo Stato ha tempi lunghi, ed il CAD lo dimostra: è del 2005, ma a distanza di 15 anni ancora il software e le comunicazioni sono in mano agli Stati Uniti (si colga ora l’occasione per rileggere il paragrafo sulla sicurezza nazionale …).

Cosa si potrebbe fare? occorre agire almeno sui seguenti fronti:

  • tecnico / legale: predisporre specifici allegati standard, sia tecnici che legali, che devono essere acclusi ad ogni bando di gara per forniture software, chiarendo quali sono gli standard (aperti!) adottati dalla PA e quali sono le modalità standard per l’interoperazione e collaborazione tra sistemi; tali documenti devono definire anche in modo chiaro e formale come devono essere predisposte le specifiche di collaudo ed accettazione, in modo da evitare situazioni in cui la PA è costretta ad accettare delle forniture inadeguate perché i requisiti progettuali sono stati prodotti da persone non competenti o senza cognizione della destinazione d’uso del prodotto da realizzare;
  • formazione delle stazioni appaltanti: è indispensabile formare e fornire gli strumenti alle stazioni appaltanti per verificare la conformità normativa delle richieste di acquisto per software commerciale e per lo sviluppo di software applicativo per la PA;
    per il primo, deve esistere la necessaria analisi prevista dal CAD, sottoscritta da una persona competente e responsabile per il progetto da realizzare, e
    per il secondo, occorre accludere ai bandi gli allegati standard di cui sopra per tutte le commesse di sviluppo software, in cui sia chiarito che qualunque prodotto che non si conformi a standard aperti, e che non si conformi alle architetture ed ai requisiti standard definite dalla PA non potrà essere collaudato né accettato;
  • client: questa è la nota dolente: l’utente finale è estremamente refrattario ai cambiamenti; tuttavia piattaforme client non standard lasciano aperta la strada ai fornitori per lo sviluppo e la fornitura di sistemi che mantengono il lock-in del cliente; occorre pertanto fare un censimento incrociato delle applicazioni utilizzate e degli utenti che le utilizzano (non tutti usano tutto), ed iniziare a riconfigurare tutte le postazioni che non hanno requisiti particolari con postazioni basate interamente su software libero;
    mano a mano che si procede emergono le applicazioni non standard, per cui la PA dovrà appaltare l’adeguamento), ed il cosiddetto shadow software, ovverosia tutti quei programmi sviluppati autonomamente dagli utenti e dagli Uffici, in mancanza di strumenti previsti e realizzati dall’Amministrazione; per tutti questi occorrerà procedere all’adattamento a software libero (e meglio ancora all’assimilazione del software trasversalmente più utile a livello nazionale), e quindi al conseguente aggiornamento a software libero dei computer degli utenti;
  • server: pur essendo vero che per alcune applicazioni possono essere necessari prodotti commerciali specifici, ciò non è necessariamente vero per tutte le applicazioni e per tutti i contesti; molte volte viene utilizzato software proprietari (e molto costoso) dove in realtà non vengono utilizzate funzionalità specifiche, ma soltanto quelle standard (penso ad esempio al file management, o al linguaggio SQL per i database); inoltre anche per gli ambienti di sviluppo e prova è spesso possibile utilizzare software libero (penso ad esempio agli ambienti di virtualizzazione, ai sistemi operativi ed ai database).
    Esistono inoltre piattaforme di amministrazione e gestione (software libero) che consentono di amministrare e gestire in modo uniforme ambienti e piattaforme liberi e non, così da non richiedere la duplicazione di know-how, competenze e persone per la gestione dei sistemi.
  • middleware: software legacy, datato, non conforme agli standard e che presuppone l’esistenza di software non standard lato server o, peggio, lato client, deve essere rapidissimamente aggiornato o sostituito, in quanto è un anello chiave nella catena che tiene legato il cliente ai produttori di software proprietario;
  • educazione: praticamente in tutte le scuole i docenti utilizzano software proprietario (si legga, Windows e MS Office), privando gli allievi della necessaria informazione per scegliere liberamente, e costringendo i genitori a spendere soldi per acquistare qualcosa che non è necessario (e di questi tempi i soldi non piovono dal cielo …); se poi una famiglia ha più figli, le licenze per il sistema operativo e per la suite di office automation si moltiplicano ….
    I genitori stessi non sanno di avere una scelta: lo Stato deve fare informazione.
  • divulgazione: lo Stato dovrebbe provvedere all’informazione e all’educazione dei cittadini; un semplice spot della Pubblicità Progresso, anche trasmesso non frequentemente, potrebbe iniziare a far girare la voce che esistono delle alternative …

Approccio economico

L’obiettivo di questo mio post non è quello di portare a tagli sconsiderati e ad un risparmio selvaggio: in medio stat virtus, diceva Aristotele (ovviamente lo diceva in greco antico) …

Ritengo che un buon obiettivo potrebbe essere quello di mantenere una spesa di 200 milioni per il software critico o per cui non vi è un’adeguata alternativa libera (e questo include principalmente il software server side).

Dei restanti circa 500 milioni, se ne potrebbero dedicare inizialmente 200 per l’adeguamento e la normalizzazione di tutti gli applicativi non conformi al CAD, ed i 300 rimanenti potrebbero essere ripartiti con un piccolo risparmio per lo Stato (100) ed un investimento (200) in formazione del personale della PA e per la creazione di posti di lavoro per un nuovo ecosistema di persone ed aziende italiane specializzate nel supporto al software libero ed al supporto agli applicativi della PA.

A tendere (nell’arco di 3-4 anni) su può puntare ai soliti 200 milioni per software critico, 250 di risparmi per lo Stato, e 250 di investimenti nell’ecosistema del software libero e delle aziende specializzate nel supporto ed evoluzione dello stesso.

Nel suo piccolo, quest’idea porterebbe ad un risparmi di 1 miliardo di Euro ogni quattro anni, e ad un investimento analogo nella creazione di posti di lavoro.

Conclusioni

L’Italia soffre oggi di un retaggio derivante dal periodo delle ‘vacche grasse’ del boom economico, della lottizzazione politica e degli interessi particolari posti sopra a quelli dello Stato.

L’inerzia delle Istituzioni, la mancanza di competenze e la deresponsabilizzazione ad ogni livello (ed attualmente anche la pandemia Covid-19) hanno portato l’Italia ad accumulare un debito spaventoso.

Non esiste una soluzione unica che possa risolvere questo problema, ma anche un rapido intervento sul risparmio sul software potrebbe portare lo Stato a ridurre il continuo impoverimento dei cittadini mediante esportazione dei capitali, riducendo al contempo le spese, ed investendo almeno parte delle risorse recuperate nella creazione di posti di lavoro.

Riferimenti

 

La metafora tra i ponti ed il software lunedì 6 febbraio 2012

Posted by andy in pensieri.
Tags: , , ,
add a comment

Ho letto un post sulle metafore per l’associazione di ponti ed edifici al software.

Il tema è quello dell’utilizzo della metafora come mezzo per facilitare la comprensione del mondo del software sfruttando analogie nel mondo fisico.

In effetti la principale differenza che il post trova tra i due mondi è la contrapposizione tra la staticità del mondo fisico (ponti, edifici, …) e la continua evoluzione del software.

Personalmente sposterei l’attenzione  su un aspetto più sostanziale: il ponte, l’edificio, la panchina e la madia sono modi per modificare la realtà.
Il software invece è uno strumento per meglio comprendere ed accedere alla sostanza della realtà.

La cosa è forse un po’ ‘tirata per i capelli’, ma credo che valga la pena di un approfondimento: i ponti (etc.) sono mezzi per facilitare la fruizione della realtà.
Il software è invece un mezzo per facilitare la modellizzazione e la comprensione della realtà.

Senza entrare nel merito delle conoscenze necessarie, la considerazione vale in entrambi i domini: se non si hanno appropriate conoscenze di fisica e di meccanica, il ponte crollerà, e se non si hanno equivalenti conoscenze nell’ambito dell’informatica, anche questa creerà più problemi e disservizi che altro, di fatto realizzando programmi e soluzioni che risulteranno inutili ed abbandonate come un ponte incompleto o crollato.

Metodologie RUP vs. Agile nello sviluppo del software martedì 12 gennaio 2010

Posted by andy in tecnologia.
Tags: , , , , , ,
add a comment

Lo sviluppo del software vede sempre più il confronto tra metodologie altamente strutturate (RUP) e quelle che vorrebbero essere le più elastiche possibili (Agile).

Il conflitto è, in parte, tra coloro che vogliono assicurare la qualità formale rispetto alla qualità sostanziale.

Il giusto, o il meglio, ovviamente non sta né da una parte né dall’altra, ma più probabilmente nel mezzo.

Ma in che modo?

Non posso che condividere il pensiero che la programmazione sia un fatto artigianale, in quanto frutto di un’invenzione; tutto ciò che non è più artigianale si trasforma in software consolidato, librerie, componenti standard.

Da programmatore riesco perfettamente a capire quanto possa stare ‘stretto’ l’abito di colui che produce righe di codice secondo regole e schemi.

Da responsabile della Qualità, ritengo che la bellezza e le promesse della metodologia RUP siano il Santo Graal per la produzione del software.

Le metodologie di tipo Agile sono soltanto un compromesso, per venire incontro all’ingestibilità innata dei programmatori (quelli bravi, soprattutto), delle specifiche del cliente in eterno divenire, la documentazione (costosissima) che non riesce mai ad essere allineata allo stato dell’arte del progetto, dei budget di progetto per definizione sottodimensionati e dei tempi di consegna spesso irragionevoli.

In medio stat virtus, dicevano i latini, e già Aristotele era giunto a questa conclusione.

Il problema è riuscire a definire (e in qualche modo a formalizzare) quale sia questa via di mezzo.

L’eccessiva formalizzazione porta a spendere più tempo a ‘vestire’ il progetto (specifiche, documentazione, etc.) che a realizzare l’obiettivo finale.

L’eccessiva libertà porta in breve tempo a risultati vicini all’optimum, lasciando tuttavia dei lavorati (o semilavorati) con costi di manutenzione impredicibili.

L’arte sta, probabilmente, nel concentrarsi nel punto di incontro tra sviluppo ed utilizzo del software, tra fornitore e cliente.

È in questo punto che si scopre se il lavoro risponde ai requisiti o meno, ed in cui emergono i requisiti nascosti.

Sostanzialmente è il momento del collaudo che, da istante finale del lavoro, deve diluirsi nel tempo, affinando i punti e gli elementi di controllo.

Ad esempio, invece che lasciare al fornitore le attività di installazione, sarebbe molto più appropriato gestire internamente tale attività, o comunque delegarla ad una società terza: in questo modo qualsiasi mancanza in termini di documentazione dell’architettura e delle procedure di compilazione ed installazione apparirebbe in modo palese dal mancato funzionamento del sistema.

E lo stesso vale per la formazione agli utenti ed al personale incaricato di gestire il sistema: interponendo una figura terza, tutte le carenze documentali verrebbero immediatamente a galla.

Diviene quindi fondamentale che all’inizio non vengano posti requisiti troppo specifici, ma soltanto quelli sostanziali, quelli che discriminano tra l’usabilità o meno del prodotto finale, tra l’eseguibilità o meno, tra l’integrabilità o meno, nonché la sua affidabilità nel tempo.

Metodologia, strumenti, linguaggi, componenti software .. tutti elementi di fatto ininfluenti ai fini del risultato, se il controllo diviene sostanziale e non formale; se il prodotto viene verificato rispetto alle reali esigenze del cliente, e con continuità.

Ovviamente, e con questo concludo, occorre assolutamente sviluppare una nuova cultura (e ribadisco ‘cultura’, rispetto al termine ‘metodologia’) per l’identificazione e la definizione dei requisiti di progetto.

il software e garanzie mercoledì 13 maggio 2009

Posted by andy in Internet e società, tecnologia.
Tags: , ,
add a comment

Un problema ormai datato, quello delle garanzie offerte per il software. Mentre ai consumatori sono riconosciuti dei diritti sanciti dalla legge per i beni materiali, per quelli immateriali (il software, giustappunto) questi diritti non sono riconosciuti.
Ma esistono realmente delle differenze?

A parte il software di tipo militare, o comunque quello che viene sviluppato su commessa, garanzie sul software di fatto non ne esistono.

Con ‘garanzie’ intendiamo quegli aspetti che responsabilizzano il produttore nei confronti del cliente a fronte di danni sofferti da questi a causa del proprio prodotto.

Qualunque prodotto materiale, dal tostapane alla macchina fotografica, è soggetto ad un periodo minimo di garanzia imposto per legge, entro il quale il prodotto non conforme alle specifiche deve essere sostituito a costo zero per il cliente, e addirittura se questi viene a soffrirne danni, può rivalersi sul produttore.

Andando a leggere i diritti concessi all’utente nei contratti di licenza (EULA) dei produttori software più importanti, si scopre che in caso di non corrispondenza alle specifiche del prodotto, il produttore in generale si riserva il diritto di valutare se gli convenga sviluppare e fornire un aggiornamento al software, o rimborsare il prezzo del prodotto.

In nessun modo vengono contemplati, ad esempio, danni derivanti da un antivirus che non funziona, o da un software di compressione o di backup che perda i dati.

Il reale danno per l’utente non è il costo del software, ma il danno al proprio business, e in nessun modo il rimborso del costo della licenza può essere in grado di risarcire il danno subito, senza contare che toglie all’utente il diritto di utilizzare il software.

Gli utenti spingono per equiparare i prodotti immateriali (il software) a quelli materiali, in modo da godere dei medesimi diritti garantiti dalla legge.

Dall’altra parte i produttori insistono nel ribadire la sostanziale differenza tra i due tipi di beni.

Persino la Commissione Europea ha iniziato a valutare con attenzione come le società produttrici di software dovrebbero essere ritenute responsabili per la sicurezza e l’efficacia del loro codice. La Commissione sembra quindi intenzionata ad estendere anche ai software le leggi di protezione dei consumatori in vigore per i manufatti fisici.

Si cerca quindi di responsabilizzare i produttori di software.

Ma in pratica, cosa sta accadendo? Il mercato sta affrontando una transizione di fase: si passa dal tempo in cui il software era realizzato da un’elite, e quindi chiuso (closed source) ad un’era in cui l’utente si sta rendendo conto che il software è conoscenza, ed in questo senso deve essere di tutti (open source).

La competizione che si è scatenata contrappone quindi prodotti sviluppati cooperativamente a quelli sviluppati in un’ottica di business tradizionale.

Un aspetto interessante della questione riguarda i brevetti sul software: i brevetti sono stati pensati per proteggere gli investimenti, e questo sicuramente vale per i beni materiali; ma se il software, in quanto bene immateriale, può essere trattato alla stessa stregua? Possiamo utilizzare due pesi e due misure?

Forse esiste un modo per interpretare la situazione e trovare una mediazione che incontri sia le esigenze degli utenti che gli interessi dei produttori: l’idea è quella di far pagare la Qualità.

Dal momento che esistono delle metodologie per verificare la qualità, la robustezza e la sicurezza del software, si potrebbe pensare che si potrebbe consentire la richiesta di un fee di licenza soltanto per il software che abbia superato una certificazione di parte terza rispetto alle metodologie stabilite come riferimento.

L’approccio è un po’ quello della ISO9001 (o anche altre norme, ma credo che questa sia la più nota): non è obbligatoria, ma se si vuole partecipare a certe gare, occorre aver preventivamente investito in una certificazione esterna della metodologia utilizzata.

Vuoi risparmiare sul costo di produzione del software? OK, ma se non non fornisci garanzie, non chiedere più di tanto (che so, per Windows, 10 Euro possono andare bene?)
Se invece certifichi il tuo prodotto (pensiamo a Windows server), a questo punto si possono anche chiedere migliaia di Euro di licenza.

Un approccio simile è quello di RedHat, MySQL, etc. che rendono disponibile gratuitamente il proprio prodotto, ma si fanno pagare un fee per la versione Enterprise, sulla quale forniscono garanzie, liste di certificazione, ed un servizio di risoluzione dei problemi.

In sostanza, la Qualità si paga.

La PA ed i monopòli del software martedì 7 ottobre 2008

Posted by andy in Etica, Miglioramento.
Tags: , , , , , ,
add a comment

Retaqgio di un tempo passato, ancora oggi il software sviluppato da aziende private per la PA è di fatto gestito in regime di monopolio.

Pur essendo i sorgenti del software ufficialmente proprietà della PA, non basta che vengano consegnati dei CD pieni di codice per poter affermare che il software sia stato realmente consegnato.

Un software è realmente consegnato quando il materiale che viene fornito è sufficiente per mettere in condizione il ricevente di poterne riprodurre ed installare una versione funzionante, e di poterne effettuare la manutenzione.

In realtà questo non accade, o accade solo parzialmente, lasciando di fatto nelle mani delle aziende sviluppatrici  il controllo ed il monopolio per la manuntezione correttiva ed evolutiva.

Pur essendo un comportamento eticamente scorretto, e pur essendovi dell’intenzionalità da parte dei privati nel sostenere questo stato di cose, non è tuttavia possibile dare a questi tutti i torti e le responsabilità della cosa.

Una (buona) parte delle responsabilità cade sulla PA per una serie di ragioni:

  • in primis perché non vengono create le appropriate condizioni commerciali per una reale competitività sulle offerte; il software esistente è sì nelle mani della PA, ma questo non viene reso disponibile al mercato dei potenziali fornitori se non dietro esplicita richiesta ed in occasione di un bando di gara; questo significa che nessuna azienda ha la possibilità di poter prendere in mano il software con anticipo tale da poter effettuare una valutazione economica oggettiva per partecipare alle gare;
  • in secondo luogo perché vengono imposte condizioni commerciali non negoziabili talmente tirate che non rimane al fornitore lo spazio per la desiderata gestione della Qualità del prodotto, che viene pertanto limitata al minimo indispensabile;
  • non da ultimo il fatto che la PA in generale non si è attrezzata con strutture proprie interne preposte alla presa in carico del software, con la responsabilità di riprodurre i prodotti ed i sistemi commissionati all’esterno partendo dalla documentazione e dai sorgenti forniti;
  • da ultimo, e tutto sommato abbastanza grave, il fatto che la PA non è in grado di stabilire delle linee guida strategiche sufficientemente chiare e condivise (o imposte) tra tutti i ministeri e gli enti, e non è spesso in grado di identificare con chiarezza e precisione nei contratti i requisiti del prodotto da realizzare, lasciando così troppi gradi di libertà al fornitore, che di fatto progetta e consegna ciò che ritiene meglio per sé più che per il cliente.

Non bisogna poi sorvolare su progetti che, pur essendo incompleti o insoddisfacenti, devono per forza di cose essere collaudati con esito positivo pena la decadenza dello stanziamento dei fondi.

Ed in tutto questo marasma annaspano e devono destreggiarsi coloro che (interni ed esterni) si trovano, loro malgrado, a dover mandare avanti la baracca, sopperendo con le proprie capacità e la propria buona volontà ai problemi che si presentano di volta in volta.

Ma i tempi stanno cambiando, ed a breve inizieranno a palesarsi gli effetti dei germi del rinnovamento.

I principali elementi penso che saranno:

  • la definizione di standard di interoperabilità nazionali, e sovranazionali;
  • l’apertura del codice e delle specifiche al mercato;
  • la valorizzazione delle risorse interne della PA;
  • la valorizzazione della peer review da parte sia degli specialisti interni che del pubblico.