Prima pagina » Tesi di laurea
 
Analisi delle caratteristiche dei progetti open source
Tesi PDF Stampa E-mail
Scritto da Michele Proto   

 

Analisi delle caratteristiche dei progetti Open Source

 

 

Abstract

 

Il lavoro di tesi, si propone l’obiettivo di analizzare i software open source presenti in uno dei maggiori repository on line: sourceforge.net, ed il loro processo produttivo, partendo dai metodi di valutazione esistenti e sfruttandone le caratteristiche comuni. Sui progetti viene fatta una valutazione analitica delle qualità dei prodotti (bugs, patches e documentazione), dell'attività delle comunità che ruotano intorno a questi software (sviluppatori, release e donazioni), nonchè del supporto a breve termine. Lo studio mostra, tramite dati e report un'analisi di massima dei progetti di sourceforge. Infine vengono mostrate le problematiche riscontrate nel reperire e gestire i dati dei software open source.

 

 

Riassunto

 

Il filone di attività della tesi ricalca gli interessi comuni del progetto QualiPSo (Quality Platform for Open Source Software), al fine di contribuire alla crescita del mondo del software Open Source definendo e implementando tecnologie e procedure inerenti tali software. Scopo del lavoro è stato quello di individuare ed analizzare i parametri fondamentali utilizzati per valutare i prodotti open source presenti all’interno del repository di SourceForge. Lo studio utilizza le caratteristiche degli attuali metodi di valutazione ampliate con altre mai introdotte in precedenza e che in seguito verranno inserite all’interno di metodi costruiti per automatizzare il processo di valutazione dei progetti open source. L’analisi viene eseguita inizialmente sull’intero database del repository, per passare successivamente ad osservare un intervallo di sei mesi, raggruppato per settimane (scelta arbitraria ma comunque rappresentativa di un andamento su un periodo sufficientemente lungo) al fine di comprendere quali variazioni hanno nel tempo le caratteristiche studiate. Da queste fasi preliminari sono state estrapolate le caratteristiche dei prodotti studiati: bugs, patches, release, documentazione, sviluppatori, donazioni, nascita di nuovi progetti e download. Lo studio inizialmente si è scontrato con l’impossibilità di poter utilizzare i dati di FLOSSmole (progetto open source che mette a disposizione alcuni dati del CVS Sourceforge) e per questo si è deciso di usare le informazioni contenute del database di Notre Dame (stessa finalità di FLOSSmole ma con dati più pertinenti). L’analisi ha mostrato immediatamente una scelta infelice nella progettazione del meccanismo di tracking di SourceForge, perché di default i bugs, le patches, le release etc, se non espressamente specificato, sono assegnate al livello di priorità cinque (SourceForge utilizza nove livelli di priorità), facendo crescere di molto le componenti di questa categoria. Ma ciò, nel caso dei bugs, espone i prodotti ad un controllo “superficiale”, perché gli sviluppatori, non potendo discriminare “a vista d’occhio” i problemi critici (quelli con i livelli più alti), potrebbero preferire continuare lo sviluppo del progetto piuttosto che controllare periodicamente la scoperta di problemi critici. Lo studio dei bugs ha permesso di capire che questi ultimi sono distribuiti in ordine crescente di stabilità dei prodotti (SourceForge classifica i prodotti in cinque livelli prealpha, alpha, beta, stabile e maturo) fino al livello stabile, mentre i progetti maturi presentano mediamente un numero di bugs molto inferiore. Di contro, analizzando le patches rilasciate, abbiano notato che i progetti ricevono anche loro un numero di miglioramenti crescenti finché non si raggiunge l’ultimo livello di stabilità (maturo) i quali non ricevono più un cospicuo numero di componenti aggiuntivi, ma, essendo ormai i prodotti consolidati, ricevono maggiormente solo le correzioni dei bugs scoperti. Inoltre, continuando lo studio dei bugs, è emerso che gli sviluppatori tendono a risolvere prima i problemi (bugs) sui progetti con una stabilità maggiore (comportamento che ci aspettavamo) e successivamente si “dedicano” a sviluppare soluzioni per i software appena nati. Un risultato opposto a quello che ci si aspettava è stato ottenuto studiando il tempo medio di soluzione dei bugs, infatti è stato evidenziato che non appena i progetti vengono dichiarati maturi, subiscono una sorta di abbandono e il tempo medio di soluzione aumenta in misura maggiore rispetto agli altri. Un altro risultato inatteso si è avuto nello studio della documentazione, perché è emerso che all’interno di SourceForge è inserita poca documentazione. Infatti, in valore assoluto i documenti presenti confrontati con il numero di progetti gestiti da SourceForge (circa 130.000 al momento in cui si è stato compiuto lo studio) rappresentano appena il 10%. C’è da dire (ad onor del vero), che un’analisi fatta fuori da SourceForge, ha mostrato che molte comunità forniscono la documentazione del proprio progetto direttamente dal proprio sito, usando il CVS espressamente per lo sviluppo ed il download. Questo lavoro di tesi ci ha permesso di capire che la strada intrapresa è quella giusta, infatti una prima sensibilizzazione potrebbe essere fatta verso le comunità che sviluppano i sistemi di tracking al fine di evitare i problemi visti con quello di SourceForge (si ricordi infatti la cattiva gestione di assegnamento alla priorità intermedia). Inoltre i problemi riscontrati ci hanno permesso di comprendere quali caratteristiche migliorare per effettuare analisi più pertinenti, come ad esempio la centralizzazione dei dati in un unico database e l’accesso diretto allo stesso.

 

 

Le slides proposte alla commisione

 

 

Dalle slides, si possono vedere alcuni grafici che mostrano i risultati dello studio.

 

 

 

 Bibliografia

 

  • Elena Grandi, Introduzione al mondo del Software Libero e dell’Open Source
  • Richard M. Stallman, Free Software, Free Society: Selected Essays of Richard M. Stallman
  • Lawrence Lessig, Cultura libera. Un equilibrio fra anarchia e controllo, contro l'estremismo della proprietà intellettuale
  • Di Bona, Ockman, Stone, Open Sources. Voci dalla rivoluzione Open Source
  • R. Borruso, La tutela giuridica del software. Diritto d’autore e brevettabilità
  • D.Taibi, L.Lavezza, S.Morasca. OPENBQR: A Framework for the assessment of the q.s.s. In proceding OSS2007
  • Jeff Tian, Software Quality Engineering – Testing, Quality Assurance and Quantifiable Improvement : John Wiley & Sons, Inc. 2005
  • Luigi Buglione, Misurare il software. Quantità, qualità, standards e miglioramento di processo nell'Information Technology
  • Karl Fogel, Open Source Development With Cvs
  • Fuggetta, A., Open source software, an evaluation, The Journal of Systemsand Software
  • Perry Donham, Ten Rules for Evaluating Open Source Software
  • Stamelos I., Angelis L., Oikonomou A., Bleris G., Code quality analysis in open source software development, Systems J,
  • Cignoni Giovanni, De Risi Piero, Il test e la qualità del software : Un modello per lo sviluppo, il controllo di qualità e l'attività di test del software
  • Casambenti Walter, Progetto Qualisoft
  • Capiluppi A., Lago P., Morisio M., Characteristics of Open Source Prjects
  • Weiss D., Quantitative Analysis of Open Source Projects on SourceForge

 

Sitografia:

 

 

 

 










Locations of visitors to this page