VERSO UN PROCESSO DI CERTIFICAZIONE DEI PORTALI WEB DI PROGETTI SOFTWARE OPEN SOURCE

Transcript

1 VERSO UN PROCESSO DI CERTIFICAZIONE DEI PORTALI WEB DI PROGETTI SOFTWARE OPEN SOURCE Lavazza, Luigi, Università degli Studi dell'insubria, via Mazzini 5, Varese Morasca, Sandro, Università degli Studi dell'insubria, via Carloni 11, Como Taibi, Davide, Università degli Studi dell'insubria, via Carloni 11, Como Tosi, Davide, Università degli Studi dell'insubria, via Carloni 11, Como Abstract Il Software Open Source (OSS) ha conosciuto negli ultimi anni una crescente popolarità; ciononostante, una grossa parte dei potenziali utenti continua a non fidarsi di alcuni prodotti OSS a causa della mancanza di dati affidabili sulla qualità dei prodotti OSS. Il fenomeno è legato principalmente al fatto che i portali che ospitano i progetti OSS raramente offrono le informazioni sufficienti ad una adeguata analisi preliminare del prodotto. Contrariamente al software proprietario, dove la pubblicizzazione, la sponsorizzazione e gli aspetti comunicativi e di marketing rivestono un ruolo prioritario nel processo di sviluppo e promozione del prodotto software, spesso i portali OSS non forniscono le informazioni essenziali necessarie agli utenti per poter valutare la qualità e la trustworthiness del prodotto OSS. Nel mondo OSS esistono innumerevoli portali di progetti in cui non viene nemmeno riportata la finalità e la tipologia del prodotto, che invece si rivela spesso di buona qualità. Questo porta l utente finale, che naviga nel portale web del prodotto e che non ha il tempo o le competenze tecnologiche per valutare in modo approfondito la qualità reale del prodotto software, ad avere una percezione distorta e sommaria rispetto alla qualità del prodotto stesso. Prendendo spunto dai concetti di usabilità definiti per il web da W3C e attraverso numerose interviste che abbiamo somministrate agli utenti OSS, al fine di identificare le informazioni che gli utenti finali considerano importanti per una valutazione preliminare di un prodotto OSS, è stato possibile definire una mappa di informazioni e di dati che ogni portale web dovrebbe avere per descrivere in modo usabile e preciso il proprio prodotto OSS. La mappa derivata è stata direttamente applicata ai portali di 32 progetti OSS per valutare il grado di corrispondenza tra le necessità espresse dagli utenti e la reale espressività dei portali analizzati. L analisi ha permesso di evidenziare che la maggior parte dei portali di prodotti OSS non soddisfa le esigenze degli utenti, sia in termini di presenza delle informazioni legate al prodotto sia in termini di facile reperibilità di questi dati. In questo articolo si propone un approccio alla certificazione di prodotti OSS a partire da un punto di vista diametralmente opposto ai modelli di certificazione esistenti e in fase di definizione. Nello specifico, non si vuole certificare il prodotto studiandone i fattori tecnologici, di processo e qualitativi che lo caratterizzano, ma si vuole studiare la maturità dei portali che ospitano il prodotto così come viene percepita dall utente finale. Nell articolo, verranno brevemente riportati i dati relativi all analisi condotta su 32 progetti OSS, verrà descritta la mappa di riferimento per la valutazione dei portali, e verrà introdotto un modello di certificazione della qualità dei portali di prodotti OSS basato sulla presenza delle informazioni che gli utenti considerano rilevanti durante la valutazione di un prodotto OSS. In primo luogo, il modello potrà essere utilizzato dai produttori di OSS per verificare la qualità del proprio portale e la capacità di proporsi in modo efficace e completo alla comunità stessa. In secondo luogo, il modello potrà essere il punto di partenza per identificare le mancanze informative del proprio portale e per migliorare in modo strutturato le informazioni da presentare. Parole Chiave: Qualità, Trustworthiness, Certificazione

