UNIVERSITÀ DEGLI STUDI DELL’INSUBRIA Facoltà Di Scienze ... CRISTIAN - UN... · UNIVERSITÀ...
86
UNIVERSITÀ DEGLI STUDI DELL’INSUBRIA Facoltà Di Scienze Matematiche, Fisiche e Naturali Sede di Varese Laurea Specialistica in Informatica UN MODELLO DI TRUSTWORTHINESS PER IL SOFTWARE OPEN SOURCE Relatore: Prof. SANDRO MORASCA Relatore Esterno: Prof. LUIGI LAVAZZA Correlatore: Dott. DAVIDE TOSI Dott. DAVIDE TAIBI Laureando: CRISTIAN SALA matricola 610132 Anno Accademico 2008 – 2009
Transcript of UNIVERSITÀ DEGLI STUDI DELL’INSUBRIA Facoltà Di Scienze ... CRISTIAN - UN... · UNIVERSITÀ...
UNIVERSITÀ DEGLI STUDI DELL’INSUBRIA Facoltà Di Scienze Matematiche, Fisiche e Naturali
Sede di Varese Laurea Specialistica in Informatica
UN MODELLO DI TRUSTWORTHINESS PER IL SOFTWARE OPEN SOURCE
Relatore: Prof. SANDRO MORASCA Relatore Esterno: Prof. LUIGI LAVAZZA Correlatore: Dott. DAVIDE TOSI Dott. DAVIDE TAIBI
Laureando:
CRISTIAN SALA matricola 610132
Anno Accademico 2008 – 2009
1
INDICE
INTRODUZIONE............................................................................................................................ 2
I. Struttura tesi ......................................................................................................................... 5 CAPITOLO 1
L’OPEN SOURCE COME FENOMENO SOCIALE ........................................................................ 6
1.1 Il fenomeno sociale dell’Open Source in Italia....................................................................... 9
1.2 Software Closed Source vs Software Open Source .............................................................. 10
1.3 Il fenomeno Open Source: considerazioni di ordine tecnico, economico e legale. ................ 12
1.4 L’Open Source e le aree di utilizzo...................................................................................... 15
1.5 La scelta dell’Open Source .................................................................................................. 16 CAPITOLO 2
VALUTAZIONE “OPEN SOURCE” ............................................................................................ 21
2.1 Concetto di fiducia del software .......................................................................................... 23
2.2 Lo Standard ISO 9126 ......................................................................................................... 26
2.3 Modelli e strumenti per la valutazione dell’OSS .................................................................. 28
2.3.1 Costo di possesso (TCO) .............................................................................................. 29
2.3.2 Modello OSMM (Open Source Maturity Model) .......................................................... 30
2.3.3 Modello OpenBRR (Open Business Readiness Rating)................................................. 34
2.3.4 Modello QSOS (Qualification and Selection of Open-Source Software) ....................... 37
2.3.5 Modello OpenBQR (Open Business Quality Rating)..................................................... 40
2.3.6 Modello MOSST (Model of Open Source Software Trustworthiness) .......................... 41
2.4 Il progetto QualiPSo............................................................................................................ 41
CAPITOLO 3
INDAGINE QUALITATIVA DEI PRODOTTI OPEN SOURCE..................................................... 44
3.1 Il modello Goal Question Metric (GQM) per l'analisi oggettiva del prodotto ....................... 45
3.2 Definizione del questionario per l'analisi soggettiva del prodotto......................................... 50
3.3 La raccolta dei dati e la loro archiviazione ........................................................................... 55
3.4 Estrazione dei dati, esempi di query per l'estrazione dei dati ................................................ 64
CAPITOLO 4
RISULTATI DELL'INDAGINE...................................................................................................... 68
4.1 La popolarità dei prodotti .................................................................................................... 69
4.2 La trustworthiness dei prodotti Open Source ....................................................................... 70
4.2.1. Open Source vs. Closed Source ................................................................................... 71
4.3 La qualità dei prodotti OSS ................................................................................................. 72
4.4 Fiducia in relazione al linguaggio ........................................................................................ 75
CONCLUSIONI ............................................................................................................................ 77
Bibliografia................................................................................................................................... 79
Sitografia ...................................................................................................................................... 82
Appendice ..................................................................................................................................... 83
2
INTRODUZIONE
l software è diventato un elemento vitale e imprescindibile nella società
moderna; esso sostiene il business attraverso la gestione, la condivisione e
la cooperazione di informazioni disponibili in tempo reale superando
barriere e confini geografici, permettendo alle organizzazioni pubbliche e private di
avere il controllo di molteplici attività e servizi e di analizzare fenomeni.
L’importanza del software cresce nel tempo e tale crescita impone una serie di
interrogativi a cui le organizzazioni ed i singoli sono chiamati a dare una risposta come
ad esempio che tipo di software utilizzare, quando utilizzarlo e quali motivazioni,
economiche, tecnologiche, sociali e politiche devono essere alla base delle decisioni di
utilizzo di un software rispetto ad altri.
Nella valutazione delle scelte, in alternativa al tradizionale modello
“commerciale” o “proprietario” si contrappone quello “Open Source”.
L’Open Source pone il suo elemento, rispetto ai modelli tradizionali, proprio sul
fatto che il codice sorgente del programma software è disponibile (appunto è open),
modificabile e copiabile.
La filosofia, dunque, alla base dell’Open Source consente agli utenti il libero
accesso e l’utilizzo del codice sorgente del software, che può essere adattato, modificato
e ridistribuito. Negli ultimi anni è stato ampiamente rivalutato da aziende e istituzioni
nonché dalla letteratura accademica, che lo ha reso oggetto di studi approfonditi in
svariati campi.
In particolare nell’ultimo periodo, dopo aver riscritto le regole di come il
software viene licenziato, l’Open Source sta influendo sul mercato dei servizi, grazie
alla grande quantità di prodotti disponibili e alla migliore qualità del codice. Linux nei
sistemi operativi, Apache nei web server, Jboss negli application server e MySQL nei
I
3
database, sono diventati oggetti consolidati e sul cui supporto alcune aziende stanno
costruendo un business vero e proprio.
Attraverso il software libero si possono realizzare sistemi “best-of-breed”,
scegliendo le tecnologie più vantaggiose per una determinata realtà e consentendone
l’integrazione grazie a protocolli aperti o piattaforme realizzate per questo scopo. Sono
molti, però, gli interrogativi che sono emersi nei diversi ambiti di applicazione ed a cui
non sempre è stata trovata una risposta univoca, sul come e perché tale fenomeno di
portata mondiale sia riuscito a trovare una così ampia diffusione e partecipazione.
La qualità del software Open Source (OSS) è generalmente molto dibattuta.
Alcuni affermano che essa è generalmente superiore a quello di altri prodotti, mentre
altri sono più scettici e meno convinti di tale affermazione.
Nel campo del Software Engineering la qualità è spesso un concetto non facile
da individuare. In primo luogo, esistono molti elementi che possono essere utilizzati
per descrivere la qualità del software. Per esempio, lo standard ISO9126 è sinonimo di
qualità del software, e diverse persone possono fare riferimento a tale modello, a
seconda della loro esperienza, degli obiettivi da raggiungere, e del software a loro
disposizione. Per esempio, rispetto a due applicazioni lo stesso modello può andare
bene per uno ma essere incompatibile per l’altro che magari ha dei componenti
incompatibili a quel tipo di software.
La percezione della qualità di un prodotto software è spesso non in linea con la
qualità reale del prodotto stesso. Questo disallineamento è ancora più forte per il
Software Open Source (OSS) che per altri tipi di software, forse perché il Software
Open Source non ha ancora raggiunto la diffusione del Software Closed Source, pur
avendo prodotti validi e di grande successo (come Linux, Apache, ecc…) o forse perché
in questi anni l’OSS ha sofferto molto di una percezione sbagliata della qualità dei
prodotti OSS stessi. Probabilmente questa percezione “negativa” è più psicologica che
altro, ed è intrinseca nel fatto che un prodotto free che non è supportato da un business
ma da una community di sviluppatori appassionati che lavorano senza scopo di lucro
deve essere necessariamente di qualità inferiore rispetto ad un prodotto closed source
sviluppato da una big company.
Quindi, è importante studiare come la qualità dei prodotti OSS venga percepita
dagli utenti, controllare se tali idee sulla qualità OSS sono ancora validi oggi e se ci
sono qualità specifiche che si ritiene necessario migliorare. Il progetto europeo Qualipso
(Quality Platform for Open Source Software) è nato proprio per definire dei modelli che
4
permettessero una valutazione oggettiva della qualità dei prodotti OSS visto la difficoltà
che c’è attualmente nel definire cos’è la Qualità.
Nel dettaglio il progetto Qualipso sviluppa attività di ricerca nelle seguenti direzioni:
o Definizione di metodi, processi di sviluppo e modelli di business per
l’implementazione e l’adozione di OSS sia da parte di utenti finali (e.g.,
industria, PMI, amministrazioni pubbliche) che di sviluppatori/integratori di
sistemi software;
o Progettazione e realizzazione di un ambiente di sviluppo integrato per facilitare
la collaborazione e la creazione di OSS idoneo alle esigenze industriali;
o Implementazione di tool specifici per il testing e la validazione di prodotti OSS;
o Identificazione e diffusione delle “best practices” nel settore;
o Sviluppo di ambienti di test e integrazione per dimostrare l’interoperabilità di
prodotti OSS;
o Valutazione delle tipologie di licenza OSS esistenti nell’ottica di sviluppare un
modello di licenza europeo
Nel contesto del progetto europeo Qualipso, la tesi si focalizza sulla
identificazione dei fattori soggettivi che determinano la fiducia percepita dagli utenti
finali verso i prodotti OSS, con l’obiettivo finale di trovare una correlazione tra questi
fattori soggettivi e fattori oggettivi misurabili a partire dalle caratteristiche del software.
Ad esempio vedere se all’aumentare della dimensione delle classi in righe di codice
aumenta anche la qualità percepita dagli utenti finali.
L'obiettivo delle indagini è quello di comprendere le motivazioni che portano le
società di software a utilizzare o respingere i prodotti OSS.
Per dimostrare la validità di tale modello concettuale e dotarlo di modelli sicuri,
abbiamo raccolto sia le valutazioni soggettive sia quelle oggettive di OSS. Il lavoro,
dunque, descrive la raccolta dei dati, il risultato delle analisi, le minacce alla validità
dei risultati e le relative conclusioni del sondaggio svolto.
Per raggiungere questo obiettivo, la tesi si compone delle seguenti fasi:
1. Definizione di un questionario per la raccolta di misure soggettive (come per
esempio qualità della documentazione, manutenibilità del prodotto OSS,
affidabilità del prodotto, ecc.) relative alla qualità percepita da utenti di prodotti
OSS
5
2. Raccolta di questionari alle conferenze direttamente distribuiti a persone che
ricoprono ruoli diversi, in diversi tipi di aziende, in modo da rappresentare
l’intero spettro di esigenze che si trovano nella realtà industriale.
3. Creazione di correlazioni tra dati soggettivi raccolti tramite i questionari con i
dati oggettivi raccolti tramite tool che sono stati sviluppati appositamente nel
contesto QualiPso per identificare un modello di trustworthiness predicibile in
modo oggettivo.
I. Struttura tesi
In questo capitolo è stata chiarita la teoria sulla quale si basa tutto il lavoro di
tesi, indicando gli obiettivi principali da raggiungere.
Nel primo capitolo parleremo della situazione attuale dell’ Open Source nello
specifico la sua evoluzione e diffusione nella società .
Nel secondo capitolo vengono introdotte alcune delle metriche oggi in uso per la
valutazione del software e una visione generale del progetto Qualipso.
Nel terzo capitolo parleremo del questionario, dei dati raccolti e della struttura
del database .
Nel quarto capitolo vedremo le analisi fatte all’interno del progetto QualiPSo
mediante i dati raccolti dal questionari.
Infine vengono tratte le conclusioni del lavoro svolto e i possibili sviluppi futuri.
6
CAPITOLO 1
L’OPEN SOURCE COME FENOMENO SOCIALE
gni giorno, come le idee, il software permea il tessuto sociale, lo
influenza e produce effetti etici, economici, politici e in un certo
senso anche culturali. Così come le idee, il software, essendo
immateriale, può essere riprodotto e trasmesso facilmente, e in modo simile a quanto
avviene per queste, parte essenziale del processo che sostiene la crescita e l’evoluzione
di un software è la sua libera diffusione.
Il concetto di software libero discende naturalmente dal concetto di libertà di
scambio di idee e di informazioni. La libertà di scambio di idee non è tuttavia una
questione puramente pratica: essa è anche alla base dei concetti di libertà di pensiero e
di espressione.
O
7
Esso si dice libero perché consente all’utente la libertà di eseguire il programma
e di modificarlo secondo le sue necessità, accedendo al codice sorgente, in cambio,
quindi, all’utilizzatore si chiede solo di distribuire e rendere disponibili tutte le
innovazioni e le modifiche ad esso apportate (copyleft).
Ma qual è l’origine della parola Open Source? La sua origine è da ricercare nel
sistema operativo Unix, nato dalla forte collaborazione di una comunità scientifica negli
anni ‘70. Da allora ne derivarono due correnti di pensiero: quella del “software libero”
e quella del “codice sorgente aperto”. Anche se entrambe condividono l’idea della
disponibilità del codice sorgente, si diversificano per alcuni aspetti.
Da una parte, i sostenitori del software libero che scelgono questa espressione
per insistere sulle libertà associate al software, libertà in un certo senso etiche, mentre
dall’altra parte, i sostenitori del termine “codice a sorgente aperto” che insistono sulla
disponibilità del codice sorgente, ma la differenza fondamentale tra i due movimenti sta
nei loro valori, nel loro modo di guardare il mondo.
Le caratteristiche di un software detto “libero”, accordate dalla Free Software
Foundation sono essenzialmente quattro:
1. La libertà di eseguire il programma per qualsiasi uso.
2. La libertà di studiare il suo funzionamento tramite la visione del codice
sorgente e adattarlo ai proprio bisogni.
3. La libertà di ridistribuire delle copie.
4. La libertà di migliorare il programma e offrire alla comunità o alla rete
internet le modifiche apportate.
Almeno fino ad oggi, questo sconvolgimento ha toccato poco l’offerta di servizi
informatici e di consulenza del mondo delle imprese. Le società del settore, a parte
poche eccezioni, sono rimaste affezionate ai pacchetti commerciali più consolidati
(software proprietario).
L’analisi sull’offerta di servizi basata su piattaforme Open Source, sembra aver
superato la fase “ideologica” mettendo in evidenza nuovi operatori capaci di mettere
insieme la partecipazione attiva alle comunità Open Source e la giusta attenzione al
mercato. Dopo una fase di sperimentazione, si stanno affacciando sul mercato imprese
che hanno smesso di scommettere sul modello Open Source in sé, puntando sulla
possibilità di utilizzare in modo economicamente sensato un software che ha oggi
caratteristiche di qualità e flessibilità superiori, rispetto a quello proprietario. Sono
imprese che partecipano alle attività delle comunità perché consapevoli che solo la
8
pratica della partecipazione attiva mantiene competitive le piattaforme su cui
promuovere servizi.
Cosa manca, allora, ancora a queste imprese di servizi per diventare protagonisti
del mercato? Queste micro-imprese non hanno ancora imparato la logica della rete; non
riescono a far valere una propria specializzazione perché non sanno a quali acquirenti
presentare il loro progetto. E’ in questo tempo di crisi l’Open Source potrebbe essere
una delle leve per una nuova generazione di servizi informatici low cost.
E nella Pubblica amministrazione? Nella PA la sfida dell’OSS si gioca sul
software applicativo custom prodotto dalle amministrazioni pubbliche per far fronte ad
esigenze amministrative specifiche o di amministrazione telematica, quali la gestione di
strade o ospedali, l’istruzione, il pagamento d’imposte, la giustizia e la gestione del
territorio.
Fra i requisiti della PA vanno ricordati l’economicità, l’indipendenza dai
fornitori, la sicurezza, il riutilizzo e l’interoperatività. L’adozione di OSS porta
normalmente ad un risparmio iniziale in termini di costi per licenze.
Uno dei tanti elementi a favore dell’OSS nella PA è l’indipendenza dai fornitori
(come sopradetto), consistente nel poter affidare il supporto di un prodotto Open Source
a un’azienda scelta dal cliente, laddove nel mondo del software proprietario solo il
produttore può supportarlo. Disporre, inoltre, del codice sorgente dei programmi
utilizzati all’interno della propria organizzazione permette un grado maggiore di
sicurezza. L’amministrazione dispone di un miglior controllo sulla politica di
evoluzione del proprio parco applicativo sul governo della gestione del patrimonio
pubblico.
In generale, il software Open Source è più adatto a essere personalizzato o esteso
come funzionalità rispetto a un software proprietario e quindi riusato. Il ricorso al
software libero può fungere da leva per la modernizzazione dei sistemi informatici dello
Stato. La possibilità di ricorrere sia al software libero che a quello proprietario aumenta
le possibilità di scelta delle amministrazioni e consente:
• Di accedere a un patrimonio considerevole di software spesso di qualità e
conforme agli standard;
• Di governare il rapporto costo totale della soluzione - rispondenza ai bisogni
attraverso il rafforzamento della concorrenza;
• Di governare il software e di avere la possibilità di assicurarne la perennità.
9
In altre parole, l’amministrazione è messa in grado di capire e modificare il
software per facilitare la sua integrazione e la sua evoluzione.
Stanno nascendo milioni di progetti Open Source, progetti che vedono non più
lavorare il singolo individuo, ma una grande comunità. L’Open Source ormai ha la
strada spianata verso un meritato successo. Meritato nella misura in cui pone l’essere
umano al centro di un percorso tecnologico che riabilita il concetto di libertà come
“veste” naturale della persona stessa.
1.1 Il fenomeno sociale dell’Open Source in Italia
Il software, oggi più che mai, sostiene il business attraverso la gestione, la
condivisione e la cooperazione di informazioni disponibili in tempo reale superando
barriere e confini geografici, permettendo alle organizzazioni pubbliche e private di
avere il controllo di molteplici attività e servizi e di analizzare fenomeni.
Il modello Open Source pone il suo elemento caratterizzante proprio sul fatto
che il codice sorgente del programma software è disponibile (appunto è open),
modificabile e copiabile. Da fenomeno meramente tecnologico nato in ambito
accademico, grazie allo sviluppo della rete internet, l’Open Source è divenuto un
modello di partecipazione cooperativa worldwide organizzata in forme costitutive
identificate con il termine di “Community”1 che, pur nella loro diversità di modelli,
basano la loro identità sulla libertà di partecipazione quale driver di continua
innovazione e di sviluppo. Pertanto il vero successo dell’Open Source è la rete che
permette a sviluppatori sparsi nel mondo di cooperare costituendo una organizzazione
libertaria di migliaia di sviluppatori che producono software.
I prodotti Open Source nascono con il preciso intento di competere con un
prodotto commerciale. Di solito, si affronta l’epica impresa di sviluppare qualcosa in
questo modo perché le aziende commerciali non offrono nulla di adatto allo scopo
oppure, in cambio di quello che offrono queste aziende cercano di vincolare a sé stesse i
loro clienti in modo inaccettabile.
1Mariella Berra, Angelo Raffele Meo, Informatica solidale. Storia e prospettive del software libero, 2001, Bollati Boringhieri, pag. 55.
10
Raramente i prodotti Open Source competono in modo diretto con dei prodotti
commerciali sul piano delle prestazioni. Il loro scopo, infatti, è quello di fornire una
soluzione ad un problema diffuso, non quello di conquistare il mercato. Di conseguenza,
spesso si tratta di soluzioni che si fanno apprezzare per la loro libertà e per la loro natura
standard, non per la loro eleganza o le loro prestazioni (come, ad esempio Open Office).
Spesso i prodotti Open Source nascono dall’abbandono di settori di mercato
ormai non più remunerativi da parte delle aziende (si pensi alla fine di Netscape
Navigator ed alla nascita di Mozilla). In altri termini, è già difficile sostenere che il
Software Open Source sia in competizione diretta con i prodotti commerciali. Questa
assenza di una vera competizione, però, è solo uno degli aspetti che devono essere tenuti
in considerazione. Difatti nel nostro territorio, l’interesse del settore pubblico nell’Open
Source è, indi considerato un modo per supportare lo sviluppo dell’industria locale,
limitando le dipendenze dai grandi fornitori di mercato e stimolando nel contempo la
competitività del mercato.
Nel mercato del software il ruolo giocato dal settore pubblico è considerato di
primaria importanza sia come regolamentatore, tramite autorità, norme e leggi, sia come
primario cliente.
L’adozione di software Open Source nel settore pubblico, tralasciando
motivazioni puramente ideologiche, è ricercata nella propria intrinseca natura di
superiorità rispetto al software proprietario in termini di immediata disponibilità,
sicurezza, flessibilità e manutenibilità del codice; tali caratteristiche derivano in prima
istanza dalle modalità organizzative delle community e in seconda istanza
dall’efficienza dei costi. Quest’ultimo è un elemento strategico in contesti in cui c’è
pressione nei budget, esplicitati dal ridotto o totale abbattimento dei costi di licenza e
dall’opportunità di instaurare liberamente rapporti contrattuali con terze parti per la
manutenzione di software senza subire lockin di fornitori esterni, o infine di usufruire
delle economie di scala legate al riuso del software.
1.2 Software Closed Source vs Software Open Source
Nell’ambito del movimento Open Source, è ormai prassi consolidata considerare la
motivazione del fare un’attività solo per la soddisfazione che ne deriva come il più forte
driver di partecipazione.
11
Riguardo il processo di procurement, le differenze di approccio rispetto al
software proprietario sono molteplici. Alcune di queste differenze risiedono nel fatto
che il software libero permette di disporre pubblicamente di molte più informazioni
rispetto al software proprietario; altre motivazioni sono da ricercare nella mancanza nel
caso Open Source di organizzazioni di marketing o di vendita che vadano alla ricerca di
nuovi clienti.
Sebbene non ci siano costi di licenza associati ai prodotti Open Source, l’attività
di procurement non è comunque a costo zero. Infatti la ricerca e la selezione di prodotti
Open Source per un cliente può essere economicamente più onerosa rispetto al software
proprietario.
Attività quali la redazione di proposte, dimostrazioni, sviluppi di demo,
coinvolgimento di specialisti, sono oneri che in un assessment di prodotti Open Source
sono assunti dal cliente. Al contrario, per il software proprietario, i costi di procurement
vengono spesso ribaltati sul cliente solo in caso di acquisto del prodotto.
La community inoltre dovrebbe assumere un ruolo importante nel prendere
decisioni in ambito procurement. Vi sono diverse teorie in proposito che suggeriscono
quali informazioni e metriche dovrebbero essere rese disponibili per supportare il
processo decisionale di scelta dei prodotti. Ad esempio la tracciatura dell’attività della
community dovrebbe indirizzare delle liste ristrette di prodotti, mentre l’analisi dei
risultati dei test uniti all’esperienza utente dovrebbero costituire un fattore importante
nella decisione finale.
È auspicabile che in un processo standard di procurement Open Source, i
risultati delle analisi svolte dai singoli clienti siano donate alla community
indipendentemente dall’adozione del prodotto. In questo modo si arriverebbe ad un
modello economico sostenibile ed equilibrato in cui le informazioni di mercato siano
disponibili a tutto il mercato evitando i consueti comportamenti da parte dei venditori di
soluzioni proprietarie che utilizzano grossi budget marketing per superare concorrenti
minori sfruttando l’indisponibilità sul mercato di analisi di prodotto libere ed oggettive.
Tali “donazioni”2 non possono essere mandatorie e proprio l’impostazione culturale
dell’Open Source sarà di guida e di stimolo.
2 Arturo Di Corinto, Revolution OS II. Software libero, proprietà intellettuale, cultura e politica, Apogeo Editore, 2005, pag. 45.
12
Per quanto riguarda il processo di manutenzione, essa non è molto diversa da
quella relativa a software proprietario. In entrambi i casi c’è la necessità di disporre in
tempi brevi di modifiche per malfunzioni e scoperture di sicurezza. È compito della
community fornire le patch mentre le organizzazioni che utilizzano i prodotti Open
Source devono impegnarsi nel mantenere aggiornato l’ambiente operativo al pari dei
prodotti proprietari.
Un elemento specifico dei prodotti Open Source è la tendenza ad un più vivace
ciclo di vita delle patch. I prodotti Open Source tendono ad avere una maggiore rapidità
nel responso ad una segnalazione, grazie all’attività di vigilanza della community,
specialmente per i problemi inerenti la sicurezza in cui si cerca di minimizzare i ritardi.
Questo fatto determina un interesse primario da parte delle organizzazioni che
utilizzano i prodotti a software libero a tenere alta l’attenzione sui problemi riportati e
sulle patch disponibili ed a contribuire attivamente nel riportare i problemi percepiti alla
community.
In conclusione, qualunque organizzazione che prevede di utilizzare un prodotto
Open Source deve investire significativamente nella relativa Community. Non esistono
indicazioni certe sull’entità dell’investimento sebbene il costo nel partecipare alla
Community dovrebbe ridursi nel tempo e mantenersi al di sotto del costo totale delle
licenze di un prodotto proprietario. Ciò che appare comunque evidente è che qualunque
approccio che miri a considerare il software Open Source come un affare in quanto a
costo zero, si dimostra sempre sostanzialmente errato.
1.3 Il fenomeno Open Source: considerazioni di ordine tecnico,
economico e legale.
Nell’ambito dell’ordinamento giuridico italiano, il software è tutelato dalla legge
sul diritto d’autore n. 633 del 1941 come forma di protezione giuridica delle opere
creative. Ciò che si protegge quindi non è un’idea, bensì l’espressione creativa di
un’idea o di un’arte. L’autore acquista sulla propria opera il diritto esclusivo di
riproduzione, di esecuzione, di diffusione, di noleggio, di prestito, di elaborazione e di
trasformazione.
13
In particolare tenendo conto di quanto previsto nella Legge 633/41 e s.m.i. come
novellato dal D.lgs. 518 del 29, l’autore di software, con la licenza Open Source
esprime semplicemente la propria volontà circa l’esercizio dei suoi diritti di esclusiva
sul software. Questa “cessione”3 però, è accompagnata da clausole che impongono certe
regole di utilizzo del programma; queste sia pure di un contenuto più permissivo
rispetto alle tradizionali licenze d’uso, costituiscono, anche se non tutte, pur sempre
l’esercizio dell’esclusiva d’autore. In tale ambito è possibile, pertanto, distinguere la
tutela garantita dal diritto d’autore e quella assicurata dalla licenza, in quanto contratto
normativo unilaterale.
La prima salvaguarda il licenziante, in quanto autore di software titolare di
diritti esclusivi, nei confronti sia del licenziatario che disconosce la paternità dell’opera
in capo al licenziante e l’integrità della stessa, sia nei confronti dei terzi, sub licenziatari
non rispettosi della licenza, poiché sconosciuta ad essi.
La seconda tutela detta Clausola di copyleft, è lo strumento utilizzato detta
Clausola di copyleft: che permette al licenziante di obbligare il licenziatario ad inserire
il regime di licenza originaria e dunque le modalità di redistribuzione del software nei
contratti con i terzi (ossia le sub-licenze).
La licenza di software libero Open Source è, dunque, un negozio giuridico
attraverso il quale il titolare dei diritti esclusivi di utilizzazione economica su un
programma concede, a titolo gratuito, alcune facoltà che la legge sul diritto d’autore gli
riserva.
Per tale ragione il legislatore ha disciplinato tale prodotto attraverso le norme
che vanno dall’art. 2575 all’art. 2583 del codice civile, ma soprattutto dalla legge n.
633/41 (Legge sul diritto d’autore).
Non esiste una definizione giuridica di software libero ma piuttosto un’etichetta
costruita sui valori condivisi dai ricercatori e formalizzata con due movimenti che
dominano il mondo del software libero: la Fondazione sul Software libero (FSF), che
riconosce che una parte del software è libera e divisa in quattro libertà che vengono
allegate alla relativa licenza, e l’Iniziativa Open Source (OSI), che certifica la natura
libera di una licenza in conformità con dieci criteri (certificato OSI).
3 Ippolita, Open non è free. Comunità digitali tra etica hacker e mercato globale, Eleuthera, 2005, pag. 125 e ss..
14
Anche al software si applicano i diritti di esclusiva, il cui contenuto si avvicina
al concetto di proprietà, tanto da essere definiti diritti di proprietà intellettuale o di
proprietà industriale. In linea generale, questi diritti di privativa si possono riassumere
nell’esclusiva per il detentore dei diritti di usare, riprodurre, duplicare, tradurre,
modificare, commercializzare.
L’elemento qualificante del modello di licenza Open Source può senz’altro
ritenersi la concessione di un diritto, non esclusivo e non soggetto a limitazioni
temporali o territoriali, di utilizzare, distribuire, modificare un programma per
elaboratore. L’autorizzazione all’utilizzo delle facoltà esclusive sul programma, nel
caso in cui l’utente decida di ridistribuire a terzi il programma per elaboratore, si
sostanzia nell’obbligo di consegnare, unitamente al software, anche una copia dello
schema contrattuale della licenza e di permettere che il codice sorgente del programma
sia liberamente accessibile a chiunque.
È possibile pertanto individuare talune caratteristiche di massima che ci
riconducono concettualmente al tipo di licenza di un software Open Source come la
libertà di redistribuzione, nel senso che la licenza non può limitare alcuno dal vendere o
donare il software che ne è oggetto, come componente di una distribuzione aggregata,
contenente programmi di varia origine; nonché la diffusione del codice sorgente, poiché
il programma deve includere il codice sorgente e ne deve essere permessa la
distribuzione sia come codice sorgente che in forma compilata. La licenza deve
esplicitamente permettere la distribuzione del software prodotto con un codice sorgente
modificato.
Dal punto di vista della causa contrattuale, la concessione delle autorizzazioni
anche a titolo gratuito propria delle licenze di software libero, trova giustificazione nella
soddisfazione di interessi diversi rispetto a quelli legati ad un corrispettivo economico,
quali la diffusione del programma e l’affermazione del suo autore in seno alla comunità,
oltre che allo sviluppo del movimento del software libero Open Source e del modello di
condivisione della conoscenza che ne costituisce il fondamento.
La questione della qualificazione delle licenze di software libero risponde
certamente ad esigenze pratiche quali l’identificazione della normativa applicabile sul
piano internazionale e privatistico. Aspetto, quest’ultimo, che assume molta importanza
in un contesto caratterizzato da un forte carattere transnazionale quale quello del
software in questione.
15
Non va inoltre sottaciuto che un aspetto piuttosto controverso è rappresentato
dalla qualificazione giuridica di tali licenze: negozi giuridici unilaterali o contratti.
Secondo una parte degli autori che si sono occupati dell’argomento, le licenze sarebbero
negozi unilaterali. Altri autori ritengono invece che alcune licenze, le quali contengono
clausole che pongono delle limitazioni nel caso di modifica e ridistribuzione di software
libero Open Source (c.d. clausole di copyleft), necessitino di una forma di accordo tra
licenziante e licenziatario.
Altra questione collegata alla qualificazione, nel caso si propenda per la natura
contrattuale delle licenze, è quella della valida formazione dell’accordo e di
conseguenza dell’applicabilità delle disposizioni civilistiche in materia di contratti
standard (art. 1341 I comma cod. civ.), clausole vessatorie (art. 1341 II comma cod.
civ.) e tutela del consumatore (art. 1469-bis e seg. cod. civ.).
Caratteristica comune alle licenze di software libero è quella di contenere
clausole volte a escludere la fornitura di qualsiasi garanzia per il corretto funzionamento
del programma e l’assunzione di responsabilità per i danni eventualmente provocati da
quest’ultimo. L’individuazione della legge applicabile alla licenza, quindi, è soltanto in
grado di rassicurare l’autore iniziale ed i successivi creatori ed utenti garantendo la
conformità dell’accordo con quella precisa legislazione. Questo tipo di sicurezza può,
però, anche favorire la più ampia divulgazione del software in questione.
1.4 L’Open Source e le aree di utilizzo
L’Open Source risulta oggi essere maggiormente utilizzato attraverso quattro
aree applicative. Questi quattro modelli sono:
1. Ampliances ovvero, i sistemi dedicati allo svolgimento ottimale di una
specifica funzioni quali sistemi che fungono da firewall, web – server,
web application sever.
2. Distributed Enterprice, in quanto l’Open Souce è un sistema robusto ed è
quindi perfetto per quelle aziende che hanno decine o centinaia di miglia
di sedi dove devono utilizzare le stesse applicazioni con sicurezza ed in
maniera economicamente efficace
3. I Cluster ovvero insieme di sever che vengono collegati fra loro al fine di
realizzare delle soluzioni infrastrutturali in grado di offrire delle
16
prestazioni e superiori livelli di sicurezza a condizioni economicamente
interessanti.
4. Workload Consolidation ossia il processo di razionalizzazione e
riduzione del fenomeno di selvaggia ed incontrollata proliferazione di
decine, centinaia e addirittura migliaia di sever che sta oggi colpendo e
mettendo in crisi la infrastruttura di tante aziende e Service provider.
Grazie al fatto che oggi l’Open Source può girare efficientemente anche sui più
grossi sever delle famiglie IBM e grazie all’estrema possibilità di portare e migrare
applicazioni dai mondi proprietari verso il software libero, i clienti possono pensare di
“consolidare” centinaia di sever su di un solo sistema con enormi vantaggi dal punto di
vita del “Total cost of ownership” (maggiore semplicità gestionale e riduzione delle
risorse richieste).
La soluzione sarebbe, quindi, quella di realizzare un sistema che eroghi un
servizio con prestazioni adeguate, ad un costo il più piccolo possibile. Prestazioni
adeguate significa che le aziende, non sono interessate ad avere il massimo delle
prestazioni possibili ma solo ad avere prestazioni adeguate alle loro esigenze. Servizio
effettivamente richiesto significa che anche se le aziende vorrebbero un sistema che non
si guasti mai e non richieda alcuna interruzione, questo non è certo l’obiettivo primario.
In effetti gli obiettivi sono:
1. Minimizzare i danni dovuti ad interruzione dell’erogazione del servizio;
2. Minimizzare il numero e la lunghezza delle interruzioni del servizio;
3. Minimizzare il numero dei guasti.
1.5 La scelta dell’Open Source
La revisione reciproca consentita dall’Open Source è l’unico metodo misurabile
per raggiungere alta fedeltà e qualità. In un mercato competitivo, perciò, una clientela
alla ricerca di alta fedeltà e qualità premierà i produttori di software che scelgono
l’Open Source scoprendo come mantenere un flusso di profitti basato sui servizi, sul
valore aggiunto e su altri mercati complementari a quello del software.
Questo è il fenomeno che sta dietro il sorprendente successo di Linux che, nato
dal nulla nel 1996 è giunto alla fine del 1998 a oltre il 17% del mercato dei server
aziendali e sembra sulla buona strada per dominare il mercato nel giro di due anni.
17
Un altro vantaggio dell’Open Source, di importanza quasi pari al primo, è la sua
utilità come metodo per propagare standard liberi e costruire mercati intorno a essi.
La fortissima crescita di Internet deve molto al fatto che nessuno possiede il
protocollo, cioè, è in possesso di un lucchetto con cui controllare i protocolli di base di
Internet. L’effetto rete innescato dal successo dei protocolli del software libero è
abbastanza chiaro e si riduce, in ultima analisi, a una questione di fiducia e simmetria.
Le potenziali parti coinvolte in un’infrastruttura comune hanno ragione di
fidarsi maggiormente, se possono vedere come funziona in tutte le sue applicazioni e
preferire un’infrastruttura in cui tutte le parti abbiano pari diritti a una in cui una sola
parte goda di una posizione privilegiata da cui trarre profitti ed esercitare il proprio
controllo.
Ciò detto, nessun consumatore di software sceglierà di chiudersi in un circuito
monopolistico controllato da un fornitore, divenendo così dipendente dal software
commerciale, se ha a disposizione un’alternativa Open Source di qualità accettabile.
Questo argomento si rafforza man mano che il ruolo del software diventa
decisivo per l’attività del consumatore: e più vitale è, meno tollerante sarà il
consumatore nei confronti di un controllo da parte di terzi.
Infine, un vantaggio importante offerto dal software Open Source ai clienti, e
collegato alla questione della fiducia, è il suo margine di sicurezza, se il codice sorgente
è disponibile, il cliente ha una via d’uscita in caso di fallimento del produttore; ciò si
rivela particolarmente importante per il debugging degli elementi di interfaccia, poiché
l’hardware tende ad avere cicli di vita brevi, ma l’effetto è più generico e si traduce in
un maggior valore del software Open Source.
Come valutare, allora, i vantaggi dell’Open Source4?
Si può iniziare da alcuni casi in cui l’approccio Open Source abbia trionfato o
fallito. Si può poi cercare di generalizzare, pervenendo a un modello che dia almeno
un’idea qualitativa dei contesti in cui l’Open Source sia la formula vincente per
l’investitore o per l’impresa che cerchi di massimizzare i rendimenti.
Il desiderio razionale da parte del consumatore di non ritrovarsi chiuso nel
circuito monopolistico di un fornitore farà aumentare il suo interesse nei confronti
dell’Open Source (e, di conseguenza, il valore sul mercato competitivo della scelta
4 Jeff Tian, Software Quality Engineering – Testing, Quality Assurance and Quantifiable Improvement : John Wiley & Sons, Inc. 2005
18
Open Source da parte dei fornitori) man mano che il ruolo del software diventa centrale
per il consumatore stesso.
Per quanto riguarda l’area di applicazione, abbiamo osservato sopra come
un’infrastruttura Open Source crei fiducia e simmetria che, nel tempo, tenderanno ad
attrarre nuova clientela e a vincere nella competizione contro il software commerciale;
e, spesso, è meglio avere una quota più piccola di questo mercato in rapida espansione
piuttosto che una quota più grande di un mercato esclusivamente commerciale e in
stagnazione.
Di conseguenza, per l’infrastruttura software, una strategia Open Source che
miri all’onnipresenza ha più probabilità di rivelarsi remunerativa nel lungo periodo
rispetto a una strategia commerciale che miri all’ottenimento dei diritti di proprietà
intellettuale. In effetti, la capacità da parte dei potenziali clienti di ragionare sulle future
conseguenze delle strategie del produttore e la loro riluttanza ad accettare il monopolio
di un fornitore implica una limitazione più stringente. Potremmo riassumere questa
logica osservando che l’Open Source sembra raggiungere il massimo dell’efficacia
nell’aumentare i profitti rispetto al software commerciale, per software che istituiscano
o abilitino una comune infrastruttura di calcolo e comunicazioni.
Infine, si può evidenziare il fatto che i fornitori di servizi unici o anche solo
altamente differenziati hanno più ragioni di temere la copia dei loro metodi da parte
della concorrenza, rispetto ai produttori di servizi i cui algoritmi centrali e conoscenze
di base siano largamente noti.
Di conseguenza, l’Open Source ha più possibilità di prevalere quando i metodi
di punta (o equivalenti funzionali) fanno parte delle comuni conoscenze ingegneristiche.
Il core software di Internet, Apache e l’implementazione Linux dell’Application
Program Interface (API) Unix con standard ANSI rappresentano esempi canonici di tutti
e cinque i criteri. D’altra parte, la scelta dell’Open Source è assai meno sensata per le
imprese che abbiano in loro possesso esclusivo una tecnologia software generante
valore, cioè che soddisfi strettamente il criterio che sia relativamente insensibile ai
guasti; facile da verificare con mezzi diversi dalla revisione reciproca e autonoma; e che
non sia centrale per l’impresa.
Riassumendo, le seguenti discriminanti fanno propendere per l’Open Source:
l’affidabilità, la stabilità, la misurabilità sono fondamentali; la correttezza del design e
dell’implementazione non possono essere verificate efficacemente se non tramite la
revisione reciproca e indipendente; il software è di vitale importanza per il controllo
19
dell’impresa da parte dell’utente; il software istituisce o abilita una comune
infrastruttura di calcolo e comunicazioni.
La comunità Open Source si è organizzata in modo tale da tendere ad
amplificare gli effetti di produttività dell’Open Source stesso. Nel mondo di Linux, in
particolare, è significativo, in termini economici, il fatto che ci siano più distributori di
Linux, in concorrenza tra loro, che costituiscono una categoria a parte rispetto agli
sviluppatori.
Gli sviluppatori scrivono il codice e lo rendono disponibile su Internet. Ogni
distributore seleziona un certo sottoinsieme del codice disponibile, lo integra, costruisce
i pacchetti, gli dà un nome, per poi venderlo ai clienti. Gli utenti possono scegliere il
tipo di distribuzione e possono anche completare una distribuzione scaricando il codice
direttamente dai siti degli sviluppatori. L’effetto di questa separazione di categorie è di
creare un mercato assai fluido, che lascia spazio al miglioramento.
Gli sviluppatori competono tra loro per l’attenzione di distributori e utenti, sulla
qualità dei loro software. I distributori competono per ottenere il denaro degli utenti,
sull’adeguatezza delle loro politiche di selezione, nonché sul valore che possono
aggiungere al software.
Un effetto di primo ordine, in questa struttura interna del mercato, è che nessun
nodo della rete è indispensabile. Gli sviluppatori possono recedere dall’attività e, anche
se la loro porzione del codice di base non viene rilevata direttamente da un altro
sviluppatore, la competizione per l’attenzione tenderà a generare rapidamente
alternative funzionali. Un altro effetto importante è la diminuzione delle spese
aggiuntive, accompagnata da un aumento dell’efficienza, dovuto alla specializzazione. I
distributori, sono liberi dalla necessità di sostenere progetti consistenti e continuativi per
lo sviluppo del software soltanto per rimanere competitivi, possono concentrarsi
sull’integrazione dei sistemi, sulla creazione di pacchetti, sulle garanzie di qualità e sui
servizi. Sia i distributori, sia gli sviluppatori si attengono ai principi di correttezza,
costantemente interpellati e controllati come sono dalla loro utenza.
I meccanismi di mercato che consentono lo sviluppo Open Source sono ancora
in rapida evoluzione. I modelli aziendali che abbiamo passato in rassegna in questo
saggio non saranno probabilmente gli ultimi a essere inventati. Gli investitori stanno
ancora pensando attentamente alle conseguenze della reinvenzione dell’industria del
software come struttura esplicitamente concentrata sui servizi, anziché sulla proprietà
intellettuale esclusiva.
20
In un futuro che comprenda la competizione con l’Open Source, possiamo
prevedere che, prima o poi, il destino di qualsiasi tecnologia software sarà o meno
quella di divenire anch’essa parte dell’infrastruttura Open Source.
Se questa non è proprio una bella notizia per gli imprenditori che sperano di
raccogliere profitti dai software commerciali per sempre, ci lascia comune intendere che
l’industria del software, nel suo insieme, rimarrà imprenditoriale, con nuove nicchie che
si apriranno in continuazione nella categoria applicativa più alta e con una speranza di
vita limitata per i monopoli IP chiusi, le cui categorie di prodotto ricadranno nelle
infrastrutture.
Alla fine, naturalmente, questo equilibrio sarà ideale perché sono i consumatori
di software a condurre il processo. Sempre più software di alta qualità diventeranno
stabilmente disponibili all’utilizzo e al perfezionamento, anziché andare fuori
produzione o essere chiusi nel solaio da qualcuno.
21
CAPITOLO 2
VALUTAZIONE “OPEN SOURCE”
l software prodotto con un modello di sviluppo Open Source è attualmente
una realtà tecnologica che ha assunto proporzioni tali da non poter essere
ignorata. L’assunzione di determinate strategie da parte delle principali
imprese del settore IT (IBM, Microsoft, Sun, HP, Intel), nei confronti di questo
fenomeno, ne attesta la portata.
Il software Open Source (OSS) deve la propria fortuna alle caratteristiche
particolari ed interessanti che ne contraddistinguono il processo di sviluppo. Tra di esse
la più nota, come accennato già, è sicuramente la natura del codice di programmazione,
sempre disponibile e modulare, che permette di adattare il prodotto alle esigenze
dell’utente.
Ovviamente i prodotti Open Source non sono la soluzione definitiva da utilizzare
in ogni tipo di sistema, ma stanno diventano una valida alternativa ad applicativi
proprietari che l’azienda conosce e considera all’interno dei propri sistemi informatici.
I
22
Introdurre applicazioni OSS in una determinata organizzazione corrisponde
univocamente a produrre una stima della qualità di tale software. Per la valutazione
vengono utilizzate delle metriche che sono in generale definite come metodi di
misurazione delle caratteristiche dei prodotti e dei processi di sviluppo. In modo più
formale, secondo una definizione IEEE (Institute of Electrical and Electronic
Engineers), la metrica è una misura quantitativa del grado di possesso di un attributo da
parte di una entità. Nell’ingegneria del software si parla invece comunemente di
usabilità, affidabilità, manutenibilità, sicurezza (ISO 9126).
Definire dei requisiti e richiederne l’applicazione significa anche dover
controllare i risultati, e tali controlli vanno effettuati sapendo cosa misurare e con quali
criteri. Infatti, nel software sono presenti attributi ben precisi (interni ed esterni) che
possono essere considerati e misurati nelle diverse fasi del ciclo di sviluppo (specifica,
progetto, codice, dati di test, livello di organizzazione, livello di formazione del
personale, ecc.). Sono anche misurabili attributi dei processi o attività delle risorse.
Poter misurare significa poter controllare, verificare, consuntivare, stimare, decidere.
La valutazione della qualità del software avviene mediante la definizione di
metriche che possono essere classificate secondo diversi punti di vista:
• metriche oggettive o misurabili, direttamente o indirettamente (linee di
codice, giorni di lavoro, etc)
• metriche soggettive, o basate sul giudizio di persone (esiti di interviste o
questionari).
Comunque l’ obiettivo comune a tutti i sistemi di qualità è la ricerca del
miglioramento continuo. Tale ricerca presuppone la possibilità di effettuare delle
misurazioni quantitative di controllo, utilizzando specifici indicatori della qualità da
calcolare con la periodicità prefissata.
Inizialmente, per l’adozione di prodotti software in un’ azienda, viene redatta
una lista dei prodotti candidati per l’inserimento e si definiscono i criteri sui quali
effettuare la stima. Ogni criterio ha un punteggio valutato su una scala normalizzata di
valori compresi tra 1 e 10: in questo modo è possibile assegnare un valore uniforme ad
ognuno di essi. L’uniformità permette di differenziare l’importanza di ogni punteggio
applicandovi un peso (moltiplicatore). Quest’ultimo viene fissato in base alle necessità
dell’azienda. Infine, il punteggio finale è ottenuto tramite la somma dei singoli punteggi
individuati.
23
Generalmente è possibile inquadrare il software da valutare in due classi distinte
(orizzontale e verticale), sulla base della portata dei vantaggi relativi all’adozione dello
stesso:
• Il software orizzontale è costituito da soluzioni di breve periodo che comportano
generalmente una riduzione dei costi, utilizzabili in imprese di diverse categorie.
• Il software verticale, al contrario, è formato da soluzioni di medio, lungo periodo
che comportano generalmente un aumento di valore del processo aziendale,
specifiche per una determinata tipologia di impresa.
Considerando infine i continui aggiornamenti del codice che contraddistinguono
le comunità di sviluppo, si dovrebbe ripetere la procedura nel tempo: l’evoluzione
continua che contraddistingue la realtà Open Source potrebbe aver portato progetti,
scartati in passato, ad un grado di maturazione tale da farli diventare un punto di
riferimento tecnologico. L’utilizzo ripetuto del processo precedente descritto, ha messo
in evidenza l’importanza di alcuni, criteri, che è possibile utilizzare indipendentemente
dalla categoria software considerata.
Il ruolo centrale di questi parametri ha portato alla formalizzazione della
procedura di stima, definendo le linee guida per la creazione di un modello di
valutazione per software Open Source.
La creazione di una base di conoscenza, in grado di categorizzare e di valutare
correttamente l'OSS esistente, è quindi una delle priorità del progetto Qualipso.
Partendo da questo presupposto, Qualipso ha canalizzato la propria esperienza nella
creazione di un modello di valutazione del software, avente lo scopo di selezionare
progetti Open Source sulla base di criteri relativi al prodotto considerato.
2.1 Concetto di fiducia del software
Le relazioni tra individui o organizzazioni hanno sempre avuto un ruolo rilevante nel
contesto privato, sociale ed economico. Ultimamente tale ruolo è divenuto di notevole
importanza, dato che le persone e le organizzazioni spesso per raggiungere i propri
obiettivi, si trovano a dover creare, sviluppare o mantenere le relazioni.
Generalmente, ci sono diverse componenti che influenzano in positivo o in
negativo una relazione; una tra le più importanti è la fiducia.
24
In letteratura sono presenti diversi studi che danno una definizione di fiducia o
presentano una riesame5 al fine di trovare o fornire una definizione comune che tenga
conto di diversi aspetti: sociale, organizzativo, psicologico ed anche informatico.
Alcuni autori considerano la fiducia come risultato della combinazione di
credenze, atteggiamenti, intenzioni e comportamenti, mentre altri vedono la fiducia
strettamente legata alla valutazione del rischio.
La fiducia è, dunque, un fenomeno complesso, che è stato oggetto di interesse in
varie discipline. Essa è definita in molti modi, di conseguenza, non possiamo dare per
scontato il significato che viene attribuito alla parola fiducia nel caso di applicazioni
software e prodotti OSS. È quindi interessante esaminare il concetto di fiducia
nell’Open Source come emerge dalla letteratura scientifica.
Antikainen6 è un sostenitore della correlazione tra il pensiero della comunità e la
fiducia. Egli parte dal presupposto che la sicurezza è un fattore chiave per le discussioni
che possono influire o manipolare l’opinione pubblica su un prodotto in modo positivo
o negativo. In altre parole, l’opinione pubblica può essere influenzata da incompleta,
parziale, o anche inesatta informazione che incide sulla fiducia di un prodotto OSS.
Essa è un fattore molto importante per le organizzazioni e le imprese quando stanno
prendendo le loro decisioni in merito alla scelta di un prodotto OSS rispetto ad un’altro.
Antikainen definisce la fiducia come “la misura in cui una persona è fiduciosa,
pronta ad agire sulla base di parole, azioni, e decisioni di qualcun’ altro”7.
Antikainen ha trovato otto fattori che sembrano pregiudicare la fiducia della
comunità, indicate nel loro ordine di importanza: la competenza, la pratica, la
reputazione, gli obiettivi comuni, la condivisione delle informazioni, la cultura, i valori,
l’influenza e la familiarità.
Nella stessa linea di Antikainen, Hertzum8 mira a spiegare il valore della fiducia
nel rapporto tra colleghi su come le informazioni che si scambiano possano incidere
sulle loro scelte, in quanto è più facile chiedere ai colleghi informazioni, piuttosto che
attingerle da fonti esterne. Nell’interazione umana, la fiducia è definita come una
5 Muffato M., Faldani M. , Open Source: Strategie, organizzazione, prospettive , Mulino 2004, pag. 34.
6 AntikainenM., “Is trust based on cognitive factor in OSS communities?”,Trust in Open-Source Software (TOSS), 2007, Limerick, June 2007. 7 Muffato M., Faldani M. Ibidem. , “Open Source: Strategie, organizzazione, prospettive” , Mulino 2004 8 Hertzum P. G., “Robust Nonproprietary Software”, In Proceedigs of the IEEE Symposium on Security and Privacy, pp. 122_123, 2000.
25
questione emotiva in cui la stessa ha una responsabilità morale verso il fiducioso ed
implica di fatto che l’altra persona possieda le necessarie conoscenze e competenze per
la valutazione. E’ possibile distinguere quattro tipi di elementi su cui la fiducia è
fondata: l’esperienza; la reputazione; la semplice ispezione di attributi; l’ipotesi
generale e stereotipi.
I risultati dei lavori da Antikainen e Hertzum sono in linea con gli obiettivi del
progetto QualiPSo, come è chiaramente evidenziato dall’importanza della fiducia.
Hansen9 osserva che la sicurezza e la privacy possono essere generalmente
indicate come un obiettivo, mentre la fiducia dipende fortemente dall’esperienza
soggettiva e dai sentimenti degli utenti. Pertanto, essi definiscono la fiducia sulla base
sicura dei concetti di sicurezza e privacy.
Hasselbring e Reussner10 mirano a fornire una visione olistica di fiducia del
software in una impostazione interdisciplinare. A loro avviso, la fiducia è costituita dai
seguenti attributi: correttezza, sicurezza, qualità del servizio (disponibilità, affidabilità,
prestazioni), sicurezza (prevenzione ad un accesso non autorizzato al sistema), privacy
(assenza di divulgazione di informazioni non autorizzata).
Lawrieand e Gacek11 sottolineano alcuni concetti chiave sullu fiducia dell’OSS.
In primo luogo, essi affermano che i termini fiducia e affidabilità sono equivalenti. La
fiducia può esistere se non vi è alcun elemento di prova per giustificare l’affidamento su
un determinato sistema, mentre l’affidabilità suggerisce che vi siano criteri di garanzia
per giustificare la nostra fiducia in un sistema. Per essere un sistema affidabile e degno
di fiducia, un sistema informatico deve includere alcuni attributi, quali la sicurezza,
l’attendibilità, la disponibilità.
Bernstein12 analizza come l’attendibilità raramente viene presa in considerazione
da progettisti software, soprattutto per quanto riguarda questioni come la pianificazione,
il costo, le prestazioni e i requisiti. Inoltre, essa è una proprietà che comprende la
sicurezza e la disponibilità. L’autore afferma inoltre che la tolleranza ai guasti è al
centro della costruzione di un software affidabile.
9 Hansen M. Ks., Uhntoop K., Pfitzmann A., “The Open Source Approach – Opportunities and limitations whit Respecht to Security and Pravacy”. Computers&Security, 2002 10 Hasselbring W., Reussnar R., “Toward Trustworthy Software System”, US Army Research Laboratories Informatories Assurance Center, IEEE. 2006 11 Lawrieand T., Gacek C., “Issues of Dependability in Open Source Software Development”, ACM SIGSOFT, Software Engineering Notes, vol. 27, n.3, pp 34, May 2002 12 Bernstein L. , “Trustworthy software system”, ACM SIGSOFT Software Engineering Notes, vol. 30, no. 1, pp. 4-5, 2005
26
Dalle analisi della letteratura, è chiaro che il concetto di fiducia dei prodotti OSS
comprende tutti quei fattori che contribuiscono alla decisione di utilizzo dell’OSS, da
utilizzare come alternativa al software privato. Ciò significa che i fattori da prendere in
considerazione per valutare la fiducia di un prodotto OSS devono includere quegli
elementi che vengono utilizzati anche per valutare il software privato.
2.2 Lo Standard ISO 9126
Dall’esperienza raccolta nello sviluppo del software emerge che il principale
modello di riferimento per la qualità del software è la normativa ISO9126 che si
compone di quattro parti:
• il modello
• le metriche per la misurazione delle qualità esterne che esprimono le prestazioni del
software nel suo ambito di utilizzo (comportamento del codice in esecuzione).
• le metriche per la misurazione delle qualità interne che esprimono la misura in cui il
codice software possiede una serie di attributi, indipendenti dall’ambito di utilizzo.
• le metriche per la misurazione delle qualità percepita che esprimono l’ efficacia e l’
efficienza, con cui il software serve le esigenze dell’ utente, ma anche l’ usabilità
del prodotto.
Nel modello ISO9126 la qualità viene intesa come l’insieme delle caratteristiche che
incido sulla capacità del prodotto di soddisfare requisiti espliciti od impliciti e viene
definita in sei caratteristiche, ognuna delle quali si dirama in altre sottocaratteristiche:
• Funzionalità: si intenda la capacità di fornire funzioni tali da soddisfare,in
determinate condizioni, requisiti funzionali stabili o impliciti. Si può suddividere
in:
o Appropriatezza: presenza di funzioni relative a compiti specifici adeguate al
tipo di software;
o Accuratezza: gli attributi del software devono avere la capacità di fornire
risultati ed effetti esatti e concordanti, come ad esempio il grado di precisione
necessaria nei valori calcolati;
o Interoperabilità: la capacità del software di interagire con altri sistemi;
o Conformità: il software deve essere aderente all'applicazione di standard,
convenzioni, leggi o prescrizioni in genere;
27
o sicurezza: capacità del software di impedire accessi non autorizzati;
• Affidabilità: si intende l'insieme di attributi che riguardano la facoltà del software
di serbare il livello di prestazioni tramite condizioni e limiti di tempo fissati. Le sue
sottocategorie sono:
o maturità: frequenza di fallimenti dovuti a errori presenti nel software;
o robustezza: cercare di mantenere un livello di prestazioni fissato in caso di
errori e malfunzionamenti:
o ripristinabilità: capacità di ristabilire il livello delle prestazioni e recupero dei
dati;
• Usabilità: intesa come l'insieme di attributi che riguardano lo sforzo necessario
all'uso del prodotto e alla valutazione individuale di tale uso riferito ad un certo tipo
di utenti (che possono essere operatori, installatori, utenti finali, …). Le sue
sottocategorie sono:
o Comprensibilità: è calcolabile tramite lo sforzo necessario agli utenti per
capirne la logica delle applicazioni e come applicarla;
o apprendibilità: è calcolabile attraverso lo sforzo necessario agli utenti per
impararne il corretto utilizzo;
o operabilità: è calcolabile attraverso lo sforzo necessario agli utenti per eseguire
e calcolare le varie operazioni;
• Efficienza: è il rapporto tra il livello delle prestazioni del software e la quantità di
risorse necessarie (come il tempo, lo spazio nella memoria, …) nell'ambito delle
condizioni fissate. Le sue sottocategorie sono:
o reattività: riguarda i tempi di risposta e di elaborazione e la capacità del sistema
di smaltire le richieste necessarie all'esecuzione delle sue funzionalità;
o sfruttamento: riguarda la quantità di risorse e la durata dell’impiego delle
risorse necessarie all’esecuzione delle sue funzionalità;
• Manutenibilità: è l'insieme di tutti gli attributi necessari ad eseguire modifiche. Le
sue sottocategorie sono:
o analizzabilità: riguarda lo sforzo necessario alla diagnosi delle inadeguatezze e
delle cause dei malfunzionamenti, e all’identificazione delle porzioni di
software che devono essere modificate;
o modificabilità: riguarda lo sforzo necessario per effettuare modifiche,
rimozione di errori, ecc.;
28
o stabilità: riguarda il rischio di effetti inattesi durante le modifiche;
o testabilità: riguarda lo sforzo necessario per approvare le modifiche al
software;
• Portabilità: è la capacità del software di essere adattato in qualsiasi ambiente. Si
può suddividere in:
o adattabilità: capacità del software di adattarsi a diversi ambienti senza applicare
azioni o strumenti, se non quelli prefissati, dal software in considerazione;
o installabilità: riguarda lo sforzo necessario per poter installare il software in un
determinato ambiente;
o uniformità: tutte le caratteristiche del software che lo rendono adeguato agli
standard e alle convenzioni di portabilità;
o sostituibilità: capacità di un software di essere utilizzato al posto di un altro
specifico software.
Al fine di superare alcune delle difficoltà incontrate in sede di adozione OSS,
sono stati sviluppati diversi strumenti e modelli di valutazione. Il loro obiettivo è quello
di aiutare i potenziali utenti a capire le caratteristiche dei prodotti disponibili, e di
valutare i vantaggi e gli svantaggi della sua adozione.
2.3 Modelli e strumenti per la valutazione dell’OSS
L’attività di valutazione di un prodotto Open Source, per la scelta di un prodotto
maturo, è ancora in fase di studio. A tal fine, negli ultimi anni, sono stati introdotti sei
modelli di valutazione:
1. Costo di Possesso (TCO);
2. Open Source Maturity Model (OSMM);
3. Open Business Readiness Rating (OpenBR);
4. Qualification and selection of Open Source Software (QOSS);
5. Open Business Quality Rating (OpenBQR)
6. Model of Open Source Software Trustworthiness(MOSS)
Tutti i modelli sono basati sulla valutazione soggettiva di un certo numero di
parametri, quindi dell’attribuzione di un fattore peso in relazione all’importanza del
29
parametro. La valutazione ottenuta, sarà quindi personale. Il punteggio finale che ogni
metodo restituirà non sarà “universale” bensì utile solo ad aziende di tipo omogeneo.
2.3.1 Costo di possesso (TCO)
Il primo modello storico di valutazione, è quello del costo di possesso,
utilizzabile anche in sovrapposizione ai modelli seguenti, che fornisce unicamente un
indicazione del solo costo relativo al possesso di un prodotto. In tempi recenti alcune
software house, hanno dato incarico a note società di consulenza internazionale di
dimostrare il minor costo totale di possesso (TCO=Total Cost of Ownership) dei
programmi commerciali rispetto a quelli non commerciali.
Il TCO è fondamentalmente un'analisi statica dei costi di esercizio di una
apparecchiatura. Non tenendo conto di eventuali ritorni, è applicabile solamente durante
la fase di analisi strategica degli investimenti, inoltre il TCO presenta dei costi connessi
molto onerosi il che lo proietta solamente nel campo applicativo di grandi aziende.
Il TCO si presenta come un metodo ottimo per misurare i costi totali,
identificando tutte le spese, in termini chiari e facilmente misurabili; ma presenta lo
svantaggio di non poter stimarne il valore aziendale complessivo. Per la sua estrema
semplicità e linearità nel fornire un primo quadro della situazione, solitamente viene
utilizzato come unico strumento di analisi tralasciando altri sistemi più importanti e
senza valorizzare altri tipi di benefici più difficili da misurare e più controversi[Errore.
L'origine riferimento non è stata trovata.]. L'analisi TCO deve quindi tener conto di:
• Costi per l'acquisto dei componenti hardware o software (ricerca del fornitore sul
mercato, costi di amministrazione per le ricerche di mercato, costi delle licenze
software);
• Costi per lo sviluppo di personalizzazione degli applicativi implementati dai
dipendenti interni;
• Costi operativi,legati all'aggiornamento e alla manutenzione e all'esercizio del
software; questi costi denominati "costi operativi" comprendono: formazione di
personale IT e di end-users, supporto degli end-users nei problemi riscontrati
nell’utilizzo della tecnologia, gestione della sicurezza informatica, utilizzo di spazi
per ospitare apparecchiature hardware (es. server, mainframe), consumi di energia,
30
costi di connessione Internet, costi derivanti dal down-time del sistema per
malfunzionamenti o errori degli end-users;
• Costi legati alla dismissione del sistema (smantellamento delle apparecchiature
hardware, eliminazione dei cavi portanti delle reti LAN).
In letteratura è possibile trovare molti esempi su come il TCO può rilevare
importanti benefici, ma fallire nel descrivere il valore totale. Secondo uno di questi si
può supporre di voler motivare una richiesta di upgrade per un server e una rete, in una
situazione di forte pressione affinché l’IT riduca le sue spese. Avvalendosi del metodo
TCO si identificano tutti i costi dell' intero ciclo di vita (acquisto, installazione,
gestione, supporto e manutenzione). A questo punto, se la scelta di mantenere la
situazione attuale costa praticamente zero per l’acquisto, ma costa molto di più per
l’esercizio rispetto alla scelta di utilizzare nuovi componenti, l’analisi evidenzierà
quantitativamente questi fattori. Così pure il TCO catturerà elementi come il costo e il
rischio di interruzioni del servizio, i costi di manutenzione e di supporto.
2.3.2 Modello OSMM (Open Source Maturity Model)
L’ OSMM13 è stato progettato per la valutare i prodotti OSS e capire se un
prodotto può soddisfare le esigenze di una data organizzazione. Il Maturity Model pone
l’accento su criteri relativi all’ambiente di sviluppo del software ed alle principali
caratteristiche che contraddistinguono il valore aggiunto degli applicativi a sorgente
aperto. E’ ripartito lungo quattro assi principali che ne racchiudono i parametri:
• L’attività fornisce una stima dell’operosità degli sviluppatori che lavorano sul
software esaminato.
• La comunità mira a valutare tutte le risorse messe a disposizione dall’utenza, più o
meno esperta, della tecnologia in esame.
• La trasparenza permette di misurare la difficoltà di inserimento all’interno
dell’organizzazione.
• La tecnologia è l’asse costituito da quei criteri che cambiano dinamicamente sulla
base della categoria in cui è inquadrato il software ed ha lo scopo di valutare le
prestazioni del prodotto.
13 Duijnhouswer F. W., Widdosws C., “Open Source Maturity Model”, accessed june 2007.
31
Il modello non è una griglia rigida da usare nella stima di ogni categoria
software, ma vuole essere un insieme di linee guida per la raccolta di criteri che
contraddistinguono la prima fase del processo di valutazione. I criteri selezionati non
sono parametri logici, ma analitici: la valutazione di un prodotto, infatti, dipende dal
contesto in cui deve essere inserito il software e non può essere compiuta tramite una
tabella universale. Per questo, ogni parametro presente può essere eliminato o
trasformato in criteri più specifici. Viceversa, qualora fosse necessario è possibile
raggruppare parametri in un unico criterio o inserirne di nuovi. Ad esempio, un
parametro importante di cui il modello non tiene volutamente conto è quello legato alla
licenza con cui il software è distribuito: tale aspetto, infatti, acquista importanza solo se
la valutazione è svolta per conto di imprese ICT ovvero per conto di organizzazioni che
potrebbero basare il proprio business sulla ridistribuzione e sulla modifica del codice
sorgente.
La flessibilità di cui il modello dispone limita quindi il rischio di compiere una
valutazione troppo costosa ed erronea, basata su criteri poco adatti per classificare il
prodotto. Inoltre, questa particolare strutturazione delle informazioni ne permette di
fatto il riutilizzo in imprese tipologicamente diverse, permettendo la costruzione di una
base di conoscenza in maniera incrementale.
Il metodo OSMM valuta, quindi, un prodotto OSS in base al sostegno dato dalla
documentazione, dall’integrazione e dai servizi offerti. Questi sono i requisiti principali
che un prodotto software deve soddisfare al fine di essere adottato da una società.
In particolare l’OSMM stima la maturità del prodotto in tre fasi che riguardano
la valutazione degli elementi essenziali (assistenza, documentazione, formazione,
integrazione dei prodotti, servizi professionali), a cui viene assegnato un punteggio
detto peso, tra 0 e 10. Successivamente viene calcolato un punteggio finale su una scala
di 100 punti.
32
Figura 1 – Estratto della checklist di OSMM
Fase 1: valutazione della maturità di prodotto:
La prima fase identifica i fattori chiave per la valutazione del livello di maturità di ogni
elemento. Si considerano elementi chiave:
• Prodotto Software
• Documentazione
• Supporto
• Training
• Integrazione di prodotto
• Servizi professionali
Ad ogni elemento viene assegnato un punteggio valutando quattro fattori:
• Definizione dei requisiti
• Locazione delle risorse
• Valutazione della maturità (da non esistente a prodotto pronto per la produzione)
• Assegnamento del punteggio di maturità
Fase 2: assegnamento di un fattore peso
In base alle proprie esigenze, si assegna un peso ad ogni punteggio. I pesi consentono ad
ogni elemento di riflettere la propria importanza in relazione alla maturità dal prodotto.
I valori di default per i pesi sono:
Software: 4
Support: 2
Documentation: 1
33
Training: 1
Integration: 1
Proferssional Services: 1
Fase 3: calcolo del punteggio di maturità finale
Dopo aver valutato e assegnato un fattore peso ad ogni elemento, il punteggio totale di
maturità sarà dato dalla somma di tutti i valori precedentemente calcolati.
L’OSMM14, Capgemini ha sviluppato un Open Source Maturity Model in sette
passi per consentire ad organizzazioni, imprese e PA di determinare se e quale prodotto
OSS è adatto. Essa descrive come un prodotto Open Source dovrebbe essere valutato al
fine di garantire le sfide che i prodotti IT affrontano oggi nelle aziende.
Sono stati trovati indicatori, sia per i prodotti che per le applicazioni. Gli
indicatori di prodotti sono dodici e sono raggruppati in quattro gruppi: prodotto, età,
punti di vendita, comunità degli sviluppatori, gerarchie umane, licenze, integrazione,
collaborazione con altri prodotti, modularità, norme utilizzo, sostegno, facilità di
implementazione, accettazione, comunità di utenti, diffusione nel mercato. Gli
indicatori delle applicazioni sono quindici e sono: usabilità, interfaccia, prestazioni,
affidabilità, sicurezza, tecnologia, indipendenza del venditore, indipendenza dalla
piattaforma, sostegno, comunicazione, amministrazione, consulenza, formazione, e
implementazione. Per ogni indicatore, il cliente dà un punteggio su una scala che va da
1 a 5.
I sette passi indicati da Capgemini per valutare un prodotto, utilizzando sia gli
indicatori di prodotti che gli indicatori di applicazione sono i seguenti:
1. Prodotto di ricerca e selezione grezzi,
2. Punteggio dei prodotti utilizzando gli indicatori di prodotti,
3. Punteggio utilizzando gli indicatori di applicazione,
4. Intervista del cliente sull’ importanza degli indicatori dell’applicazione,
5. Punteggio dell’applicazione da parte del cliente,
6. Determinazione della somma dei punteggi per la selezione finale del prodotto
giusto per cliente,
7. La stima del prodotto.
14 Muffato M., Faldani M. , Open Source: Strategie, organizzazione, prospettive , Mulino 2004, pag. 56.
34
2.3.3 Modello OpenBRR (Open Business Readiness Rating)
L’OpenBRR15 propone un modello, denominato Business Readiness Rating for
Open Fonte, come uno standard aperto per facilitare la valutazione e l’adozione di OSS.
Essi rilevano come, in pratica, molti modelli di valutazione del software sono
fatti ad hoc, senza una metodologia di valutazione formale. Modelli ad hoc possono
essere inesatti o incompleti nella loro valutazione, ed è estremamente difficile
convalidare la correttezza della valutazione. Pertanto l’uso di un modello standard per
la valutazione del software aumenta la facilità e la correttezza della valutazione, e
accelera l’adozione di Software Open Source. Inoltre, gli utenti OSS possono
condividere la loro valutazione all’interno della comunità dell’OSS.
Il modello OpenBRR si compone di quattro fasi. Nella prima fase della
valutazione, viene compilato un elenco dei programmi da valutare. Ogni componente
viene valutata in base alla destinazione d’uso, tra cui: il tipo di licenza, il rispetto delle
norme, l’esistenza di un utente base, la disponibilità di un supporto, di un linguaggio di
implementazione, di internazionalizzazione, ecc. Poi viene valutata la funzionalità del
prodotto. Le caratteristiche di una applicazione di riferimento sono identificate e la loro
importanza è classificata rispetto al tipo di utilizzo. Quindi, ogni prodotto viene valutato
in base a come implementa le caratteristiche. Infine, i gradi sono normalizzati e la
valutazione finale (in una scala che va da 1 a 5 ) è calcolata.
Figura 2 – Fasi del modello OpenBRR
15 “Business Readiness Ratung for open Source” , OpenBRR.org, BRR2005-RFC 1, accessed in June 2007.
35
Fase 1: Quick assessment:
Si identifica una lista di componenti da valutare. Si valuta ogni componente tenendo
conto di alcuni indicatori, assegnando un punteggio da 1 a 5 dove uno indica “inaccettabile” e
5 “Eccellente”. L’obiettivo è quello di eliminare i prodotti che sono chiaramente inadatti.
Gli indicatori da considerare sono:
1. Il target di utilizzo dell’applicazione (mission-critical, Regular, Development,
Experimentation)
2. Selezionare un elenco di indicatori basati sul target di utilizzo:
• Tipo di licenza:
• Licenze approvate dall’Open Source Initiative;
• Copyleft License.
Il tipo di licenza può essere importante per l’effettivo bisogno che si ha del software, se
ad esempio si vuole modificare un prodotto e poi rivenderlo a proprio nome, bisogna
verificarne la fattibilità nella licenza.
• Rispetto degli standard.
• Esistenza di utenti referenziabili che utilizzano il componente: è importante sapere chi
utilizza il prodotto e che tipo di utilizzo ne fa.
• Supporto fornito da un’organizzazione stabile.
• Linguaggio di implementazione. Il linguaggio potrebbe essere importante nel caso di
aziende con un’ottima padronanza di un tale linguaggio e mancanza di competenza su di
un altro.
• Supporto per l’internazionalizzazione o per la lingua desiderata.
• Presenza di moduli aggiuntivi sviluppati da terze parti.
• Presenza di libri pubblicati sul prodotto
• Il prodotto è seguito da analisti, tipo Gartner o IDC?
3. Aggiungere altri indicatori alla lista se necessario: alcuni tipi di prodotti potrebbero
necessitare di criteri di valutazione ulteriori.
4. Creazione di regole di accettazione degli indicatori specificati
5. Valutazione di tutti i componenti
Fase 2: Target usage assessment
La seconda fase nell’ordinamento dei prodotti, dal migliore al peggiore, rispetto al
punteggio calcolato nella fase 1.
36
Fase 3: Data collection and processing
La terza fase consiste nella raccolta dei dati, indicando tutti i punteggi in un scala da
uno a cinque. Quindi si passa alla verifica delle funzionalità di prodotto. La verifica delle
funzionalità è una valutazione computazionalmente diversa dalle altre categorie. Ogni tipo di
applicazione ha un insieme diverso di caratteristiche. Il punteggio relativo alle funzionalità è
ottenuto inizialmente confrontando le caratteristiche del componente rispetto ad un “uso
standard” . Una volta disponibile l’insieme di caratteristiche standard, è possibile iniziare la
valutazione delle caratteristiche attraverso quattro fasi:
1. Assegnare un punteggio di importanza a tutti gli elementi della lista delle caratteristiche,
utilizzando una scala da 1 a 3, dove 1 è poco importante e 3 molto importante.
2. Comparazione della lista delle caratteristiche del componente con le caratteristiche
standard. Per ogni caratteristica, sommare il punteggio di importanza, se non è
implementata una caratteristica standard, sottrarre il punteggio.
3. Se il software ha delle caratteristiche ulteriori non incluse in quelle standard, assegnare
un punteggio di importanza ad ogni funzionalità e sommarla al punteggio di importanza.
4. Calcolare il punteggio delle caratteristiche dividendo il punteggio di importanza totale
con il massimo ottenibile dalla somma dei punteggi delle caratteristiche standard. Con
tale punteggio è possibile sapere la percentuale di caratteristiche implementate dal
prodotto.
Fase 4: Data translation
L’ultima fase consiste nella normalizzazione del punteggio delle caratteristiche, su una
scala da 1 a 5 nel seguente modo:
• Meno del 65% ı 1 (inaccettabile)
• 65% - 80% ı 2 (quasi accettabile)
• 80% - 90% ı 3 (accettabile)
• 90% - 96% ı 4(ottimo)
• Più del 96% ı5 (eccellente)
L’Open BRR è un importante passo avanti per quanto riguarda l’OSMM, dal
momento che comprende più indicatori e la possibilità di personalizzare le valutazioni
svolte da altri, così da fornire un peso personalizzato. Esso ha tuttavia alcuni limiti:
• Per molti prodotti, è difficile scegliere una domanda di riferimento che riflette le
esigenze di tutti gli utenti;
• Ci sono molteplici finalità d’usi, ciascuno con le proprie esigenze;
37
• Ogni valutazione effettuata da un utente potrebbe non essere applicabile ad altri
utenti.
In ogni caso, il punteggio finale è probabilmente un indicatore sintetico per
rappresentare la qualità di un prodotto software.
2.3.4 Modello QSOS (Qualification and Selection of Open-Source Software)
L’ QSOS16 è un metodo sviluppato da Atos Origin per consentire la
qualificazione del software con l’integrazione delle caratteristiche dell’OSS e il
confronto formalizzato in base ai requisiti, al fine di fare una scelta definitiva. Il
processo generale di QSOS si compone di quattro fasi interdipendenti:
1. La fase di definizione che mira a individuare i fattori da prendere in
considerazione per le fasi seguenti.
2. La fase di valutazione che mira a raccogliere le informazioni riguardanti prodotti
dalla comunità OSS, l’obiettivo è quello di creare una carta d’identità (IC) per
ogni prodotto con le informazioni generali, i servizi disponibili, le funzionalità e
le specifiche tecniche.Tuttavia, la procedura di valutazione è troppo rigida.
3. La fase di qualificazione che mira a definire dei requisiti che riflettano i bisogni
e i vincoli relativi alla selezione dei prodotti.
4. La fase di selezione che mira alla elezione del prodotto che meglio risponde alle
esigenze dell’utilizzatore.
16 “Method for Qualification and Selection of the Enterprise: The open Source Maturity Model”, Atos Origin, version 1.6, accessed June 2007.
38
Figura 3 – Fasi del modello QSOS
Fase 1: Definizione
La fase di definizione mira a individuare i fattori da prendere in considerazione per le
fasi seguenti.
Gli elementi da valutare sono:
• Software families
• Tipo di licenza
o Proprietà
o Viralità
o Ereditarietà
• Tipo di comunità
o Sviluppo isolato
o Gruppi di sviluppatori
o Organizzazioni di sviluppatori
o Società commerciali
Fase 2: Valutazione
La fase di valutazione che mira a raccogliere le informazioni riguardanti prodotti dalla
comunità OSS, l’obiettivo è quello di creare una carta d’identità (IC) per ogni prodotto
dove vengono indicati i seguenti fattori:
• Informazioni generali:
o Nome del software
39
o Riferimenti, data di creazione, data di rilascio della id card
o Autore
o Tipo di software
o Breve descrizione
o Tipo di licenza
o Link al progetto (url)
o Sistemi operativi compatibili
o Fork’s origin
• Servizi esistenti
o Documentazione
o Numero di offerte di supporto commerciali
o Numero di offerte di training
o Numero di consulenti
• Aspetti tecnici e funzionali
o Tecnologia di implementazione
o Prerequisiti tecnici
o Funzionalità dettagliate
o Roadmap
• Sintesi
o General trend
o Commenti
Dopo la creazione delle carta di identità si descrive ogni release del prodotto in un foglio di
valutazione. Tale documento include informazioni molto più dettagliate delle identità card,
andando a specificare tutti gli aspetti che verranno ritenuti critici. Si assegna quindi un
punteggio da 0 a 2 a tutti i criteri. Tale punteggio, sarà poi utilizzato nello step quattro.
Fase 3: Qualificazione
La fase di qualificazione mira a definire dei requisiti che riflettano i bisogni e i vincoli relativi
alla selezione dei prodotti.
Un primo livello di selezione può essere definito sui dati delle id card.
Per esempio può essere definito un vincolo relativo al sistema operativo su cui il prodotto
deve funzionare. In generale, i requisiti non sono mandatari e non includono alcun fattore di
peso, il loro utilizzo serve solo per l’eliminazione dei fattori inadeguati raccolti nelle id card.
40
Fase 4: selezione
La fase di selezione mira alla selezione del prodotto che meglio risponde alle esigenze
dell’utilizzatore.
Sono possibili due diversi tipi di selezione:
• Strict selection: La selezione è fortemente restrittiva, si basa direttamente
sull’eliminazione diretta rimuovendo automaticamente i prodotti con identity card non
compatibili con i requisiti specificati nella fase 3 non appena una caratteristica di
prodotto non risponde completamente ai requisiti formulati.
• Loose selection: Questo metodo è meno rigido del precedente, invece di eliminare
direttamente i prodotti non eleggibili, crea una classifica assegnando un gaps ai
requisiti non pienamente soddisfatti.
La pesatura delle funzionalità è basata sul livello di requisito definito nella fase
precedente sotto forma di griglia funzionale:
Livello di requisito Peso
Funzionalità richiesta +3
Funzionalità opzionale +1
Funzionalità non richiesta 0
2.3.5 Modello OpenBQR (Open Business Quality Rating)
L’OpenBQR17 fonde ed estende OpenBRR e QSOS, introduce nuovi criteri di
valutazione e capovolge la procedura di selezione e di ponderazione dei prodotti, a
partire dal coefficiente di elementi basandosi sul peso, valutando gli elementi che
devono essere pesati.
L’OpenBQR mira ad essere un semplice modello, adattabile, e completo. Il
processo di valutazione può essere effettuata in tre fasi: la valutazione filtro, la raccolta
dei dati e dei processi e la visualizzazione dei dati.
Come in OpenBRR, l’OpenBQR nella prima fase individua un elenco di
elementi da valutare. A differenza di altri modelli, OpenBQR assegna un peso a ogni
elemento considerando cinque indicatori: l’uso del prodotto, l’analisi delle qualità
17 Taibi D., Lavazza L., Morasca S., “OpenBQR: a framework for the assessment of OSS”, The Third International Conference on Open Source System, Limerik, Ireland 11-14 June 2007
41
interne, l’analisi delle qualità esterne, la disponibilità di supporto nel tempo ed infine la
valutazione dei requisiti funzionali.
La seconda fase inizia con l’eliminazione di tutti gli elementi in cui il peso è pari
a zero o quasi. I pesi vengono normalizzati e imposto un punteggio base per indicare
l’importanza degli elementi.
Infine, ogni peso, è moltiplicato per il valore del punteggio, ottenendo un
risultato finale. Il punteggio finale per ogni prodotto può essere ottenuto sommando tutti
i punteggi.
Il passo finale previsto dal metodo OpenBQR è la visualizzazione dei dati con
una griglia contenente i risultati per ogni prodotto.
2.3.6 Modello MOSST (Model of Open Source Software Trustworthiness)
I modelli di valutazione OSS illustrati in precedenza contribuiscono alla
semplificazione della scelta di un nuovo prodotto OSS. Tuttavia, tali modelli hanno due
limitazioni: affrontano le questioni più tecniche tralasciando gli aspetti economici e
giuridici in materia di rilascio, nonché altri aspetti relativi ai processi di acquisizione,
sviluppo, integrazione.
Per venire incontro alle esigenze degli utenti OSS e favorire l’adozione di nuovi
prodotti, il progetto QualiPSo sta sviluppando un nuovo modello di valutazione per la
trustworthiness dell’OSS.
Il modello MOST è ancora in fase di definizione ma possiamo anticipare che
sarà basato principalmente sui risultati dell’attività svolta nel progetto QualiPSo.
2.4 Il progetto QualiPSo
Gli obiettivi del progetto QualiPSo sono stati quelli di scoprire quali sono i
fattori più comunemente utilizzati per valutare della fiducia di un prodotto OSS, capire
in che modo questi fattori sono correlati gli uni agli altri e ai tipi di organizzazioni, ai
tipi di prodotti OSS usati, e al profilo dell’ intervistato.
42
Il raggiungimento di questi obiettivi è stato molto importante per l’attività di
QualiPSo (Trustworthy Area)18.
In particolare, i risultati della ricerca sona la guida e la base dei seguenti
compiti: dei piani del GQM, l’individuazione di misure, i requisiti per la definizione di
strumenti di sviluppo, e la convalida dei fattori individuati sul campo.
Il progetto QualiPSo si propone di costruire un modello di fiducia per l’OSS,
destinato al fine di migliorare i modelli di valutazione esistenti semplificando la
selezione dei nuovi prodotti OSS. Tale modello sarà utile sia agli utenti che selezionano
un nuovo OSS, ai produttori dell’OSS per verificare la trustworthiness del proprio
prodotto.
Per raggiungere questo obiettivo, QualiPSo opererà in stretta collaborazione con
le principali comunità del software open, quali ad esempio QbjectWeb and Morfeo.
QualiPSo sviluppa attività di ricerca diretti alla definizione di metodi, processi di
sviluppo e modelli di business per l’implementazione e l’adozione di OSS sia da parte
di utenti finali che di sviluppatori di sistemi software. Progettazione e realizzazione di
un ambiente di sviluppo integrato per facilitare la collaborazione e la creazione di OSS
idoneo alle esigenze industriali. Implementazione di tool specifici per il testing e la
validazione di prodotti OSS. Identificazione e diffusione delle “best practices” nel
settore; sviluppo di ambienti di test e integrazione per dimostrare l’interoperabilità di
prodotti OSS ed infine valutazione delle tipologie di licenza OSS esistenti nell’ottica di
sviluppare un modello d licenza europeo
Qualipso prevede la realizzazione di 6 centri di competenza (4 in europa - a
Roma, Madrid, Berlino, e Parigi - uno in Cina e uno in Brasile) che opereranno in rete
quali punti di aggregazione di risorse e conoscenze in domini specifici
(dall’interoperabilità alla validazione di soluzioni OSS) ma anche come terminali per la
diffusione dei risultati del progetto.
Le amministrazioni pubbliche, utilizzando (ma anche commissionando
direttamente) soluzioni OSS, non solo possono meglio condividere le proprie esperienze
e ridurre tempi e costi di sviluppo dei propri sistemi, ma possono anche favorire la
creazione di un mercato software più dinamico ed efficiente, con un numero maggiore
di attori in grado di fornire servizi ad alto valore aggiunto a prezzi competitivi.
18 Free/Libre and Open Source Software: Survey and Study - International Institute of Infonomics, University of Maastricht - Final Report.
43
Con Qualipso sarà possibile approfondire lo studio di tali dinamiche ed
identificare combinazioni efficaci tra politiche del settore pubblico, modelli di business
e strategie di adozione del OSS.
In particolare, si contribuisce direttamente alla definizione di: modelli di
sviluppo e adozione di soluzioni OSS; approcci e metodologie per la documentazione e
validazione di prodotti OSS (sia a livello tecnico che organizzativo, ad esempio in
termini di tipologie di licenze d’uso) atti a supportarne il processo di selezione ed
eventualmente adozione.
Nei prossimi due capitoli verrà descritto il contributo dato al raggiungimento
degli obiettivi del progetto QualiPSo nella definizione del modello MOSST.
44
CAPITOLO 3
INDAGINE QUALITATIVA DEI PRODOTTI OPEN SOURCE
egli ultimi anni il software Open Source (OSS) è stato ampiamente
accreditato ed adottato, ma vi sono ancora numerose preoccupazioni
sulla fiducia del prodotto OSS. Tali dubbi hanno portato ad un più
basso tasso di adozione rispetto al previsto.
Ma cosa pensano gli utenti dell’OSS? L’obiettivo dell’indagine qualitativa sarà
quello di raccogliere e sintetizzare le informazioni in merito alla fiducia per un insieme
di prodotti Open Source, determinando i fattori che influenzano le decisioni delle
organizzazioni (private o pubbliche) nella scelta di adottare ed utilizzare un prodotto
OSS.
In particolare, i risultati riportati qui verranno utilizzati come base per definire la
fiducia dei prodotti OSS, in modo tale che essi risultino rilevanti e utili all’industria
europea del software.
L’obiettivo delle indagini è duplice: in primo luogo è necessario comprendere le
ragioni e le motivazioni che portano le società di software ad adottare o meno prodotti
OSS e capire quali fattori specifici sono presi in considerazione al momento della scelta
definitiva.
N
45
A tal fine:
• E’ stato definito un modello GQM che raccolga le misure oggettive da
applicare ai prodotti da analizzare;
• E’ stato definito un questionario che contiene un insieme di prodotti
OSS Java e C++ da valutare in riferimento ai fattori di qualità
precedentemente identificati.
• Sono state effettuate una serie di interviste mediante il questionario e
raccolto una serie di dati soggettivi.
• I dati raccolti dai questionari cartacei sono stai automatizzati e
memorizzati all’ interno di un data base dedicato.
• Sono state fatte delle analisi sul set di dati raccolti mediante il
questionari
• Creato delle correlazioni tra il set di dati soggettivi e i dati oggettivi.
Io mi sono principalmente occupato:
• Della definizione del questionario per le valutazioni dei prodotti;
• Della distribuzione e raccolta dei questionari;
• Della automatizzazione dei dati raccolti svilippando un data base
dedicato;
3.1 Il modello Goal Question Metric (GQM) per l'analisi oggettiva del prodotto
Il piano GQM19 serve a definire meglio l’utilizzo e le misure che caratterizzano
i modelli e i prodotti QualiPSo definendone la fiducia e l’impiego fra gli utenti finali.
Difatti uno dei principali aspetti che contribuiscono alla adozione o, al contrario,
al rifiuto, di un prodotto software è la fiducia del prodotto stesso. Questo vale per
qualsiasi software, ma è vero soprattutto per i prodotti OSS, la cui fiducia è a volte
ancora considerata da alcuni come non garantita.
Solo di recente molti organizzazioni industriali hanno avviato la valorizzazione
dei prodotti OSS; così come gli utenti o anche i produttori sono oggi sempre più
coinvolti nella valutazione della fiducia di tali beni, in modo da scegliere quelli che
19 Basili and D. Rombach, “The TAME project: towards improvementoriented software environments,” IEEE Transactions on Software Engineering, 1988, vol. 14, no. 6, pp. 758-773.
46
sono più adeguati per i loro obiettivi e per le loro esigenze. Per contribuire e
promuovere l’adozione, l’utilizzo e la produzione di OSS è quindi importante che le
organizzazioni produttrici di software20
diano la massima priorità nell’ambito delle
indagini, attraverso metodi di valutazione, e tecniche di valutazione indicative della
qualità dei prodotti OSS.
Nell’ambito del progetto QualiPSo molte interviste sono state effettuate per
sindacare l’apertura delle aziende nei confronti dei prodotti Open Source e della loro
funzionalità.
La fiducia verso i prodotti Open Source è stata valutata seguendo diversi
parametri e realizzando studi specifici su di essi. Tali strumenti di analisi sono stati
utilizzati per analizzare tutti i prodotti free software.
Naturalmente, la percezione di fiducia varia da un utente all’altro: per esempio,
l’utente A può essere perfettamente soddisfatto della funzionalità del prodotto X, mentre
l’utente B non ne sarà appagato perché utilizza il prodotto in modo diverso. La
funzionalità di un prodotto dipende, allora, dalla percezione che gli utenti finali hanno
della sua qualità, funzionalità, interoperabilità, affidabilità e prestazioni mostrata dallo
stesso. Tali qualità l’utente le desume anche dalla natura intrinseca del prodotto come ad
esempio dal modo in cui può essere utilizzato. Pertanto, l’affidamento può essere
ricavato dalla natura concettuale, dalla qualità individuale e operativa del modello e dal
modo in cui viene posta tale fiducia sul OSS.
Quindi efficienza ed utilità del prodotto seguono le sue esigenze e il tipo di
utilizzo. Ma come si ottengono questi risultati? Il metodo utilizzato si basa sulla raccolta
di una serie di misure a cui poi si cerca di dare un senso al di fuori di esse. Questo
permette di ottenere in particolar modo parametri chiari e precisi sull’utilizzo del
prodotto Open Source21.
Il GQM è stato proposto ed applicato come una tecnica sistematica per lo sviluppo di
un programma di misura per i processi di software ed i relativi prodotti. Esso si basa
sull’idea che i parametri devono essere orientati verso un obiettivo, vale a dire, tutti i
dati di raccolta dei dati in un programma di misurazione devono essere basati su una
logica esplicitamente documentata. Gli obiettivi sono quelli che derivano dalle
20 V. Basili, G. Caldiera, and D. Rombach, “Goal/Question/Metric Paradigm,” in En-cyclopedia of Software Engineering, vol. 1, J. C. Marciniak, Ed.:John Wiley & Sons, 1994, pp. 528-532.
21 Software Measurement Laboratory, “GQM Method”, on-line tutorial, Otto von Guericke Univerity Magdeburg, http://ivs.cs.uni-magdeburg.de/sw-eng/us/java/GQM/general1.shtml
47
specifiche esigenze contrattuali, quali, ad esempio, la Gestione dei Rischi, la
Conformità del Processo di Sviluppo agli obiettivi dell’Utente, ecc. e dalle indicazioni
stabilite dalla normativa, quali, ad esempio, per un progetto software, le caratteristiche
di qualità fissate dalla norma ISO 9126 . Il piano GQM, definisce una serie di parametri
utilizzati per raggiungere gli obiettivi organizzativi della produzione.
Per l’applicazione del modello, ciascuno degli obiettivi, denominato nel seguito
Goal, è articolato secondo il seguente schema:
• GOAL: obiettivo o caratteristica da valutare;
• QUALITY FOCUS: sotto obiettivo o sotto caratteristica di qualità associato al
Goal;
• QUESTION: domanda la cui risposta concorre a valutare il raggiungimento del
Quality Focus;
• METRIC: metrica che fornisce una risposta quantitativa alla Question a cui è
associata.
La seguente Figura 4 schematizza la struttura definita dal Modello:
Figura 4. Struttura definita dal Modello GQM.
48
Inoltre, ad ogni obiettivo individuato sono associate altre informazioni quali:
• lo Scopo per cui è preso in considerazione l’obiettivo in esame;
• il Punto di vista ossia il riferimento rispetto al quale è valutato l’obiettivo (es.
dal punto di vista dell’Utente, dello Sviluppatore, ecc.);
• l’Ambiente all’interno del quale è considerato l’obiettivo.
Tali obiettivi sono così sintetizzabili:
• studio della realtà;
• motivazione di studio dell’oggetto;
• caratteristiche degli oggetti che sono considerati nello studio.
La Question, o più in generale l’insieme di domande, deve essere rivolta a coprire tutti
gli aspetti caratteristici del Goal in esame. Inoltre, attraverso le risposte alle Question,
deve essere possibile ricavare misure (le cosiddette Metriche) sulle grandezze
osservabili dei prodotti intermedi e dei prodotti finiti del progetto. Tali Metriche,
confrontate con i rispettivi Valori di soglia, forniscono la valutazione di quanto si stiano
raggiungendo gli obiettivi prefissati.
Lo schema di misurazione definito con la metodologia GQM deve essere sottoposto ad
una verifica per controllarne la correttezza sintattica e semantica.
Per esempio, per verificare che il Modello ottenuto sia sintatticamente corretto,
possiamo applicare la seguente lista di controllo:
Domanda Risposta Attesa
Tutte le Question sono classificate per Goal? Si
Tutte le Question sono completate con le rispettive metriche? Si
Le descrizioni dei Goal, dei Quality focus, delle
Question e delle metric sono chiare? Si
Per ciascuna metrica è indicato il Metodo di
Derivazione? Si
Per ciascuna metrica è indicata l’unità di misura? Si
Per ciascuna è indicato il valore di soglia? Si
49
Analogamente, per verificare la correttezza semantica del Modello possiamo, ad
esempio, applicare la seguente lista di controllo:
Domanda Risposta Attesa
Tutte le Question sono rilevanti per i Goal selezionati? Si
Le relazioni ricavabili attraverso le Metric consentono di
rispondere in maniera esauriente a tutte le Question? Si
Le relazioni tra Question e Goal sono evidenti e plausibili? Si
Tutte le Metric sono operazionali? Si
Il Modello GQM, completato e verificato, definisce quali misure debbano essere
raccolte durante l’esecuzione del Monitoraggio, le quali dovranno essere raffrontate con
i rispettivi valori di soglia.
Il piano GQM per quanto riguarda il progetto QualiPSo è organizzato come
segue:
• Una prima parte del piano è dedicato per acquisire informazioni circa l’identità
del prodotto e del produttore;
• Una seconda parte è dedicata a raccogliere la percezione degli utenti sulla fiducia
del prodotto, sia a livello globale che a livello di qualità (ad esempio, la
funzionalità, l’affidabilità, la modificabilità);
• La terza, nonché l’ultima parte del piano è dedicata ad individuare le
caratteristiche di sicurezza e le proprietà del prodotto.
Il lavoro svolto mira, dunque, a trovare una correlazione tra la fiducia percepita
dall’utente e le proprietà del prodotto (che spesso può essere misurata in modo obiettivo
e quantitativamente).
I risultati completi hanno lo scopo di forniranno le basi per costruire modelli di
prodotti Open Source22 fidati e manufatti che sono in grado di spiegare le relazioni
22 V. del Bianco, L. Lavazza, S. Morasca, D. Taibi, “Analysis of relevant open-source projects and artifacts”, Working document wd 5.2.1, Version 0.1 - QualiPSo report, February 2008.
50
esistenti tra le caratteristiche dei prodotti OSS e il livello di fiducia percepita dagli
utenti di tali software.
3.2 Definizione del questionario per l'analisi soggettiva del prodotto
Abbiamo effettuato un sondaggio per raccogliere le valutazioni su alcuni
prodotti, in relazione al piano di GQM, perché sappiamo che gli utenti possono non
essere in grado di valutare tutti i prodotti OSS, in quanto ogni prodotto presenta troppe e
diverse caratteristiche qualitative.
Sono state poste alcune domande agli utenti, abbiamo chiesto loro di valutare la
fiducia complessiva dei prodotti e le qualità che presentavano, che si ritiene siano quelle
che più influenzano la fiducia, sulla base di una precedente indagine che abbiamo
effettuato tra le parti interessate sugli OS. Le domande poste agli utenti sul prodotto
Open Source effettuate mediante un questionario, hanno l’obiettivo di porre in evidenza
la fiducia dello stesso. Le ragioni di questa scelta sono date dal fatto che: i due aspetti
sono chiaramente collegati; che per i professionisti del software il tempo è un fattore
molto importante, quindi i questionari massimizzano la possibilità di ottenere delle
risposte da parte dagli operatori industriali.
Con il questionario, si cerca di ottenere delle risposte alle domande dettagliate
sulla situazione attuale dell’OSS e chiarire alcuni dei problemi menzionati sulla
valutazione della fiducia dell’OSS. Inoltre, si cerca di comprendere come l’OSS viene
percepito da persone provenienti da diverse aziende ICT e con ruoli diversi.
Il questionario è stato sviluppato considerando l’attuale letteratura sulla fiducia
dei prodotti OSS. Le domande presenti nel questionario possono essere classificate
principalmente in tre diversi categorie:
• Quelle relative al ruolo e all’ organizzazione, necessarie per capire il profilo
dell’intervistato, la società nella quale lavora e il progetto sul quale partecipa. Le
informazioni personali raccolte è costituita da nome, indirizzo email, ruolo,
mentre le informazioni raccolte, riguardanti l’organizzazione, consistono nel tipo
di organizzazione, nel numero di dipendenti, e il settore di applicazione di
interesse.
Le possibili risposte riguardo al ruolo sono:
o Upper management
51
o Project manager
o Developer
o Other
E le possibili risposte riguardo all’organizzazione:
o Public Administration
o Private
o No profit
• Quelle relative all’utilizzo del prodotto OSS, raccolte per capire l’uso specifico
dall’ OSS in una qualsiasi organizzazione: vogliamo capire quale versione del
prodotto viene utilizzata e se i prodotti che vengono dall’OSS sono utilizzati,
integrati o estesi. Mediante queste domande ci interessa capire se i prodotti OSS
sono utilizzati per sostenere lo sviluppo del software o come parte di altri
prodotti; sono personalizzati e configurati; sono utilizzati per sostenere il
processo interno; sono utilizzati per fornire servizi al mondo esterno.
Le possibili domande riguardo la versione del prodotto utilizzato sono:
o The last one
o A recent one
E le possibili domande riguardo alla relazione con il prodotto utilizzato:
o User of the product ‘as is’
o Integrator/Customizer
o Producer
o Other
• Quelle necessarie per identificare i principali fattori da prendere in
considerazione quando si valuta l’opportunità di adottare un prodotto OSS. In
particolare sono stati presi in considerazione i seguenti valori:
• Portabilità: la capacità del software di funzionare in ambienti diversi;
• Usabilità: il programma deve essere adeguato ai bisogni ed alle aspettative degli
utenti ed essere soddisfacente e non troppo complesso;
• Soddisfazione,
• Affidabilità: esprime l'esigua manifestazione di malfunzionamenti
52
• Interoperabilità: la capacità di un sistema di cooperare e di scambiare
informazioni con altri prodotti in maniera più o meno completa e priva di
errori, con affidabilità e con ottimizzazione delle risorse, facilitandone
l'interazione tra sistemi differenti
• Sicurezza: capacità del software di impedire accessi non autorizzati;
• Comunità di sviluppo;
• Efficienza: esprime i tempi di risposta, utilizzo della memoria, ecc;
• Documentazione;
• Fiducia verso l’OSS concorrenti;
• Fiducia verso i concorrenti produttori dei prodotti CSS.
Per la valutazione di ogni singolo fattore abbiamo usato una scala ordinale che
va da 1 a 6 per evidenziare il grado di gradimento che gli utenti hanno sui prodotti, dove
1 è la valutazione peggiore e 6 la valutazione migliore per una specifica qualità di un
prodotto. Le risposte possibili sono:
• 1 = assolutamente no;
• 2 = poco;
• 3 = sufficiente;
• 4 = più che sufficiente;
• 5 = molto / abbastanza;
• 6 = completamente.
L’idea è quella di non dare un preciso significato a questi numeri, ma fornire agli
intervistati un modo per dare la loro l’idea dell’importanza relativa a questi fattori.
Abbiamo utilizzato un questionario per chiedere ai nostri intervistati la qualità
percepita su 44 prodotti OSS divisi in 22 prodotti Java e 22 prodotti C++ (vedi
tabella1).
La raccolta dei dati è stata effettuata attraverso domande dirette con gli
intervistati. Si ritiene che questo è il modo più efficace per ottenere informazioni e
stabilire un giusto canale di comunicazione con gli utenti.
In appendice viene riportato il questionario utilizzato.
Tutte le interviste si sono svolte in modo individuale, è importante che gli
intervistati forniscano il proprio punto di vista, senza alcuna sorta di interferenza dovuta
dalla presenza di altre persone, specialmente se appartenenti alla stessa organizzazione.
53
Fino alla fine di gennaio 2010, abbiamo raccolto 100 questionari, contenente la
valutazione di 722 valutazioni, di cui circa il 36% riguardava prodotti di Java, mentre le
restanti riguardavano gli altri prodotti. Per maggiori dettagli vedi tabella 1.
Tabella 1. Valutazioni Raccolte
JAVA N°Questionari C++ N°Questionari
Checkstyle 10 Ant 25
Eclipse 63 Axis 5
Findbugs 10 BusyBox 17
Hibernate 22 CVS 32
HttpUnit 9 CygWin 23
Jack.Commons 4 DDD 6
Jasper Reports
16 GDB 20
JBoss 22 Gnu C Library
25
JFreeChart 11 Gnu GCC 32
JMeter 13 Lib XML 14
Log4J 28 Linux Kernel 55
PMD 7 Mono 9
Saxon 2 MySQL 59
Spring Framework
10 OpeLDAP 13
Sturt 15 Open Pegasus 2
Tapestry 1 Open SSL 31
TPTP 2 Perl 23
Velocity 3 PosgreSQL 20
Weka 2 SpiderMonkey 2
Xalan 9 SQLite 17
Xerces 13 Subversion 38
Servicemix 3 TCL/Tk 9
TOTALE 375 TOTALE 477
54
I questionari sono stati raccolti in occasione di importanti eventi internazionali
con la precisazione che non necessariamente trattano argomenti OSS, come riassunto
nella tabella 2.
Tabella 2. Questionari raccolti
Eventi Data (anno 2009) e
località Questionari
raccolti Valutazione dei prodotti
Apache Conference
March 24-27, Amsterdam, The Netherlands
15 31
OW2 Conference April 1-2, Paris, France
20 31
XP 2009 April 24-30, Pula, Italy
12 95
OSS 2009 June 2-5, Skovde, Sweden
2 5
ICSE 2009 May 15-20, Vancouver, Canada
9 69
CONFSL 2009 June 12-13, Bologna, Italy
3 27
QualiPSo Meeting
July 1-2, Madrid, Spain
6 38
ESC August 30-31, Venice, Italy
31 411
Others 2 15
La nazionalità degli intervistati comprende diversi paesi che partecipano al
progetto QualiPSo23 (Italia, Germania, Francia, Spagna, Polonia, Brasile, Regno Unito,
Cina) e altri due (Regno Unito e Stati Uniti d'America).
L’attuale campione è eterogeneo, non solo considerando la nazionalità degli
intervistati, ma anche prendendo in considerazione: il ruolo dell’intervistato; il tipo di
organizzazione dell’intervistato; il modo in cui il software libero è utilizzato dalla
persona intervistata.
23 Jeff Tian, Software Quality Engineering – Testing, Quality Assurance and Quantifiable Improvement : John Wiley & Sons, Inc. 2005, pag. 41.
55
3.3 La raccolta dei dati e la loro archiviazione
I dati raccolti nella fase precedente tramite i questionari cartacei devono essere
digitalizzati di modo da rendere più veloce il recupero dei dati che verranno utilizzati
per le successive fasi di analisi. Il miglior modo per permetterne l’utilizzo e
successivamente ricavarne misurazioni è quello di inserirli in un database. I dati
raccolti, prima di essere inseriti all'interno di un sistema di Database, vengono raccolti
in documenti Excel per facilitarne la raccolta e al fine di mantenerne una copia di
backup in maniera separata.
Il passaggio quindi si compone di tre fasi:
File excel : experimental_data
All'interno dei file Excel i dati vengono inseriti manualmente.
Data base: macximdb
Nell’ambito del progetto Qualipso esiste già un database contenente
informazioni riguardanti progetti Open Source e relative misurazioni oggettive ottenute
56
tramite il tool Macxim24. Per questo motivo si è deciso di estendere lo schema entità-
relazione (ER) esistente in modo che possa permettere l’archiviazione delle
informazioni sulle misurazioni soggettive ottenute tramite il questionario cartaceo.
Viene riportato in Figura 6, lo schema relazionale della base di dati del progetto
Qualipso:
Figura 6. Schema relazionale progetto QualiPSo
24 Home Page Macxim: http://qualipso.dscpi.uninsubria.it/macxim/
57
Lo schema originale, però, manca di una struttura per la memorizzazione delle nuove
informazioni raccolte. Lo schema precedente è stato esteso come mostrato in Figura 7,
aggiungendo le tabelle.
• USERS
• PERCEIVEDTRUSTWOTHINESS
Figura 7. Tabelle aggiuntive per le misure soggettive
58
Tabella USER
Nella tabella USERS vengono inseriti i dati personali relativi all’ intervistato che
riguardano le informazioni personali raccolte, quindi ogni campo di questa tabella fa
riferimento ad un intervistato. E’ costituita da nome, indirizzo email, ruolo, tipo di
organizzativa per il quale lavora, numero di dipendenti, settore di applicazione di
interesse e il numero di dipendenti per quel settore. Nella Tabella 3 è riportato una
descrizione completa dei campi di USER.
Tabella3. Descrizione tabella USER
Nome Campo Tipo Campo Descrizione Campo
Id Int(10)
Chiave interna (crea
collegamento con tabella
PERCEIVEDTRUSTWOTHINESS )
Name VARCHAR(255) Nome dell’intervistato
Email VARCHAR(255) Email dell’intevistato
Role
ENUM('Upper
Manager','Project
Manager','Developer','Us
er','End User','Other')
Ruolo dell’intevistao
OrganizationType
ENUM('Private','No
Profit','Public
Administration','Other')
Ruolo dell’organizzazione
OrganizationEmployersNu
m INT(11)
Numero degli impiegati
dell’organizzazione
OrganizationDomain VARCHAR(255) Domini dell’organizzazino
in cui lavora l’intervisato
UnitEmployersNum INT(11)
Numero degli impiegati che
lavorano con l’intervistato
nel dato dominio
Prod_ref INT(10)
Chiave esterna (crea
collegamento con tabella
OSS_PRODUCT)
59
Ha come chiave esterna il campo id, che si auto incrementa ogni volta che viene inserito
un nuovo utente e che ci permette di creare un collegamento con la tabella
PERCEIVEDTRUSTWOTHINESS che contiene le valutazioni fatte. E’ una
correlazione uno a molti, quindi per un intervistato esistono più valutazioni.
Tabella PERCEIVEDTRUSTWOTHINESS
Nella tabella PERCEIVEDTRUSTWOTHINESS vengono inseriti i dati relativi alle
valutazioni date dai singoli intervistati sui prodotti da noi indicati e da loro utilizzati in
base hai fattori da noi indicati. Vi sono anche i campi relativi ai dati che si riferiscono
all’utilizzo del prodotto cioè se sono utilizzati come sono, o vengono integrati o estesi.
Nel campo User_ref viene salvato l’id dell’intervistato, precedentemente inserito nella
tabella user, per creare il collegamento tra le due tabelle. Nella tabella 4 è riportato una
descrizione completa dei campi di PERCEIVEDTRUSTWOTHINESS.
Tabella 4. Descrizione tabella PERCEIVEDTRUSTWOTHINESS
Nome Campo Tipo Campo Descrizione Campo
Id INT(10) Chiave interna
User_ref
Product_Name VARCHAR(255) Nome del prodotto
valuato
YourFamiliarity
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della
familiarità che
l’ intervistato ha rispetto
al prodotto
Usability
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione dell’usabilità
percepita dall’intervistato
rispetto al prodotto
Portability
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della
portabilità percepita
dall’intervistato rispetto
al prodotto
FunctionalRequirem ENUM('Absolutely Valutazione della
60
entSatisfaction not','Little','Just enought','More
than enought','Very/A
lot','Completely')
funzionalità percepita
dall’intervistato rispetto
al prodotto
Interoperability
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione dell’
interoperabilità percepita
dall’intervistato rispetto
al prodotto
Reliability
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione
dell’affidabilità percepita
dall’intervistato rispetto
al prodotto
Security
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della
sicurezza percepita
dall’intervistato rispetto
al prodotto
DeveloperCommuni
tyUtility
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della
comunità di sviluppo
percepita dall’intervistato
rispetto al prodotto
Fastness
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione
dell’efficienza percepita
dall’intervistato rispetto
al prodotto
DocQuality
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della
documentazione
percepita dall’intervistato
rispetto al prodotto
Overall
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della fiducia
percepita dall’intervistato
rispetto ad prodotto
OssCompetitors ENUM('Absolutely
not','Little','Just enought','More
Valutazione della fiducia
percepita dall’intervistato
61
than enought','Very/A
lot','Completely')
rispetto al prodotto nei
confronti di altri prodotti
Oss
CssCompetitors
ENUM('Absolutely
not','Little','Just enought','More
than enought','Very/A
lot','Completely')
Valutazione della fiducia
percepita dall’intervistato
rispetto al prodotto nei
confronti di altri prodotti
Css
user_usage ENUM('Yes','Future','no') Indica se conosce il
prodotto valutato
user_used_version ENUM('last','recent') Versione del prodotto
valutato
user_product_relatio
nship
ENUM('end_user','customizer','pr
oducer','other')
Modo di utilizzo del
prodotto valutato
Inoltre, bisogna specificare che alcune delle valutazioni fatte, contenute nella
tabella PERCEIVEDTRUSTWOTHINESS non sono in correlazione con nessun
elemento della tabella user in quanto non vi è l’ obbligo di rispondere a tutte le
domande e quindi molti degli intervistati hanno preferito non rispondere alle domande
personali riferite al nome al ruolo e all’organizzazione di appartenenza.
Importazione dei dati
Per importare i dati dal file excel al data bese è stata sviluppata una procedura,
realizzata in java, che ci permette di andare ad estrarre i dati del file, connetterci al
database e mediante una apposita query di memorizzarli nel data base.
public class InsertData { private static BasicOperations basicOp= new BasicOperations(); /** * The driver class that implements the database functionality. */ private static final String jdbcDriver = "com.mysql.jdbc.Driver"; /**
62
* The string URI used to connect to the database. */ private static String jdbcURI; /** * Initialize the internal BasicOperations object. * @throws IOException */ public InsertData() throws IOException { basicOp = new BasicOperations(); if (jdbcURI == null) { jdbcURI = FileSystemUtils.getFileConfigurationProperty("MySqlAPI", "macximdb_jdbcURIString"); } } public void connect() throws SQLException, ClassNotFoundException { basicOp.connect(jdbcDriver, jdbcURI); } public void disconnect() throws SQLException { basicOp.disconnect(); } public void readDataToEcxel(String originalCSVFile) throws IOException, SQLException{ String filename = originalCSVFile; // Create an ArrayList to store the data read from excel sheet. List sheetData = new ArrayList(); FileInputStream fis = null; try { // Create a FileInputStream that will be use to read the excel file. fis = new FileInputStream(filename); // Create an excel workbook from the file system. HSSFWorkbook workbook = new HSSFWorkbook(fis); // Get the first sheet on the workbook. HSSFSheet sheet = workbook.getSheetAt(2); // When we have a sheet object in hand we can iterator on each // sheet's rows and on each row's cells. We store the data read // on an ArrayList so that we can printed the content of the excel // to the console. Iterator rows = sheet.rowIterator(); while (rows.hasNext()) { HSSFRow row = (HSSFRow) rows.next(); Iterator cells = row.cellIterator(); List data = new ArrayList(); while (cells.hasNext()) { HSSFCell cell = (HSSFCell) cells.next(); String cella = String.valueOf(cell); data.add(cella); }
63
sheetData.add(data); } } catch (IOException e) { e.printStackTrace(); } finally { if (fis != null) { fis.close(); } } showExelData(sheetData); } public static void ExelDataToDataBase(List sheetData) throws SQLException { String project = null,delete= null; int[] estimate= new int[13]; // Iterates the data and print it out to the console. for (int i = 2; i < (sheetData.size()-15); i++) { List list = (List) sheetData.get(i); if ((String)list.get(0)!=("")){ project = (String)list.get(0); System.out.println(i+" "+project); } delete= (String)list.get(1); if ((list.get(2)!= "") & !(delete.contains("Ave")) & !(delete.contains("Med")) ) { for (int j = 2; j < 15; j++) { if (((String)list.get(j)).contains("-")) estimate[j-2]=0; else estimate[j-2]= (int) (Double.parseDouble((String)list.get(j))); System.out.print(estimate[j-2]); } System.out.println(""); String values=""; // insert the estimate into the database for(int r=0; r<13;r++){ if (estimate[r]==0) values += "null,"; else values += (estimate[r]+ ","); } System.out.println(values); String sqlCommand="INSERT INTO perceivedtrustwothiness(YourFamiliarity, Usability,Portability,FunctionalRequirementSatisfaction,Interoperability,Reliability,Security,DeveloperCommunityUtility,Fastness,DocQuality,Overall,"OssCompetitors,CssCompetitors,Product_Name) VALUES (" + values + "'" + project + "')";
64
// The Query for inserting data into the data base. basicOp.DMLStatement(sqlCommand); } } } }
3.4 Estrazione dei dati, esempi di query per l'estrazione dei dati
Per l’ estrazione dei dati sono state create delle query. In questo paragrafo
faremo vedere alcune query eseguite per l’estrazione di alcuni dati per fare delle analisi. Analisi distribuzione ruolo:
E’ possibile vedere come sono distribuiti i dati raccolti in base al tipo di ruole
degli intervistati mediante la query:
SELECT COUNT(*) FROM macximdb.user
WHERE Role="Developer";
In questo modo otteniamo il numero di intervistati che hanno come ruolo Developer.
Andando poi a modificare il campo Role, con i possibili valori sopra descritti, riusciamo
ad ottenere il numero di intervistati che appartengono alle varie categorie riferite al
ruolo e andremo a fare una analisi statistica per vedere come sono distribuiti gli
intervistati.
Figura 8. Distribuzione in base al Ruolo
9%
31%
29%
31%Upper manager
Project manager
Developer
Other
65
I risultati riportati in Figura 8 dimostrano che i ruoli degli intervistati sono equamente
distribuiti tra i project manager, sviluppatori e altri, mentre abbiamo una bassa
percentuale per quanto riguarda gli Upper Manager.
Analisi distribuzione organizzazione:
E’ possibile vedere come sono distribuiti i dati raccolti in base al tipo di
organizzazione mediante la query:
SELECT COUNT(*) FROM macximdb.user
WHERE OrganizationType="Private";
In questo modo otteniamo il numero di intervistati che lavorano in un’ organizzazione
privata. Andando poi a modificare il campo OrganizationType, con i possibili valori
sopra descritti, riusciamo ad ottenere il numero di intervistati che appartengono alle
varie categorie riferite all’organizzazione e andremo a fare una analisi statistica per
vedere come sono distribuiti gli intervistati.
Dai risultati visibili in figura 9 si nota che la maggior parte degli intervistati è
impiegato nella pubblica amministrazione, mentre una parte minore ma significativa è
occupata in organizzazioni private e organizzazioni no profit.
Figura 9. Distribuzione in base all’ Organizzazione
25%
61%
14%
Public
Administrator
Private
Other
Analisi sulla versione del prodotto: E’ possibile vedere come sono distribuiti i dati raccolti in base alla versione del prodotto
OSS utilizzato mediante la query:
66
SELECT COUNT(*) FROM macximdb.perceivedtrustwothiness p
WHERE user_used_version="last";
In questo modo otteniamo il numero di intervistati che utilizzano l’ultima versione del
prodotto OSS valutato. Andando poi a modificare il campo user_used_version, con i
possibili valori sopra descritti, riusciamo ad ottenere il numero di intervistati che
utilizzano l’ultima versione, la precedente versione e che non hanno indicato quale
versione utilizzano. Andremo poi a fare una analisi statistica per vedere come sono
distribuiti gli intervistati.
Dai risultati visibili in figura 10 risulta che la maggior parte degli intervistati non ha
indicato quale versione utilizza. Comunque risulta che il numero di utenti che utilizzano
l'ultima versione del prodotto è maggiore, anche se di poco, del numero di utenti che
utilizza l'ultima versione del prodotto.
Figura 10. Distribuzione in base alla versione utilizzata
27%
29%
44% Last One
Resent One
Null
Analisi sull’ utilizzo del prodotto:
E’ possibile vedere come sono distribuiti i dati raccolti in base al tipo di utilizzo del
prodotto OSS mediante la query:
SELECT COUNT(*) FROM macximdb.perceivedtrustwothiness p
WHERE user_product_relationship="producer";
67
In questo modo otteniamo il numero di intervistati che producono il prodotto OSS
valutato . Andando poi a modificare il campo user_product_relationship, con i possibili
valori sopra descritti.
Figura 11. Distribuzione in base all’utilizzo del prodotto OSS
64%8%
1%
27% User of the product'as is'Integrator/Customizer
Producer
Other
La maggior parte degli intervistati, come si vede dalla figura 11, utilizza i prodotti OSS
così come sono, una più piccola ma significativa utilizza i prodotti OSS come altro,
mentre sono molto pochi gli sviluppatori e coloro che vanno ad integrare il prodotto.
68
CAPITOLO 4
RISULTATI DELL'INDAGINE
ll’ interno di questo capitolo vedremo come QualiPSo utilizza i
risultati ottenuti dal questionario per determinare la distribuzione di
fiducia dei prodotto Open Source, un confronto tra la fiducia dei
prodotti Open Source e quella dei prodotti concorrenti Closed Source e l’individuazione
delle caratteristiche che influenzano la percezione della fiducia, sulla base di una
rigorosa analisi statistica.
E’ importante studiare come la qualità dei prodotti OSS viene percepita dagli
utenti, e se ci sono fattori di qualità specifici che si ritiene necessario migliorare.
Come abbiamo detto precedentemente l'obiettivo principale del progetto
QualiPSo è come valutare i prodotti OSS sulla base della fiducia.
I ricercatori di QualiPSo hanno studiato i fattori che si ritiene di ritenere
attendibili, da un certo numero di soggetti interessati, e poi hanno scoperto la
dipendenza riferita ad altre qualità e caratteristiche del software.
A
69
Per dimostrare la validità di tale modello concettuale e dotarlo di modelli sicuri,
sono stati utilizzati sia le valutazioni soggettive sia quelle oggettive di OSS.
Le valutazioni soggettive sono riferite a quelle raccolte mediante questionari,
tale indagine ha dimostrato che la maggioranza (56%) dei prodotti OSS sono considerati
molto fidabili.
Qui descriveremo il risultato delle analisi svolte da ricercatori del progetto
Qualipso.
4.1 La popolarità dei prodotti
Un primo risultato dell’ indagine riguarda la popolarità dei prodotti OSS
selezionati.
Poiché gli utenti sono stati invitati a rispondere in merito ai prodotti che
conoscevano abbastanza bene, il numero delle valutazioni ricevute da un prodotto può
essere considerato come un’ indicazione ragionevole della sua popolarità.
La figura 12 illustra il numero totale di valutazioni per ogni prodotto e il numero
di valutazioni con famigliarità maggiore di una data soglia per tale prodotto.
I risultati riportati in figura 12 mostrano che i prodotti più popolari sembrano
essere MySQL, Eclipse e il Linux Kernel.
Si è quindi proceduto a valutare se la popolarità potrebbe essere spiegata in
termini di tipo di prodotto ( sistemi di gestione di database verso sistemi di gestione
della configurazione, ecc.)
Tuttavia, non c’è stata nessuna di queste relazioni.
Si ritiene, di avere ottenuto un buon risultato, dato che sembra indicare che gli
utenti hanno valutato la qualità effettiva dei prodotti, indipendentemente dalla loro
tipologia e target.
70
Figura 12. Numero degli intervistati per ogni prodotto e familiarità per ogni
prodotto.
0 10 20 30 40 50 60
Tapestry
Open Pegasus
Saxon
SpiderMonkey
TPTP
Weka
Servicemix
Velocity
Jack.Commons IO
Axis
DDD
PMD
Xalan
HttpUnit
Findbugs
Mono
Spring Framework
TCL/Tk
Checkstyle
JFreeChart
Xerces
JMeter
Jasper Reports
OpeLDAP
Struts
Lib XML
SQLite
BusyBox
Hibernate
JBoss
PosgreSQL
GDB
Perl
CygWin
Ant
Log4J
Gnu C Library
Open SSL
Gnu GCC
CVS
Subversion
Linux Kernel
Eclipse
MySQL
Total users
Familiar users
4.2 La trustworthiness dei prodotti Open Source
La figura 13 mostra la media delle valutazioni degli utenti per ogni prodotto.
71
Sull’asse x sono elencati i 32 prodotti per i quali abbiamo raccolto abbastanza
dati da parte degli utenti che hanno familiarità sufficiente col prodotto.
In altre parole, il termine "Prodotti" è una variabile nominale.
Sembra che gli utenti sono in genere molto soddisfatti con i prodotti OSS e
paiono avere fornito valutazioni equilibrate e affidabili.
Figura 13. Fiducia complessiva dei prodotti valutati
Products
Me
dia
n(T
rustw
ort
hin
ess
)
0 5 10 15 20 25 30
3.0
3.5
4.0
4.5
5.0
4.2.1. Open Source vs. Closed Source
Gli utenti sono stati invitati a votare la fiducia di ogni singolo prodotto rispetto a
prodotti Open source simili e rispetto a prodotti Closed Source.
Questi voti sono illustrati nella figura 14.
Una prima osservazione suggerita dalla figura è che in generale i progetti
valutati sono altamente fidabili sia per quanto riguarda gli OSS, sia la concorrenza CSS.
In realtà, entrambi i punteggi vengono posizionati prevalentemente nella
sezione che va dal 4 al 5.
E’ quindi possibile osservare che i prodotti CSS e i prodotti OSS sono
considerati di qualità equivalente in 21 dei 32 casi (65,6%), anche se generalmente
inferiore rispetto ai prodotti OSS considerati.
72
Questo risultato sembra confermare che la scelta di prodotti OSS per effettuarne
una valutazione è stata buona, in quanto i prodotti in questione sono generalmente
considerati ben posizionati rispetto all’ OSS ed ai CSS.
Figura 14. Fiducia complessiva dei prodotti valutati rispetto a prodotti OSS
simili e prodotti CSS (mediane al prodotto considerato).
Products
Trust wrt CSSTrust wrt OSS
0 5 10 15 20 25 30
3.0
3.5
4.0
4.5
5.0
5.5
6.0
Tru
st_
vs_
OS
S_
me
dia
n
In soli 9 casi su 32 (33%),i prodotti OSS sono migliori rispetto alle alternative
CSS (questo è il caso in cui la linea rossa è sopra la linea tratteggiata blu), mentre solo
in 2 casi su 32 (6% ) le alternative CSS sono considerate migliori di quelle OSS.
Con la figura 14 l’impressione trasmessa è che la comunità degli utenti
riconosce fiducia ai prodotti OSS, prendendo in considerazione le alternative OSS e
CSS e considerandole come sostanzialmente equivalenti.
4.3 La qualità dei prodotti OSS
Nel progetto QualiPSo, abbiamo studiato le qualità che i prodotti OSS devono
avere in base agli utenti.
A seguito di tali indicazioni, abbiamo costruito un modello concettuale di
fiducia dei prodotti OSS che si propone di spiegare come il sub prodotto OSS (in base
73
all’utilità, sfruttabilità in fase di sviluppo, funzionalità, affidabilità) concorre alla
determinazione della fiducia percepita dagli utenti.
Tale modello è definito attraverso un piano di GQM, che coinvolge anche le
caratteristiche oggettivamente misurabili di prodotti OSS.
L’idea è che, quando i dati sono sufficienti, si può costruire un modello che
spiega in che misura le qualità soggettivamente percepite di un prodotto OSS dipendono
dalle sue caratteristiche interne.
I dati qui riportati sono il risultato della raccolta dei dati (riguardanti
esclusivamente le valutazioni soggettive) effettuati nell’ambito della realizzazione del
piano di GQM.
La figura 15 illustra la distribuzione delle valutazioni di prodotti diversi per
ciascuna qualità di indagine.
Figura 15. Qualità dei prodotti valutati.
usability portability functionality interoperab. reliability security efficiency trustworth.
3.0
3.5
4.0
4.5
5.0
5.5
6.0
Per questa analisi, sono stati considerati solo i prodotti valutati da almeno 10
utenti e con una familiarità minima pari alla sufficienza verso il prodotto finale OSS.
Per ogni qualità dei prodotti valutati, la casella rappresenta l’intervallo che
comprende metà della popolazione intervistata, il segmento di spessore rappresenta la
media rilevata.
Una prima osservazione suggerita dalla figura 15 è che tutte le qualità sono tra
4.0 e 5.0.
74
Inoltre, mentre l’affidabilità globale è valutata molto bene (vedi anche figura
13), gli utenti sono stati più critici con altre qualità, come l’usabilità, l’interoperabilità,
la sicurezza e l’efficienza, che sono indicati in gradi inferiori di fiducia.
E’ interessante notare che la sicurezza, la quale è di solito positivamente
correlata con la fiducia, non è particolarmente ben valutata, anche se la maggior parte
dei prodotti sono classificati “più che sicuri”.
La figura 16 riporta la media sulle documentazione disponibile ed il sostegno
della comunità degli sviluppatori.
Questo è un aspetto piuttosto rilevante, dal momento che gli utenti di prodotti
OSS spesso hanno bisogno di fare affidamento esclusivamente sulla documentazione
disponibile o sul sostegno della comunità degli sviluppatori, al fine di ottenere
informazioni o risolvere problemi riguardanti i prodotti OSS.
Figura 16. Qualità di supporto dei prodotti valutati.
2.0
2.5
3.0
3.5
4.0
4.5
5.0
documentation community support trustworthiness
Il valore medio di supporto agli utenti è valutato “più che sufficiente” in
generale.
La documentazione, che è spesso considerata un punto debole di OSS, è stata
valutata bene dagli utenti, mentre il sostegno de parte della comunità degli sviluppatori,
che generalmente si crede un punto di forza degli OSS è stata considerata tenue per i
diversi prodotti.
La figura 17 mostra che i quattro prodotti più popolari sono anche tra quelli
considerati più affidabili.
75
In ogni caso, non esiste alcuna correlazione tra la popolarità e la credibilità; per
esempio, molti prodotti Open Source hanno una scarsa popolarità ma sono poi
considerati molto affidabili.
Figura 17. Fiducia e popolarità a confronto
0
5
10
15
20
25
30
35
40
45
50
MyS
QL
Eclip
se
Lin
ux K
ern
el
Su
bve
rsio
n
CV
S
Op
en
SS
L
Lo
g4
J
Gn
u G
CC
Gn
u C
Lib
rary
GD
B
Cyg
Win
Pe
rl
Po
sg
reS
QL
An
t
Bu
syB
ox
JM
ete
r
Hib
ern
ate
JB
oss
JF
ree
Ch
art
Lib
XM
L
SQ
Lite
Str
uts
Ch
ecksty
le
Ja
sp
er R
ep
ort
s
Op
eL
DA
P
Xe
rce
s
PM
D
Sp
rin
g F
ram
ew
ork
TC
L/T
k
Fin
db
ugs
Http
Un
it
Mo
no
Familiar users
Trustworthiness
4.4 Fiducia in relazione al linguaggio
Abbiamo raccolto le opinioni degli utenti sui prodotti scritti con un linguaggio di
programmazione in Java e C++.
Si è studiato se il linguaggio di programmazione influisce sulla fiducia percepita
dall’utente.
La figura 18 riassume le distribuzioni delle valutazioni di fiducia per programmi
scritti in C++ e programmi scritti in Java.
Mentre il 64% dei prodotti di Java sono classificati come “molto attendibili”,
solo il 50% del C++ sembrano ottenere tali stima.
Secondo la figura 18, i programmi Java sembrano essere leggermente migliori
rispetto alla fiducia dei programmi scritti in C++.
76
Ma non è possibile affermare che vi è una dipendenza di fiducia sul linguaggio
di sviluppo del software.
Figura 18. Confronto globale della fiducia dei prodotti valutati a seconda del
linguaggio di programmazione.
3.0
3.5
4.0
4.5
5.0
Java C++
Tru
stw
ort
hin
ess
77
CONCLUSIONI
a valutazione oggettiva della fiducia e della qualità dei prodotti
software è alla base per garantire una larga diffusione dei prodotti
Open Source. In tal senso, sono stati fatti molti tentativi per affrontare
la questione sulla valutazione della qualità del software in generale, e in particolare per i
prodotti OSS.
Tuttavia, in mancanza di modelli oggettivi, gli utenti contano su proprie
valutazioni soggettive quando decidono di adottare, o meno, un prodotto Open Source.
In questo lavoro di tesi è stato definito un questionario ed effettuato un
sondaggio per la raccolta di dati utili per studiare la percezione di fiducia che hanno gli
utenti su un certo numero di prodotti OSS.
Mi sono principalmente occupato della realizzazione del questionario cartaceo,
della distribuzione del questionario, della raccolta dati e della loro archiviazione.
E’ stato realizzato un questionario selezionando 22 prodotti Java e 22 prodotti
C++ e le qualità da valutare per ogni singolo prodotto, ottenute mediante un modello
GQM precedentemente studiato, per la raccolta di misure soggettive relativa alla qualità
percepita da utenti di prodotti OSS.
Il questionario è stato distribuito alle conferenze direttamente a persone che
ricoprono ruoli diversi in diverse aziende in modo da rappresentare una più vasta fascia
di utenti.
È stato chiesto agli utenti OSS i diversi aspetti specifici di qualità,
rappresentando quindi non solo la percezione generale di fiducia, ma anche la
L
78
percezione di affidabilità, l’interoperabilità, l’efficienza, l’usabilità e la documentazione
dei prodotti OSS.
I dati raccolti, tramite i questionari cartacei, sono stati memorizzati in un data
base dedicato.
Sono state fatte delle analisi su com’è distribuita la popolazione degli intervistati
e la popolarità dei prodotti selezionati.
I dati raccolti attraverso i questionari, sono stati utilizzati all’interno del progetto
QualiPSo per studiare la popolarità dei prodotti selezionati, l’influenza del linguaggio di
programmazione verso la fiducia percepita, e se i prodotti OSS sono classificati meglio
dei prodotti CSS. Le indagini fatte e le analisi statistiche effettuate hanno permesso di
evidenziare come gli utenti percepiscono la qualità di un campione rappresentativo di
prodotti Java e C++.
I risultati emersi nel progetto QualiPSo sembrano fornire prove a favore
dell’esistenza di un insieme di correlazioni statistiche tra i concetti di qualità e fiducia
che hanno gli utenti su un certo numero di prodotti Open Source, e il set di misure
oggettive calcolabili a partire dai prodotti stessi.
Un lavoro futuro comprenderà l’attività di raccolta di dati supplementari
concernenti le valutazioni di prodotti Open Source, la raccolta di dati sulle qualità
aggiuntive che possono essere di interesse, la realizzazione di studi per verificare se
esistono correlazioni tra alcune caratteristiche strutturali di OSS (ad esempio la
dimensione, la complessità strutturale) e le qualità esterne, il tutto utilizzando le
informazioni sui profili degli intervistati per costruire modelli più precisi per classi
specifiche di soggetti interessati a tali prodotti.
79
Bibliografia
Ippolita, Open non è free. Comunità digitali tra etica hacker e mercato globale,
Eleuthera, 2005.
Pekka Himanen, L’etica hacker e lo spirito dell’età dell’informazione, 2001, Feltrinelli.
Arturo Di Corinto, Revolution OS II. Software libero, proprietà intellettuale, cultura e
politica, Apogeo Editore, 2005.
Mariella Berra, Angelo Raffele Meo, Informatica solidale. Storia e prospettive del
software libero, 2001, Bollati Boringhieri.
Steffen Evers, An Introduction To Open Source Software Development, FLP, Giugno
2000
David A. Wheeler, Why Open Source Software / Free Software (OSS/FS)? Look at the
Numbers!, Febbraio 2003.
Angelo Gallippi, Dizionario di informatica e multimedialità (inglese - italiano),
TECNICHE NUOVE, Milano 2001.
Muffato M., Faldani M. , Open Source: Strategie, organizzazione, prospettive , Mulino
2004.
Raymond E., The Cathedral and the Bazaar , O'Reilly 2001.
Golden B. , Succeeding with Open Source, Addison Wesley 2004.
Muffato M., Faldani M. , Open Source: Strategie, organizzazione, prospettive , Mulino
2004.
DiBona C.; Ockman S.; Stone M.,Open Sources. Voci dalla rivoluzione Open Source,
Apogeo, 1999.
Richard M. Stallman, Free Software, Free Society: Selected Essays of Richard M.
Stallman, Boston, 2004.
R. Borruso, La tutela giuridica del software. Diritto d’autore e brevettabilità, Giuffrè,
2000.
80
Luigi Buglione, Misurare il software. Quantità, qualità, standards e miglioramento di
processo nell'Information Technology, 2008.
Jeff Tian, Software Quality Engineering - Testing, Quality Assurance and Quantifiable
Improvement : John Wiley & Sons, Inc. 2005.
ISO/IEC 9126-1:2001 “Software Engineering—Product Quality—Part 1: Quality
model”, June 2001.
D. Taibi, L. Lavazza, S. Morasca, “OpenBQR: a framework for the assessment of
OSS”, Open Source Software 2007, Limerick, June 2007.
Del Bianco, V., Chinosi, M., Lavazza, L., Morasca, S., Taibi, D. “How European
software industry perceives OSS trustworthiness and what are the specific criteria to
establish trust in OSS”, QualiPSo report, October 2008.
Vieri del Bianco, Luigi Lavazza, Sandro Morasca and Davide Taibi, “Quality of
Open Source Software: the QualiPSo Trustworthiness Model”, The 5th International
Conference on Open Source Systems OSS09, 3-6 June 2009, Skövde, Sweden.
Shapiro, S. S.; Wilk, M. B. (1965). "An analysis of variance test for normality
(complete samples)". Biometrika 52 (3-4): 591–611.
A. Tawileh, O. Rana and S. McIntosh, “A Social Networking Approach to F/OSS
Quality Assessment”, Proceeding of the International Conference on Computer
Mediated Social Networking (ICCMSN’08), Dunedin, New Zealand, June 2008.
TOSSAD, “Annex5 – Survey Report”. Web published:
www.tossad.org/publications/. Accessed: 14/12/2009.
Eclipse, “The Open Source Developer Report”. Web published:
http://www.eclipse.org/org/press-release/Eclipse_Survey_2009_final.pdf. May 2009.
Accessed: 14/12/2009.
QualiPSo project portal. http://www.qualipso.org.
Atos Origin, “Method for Qualification and Selection of Open Source software (QSOS),
version 1.6”, http://www.qsos.org/download/qsos-1.6-en.pdf
“Business Readiness Rating for Open Source - A Proposed Open Standard to
Facilitate Assessment and Adoption of Open Source Software”, BRR 2005 - RFC 1,
http://www.openbrr.org.
“Making Open Source Ready for the Enterprise: The Open Source Maturity Model”,
from “Succeeding with Open Source” by Bernard Golden, Addison-Wesley, 2005,
available form http://www.navicasoft.com
81
Audris Mockus, Roy T. Fielding,James D. Herbsleb “Two case studies of open
source software development: Apache and Mozilla”, ACM Trans. Softw. Eng.
Methodol., vol. 11, n. 3, 2002.
Audris Mockus, David Weiss, “Interval quality: relating customer-perceived quality
to process quality, International Conference on Software Engineering 2008, Leipzig,
Germany, May 2008.
Audris Mockus, Ping Zhang, Paul Luo Li, “Predictors of customer perceived
software quality”, International Conference on Software Engineering 2005, St Louis,
May 2005.
82
Sitografia
http://www.notiziariogiuridico.it/software1.html
http://www.pluto.it/files/ildp/doc-it/intro-swlibero/
http://www.fsf.org
http://www.fsf.org/licensing/essays/free-sw.html
http://opensource.org/docs/osd
http://opensource.org
http://www.gnu.org/copyleft/copyleft.html
http://www.gnu.org/copyleft/gpl.html
http://www.microsoft.com
http://www.stallman.org/
http://opensource.org/licenses/bsd-license.php
http://www.gnu.org
http://www.nongnu.org/cvs/
http://Freshmeat.net
http://Rubyforge.org
http://ossmole.sourceforge.net/
http://sourceforge.net/
https://zerlot.cse.nd.edu/
http://zerlot.cse.nd.edu/mywiki/
http://www.seriouslyopen.org/
http://www.openbrr.org
http://www.qsos.org
http://www.taibi.it/openbqr
http://ossmole.sourceforge.net/
https://zerlot.cse.nd.edu/mywiki/index.php?title=FAQ#Date_Format
http://support.intel.com/support/processors/pentium/fdiv/wp/
http://www.dicom.uninsubria.it/qualipso/doku.php?id=literature_reviews
83
http://www.dicom.uninsubria.it/qualipso/doku.php?id=characteristics_os_projects
http://www.dicom.uninsubria.it/qualipso/doku.php?id=floss_repositories
http://www.dicom.uninsubria.it/qualipso/doku.php?id=quantitative_analysis_of_open_s
ource_projects_on_sourceforge
Appendice
PLEASE FILL IN THE SURVEY AND GIVE IT BACK TO THE RECEPTION
YOUR OPINION WILL BE VERY
USEFUL TO THE OSS COMMUNITY
Qualipso Survey – The Trustworthiness of Open Source Product
www.qualipso.org
Why This Survey? The purpose of this survey is to elicit information from the users and developers of Open Source Software (OSS) products about their perceptions on the trustworthiness of OSS products and the related factors. Who Are We? This survey has been developed in the framework of the QualiPSo (Quality Platform for Open Source Software) project, which is a European Union-funded Integrated Project which aims at making a major contribution to the state of the art and practice of Open Source Software. The QualiPSo project started in November 2006 and will last until October 2010. The project brings together 18 software companies, application solution developers, and research institutions. Its goal is to define and implement technologies, procedures, and policies to leverage the Open Source Software development current practices to sound, well-recognized, and established industrial operations. What Will Happen to the Questionnaires? All information provided by each individual or organization will be treated as confidential. As such, it will not be released in other form than aggregated statistical analyses that will make it impossible to identify the single respondents. Please do not hesitate to contact us if you need any information or clarification. Sandro Morasca Università degli Studi dell’Insubria Dipartimento di Scienze della Cultura, Politiche e dell’Informazione Via Carloni 78 I-22100 Como, Italy [email protected]
84
85