2 1 INTRODUZIONE Contrariamente al software proprietario, dove gli aspetti comunicativi e di marketing rivestono un ruolo prioritario nel processo di sviluppo e promozione del prodotto software, spesso i portali OSS non forniscono le informazioni essenziali necessarie agli utenti per poter valutare la qualità del prodotto OSS sotto osservazione. Nel mondo OSS esistono innumerevoli portali di progetti in cui non viene nemmeno riportata la finalità e la tipologia del prodotto, che invece dopo una sua attenta analisi e un suo uso si rivela spesso di buona qualità. Questo porta l utente finale, che naviga nel portale web del prodotto e che non ha il tempo o le competenze tecnologiche per valutarne la qualità reale, ad avere una percezione distorta e sommaria della qualità del prodotto stesso. In questo articolo si vuole discutere un modello preliminare di certificazione che possa essere utilizzato sia dagli utenti finali per valutare in modo oggettivo le caratteristiche qualitative del prodotto OSS, sia dai produttori di OSS per verificare la qualità informativa del proprio portale e la capacità di proporsi in modo efficace e completo alla comunità stessa. Il modello potrà poi essere utilizzato dai produttori per identificare le mancanze informative del proprio portale e per migliorare in modo strutturato le informazioni da presentare agli utenti. Verrà riportato un insieme di informazioni di riferimento per la valutazione dei portali, introducendo un modello preliminare di certificazione della qualità dei portali di prodotti OSS basato sulla presenza delle informazioni che gli utenti considerano rilevanti durante la valutazione di un prodotto OSS e che di conseguenza devono essere facilmente reperibili sui portali web che ospitano il prodotto. Verranno brevemente riportati i dati relativi all analisi dei portali web condotta per 32 progetti OSS con particolare riferimento al contenuto informativo che ogni portale ha e dovrebbe avere per essere un portale usabile e di qualità. 2 RELATED WORK Recentemente, con l'aumentare del numero di applicazioni OSS disponibili nel web, si è sollevata la necessità di definire nuovi metodi di valutazione dell'oss. I principali modelli di valutazione, nati in questi anni, sono l'open Source Maturity Model (OSMM) [G05], il Qualification and Selection of Open Source Software (QSOS) [Atos04] e l'open Business Readiness Rating (Open BRR) [OpenBRR05], successivamente esteso dall'open Business Quality Rating (OpenBQR) [TLM07]. Tutti i metodi di valutazione sono basati sulla valutazione soggettiva di un insieme di fattori attraverso l'analisi dei portali web. L'OSMM è uno standard aperto con l'obiettivo di facilitare l'adozione dell'oss sulla base della valutazione di alcuni aspetti di maturità del software quali il prodotto software in se, la documentazione, il supporto fornito, l'eventuale disponibilità di training e l'integrazione di componenti di terze parti. Il QSOS amplia l'insieme dei fattori da valutare introducendo nuove aree di valutazione quali la qualità della documentazione e della comunità di sviluppo. L'OpenBRR ed OpenBQR aggiungono ulteriori fattori (come per esempio la valutazione della comunità OSS) migliorando ulteriormente la qualità della valutazione. Correia e Visser [CV08] propongono un metodo per la certificazione della qualità dell'oss. Il metodo di certificazione utilizza un modello a livelli basato sull'iso/iec Tale modello, così come i metodi di valutazione dell'oss, è stato sviluppato al fine di comprendere la qualità generale del prodotto a partire dalla valutazione di un insieme di fattori predefiniti. Nel 2001 e' stato proposto un primo schema di certificazione per la qualità dei siti web delle pubbliche amministrazioni italiane [MSR01] con l'obiettivo di comprendere la semplicità di utilizzo e l'utilità di tali siti dal punto di vista degli utenti finali. Lo schema di certificazione proposto è basato su un insieme di caratteristiche che i portali delle pubbliche amministrazioni dovrebbero pubblicare. Tale insieme è stato definito attraverso un indagine su 30 istituzioni italiane considerando la qualità dei contenuti dei siti web, l'usabilità e l'accessibilità. Un altro campo rilevante per questo studio è la certificazione dei siti web. Allo stato attuale esistono due categorie di certificazione: quella legata agli standard di programmazione e quella legata all'accessibilità / usabilità. Il World Wide Web Consortium (W3C), fondato nel 1994 da Tim Berners- Lee, si occupa della definizione di standard, linee guide, tecnologie e protocolli con l obiettivo di

3 rendere il contenuto della rete accessibile a tutte le persone indipendentemente dalla condizione fisica, lingua, cultura, hardware, software e dispositivo utilizzato. Le certificazioni W3C sono rivolte a tutte le possibili applicazioni web, dalla semplice certificazione XHTML [W3C00] dove viene verificata l'aderenza allo standard xhtml, alla certificazione dell'accessibilità e per finire a quella dei web service dove viene verificata l'aderenza ai protocolli di comunicazione standard. Nel 2008, il W3C ha rilasciato la seconda versione della Web Content Accessibility Guideline (WCAG) con l'obiettivo di fornire un singolo standard condiviso per l accessibilità dei contenuti web che incontri le necessità dei singoli, delle organizzazioni e dei governi da un punto di vista internazionale. La WCAG indica che un sito deve rispettare dodici linee guida suddivise in base a quattro principi: percepibile, utilizzabile, comprensibile, robusto e prevede dei criteri di successo che variano da A ad AAA. L'usabilità è definita dall'international Organisation for Standardisation (ISO) come l'efficacia, l'efficienza e la soddisfazione con le quali gli utenti raggiungono determinati obiettivi in determinati contesti. Alcuni studi hanno mostrato problemi di usabilità di Sourceforge ( Arnesen et al. [ADI+00] hanno descritto numerosi problemi di navigazione in Sourceforge legati principalmente all'organizzazione dei menu di navigazione e all'organizzazione delle informazioni. Successivamente, Un altro studio condotto da Pike et al. [PGU03] ha delineato altri problemi di usabilità di Sourceforge e del portale della Free Software Foundation ( attraverso tecniche di eye tracker basate su modelli key stroke [CMN83]. Tutti i principali metodi di valutazione, ad esclusione dell'openbqr, analizzando sempre tutti i fattori, indipendentemente dalla loro rilevanza. In un lavoro degli autori [DelBCL+07], nell'ambito del progetto europeo QualiPSo, è stato definito, attraverso 151 interviste somministrate agli utenti OSS, l'insieme di fattori che gli utenti stessi ritengono più importanti durante la valutazione di prodotti OSS. Sono stati intervistati utenti con profili diversi (upper manager, project manager, sviluppatori...) al fine di comprendere le reali necessità di ogni utente. Successivamente, in [DelBLM+08] sono stati analizzati 32 progetti in modo da valutare la presenza delle informazioni ritenute necessarie dagli utenti OSS. Allo stato attuale, la maggioranza dei prodotti OSS non forniscono questi dati. Il nostro modello si propone quindi di certificare la presenza di tali informazioni sui portali dei prodotti OSS. 3 IL SISTEMA DI CERTIFICAZIONE PROPOSTO Per poter definire l'insieme di informazioni che sono rilevanti alla comunità OSS, si è definito un set di fattori che hanno un reale impatto sulla qualità e sul grado di trustworthiness dei prodotti OSS. Si è poi intervistato un campione di 151 utenti del mondo OSS per capire la loro opinione rispetto ai fattori identificati nel modello e si è chiesto di attribuire un peso da 1 a 8 (1=fattore trascurabile, 8=fattore essenziale) ad ogni fattore. Sulla base dei risultati ottenuti dalle interviste è stato possibile definire un insieme di informazioni e dati che dovrebbero essere sempre presenti sui portali dei prodotti OSS per garantire una corretta interpretazione delle finalità del prodotto e dei suoi aspetti di qualità [DelBCL+07]. In Tabella 1 vengono riportate le informazioni considerate dagli intervistati, con il relativo grado di importanza. Le informazioni indicate nella parte superiore della Tabella 1 sono considerate le più importanti dagli utenti OSS e di conseguenza dovrebbero essere le informazioni che trovano maggior visibilità e spazio sul portale web del prodotto. La presenza di tali informazioni può essere determinante per l'adozione o meno di un prodotto OSS. Tuttavia, come evidenziato in [DelBLM+08], tali informazioni non sono quasi mai reperibili sui portali web. Per questo si vuole suggerire il modello di certificazione in oggetto quale sistema per rendere più semplice e strutturata la pubblicazioni delle informazioni rilevanti al fine di favorire l'adozione dei prodotti OSS. Un ulteriore problema, abbastanza comune e relativo alla presenza delle informazioni suddette, è legato anche alla fruibilità delle informazioni stesse. Spesso i portali sono molto complessi e poco usabili e risulta difficile trovare ciò di cui si ha bisogno. A tal fine, il processo di certificazione si compone sia della definizione delle informazioni che si vogliono fornire che della verifica della fruibilità delle informazioni stesse.

4 3.1 Il processo di Certificazione Il primo passo del processo di certificazione è l'identificazione e la definizione delle informazioni che si devono pubblicare per il proprio prodotto affinché l utente finale possa facilmente reperire e valutare un sottoinsieme delle informazioni mostrate in Tabella 1. Più informazioni verranno fornite più alta sarà la probabilità che il prodotto verrà valutato correttamente dall'utente e successivamente adottato. Risulta ovvio che se l'utente si trova a dover scegliere tra due prodotti qualitativamente equivalenti, il prodotto che è anche supportato da informazioni chiare, ricche e ben strutturate risulta essere vincente rispetto ad un prodotto privo di queste informazioni. Le informazioni mostrate in Tabella 1 sono definite ad un alto livello di astrazione. Per ogni informazione, bisogna definire un insieme di indicatori utili alla valutazione della singola informazione. Considerando per esempio la prima riga della Tabella 1 requisiti funzionali, il portale deve mostrare un insieme di indicatori che siano sufficientemente dettagliati al fine di permettere all'utente finale la valutazione imparziale dei propri requisiti funzionali. Un esempio di insieme di indicatori per i requisiti funzionali può essere: (1) descrizione del prodotto, (2) elenco delle sue caratteristiche, (3) requisiti hardware e software necessari per la sua corretta installazione, e (4) librerie utilizzate. Il grado di certificazione rispecchierà quindi il contenuto informativo che il portale web sarà in grado di esporre del proprio prodotto OSS. Un portale con un'indicazione chiara e precisa dei requisiti del prodotto, dei suoi aspetti di affidabilità, manutenibilità, interoperabilità, modularità, e con una ricca documentazione utente e tecnica, avrà un alto grado di certificazione e presumibilmente anche un alto livello qualitativo. Al contrario, un portale sprovvisto di queste informazioni basilari, riceverà un basso grado di certificazione con una conseguente bassa percezione della sua qualità. Una volta definite le informazioni da mettere a disposizione, bisogna progettare l'interfaccia del portale nel modo più usabile possibile. L'obiettivo è quello di far sì che tutti gli utenti, anche i meno esperti, riescano a trovare tutte le informazioni in breve tempo, senza perdersi in gerarchie di menù infinite. In questo articolo non si vuole definire uno schema di usabilità bensì focalizzare l'attenzione dei web designer dei portali OSS sul problema della fruibilità delle informazioni. Un buon indicatore per comprendere la complessità nel ritrovamento delle informazioni da parte degli utenti è il Keystroke-Level Model (KLM). Il KLM è un metodo che può essere utilizzato per stimare il tempo necessario per completare un semplice compito di data input o di ricerca dei dati, utilizzando un computer ed un mouse. L'utilizzo del KLM è utile per rendersi conto dei passi necessari per ottenere tutte le informazioni richieste. Semplificando il processo KLM, al fine di valutare la fruibilità delle informazioni, è sufficiente chiedere ad un utente che non conosce il prodotto in oggetto di compilare la Tabella1 indicando le informazioni necessarie in ogni riga. Il rapporto tra il tempo impiegato e il numero di informazioni trovate correttamente è un buon indicatore per la valutazione della fruibilità delle informazioni stesse. 3.2 Applicabilità del processo Al fine di verificare l'applicabilità del modello di certificazione proposto, abbiamo utilizzato il modello identificato su portali web noti e abbiamo verificato la presenza delle informazioni richieste su un campione di 32 progetti OSS. In Tabella1 (colonna 3) vengono mostrati il numero di progetti in cui è possibile trovare le informazioni richieste. L'analisi è stata fatta navigando nei portali dei progetti OSS, e annotando manualmente le informazioni trovate. Per ragioni di spazio, in Tabella1 è stato indicato solo il numero di progetti in cui è possibile identificare e valutare l'informazione richiesta. La versione completa dell'analisi è disponibile in [DelBLM+08]. Dall'analisi sono stati evidenziati numerosi problemi di usabilità dei portali: la durata media dell'analisi è stata di 4 ore a progetto (8,5 minuti ad informazione), con un massimo di 6 ore (12,8 minuti ad informazione) ed un minimo di 45 minuti (1,6 minuti ad informazione). Questa è la prova della complessità di navigazione dei portali. Sono stati riscontrati problemi di suddivisione delle informazioni nella maggior parte dei portali, presenza di troppi menù, spesso fuorvianti, e la mancanza di una mappa del sito nella maggior parte dei portali analizzati. Inoltre, molte delle informazioni di grande interesse per gli utenti finali (come per esempio: Esistenza di una comunità di utenti da

5 medio/lungo termine - data di inizio ) non sono reperibili sui portali o spesso, se indicate, vengono trattate marginalmente e in modo approssimativo così da non permettere una valutazione completa e strutturata dell informazione. E' interessante notare come il 25% delle informazioni (7 su un totale di 28) non siano mai state trovate analizzando i 32 progetti OSS. Inoltre l'analisi ha dimostrato come anche i prodotti di qualità (come per esempio Apache Httpd) non sempre sono corredati da portali con un insieme sufficiente di informazioni (il portale di Apache Httpd riporta poco meno del 50% delle informazioni necessarie ad una valutazione corretta del prodotto). Informazioni richieste Importanza Descrizione completa del prodotto per la valutazione dei requisiti Funzionali 8 11/32 Affidabilità 7 8/32 Manutenibilità 7 7/32 Interoperabilità 7 10/32 Disponibilità di documentazione utente 7 30/32 Disponibilità di documentazione tecnica 6 2/32 Modularità 6 18/32 Utilizzo di architetture standard 6 11/32 Rispetto degli standard 6 10/32 Esistenza di una comunità di utenti da medio/lungo termine (data di inizio) 6 Non Trovato Performance 5 15/32 Usabilità 5 9/32 Disponibilità di supporto a breve termine 5 Non Trovato Licenza utilizzata 5 32/32 Riusabilità 3 Non Trovato Disponibilità di strumenti specifici per lo sviluppo e la customizzazione del prodotto 5 10/32 Portabilità 4 15/32 Disponibilità di best practices 3 17/32 Disponibilità di diverse localizzazioni 3 15/32 Self containedness 3 15/32 Utilizzo di design patterns 3 6/32 Uniformità del linguaggio di programmazione 3 25/32 Disponibilità di training 3 20/32 Complessità 3 Non Trovato Esistenza di benchmarks / test suites 3 5/32 Esistenza di un maintainer a medio lungo termine 2 Non Trovato Security 2 Non Trovato Dimensione del prodotto 1 Non Trovato TOTALE (28 informazioni richieste) 127 N. Di progetti che supportano la valutazione dell'informazione Tabella 1. Le informazioni considerate dagli utenti durante la valutazione di un prodotto OSS 4 CONCLUSIONI I portali dei prodotti OSS sono le vetrine di ogni prodotto. In questo articolo abbiamo analizzato i problemi relativi alla mancanza di informazioni nei portali stessi evidenziando le informazioni che i produttori di OSS dovrebbero fornire e abbiamo introdotto un semplice metodo per la valutazione della complessità del proprio portale. Successivamente è stata verificata l'applicabilità del processo ad un insieme di progetti maturi. Tutti i portali sono risultati molto complessi. Il paradosso ritrovato è che anche i prodotti maturi hanno spesso portali poco informativi. Tale problema può essere dovuto al fatto che la comunità è molto attenta allo

6 sviluppo del prodotto ma non cura la propria immagine. L'applicazione del modello in oggetto ad un portale OSS eviterebbe molte perdite di tempo nella valutazione di un prodotto OSS e, in certi casi, un prodotto con un portale ben fatto potrebbe essere scelto rispetto ad un altro con un portale dove le stesse informazioni non vengono fornite. Ringraziamenti Il lavoro presentato in questo articolo è stato svolto nell'ambito del progetto IST QualiPSo, cofinanziato dalla Unione Europea, sesto Programma Quadro (IST ). Bibliografia [G05] Golden, B. (2005). Making Open Source Ready for the Enterprise: The open Source Maturity Model. Extracted from "Succeeding with Open Source, Addison-Wesley. [OpenBRR05] OpenBRR.org BRR RFC 1. (2005). Business Readiness Rating for Open Source. Available on-line: [Atos04] Atos Origin. (2004). Method for Qualification and Selection of open Source software (QSOS). Available on-line: [TLM07] Taibi, D., Lavazza, L. e Morasca, S. (2007). OpenBQR: a framework for the assessment of Open Source Software. Open Source Software Conference. Limerick. [DelBCL+07] Del Bianco, V., Chinosi, M., Lavazza, L., Morasca, S. e Taibi, D. (2007). How European software industry perceives OSS trustworthiness and what are the specific criteria to establish trust in OSS. QualiPSo report (October). [DelBLM+08] Del Bianco, V., Lavazza, L., Morasca, S. e Taibi, D. (2008). Analysis of relevant open source projects and artefacts, QualiPSo repor (October). [CV08] Correia, J.P. e Visser, J. (2008). Certification of technical Quality of Software. OpenCert Workshop. Italy. [MSR01] Minelle, F., Stolfi, F. e Raiss, G. (2001). A proposal for a certification scheme for the Italian Public Administration web sites quality. W3C Euroweb Conference. Italy. [CMN83] Card, S.K., Moran, T.P. e Newell, A. (1983). The Psychology of Human-Computer Interaction. Erlbaum Associates Inc. [ADI+00] Arnesen, L.P., Dimiti, J.M., Ingvoldstad, J., Nergaard, A. e Sitaula, N.K.(2000). Sourceforge: Analysis, evaluation and improvements. University of Oslo report. [PGU03] Pike, C., Gao, D. e Udell, R. (2003). Web Usability Analysis Report. School of Information Sciences and Technology. Pennsylvania State University. [W3C00] W3C. XHTML 1.0. (2000). The Extensible HyperText Markup Language (Second Edition) - W3C Recommendation. Revised 1 August Available on-line: [W3C08] W3C. (2008). Web Content Accessibility Guidelines (WCAG). W3C Recommendation. Available on-line: