UNIVERSITÀ DEGLI STUDI DELL INSUBRIA Facoltà Di Scienze Matematiche, Fisiche e Naturali Sede di Varese Laurea Specialistica in Informatica

Transcript

1 UNIVERSITÀ DEGLI STUDI DELL INSUBRIA Facoltà Di Scienze Matematiche, Fisiche e Naturali Sede di Varese Laurea Specialistica in Informatica OP2C: UNA PROPOSTA DI CERTIFICAZIONE DEI PORTALI CHE OSPITANO PRODOTTI OPEN SOURCE Relatore: Prof. SANDRO MORASCA Relatore Esterno: Prof. LUIGI LAVAZZA Correlatore: Dott. DAVIDE TAIBI Correlatore Esterno: Dott. DAVIDE TOSI Laureando: Gabriele BASILICO matricola Anno Accademico

2 EXECUTIVE SUMMARY Open Source Software (OSS) communities do not often invest in marketing strategies to promote their products in a competitive way. Even the home pages of the web portals of well-known OSS products show technicalities and details that are not relevant for a fast and effective evaluation of the product s qualities. So, final users and even developers, who are interested in evaluating and potentially adopting an OSS product, are often negatively impressed by the quality perception they have from the web portal of the product and turn to proprietary software solutions or fail to adopt OSS that may be useful in their activities. In this thesis, after analyzing the literature of the sector, we define an evaluation model and we derive a checklist that OSS developers and web masters can use to design their web portals with all the contents that are expected to be of interest for OSS final users. We exemplify the use of the model by applying it to the Apache Tomcat web portal.[35]

3 INDICE EXECUTIVE SUMMARY... I INDICE... I INDICE FIGURE...V INDICE TABELLE...VII INTRODUZIONE... 1 Contesto applicativo... 2 Obiettivi della tesi... 3 Approccio al problema... 3 Struttura della tesi... 3 LA VALUTAZIONE DEL SOFWARE OPEN SOURCE La fiducia nell OSS La valutazione del OSS Il modello OSMM Il Modello OpenBRR Il Modello QSOS Il Modello OpenBQR Il modello di trustworthiness QualiPSo Conclusioni I

4 USABILITÀ Attributi Usability e User interface L usabilità nello sviluppo di un software La strada verso l usabilità Come migliorare l usabilità L usabilità non è un lusso L usabilità nel modello ISO Lo standard ISO/IEC Il progetto MiLE Il decalogo di Nielsen Conclusioni IL MARKETING DELL OSS Le 3 fasi di evoluzione del marketing Il piano di marketing Il successo di un prodotto OSS OP2C: Open Source Product and Portal certification Il modello OP2C Funzionamento e livelli di certificazione Valutazione e Refactory del portale di Apache Tomcat CONCLUSIONI Sviluppi futuri BIBLIOGRAFIA SITOGRAFIA II

5 APPENDICE A : DOCUMENTAL CHECK LIST OP2C - DOCUMENTATION INDEX... I INTRODUCTION How to collect information To do... 2 PROJECT INFORMATION AVAILABILITY Overview Features Requirements License Documentation Downloads Quality reports Community & Support USABILITY EVALUATION GUIDELINES Visibility of system status Match between system and the real world User control and freedom Consistency and standards Error prevention Recognition rather than recall Flexibility and efficiency of use Esthetic and minimalist design III

6 3.9 Help users recognize, diagnose, and recover from errors Help and documentation APPENDICE B : DOCUMENTAL CHECK LIST OP2C APPENDICE C : DOCUMENTAL CHECK LIST OP2C Apache TOMCAT APPENDICE D : TABELLA INFORMAZIONI RITENUTE IMPORTANTI DAGLI UTENTI APPENDICE E: OP2C: TOWARDS THE CERTIFICATION OF OPEN SOURCE PRODUCT PORTALS ICWE IV

7 INDICE FIGURE Figura 1: Tabella per la valutazione della maturità del software... 9 Figura 2: Pesatura di default degli elementi secondo il modello OSMM Figura 3: OSMM template Figura 4: Le quattro fasi del modello BRR Figura 5: Fase 3 e 4 del BRR Figura 6: Le 4 fasi del QSOS Figura 7: Esempio schema di valutazione Figura 8: Graglia di valutazio per 3 prodotti Figura 9: Grafico comparativo di tipo radar Figura 10: Usability Process Figura 11: ISO Figura 12: Schema del processo di valutazione Figura 13: Fasi e attività del processo di valutazione Figura 14: Relazioni Figura 15: Le 3 attività del progetto MiLE Figura 16: L'analisi tecnica è la seconda fase del processo di valutazione dell usabilità Figura 17: La User Experience Inspection è la seconda fase del processo di valutazione dell usabilità Figura 18: Esempio di visibilità gerarchica dello stato del sistema [1] Figura 19: Non cambiare l'ordinestandard degli elementi Figura 20: È spesso importante specificare tempi e dimensione del download. [19] Figura 21: L'icona del calendario aiuta l'utente a destreggiarsi nel sito.[19] Figura 22: I comandi da tastiera sono un buon esempio di flessibilità d'uso. [19] Figura 23: Il messaggio aiuta l'utente a capire dove ha sbagliato e come correggere l'errore. [19] Figura 24: I due aspetti del processo di marketing. [29] V

8 Figura 25: Il processo di pianificazione di marketing. [29] Figura 26: Matrice di Ansoff. [29] Figura 27: Classifica dei mercati - Mercato di Acquisto. [29] Figura 28: Classifica dei mercati - Mercato Potenziale. [29] Figura 29: Il ciclo PDCA (Plan, Do, Check, Act). [27] Figura 30: Modello di DeLone e McLean per l'analisi del successo di un prodotto nel campo dell'information System [20] Figura 31: Annuncio pubblicitario del nuovo browser Mozzila Firefox, pubblicato nel 2004 sul New York Times per la considerevole somma di $. [24] Figura 32: OP2C maturity levels Figura 33: Livello Gold Figura 34: Livello Silver Figura 35: Livello Bronze Figura 36: Bollo di certificazione OP2C Bronze. Per una descrizione completa, vedi Appendice A Figura 37: Portale Tomcat prima del refactory del menu Figura 38: Portale Tomcat dopo del refactory del menu Figura 41: changing the pointer, the user understands what has clicked. [19] Figura 42: Hierarchical visibility of system status [32] VI

9 INDICE TABELLE Tabella 1: Esempio di scenario Tabella 2: Esempio di tabella di valutazione tecnica Tabella 3: Esempio di tabella di valutazione per uno specifico task Tabella 4: Alcune delle misure del successo [20] Tabella 5: License. Extract of the Project information availability table... 2 Tabella 6Elenco delle informazioni che sono risultate essere le più importanti per gli utenti. La tabella è frutto del lavoro svolto in [30] dal team QualiP VII

10 Capitolo 1 INTRODUZIONE A ll interno della scena dell Information Technology, un ruolo di primo piano è ricoperto dai Software Open Source (OSS). Con la nascita di numerose aziende distributrici di software a OSS, il modello Open Source si è diffuso in diversi Paesi del mondo; tanto che spesso la scelta tra un software libero e uno proprietario diventa molto difficile. Nell analisi del panorama mondiale, viene da chiedersi com è possibile che in molti continuino a fare investimenti per acquistare software proprietari, quando ve ne sono di simili e per di più distribuiti liberamente. Una delle risposte sta nel fattore comodità. Quando un utente utilizza abitualmente un prodotto, lo fa perché si trova bene, perché appaga le sue esigenze e vien da se che difficilmente lo cambierà. Per prendere il polso di questa situazione, non serve addentrarsi in statistiche o terminologie tecniche dai nomi roboanti, perché rischierebbero di sviare il discorso; piuttosto fermiamoci a pensare a quanti utenti usano Windows come sistema operativo e Word come software per scrivere i documenti; tantissimi vi direte, ma la cosa che stupisce è che molti ignorano totalmente, che oltre all orizzonte di Microsoft c è molto altro. Ma se è vero che quando in gioco ci son due parti, la colpa non è mai solamente di uno solo, allora sarà anche vero che la colpa dello scarso uso dei software open source non è solamente degli utenti ma anche degli sviluppatori. Infatti, quando un nuovo prodotto viene sviluppato e immesso sul mercato, è necessario che gli vengano affiancati dei sistemi per renderlo noto al pubblico, per fargli pubblicità, se no difficilmente questo prodotto si discosterà dall ambito di ricerca in cui è nato e proseguirà la sua esistenza 1

11 Capitolo 1 Introduzione all ombra di prodotti più famosi, ma non per questo più validi. Per avvicinarsi al progetto di tesi che seguirà nelle prossime pagine, bisogna partire dal concetto che un prodotto OSS venga utilizzato, è necessario che venga caricato su un portale, così che i futuri utilizzatori, possono scaricarlo, testarlo e vedere se soddisfa le loro esigenze. In pratica questo portale svolge il ruolo che per decenni è stato ricoperto dalle vetrine dei negozi; infatti, quando un negoziante vuole vendere un prodotto cercherà di esporlo in una vetrina ordinata e precisa piuttosto che in una polverosa e disorganizzata, questo perché se così fosse il cliente sarebbe restio ad entrare nel negozio. Analogamente se il portale è disorganizzato e l utente non trova le informazioni che cerca, difficilmente insisterà nella ricerca, semmai chiuderà il browser e lo aprirà sul portale della concorrenza. L idea, quindi, di capire più approfonditamente l importanza del portale nella diffusione di un prodotto OSS, ci ha portato a sviluppare un sistema di certificazione volto a verificare se i portali che ospitano questi software espongono in modo chiaro ed esaustivo tutte le informazioni che gli utenti ritengono fondamentali. Contesto applicativo La realizzazione di questo progetto di tesi è stata possibile grazie alla stretta collaborazione col team del progetto QualiPSo (Quality Platform for Open Source Software) un progetto europeo con l intenzione di dare un miglior contributo allo stato dell arte del software Open Source definendo e implementando tecnologie, procedure e policies per influenzare le attuali pratiche di sviluppo Open Source. Pertanto, i risultati ottenuti da questo lavoro di tesi, saranno propedeutici al lavoro da svolgere nel progetto. Al momento una larga parte degli sviluppatori di prodotti OSS relegano il portale a ricoprire un ruolo marginale all interno di quella visione di ampio respiro che dev essere un prodotto OSS. Gli studi che seguiranno nelle pagine successive dimostreranno che è sufficiente seguire dei semplici ma mirati accorgimenti per migliorare il portale di un prodotto OSS, con un conseguente beneficio nella sua diffusione. 2

12 Capitolo 1 Introduzione Obiettivi della tesi Scopo di questa tesi è la definizione di un modello formale semplice ed affidabile per la valutazione dei portali di prodotti Open Source. Si intende creare un modello in grado di assistere i progettisti durante la realizzazione del portale che ospiterà il prodotto che il team di sviluppo ha realizzato. Il processo che porterà alla creazione del modello di valutazione OP2C sarà composto dapprima dall analisi dei modelli di valutazione preesistenti, successivamente dall analisi delle indagini volte a identificare le informazioni più rilevanti per gli utenti e infine a stilare la checklist del nostro modello, stando sempre attenti a far tesoro delle conoscenze apprese durante le fasi precedenti. Approccio al problema La natura stessa del progetto comporta la necessità di stabilire una sinergia tra attività e ambienti che differiscono sia nel tipo che nella complessità. Il problema della valutazione del portale viene affrontato in modo del tutto razionale, valutando prima i principali metodi di valutazione presenti in letteratura, estrapolando quindi i concetti necessari al raggiungimento dello scopo ed aggiungendo infine le parti mancanti. Struttura della tesi Nel presente capitolo, sono state chiarite le problematiche alla base dei questo lavoro di tesi, mettendo in luce le ragioni che ci hanno spinto a realizzare un nuovo modello di valutazione, gli obiettivi principali che si prefiggeva di raggiungere nonché le possibili difficoltà incontrabili. Nel secondo capitolo vengono analizzati i modelli di valutazione dell OSS presenti in letteratura, con uno sguardo particolare al modello trustworthiness QualiPSo. Nel terzo capitolo verrà approcciata la questione dell usabilità, cercando di capire approfonditamente quali sono le leggi che regolano questo aspetto così sottile e sfuggente ma che gioca un ruolo fondamentale nella diffusione di un prodotto. Anche 3

13 Capitolo 1 Introduzione per quanto concerne l usabilità, si è proceduto ad analizzare quanto riportato nella letteratura di settore. Nel quarto capitolo, consci della sua importanza, si è affrontata la questione del marketing nell ambito dei prodotti OSS, cercando di mettere in luce le leggi che lo regolano e che eventualmente lo differenziano dal marketing dei prodotti proprietari. Il quinto capitolo costituisce il cuore di questo progetto di tesi, in quanto verrà esposto in modo esauriente il modello di valutazione realizzato e varrà presentato anche un caso di studio, ossia: il refactory del portale di Apache Tomcat. Infine vengono tratte le conclusioni del lavoro svolto e messi alla luce i possibili sviluppi futuri. Il progetto di tesi viene poi corredato di una serie di appendici che consentono di apprendere in modo dettagliato il funzionamento del modello di valutazione, nonché di visionare i risultati concreti del caso di studio. Il presente lavoro di tesi e' stato inizialmente presentato ESC2K9 (End Summer Camp) di Venezia nell'agosto Successivamente, in collaborazione col Prof. Morasca, Lavazza e i Dott. Taibi e Tosi - è stato sottomesso l'articolo "OP2C: open source product and portal certification", ICWE 2010, Vienna (Vedi appendice E), attualmente in attesa di approvazione. 4

14 Capitolo 2 LA VALUTAZIONE DEL SOFWARE OPEN SOURCE La valutazione e la scelta di un prodotto open source (OSS) è un processo molto complicato sia per chi, operando nel settore dell IT ha delle buone conoscenze in materia di OSS, che per i semplici utenti finali. In questo capitolo verrà introdotto il problema della fiducia nell OSS, quindi saranno descritti i principali modelli di valutazione dell OSS, infine verrà descritto il modello di trustworthiness sviluppato nel progetto QUaliPSo. I progetti OSS, così come tutti gli altri progetti, variano nella qualità, nella documentazione e anche nella capacità di adattarsi ad un utilizzo su larga scala. Un aspetto fondamentale di molti progetti open source è che spesso hanno una nutrita comunità che gli ruota attorno, così come succede con Apache, Tomcat, Firefox, PHP, Eclipse e molti altri. Questi progetti, non solo vengo ampiamente utilizzati da tutti, ma spesso vengono anche confrontati con i software proprietari sia per quanto riguarda la qualità che la funzionalità. Questo fa si che spesso gli utenti adoperino questi software con la stessa confidenza e fiducia che hanno verso i software proprietari. I principali OSS vengono distribuiti tramite i siti web ufficiali o tramite repositories dove, oltre al codice sorgente, si può reperire la documentazione, nonché l assistenza necessaria. Questo non vale però per tutti i prodotti OSS, molti dei quali non disponendo deifinanziamenti necessari, restano più nell ombra, anche se va sottolineato che ciò non è assolutamente indice del fatto che siano meno efficienti. 5

15 Capitolo 2 La valutazione del Software Open Source 2.1 La fiducia nell OSS La Fiducia (in inglese Trust) è senza dubbio un fenomeno complesso, che è stato oggetto di interesse di molti ambiti di ricerca; tanto da assumere differenti definizioni, a seconda dell approccio utilizzato per trattarla. In generale, non si può utilizzare solo la classica definizione enciclopedica di fiducia quando abbiamo a che fare col software open source, bensì è bene integrarla coi concetti presenti in letteratura. Antikainen in [2] sostiene che la fiducia è un fattore chiave, in quanto alcuni soggetti possono, comportandosi in modo opportunistico, influenzare in positivo o in negativo, l opinione sull OSS. In pratica se si forniscono delle informazioni incomplete, errate o prevenute, l opinione pubblica può risultare influenzata in modo negativo e di conseguenza adottare comportamenti nei confronti del software open source che altrimenti non adotterebbe. Inoltre va ricordato che la fiducia è un aspetto molto importante anche per quelle società che si trovano a dover decidere se adottare un prodotto OSS per rispondere ai loro bisogni, oppure virare su un prodotto commerciale che, solo perché è a pagamento, da più l idea di essere affidabile. Antikainen in [2] definisce la fiducia come: The extent to which a person is confident in and willing to act on the basis of, the words, actions and decisions of another. Sempre in [2] Antikainen ha analizzato una delle più attive comunità OSS: la Linux Kernel Community e ha estrapolato otto fattori che influenzano la trustworthiness all interno della comunità: esperienza (skills); pratica (practices); reputazione; obiettivi comuni; condivisione di informazioni; 6

16 Capitolo 2 La valutazione del Software Open Source cultura e valori; possibilità di essere influenzati; familiarità. Va specificato che la fiducia non è un entità astratta, bensì è il frutto di una corretta iterazione tra colui che necessita di un informazione e colui che possiede questa informazione; esattamente come avviene nel campo dell OSS, dove colui che necessita l informazione è la società che si accinge a decidere se scegliere un software libero e soprattutto cerca di capire quali sono le sicurezze e le affidabilità all interno di un mondo poco conosciuto e pubblicizzato. Su questa linea si vanno ad inserire gli studi di Hertzem [1], il quale mira a definire la fiducia che un utente dimostra all OSS come quella che si può instaurare tra due colleghi. Infatti, in [1] si mette in evidenza come nella vita quotidiana, un soggetto per risolvere un problema, è portato a chiede aiuto ad un collega del quale si fida, piuttosto che ricercare la risposta presso altre fonti. Questo avviene perché nelle relazioni umane c è una sorta di vincolo morale di dare un informazione corretta piuttosto che fuoriviante. Per completezza è bene ricordare i 4 tipi di fiducia che ha individuato Hertzum in [1]: first-hand experience; reputation; simple inspection of surface attributes; general assumptions and stereotypes. Ad ogni modo, sia gli studi di Antikainen che quelli di Hertzem sono in linea con gli obiettivi del progetto QualiPSo. 2.2 La valutazione del OSS Per assistere gli utenti nel processo di valutazione e di selezione del software open source, sono stati sviluppati una serie di modelli e di strumenti. Il loro obiettivo è quello di aiutare chi si avvicina al mondo dell OSS a comprendere le caratteristiche di ciascun 7

17 Capitolo 2 La valutazione del Software Open Source prodotto e saper valutare i pro e i contro di ogni prodotto. I principali modelli di valutazione sono: OSMM Open Source Maturity Model; OpenBRR Open Business Readiness Rating; QSOS Qualification And Selection Of Open-Source Software; OpenBQR Open Business Quality Rating. 2.3 Il modello OSMM Il modello OSMM è stato pensato per permettere alle società di valutare il software open source e di capire se il software OSS in questione è in grado di soddisfare i requisiti della società. Nonostante molte discussioni sul software open source, le necessità che le aziende hanno al riguardo vanno ben al di là delle classiche funzionalità, ad esempio sono importanti aspetti come la disponibilità di supporto, la documentazione, la possibilità di integrarsi col software pre-esistente. L OSMM valuta il prodotto basandosi su questi aspetti, assegna un punteggio ad ogni elemento e genera una valutazione complessiva finale che indica il livello di maturità del software. Senza una metodologia formale, che implementi un modello standardizzato di analisi, le società sono limitate nella loro capacità di valutare la maturità del prodotto; inoltre, senza un tale modello, non c'è modo di individuare quali elementi del prodotto richiedono un miglioramento. Naturalmente, in mancanza di uno strumento per valutare formalmente gli OSS, le aziende non possono confrontare i software open source per determinare quale sarebbe meglio usare. È per affrontare sfida di questo tipo che Navica [3] ha sviluppato l'open Source Maturity Model (OSMM). L OSMM valuta la maturità del prodotto in 3 fasi: Valutazione della maturità: valuta gli elementi vitali del prodotto (software, il supporto, la documentazione, il training, la capacità di integrazione); Assegnamento dei pesi: definisce un peso per ogni voce sopra elencata, 8

18 Capitolo 2 La valutazione del Software Open Source basandosi sui requisiti dell azienda; Calcolo della maturità complessiva del prodotto: calcola il livello generale di maturità del software. Figura 1: Tabella per la valutazione della maturità del software Fase 1 - Valutazione della maturità La prima fase identifica gli elementi chiave del prodotto e ne valuta il livello di maturità. Gli elementi chiave sono quelli che rendono difficile l implementazione corretta di un software di buona qualità, ossia: product software; support; documentation; training; product integrations; professional services; Successivamente per ognuno di questi sei elementi, bisogna intraprendere un sottoprocesso di 4 fasi, che consente di effettuare una valutazione precisa e soprattutto di assegnare un valore (score) finale. Queste 4 fasi sono: definizione dei requisiti; 9

19 Capitolo 2 La valutazione del Software Open Source localizzazione delle risorse; valutazione della maturità; assegnazione di un valore di maturità. Fase 2 - Assegnamento dei pesi L assegnamento dei pesi fa in modo che ogni elemento rifletta l importanza che esso ha nella determinazione della maturità totale del prodotto. Solitamente il peso maggiore è assegnato alla voce Product software, mentre gli altri aspetti chiave hanno un peso inferiore, in quanto sono meno determinanti nel determinare il livello complessivo di maturità del software. Figura 2: Pesatura di default degli elementi secondo il modello OSMM Fase 3 - Calcolo della maturità complessiva del prodotto Dopo che gli elementi chiave sono stati determinati e che ad ognuno di questi elementi è stato assegnato un peso, si procede a calcolare la maturità complessiva, nota anche come Product s Overall Maturity Score. Questo livello di maturità è misurato su una scala da 1 a

20 Capitolo 2 La valutazione del Software Open Source Figura 3: OSMM template Concludendo possiamo dire che l obiettivo che si cercava di perseguire quando Navica [3] ha realizzato il modello OSMM, era quello di fornire alle aziende e a chiunque ne avesse bisogno, uno strumento per la valutazione del grado di maturità del software open source. 2.4 Il Modello OpenBRR Il modello BRR mette a disposizione una struttura per valutare le varie caratteristiche di un prodotto open source. Nelle intenzioni degli ideatori, il modello sarà adattabile per riflettere le differenti tipologie di utilizzo: per esempio, distinguendo tra i requisiti delle università e quelli, molto differenti, delle grandi aziende. Sul sito ufficiale [36] è possibile trovare svariati esempi di applicazione del modello Open BRR, utili ad una rapida valutazione personale del prodotto. Essendo basati su semplici fogli di calcolo (excel e openoffice), è inoltre possibile variando semplicemente alcuni parametri di valutazione personale, adattare la stima alle proprie esigenze. Il modello prevede 7 aree di valutazione: Functionality; Operational Software Characteristics; Support and Service; Documentation; Software Technology Attributes; 11

21 Capitolo 2 La valutazione del Software Open Source Adoption; Development Process. Col termine Operational Software Characteristics si fa riferimento a quelle qualità del software che possono essere valutate senza dover avere accesso al codice sorgente; esso comprende aspetti quali l usabilità, la scalabilità, le performance, l installabilità, la sicurezza, l interoperabilità e l aderenza agli standard. Viceversa i Software Technology Attributes fanno riferimento a quegli aspetti che necessitano l accesso al codice sorgente per essere valutati, quali ad esempio: l architettura, la qualità del codice, la documentazione interna. Le prime quattro categorie sono abbastanza simili a quelle che vengono utilizzate per la valutazione dei software proprietari, esse sono spesso utilizzate anche come base per il confronto tra software proprietario e OSS, in particolar modo per quanto riguarda le caratteristiche e le funzionalità. Il modello BRR si compone di 4 fasi: 1) Quick assessment 2) Target usage assessment; 3) Data collection & Processing; 4) Data translation. Figura 4: Le quattro fasi del modello BRR 12

22 Capitolo 2 La valutazione del Software Open Source Fase 1 - Quick Assessment Si identifica una lista di componenti da valutare e si valuta ogni componente tenendo conto di alcuni indicatori, assegnando un punteggio da 1 a 5 dove 1 indica inaccettabile e 5 Eccellente. L obiettivo è quello di eliminare i prodotti che sono chiaramente inadatti. Fase 2 - Target Usage Assessment La seconda fase consiste nell ordinare i prodotti, dal migliore al peggiore, rispetto al punteggio calcolato nella fase 1. Fase 3 - Data Collection & Processing La terza fase consiste nella raccolta dei dati, indicando tutti i punteggi in un scala da uno a cinque. Successivamente si passa alla verifica delle funzionalità di prodotto. 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 ulteriori sotto-fasi. 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) 13

23 Capitolo 2 La valutazione del Software Open Source Figura 5: Fase 3 e 4 del BRR 2.5 Il Modello QSOS Introdotto nel 2004 da Atos Origin, il Qualification and Selection of Open Source Software è un metodo che consente di comparare e selezionare i prodossi OSS e per via delle sue peculiarità, è da considerarsi come una valida alternativa all Open BRR e all OSMM. Il processo si compone di quattro fasi indipendenti ed iterativi: Definition: definizione di una struttura di riferimento, da utilizzare nei passi successivi (licenza, comunità, griglia funzionale ); Evaluation: valutazione del software su tre assi principali: funzionalità, rischi per l utente, rischi per il fornitore dei servizi. Ogni asse contiene più criteri. Per esempio, l analisi dei rischi utente include la curabilità intrinseca, l adattabilità tecnica, l industrializzazione e la strategia; Qualification: consiste nella pesatura dei criteri precedenti; 14

24 Capitolo 2 La valutazione del Software Open Source Selection: selezione e comparazione dei prodotti software. Figura 6: Le 4 fasi del QSOS Fase 1 - Defintion Obiettivo di tale fase è quello di definire i vari elementi riutilizzati nelle tre fasi successive. 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; 15

25 Capitolo 2 La valutazione del Software Open Source Step 2 - Evaluation Come si evince già dal nome, l obiettivo di questa fase è quello di effettuare una valutazione del software; in particolare, si cerca di collezionare tutte le informazioni dalla comunità Open Source al fine di realizzare una carta d identità del software e un foglio di valutazione. Quest ultimo documento include informazioni molto più dettagliate rispetto all identity card, andando a specificare tutti gli aspetti che verranno ritenuti critici. Successivamente si assegna un punteggio da 0 a 2 a tutti i criteri elencati nei documenti prodotti in precedenza; questo punteggio verrà poi utilizzato nella fase quattro. Fase 3 - Qualification Durante questa fase si definiscono quei 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 obbligatori e non includono alcun fattore di peso, il loro utilizzo serve solo per l eliminazione dei fattori inadeguati raccolti nelle id-card. Fase 4 - Selection L ultima fase consiste nella 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 idonei, crea una classifica assegnando in base al grado di idoneità. 16

26 Capitolo 2 La valutazione del Software Open Source 2.6 Il Modello OpenBQR Nessun metodo di valutazione per prodotti Open Source tratta efficacemente le qualità interne ed esterne del prodotto pur avendo a disposizione il codice sorgente. Perciò si è giunti alla formulazione di un modello come unione ed estensione dell Open BRR e del QSOS, introducendo nuove aree di valutazione e modificando la procedura in modo da considerare prima quali siano gli elementi da valutare assegnandogli un peso, quindi in base all importanza attribuita, si valuterà quali saranno gli elementi da stimare. L Open BQR è rivolto ad un target di lettori abbastanza ampio: Persone interessate ad approfondire nuove metriche per prodotto Open Source Comunità di progetti Open Source Esperti IT che vogliono ottenere, attraverso l utilizzo del metodo, una valutazione ed una selezione tra prodotti Open Source omogenei. Il processo di valutazione si compone di tre fasi: 1) Quick Assessment Filter 2) Data Collection & Processing 3) Data Translation Fase 1 - Quick Assessment Filter: Come nel BRR, si identifica una lista di componenti da misurare ma, diversamente, le componenti individuate verranno valutate nella fase successiva, solo in seguito all assegnazione di un fattore peso. Fase 2 - Data Collection & Processing In questa fase si eliminano tutti quegli elementi che hanno peso zero o vicino allo zero. Per ogni area, i pesi vengono normalizzati e viene assegnato un punteggio in base all importanza dell elemento. Infine, ogni peso viene moltiplicato per il rispettivo punteggio, così da ottenere il valore finale per ogni area. Sommando poi i valori di tutte le aree, si ottiene il valore totale del prodotto. 17

27 Capitolo 2 La valutazione del Software Open Source AREA DI VALUTAZIONE PESO STIMA SCORE Ambiti e modalità di utilizzo qualità esterne qualità interne supporto Funzionalità % Figura 7: Esempio schema di valutazione Fase 3 - Data visualization In questa fase si visualizza la griglia del punteggio delle caratteristiche per ogni prodotto. Al fine di agevolare il confronto tra i prodotti, vi è la possibilità di rappresentarli su un grafico di tipo radar (vedi Figura 9), così il confronto risulta visivo e immediato. AREA DI VALUTAZIONE Prodotto A Prodotto B Prodotto C indicatori target qualità esterne qualità interne supporto funzionalità Open BQR Figura 8: Graglia di valutazio per 3 prodotti 18

28 Capitolo 2 La valutazione del Software Open Source Figura 9: Grafico comparativo di tipo radar 2.7 Il modello di trustworthiness QualiPSo I modelli sopra descritti, sono la prova che esiste una vasta gamma di strumenti a supporto di coloro i quali si avvicinano al mondo OSS o comunque si trovano a dover scegliere un prodotto open source e necessitano di strumenti di valutazione. Va però detto, che nella maggior parte dei casi questi modelli trattano questioni tecniche tralasciando aspetti importanti come l aspetto economico e quello legale. Questi modelli di valutazione nascono in ambiti di ricerca e difficilmente si allontanano da quei contesti, nel senso che poi le aziende che producono OSS non sempre si avvalgono di quei modelli e gli utenti che devo scegliere tra due o più prodotti, difficilmente sono a conoscenza della loro esistenza. Per porre rimedio a queste limitazioni, nel progetto QualiPSo [29], è stato sviluppato un modello di valutazione partendo dalle informazioni ritenute importanti dagli utenti dell OSS Le indagini preliminari per la valutazione dei fattori ritenuti importanti per la valutazione dell OSS sono state effettuate tramite più di 150 interviste dirette. I risultati ottenuti sono molto interessanti. Molti di questi risultati hanno confermato le ipotesi fatte all inizio del processo di indagine, mentre altri hanno completamente sorpreso, in quanto hanno messo in luce degli aspetti che non si pensava fossero importanti; anche perché erano sfaccettature che gli altri modelli di valutazione non prendevano in 19

29 Capitolo 2 La valutazione del Software Open Source considerazione. In particolare in [29] è emerso che i seguenti aspetti contribuiscono in larga parte alla determinazione della trustworthiness di un progetto OSS: Comunità: l esistenza di una comunità florida e attiva attorno ad un progetto è prova che il progetto sarà sempre aggiornato, e se si verificassero dei problemi, si ha la certezza di trovare qualche utente/tecnico disposto a prodigarsi alla ricerca di una soluzione; Qualità esterne: queste qualità, dal canto loro, rivestono un ruolo di primo piano nel rendere affidabile un prodotto; Documentazione: più è ricca e completa la documentazione di un progetto, più semplice sarà il suo utilizzo. Mentre gli aspetti che hanno sorpreso sono stati [29]: Complessità e dimensione: questi sono due degli attributi più largamente utilizzati nella valutazione di un sistema software; eppure dalle interviste sono risultati essere aspetti di secondaria importanza, in particolar modo per quando riguarda la dimensione. Questo è stato ricondotto al fatto che gli intervistati hanno pensato che un progetto complesso corredato anche da una florida comunità fosse migliore e preferibile ad un progetto di piccole dimensioni e con una scarsa comunità; Fattori economici: il ROI (Return on Investment) e il TCO (Total Cost of Ownership) sono due aspetti che hanno sorpreso molto. Infatti, all inizio li si considerava poco importanti, mentre i risultati hanno dimostrato che l impatto economico è fondamentale per i consumatori; Licenze: è emerso che questioni riguardanti il tipo di licenze adottate sono fondamentali. In particolare c è una larga predilezione per le licenze GPL. In particolare molti utenti avevano ben chiaro in mente quali vantaggi garantivano le licenze GPL, piuttosto che le licenze completamente permissive come le BSD free license. 20

30 Capitolo 2 La valutazione del Software Open Source I fattori che influenzano la trustworthiness di un prodotto OSS agli occhi degli utenti finali sono molteplici e variano a seconda che siano inerenti alla fase di sviluppo: tipo di licenza; disponibilità di strumenti per lo sviluppo o la modifica del prodotto open source; manuale tecnico. Che siano relativi alla qualità della comunità che sta attorno all OSS: l esistenza di una comunità a medio/lungo termine; l esistenza di una comunità sufficientemente grande; la disponibilità di un supporto a breve termine o addirittura immediato; l esistenza di uno sponsor che sostiene e finanzia il prodotto. Che siano relativi alle qualità interne dell OSS: l utilizzo di un architettura standard; l uniformità nel linguaggio di programmazione; la complessità del codice sorgente; la dimensione del prodotto finito. Che siano relativi alle qualità esterne dell OSS: affidabilità; manutenibilità; modularità del prodotto; l usabilità; portabilità; performance. Che siano relativi ad altre qualità dell OSS, come: soddisfazione del cliente; disponibilità di un manuale utente; la compatibilità con gli standard; 21

31 Capitolo 2 La valutazione del Software Open Source il linguaggio utilizzato per interfacciarsi con l utente; l esistenza di strumenti di testing e benchmark; l esistenza di tutorial per il training; il numero di download effettuati; Il primo passo dell analisi condotta in [10] è stato basato sulle informazioni che si è riusciti a recuperare navigando tra i siti dei vari progetti. E stato scoperto, che la maggior parte delle informazioni che più influenzano l affidabilità di un prodotto non sono reperibili in modo intuitivo dal sito internet del progetto e talvolta non sono presenti affatto. Gli studi hanno dimostrato che soltanto il numero di download è presente su tutti i siti, invece, è stato possibile valutare solamente 8 informazioni, basandosi sui dai messi a disposizione sui siti internet dei vari OSS, queste sono: la disponibilità di una documentazione: sui siti web è, spesso, presente la documentazione ma non la documentazione tecnica o le specifiche sull architettura utilizzata per sviluppare il prodotto il tipo di licenza impiegato: spesso un progetto utilizza una particolare licenza, ma non specifica se anche tutti i sotto-progetti, le librerie e tutti gli altri componenti adottano la stessa licenza del progetto principale. Questo aspetto è molto importante perché ad uno sviluppatore potrebbe interessare di riutilizzare una particolare libreria e quindi necessita di sapere sotto che licenza è stata sviluppata l esistenza, a lungo termine, di uno sponsor; la disponibilità di strumenti per il training (ad es. tutorial); l uniformità del linguaggio di programmazione; i canali di distribuzione. Alcuni fattori è stato possibile valutarli solamente dopo un approfondita analisi dei siti web, e quindi impiegando una discreta mole di tempo. Infine il resto delle informazioni 22

32 Capitolo 2 La valutazione del Software Open Source non è stato possibile rintracciale, a causa della loro completa assenza. Al fine di valutare la presenza dei fattori identificati dalle interviste, sono stati analizzati 32 progetti OSS. 2.9 Conclusioni In questo capitolo abbiamo visto come in letteratura esistono diversi metodi per la valutazione dei prodotti OSS, il loro scopo è ovviamente quello di aiutare gli utenti nella scelta del prodotto più adatto alla loro esigenze, ma soprattutto quello di liberarli dall influenza dell enorme quantità di opinioni disinformate che è facile leggere o sentire [30]. Per cercare di far chiarezza, s è fatto cenno ad alcuni di questi modelli (Ad esempio: OSMM paragrafo 2.3, OpenBRR paragrafo 2.4, QSOS paragrafo 2.5, OpenBQR paragrafo 2.6, QualiPSo paragrafo 2.7), su quali parametri si basano e sull efficacia che hanno. Non va però dimenticato che per quanto è vero che la diversità dei metodi di analisi arricchisce la strada verso la soluzione di un problema, è vero anche che l avere tante metodologie di analisi significa che i metodi precedenti hanno lasciato scoperto qualche aspetto che successivamente qualcuno ha ritenuto fondamentale. Va infatti ricordato, che nella maggior parte dei casi questi modelli si occupano di questioni tecniche e tralasciano aspetti importanti come quello economico e giuridico. Inoltre, molti di loro nascono in ambiti accademici e difficilmente riescono a discostarsene, nel senso che le società che producono OSS non sempre li utilizzano e anche gli utenti, talvolta, sono all oscuro della loro esistenza. In tal proposito, uno studio svolto nell ambito del progetto QualiPSo [10] ha messo alla luce che la maggioranza degli utenti utilizza molto raramente i suddetti modelli; vuoi perché sono poco conosciuti o vuoi perché non li ritengono affidabili. Per concludere è bene ricordare che l OP2C effettua la valutazione con un approccio differente da quello dei modelli preesistenti, infatti, valuta il portale che ospita il prodotto e inoltre prende in considerazione i risultati delle ricerche condotte in [10] riguardanti le informazioni che gli utenti ritengono fondamentali. 23

33 Capitolo 3 Capitolo Usabilità 3 USABILITÀ I n questo capitolo verrà introdotto il concetto di usabilità e verranno analizzate tutte le problematiche ad essa collegate. L idea di trattare gli aspetti riguardanti l usabilità è nata in seguito allo studio della letteratura, in quanto ci si è resi conto che l usabilità ricopre un ruolo principe nella diffusione di un prodotto. Come verrà evidenziato nelle righe seguenti, se un prodotto non è usabile difficilmente sarà in grado di alimentare la crescita di una comunità di utilizzatori. Contrariamente a quanto molti pensano, l usabilità non è soltanto la facciata dell interfaccia utente; bensì, essa si ricollega alle modalità con cui il sistema interagisce con l utente. L usabilità è generalmente composta da 5 attributi base: apprendimento; efficienza; tasso d errore; soddisfazione; memoria dell utente. Come specificato nel modello ISO 9241, la usabilità è: the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. Nel tempo si è andata anche a definire una particolare branca dell ingegneria, nota come 24

34 Capitolo 3 Usabilità usability engineering. Questo termine è stato coniato in modo da riflettere l approccio ingegneristico che hanno gli esperti quando studiano l usabilità. Nello specifico, è quel processo attraverso il quale le caratteristiche di usabilità vengono specificate e successivamente quantificate. Va inoltre ricordato, che la questione dell usabilità è molto vasta e può essere affrontata da differenti punti di vista, dalla psicologia all informatica. Attributi Non è possibile definire l usabilità come un singolo e specifico aspetto del sistema. Essa, infatti, dipende da una moltitudine di fattori, non da ultimo l utilizzo che se ne farà del sistema che si sta sviluppando. Dal momento che l usabilità è un concetto troppo astratto per essere trattato in modo diretto, è bene andare a suddividerlo in una serie di sotto attributi e in seguito valutare quelli per capire il livello di usabilità di un prodotto. Gli attributi della usabilità sono cinque: Comprensibilità: ossia quanto è facile apprendere le principali funzioni del sistema in esame. Solitamente questa caratteristica viene valutata misurando il tempo che l utente impiega, prima di riuscire ad eseguire un operazione nel tempo che impiegherebbe un esperto per eseguire la stessa operazione; Efficienza: ossia il numero di operazione che l utente è in grado di eseguire nell unità di tempo; Memoria dell utente: ossia la capacità che l utente ha di ricordarsi come funziona il sistema, anche dopo un periodo (più o meno lungo) di non utilizzo. Questo aspetto è fondamentale per quegli utenti che utilizzano il prodotto ad intermittenza; Tasso d errore: questa caratteristica non fa riferimento agli errori del sistema, bensì, fa riferimento al numero di errori che commette l utente nell utilizzare il sistema per eseguire delle operazioni. Questo aspetto è fondamentale, perché se il livello di usabilità è elevato, il tasso di errore sarà inevitabilmente basso, dato 25

35 Capitolo 3 Usabilità che l utente capisce subito come funziona il sistema e quindi non sbaglia, o se lo fa, sicuramente lo fa in misura minore. Soddisfazione: questa caratteristica è relativa alle impressioni che l utente ha del sistema. Un problema che sorge spesso, è che questi attributi possono andare in conflitto tra loro. Ad esempio, la comprensibilità e l efficienza spesso tendono ad influenzarsi negativamente, infatti, se un sistema è troppo semplice si rischia che perda in efficienza e viceversa, se si omettono troppi dettagli, per renderlo più veloce, si rischia che perda in comprensibilità. Ne consegue quindi, che l usabilità di un sistema non è la mera somma dei 5 attributi, bensì è la capacità di massimizzare questi attributi, così da finire a massimizzare il sistema nel suo complesso. 3.2 Usability e User interface Bisogna distinguere tra interfaccia utente (composta da bottoni, menu, sfondi, ) e interazione con l utente, se si vuole conoscere a fondo l usabilità del sistema. In particolar modo, l interazione è un aspetto che deve essere tenuto ben presente, non solo quando si sviluppa l interfaccia, ma anche quando si sviluppa tutto il resto del sistema. Purtroppo non è così difficile trovare delle software house che prima sviluppano il software e poi lo danno in input al team che si occupa di valutarne e soprattutto incrementarne l usabilità, aggiungendo bottoni, interfacce, colori e gingilli simili. Questi soggetti non si rendono conto che l usabilità non è la fase finale del processo di sviluppo, bensì ne è la colonna vertebrale, una sorta di fascio di nervi che percorre tutta la fase produttiva, dalla progettazione fino alla presentazione all utente. Questo perché è sin dalla fase iniziale che il prodotto deve essere pensato per essere usabile, e non solo dopo che è stato confezionato. 26

36 Capitolo 3 Usabilità 3.3 L usabilità nello sviluppo di un software Il principale motivo che porta a tenere in primo piano gli aspetti dell usabilità, quando si va a sviluppare un software, è che essa è in grado di influenzare in modo positivo, sia efficienza che soddisfazione e di conseguenza anche la produttività. Le tecniche a supporto dell usabilità sono, perciò, d aiuto ad ogni software per raggiungere lo scopo previsto, aiutando gli utenti a portare a termine i loro task. Inoltre l usabilità si ritaglia un ruolo sempre più di primo piano, anche perché molto spesso oggi gli utenti che utilizzano software sono spesso neofiti o a digiuno di approfondite conoscenze informatiche e quindi una buona usabilità gli consentirebbe di evitare di dover approfondire le loro conoscenze tramite studi o corsi di aggiornamento sull utilizzo del sistema. Inoltre, se l utente finale identifica come non usabile un software, allora vi sarà la possibilità che lo abbandoni a vantaggio di un altro software (della concorrenza) e quindi si avrebbero ripercussioni anche sull aspetto commerciale. Ovviamente l usabilità non è l unico fattore che spinge un utente ad utilizzare un prodotto, infatti capita spesso che alcuni prodotti non brillino per usabilità ma che comunque vengono ampiamente utilizzati, questo è riconducibile ad altri fattori, quali il costo, la disponibilità di assistenza, la diffusione di massa, 3.4 La strada verso l usabilità L usabilità è un aspetto che va tenuto in considerazione durante tutta la fase di sviluppo del sistema. Da ciò ne consegue che effettuare solamente il test sull usabilità non è sufficiente per ottenere un prodotto altamente usabile, infatti, esso mette alla luce i problemi che sono presenti, ma non li risolve. È noto che i software sono semplicemente degli strumenti che aiutano gli utenti ad eseguire delle operazioni. Ad ogni modo, prima di progettare o realizzare uno di questi strumenti, è bene chiederci chi sarà l effettivo destinatario di questi tools, oppure quali aspetti il prodotto deve andare soddisfare. Per dare una risposta a questi interrogativi, si ricorre ad un processo noto come usability process. Ne esistono diversi, uno di questi 27

37 Capitolo 3 Usabilità è composto da 5 fasi[17]: Uesr Analysis: Esistono una serie di metodi per ottenere informazioni sugli utenti, primo tra tutti le interviste. Ovviamente, la qualità dei dati ottenuti dipende dalla qualità delle domande che sono state poste agli utenti; al riguardo esistono, in letteratura, una serie di testi che spiegano le modalità migliori per porre le domande e indirizzare l utente verso uno specifico argomento; Task Analysis: Questo aspetto descrive le tecniche che gli utenti utilizzano per eseguire le loro operazioni; Usability Benchmarks: Solitamente si impostano i benchmarks sull usabilità come una serie di obiettivi che vanno perseguiti e questi vengono specificati prima che inizi la fase di progettazione del prodotto; Conceptual Design: Durante questa fase si vanno a definire le principali interazioni utente-sistema, gli oggetti che andranno a costituire l interfaccia utente e ovviamente anche il contesto nel quale avverrà l interazione. Questa fase è da considerarsi come una delle più importanti, in quanto costituisce una delle colonne portanti del processo di sviluppo del sistema. Purtroppo la fase di design è un operazione molto creativa e non può essere imbrigliata da un metodo automatizzato, anche se esistono delle regole da rispettare se si vuole ottenere un buon prodotto; Visual Design: Una volta terminata la fase di conceptual design, si passa alla fase di visual design, nella quale si va a definire l interfaccia utente vera e propria, ossia i colori da usare, i font, quali menu usare, i bottoni e altri oggetti simili. a cui se ne aggiungono, talvolta, 2 ulteriori: Prototyping: Esistono varie tecniche di prototipizzazione: o Paper mock-ups: all inizio delle fase di design, il progettista realizza dei modelli su carta di come dovrà apparire il progetto finito, specificando anche le varie relazioni tra le varie schermate; o Wizard of Oz: un esperto finge di essere il sistema e prova a fornire lui le 28

38 Capitolo 3 Usabilità risposte alle richieste dell utente (imitation game?!); o Storyboard: è una sequenza di snapshot che si soffermano a descrivere la principale operazione eseguibile in un particolare momento; Usability Evaluation: La valutazione dell usabilità è un passaggio fondamentale poiché consente di determinare l attuale livello di usabilità del prodotto e quindi verificare se ci sono stati degli incrementi ma soprattutto permette di capire se il design che è stato scelto, funziona o necessita di un restyling. Per testare l usabilità di un software esistono varie tecniche, una di queste prevede la scelta di un gruppo di utenti e metterli ad eseguire il programma più volte, e in seguito raccogliere le loro considerazioni (questa tecnica è impiegata nel game testing). Un altra tecnica, alternativa a quella di raccogliere le opinioni degli utenti, è quella di ascoltare ciò che dicono durante la fase di utilizzo del software, spesso aiutandosi tramite videocamere o microfoni e chiedendo ai tester di pensare ad alta voce, perché così facendo si riescono a captare quegli aspetti più istintivi, che se si aspettasse la fine del test non verrebbero alla luce. Figura 10: Usability Process 3.5 Come migliorare l usabilità Come descritto in [24] esistono sostanzialmente due differenti tipologie di interventi per migliorare l interazione tra l utente e il sito/portale/prodotto software in genere. La 29

39 Capitolo 3 Usabilità prima tipologia è sicuramente la più teorica e si avvale di una serie di esperti che, utilizzando una serie di assunti considerati veri (decalogo di Nielsen), analizzano il sito e generano una serie di osservazioni e di suggerimenti su come migliorarlo. La seconda tipologia si basa, invece, sull'osservazione diretta del comportamento di un utente alle prese col sito in fase di beta testing. E in base a come l utente svolge i vari compiti che gli vengono proposti e alle difficoltà che incontra, si traggono dei suggerimenti per migliorare il prodotto finale. Entrambe le tecniche sono utili, dato che, come descritto in [24], anche Jakob Nielsen ha rilevato che è praticamente impossibile risolvere tutti i problemi di usabilità in un sito; tanto che sarebbe un ottimo traguardo se si riuscisse a fare in modo che almeno l 85% degli utenti non incontri seri problemi di usabilità. Ad ogni modo, esistono sostanzialmente due diverse tecniche di analisi dell usabilità [24]: Analisi analitica: questa analisi non viene condotta basandosi su una generica esperienza maturata dall analista, ma si basa su ferrei capisaldi facenti parte della letteratura di settore. Come detto in [24], i metodi analitici sono particolarmente utili in fasi precoci del progetto, ossia quando i problemi di usabilità sono talmente numerosi che non avrebbe senso sprecare dei soggetti (che rappresentano un notevole costo) per rilevare errori che potrebbero essere facilmente identificati anche da uno o più esperti. Tra i metodi analitici, è doveroso citare: o Task analysis:consiste nell analizzare il modo in cui un particolare task viene portato a termine, ossia quali passi vengono eseguiti per giungere al completamento del task; o Cognitive walkthrough: con questo metodo si cerca ti prendere in considerazione anche le caratteristiche cognitive dell'utente (competenze richieste, conoscenze del dominio, ), prestando attenzione a se si verificano eventuali problemi; o Valutazioni euristiche: la valutazione euristica valuta l'interfaccia sulla base di liste di euristiche. Tali euristiche sono principi che hanno un 30

40 Capitolo 3 Usabilità elevato valore predittivo perché rappresentano la sintesi dei problemi di usabilità più frequenti organizzati in categorie. Le euristiche di Nielsen [37], (vedi Paragrafo 3.10) ad esempio, derivano dall applicazione di tecniche di analisi fattoriale su 249 problemi di usabilità [18,19]. Analisi empirica: per essere eseguita, questa analisi necessita di appositi laboratori, attrezzati con telecamere, dispositivi di rilevamento temporale, specchi unidirezionali e tutta una lunga serie di dispositivi di analisi che comportano un cospicuo innalzamento dei costi. Come detto in [24], questa tecnica di analisi richiede l intervento di personale addestrato e specializzato nello studio del comportamento umano; questa così elevata richiesta di specializzazione è necessaria per riuscire a tenere sotto controllo i problemi legati alla variabilità interindividuale e alla scarsa naturalezza della situazione. Questo presuppone una certa esperienza nella preparazione del set, nella conduzione del test e nell'analisi dei risultati, che andranno opportunamente classificati e sottoposti, laddove è possibile, ad analisi statistica [24]. Prima di elencare alcuni dei metodi empirici più conosciuti, è bene sottolineare che la durata di queste tecniche è molto variabile, così come lo sono anche i costi. Alcuni dei metodi empirici più noti sono [24]: o Analisi dei tempi di esecuzione: si chiede all utente di eseguire un particolare compito e si tiene traccia di quanto tempo impiega per portarlo a termine ; o Questionari di soddisfazione:: si chiede all utente di compilare un questionario in cui egli possa esprimere il suo grado di soddisfazione del prodotto; o L'osservazione diretta con annotazione degli errori: si osserva l utente mentre porta a compimento un task e si annotano gli eventuali errori in cui incorre; o Thinking aloud: si chiede all utente di pensare ad alta voce ai comandi che si accinge ad eseguire, mentre porta a termine un particolare 31

41 Capitolo 3 Usabilità compito. E' importante insomma porsi di volta in volta gli obiettivi e le domande più appropriate al progetto e usare le tecniche di analisi dell'usabilità più adeguate all'obiettivo che ci si è posti. Questa capacità di focalizzare le tecniche sui problemi appropriati è determinante. Una tecnica condotta benissimo, ma a partire da presupposti errati può, com'è evidente, portare alla totale invalidazione dei risultati, con conseguente spreco economico. In generale è bene, se si dispone di un budget adeguato, distribuire l'investimento in usabilità su diversi test svolti a più riprese nel corso della progettazione, in maniera da correggere il prodotto. Ciò comporta un certo dispendio da parte di designer e progettisti, e può talvolta essere visto con riluttanza dallo staff di progettazione, ma porta a indubbi vantaggi nel momento in cui il prodotto finale ha un ciclo di vita più lungo, almeno nel senso che non necessiterà di premature modifiche e darà una maggior soddisfazione agli utenti. Nonostante questi vantaggi, la cultura dell'usabilità sul web non è molto diffusa in Italia probabilmente per due motivi [24]: Organizzativo: da una parte essa richiede un lavoro d'equipe che coinvolge esperti di usabilità e designer/progettisti che può non essere semplice far accettare a tutti gli elementi coinvolti; Economico: dall'altra in certa ottica manageriale si preferisce tagliare i costi per attività delle quali non si apprezzano benefici immediati ed evidenti. Come ricordato in [24]: l'usabilità non dà pagelle ai designer, ma tenta di aiutarli a risolvere problemi che emergono durante l'interazione tra utente e interfaccia. Sottolineare questo aspetto è compito degli esperti di usabilità e può alle volte contribuire anche a vincere le resistenze alla collaborazione di una parte dello staff coinvolta nel progetto. 3.6 L usabilità non è un lusso Nel mondo di internet [25] l usabilità non è da considerarsi come un lusso, bensì come 32

42 Capitolo 3 Usabilità una componente essenziale per la sopravvivenza. Parafrasando il detto che nel mondo animale è il più forte a sopravvivere, possiamo dire che su internet è il più semplice e usabile a sopravvivere. Questo perché se un utente non è in grado di trovare il prodotto sul sito del produttore, difficilmente riuscirà ad acquistarlo. Nielsen e Norman in [25] specificano che è molto più conveniente incrementare la quota del budget destinata al design del sito che quella destinata alla pubblicità. Dedicando del tempo a studiare e migliorare l usabilità del sito, si riuscirà ad incrementare il numero di utenti che riusciranno a portare a termine con successo l acquisto del prodotto o anche semplicemente il download del software interessato. Nel progettare un sito/portale, bisogna sempre tener presente che l utente che lo utilizzerà dovrà sempre ricoprire un ruolo di primo piano, perché senza l utente finale il prodotto che si sta cercando di diffondere non si diffonderà. In [25] si dice che appena un utente entra in un sito, cerca di capire se è usabile e solo se ne rimane soddisfatto si accinge ad acquistare. Va ricordato che, a differenza del mondo reale, il web offre dei ridottissimi costi di passaggio da un fornitore all altro; questo a dimostrare che se l utente non rimane soddisfatto, sicuramente si rivolgerà altrove e, vista la disponibilità di prodotti reperibile in rete, difficilmente non riuscirà a trovare un prodotto simile e più facilmente accessibile. Degli studi condotti sull interazione utente-internet [25], hanno dimostrato che gli utenti hanno una scarsa tolleranza nei confronti dei siti troppo complessi o troppo pesanti. La gente non vuole aspettare e non vuole imparare come funzione l home page di un sito; essi devono essere in grado di comprenderne il funzionamento dopo pochi secondi che l hanno vista. L ideale sarebbe di creare una struttura organizzativa incentrata sul destinatario del prodotto che si sta sviluppando, ma per quanto sembra facile a dirsi, è molto difficile nella realtà. Nielsen e Norman in [25] ricordano che ai clienti non interessa il modo in cui la società è organizzata, ciò che gli importa è che il sito sia usabile e facile da capire. Concludendo si può dire che realizzare un sito usabile non è affatto facile, non basrta mettere in pratica le euristiche presenti in letteratura, si presuppone che l azienda investi 33

43 Capitolo 3 Usabilità del tempo e assuma dei professionisti che dedichino del tempo a studiare chi sono i destinatari dei prodotti finiti, quali esigenze e aspettative hanno. In pratica, come detto all inizio di queto paragrafo, l usabilità su internet non è un lusso bensì un privilegio. 3.7 L usabilità nel modello ISO 9126 Lo standard ISO 9126 è, probabilmente, da considerarsi come il modello più grande che tratta la qualità del software, anche se nonostante ciò non è da considerarsi completamente esaustivo. Presentato per la prima volta nel 1991, il modello divide la qualità del software in 6 categorie. Figura 11: ISO 9126 L obiettivo di questo standard è quello di fornire un modello per la valutazione della qualità del software, senza però specificare i requisiti di qualità. Il modello definito è sufficientemente generale da essere applicabile ad una vasta gamma di software, ossia indipendentemente dal tipo di prodotto che si ha davanti. 34

44 Capitolo 3 Usabilità Il modello ISO 9126 definisce l usabilità come: A set of attributes that bear on the effort needed for use and on the individual assessment of such use, by a stated or implied set of users L usabilità è quindi vista come un fattore indipendente della qualità del software. In ogni caso gli attributi di usabilità di un prodotto, variano a seconda dell utente che lo utilizzerà, del tipo di operazioni che ci si prefigge di svolgere, nonché dall ambiente nel quale andrà ad operare. Questo ha portato ad una modifica del concetto di usabilità, tant è che nel 2000 è stata ridefinita come: The capability of the software product to be understood, learned and liked by the user, when used under specified conditions. Inoltre va sottolineato che per specificare la qualità del software, un acquirente necessita di un modello e di una serie di strumenti per poter comunicare in modo preciso i suoi requisiti allo sviluppatore. Per contrasto, anche lo sviluppatore deve essere in grado di poter valutare che il software risponda ai requisiti di qualità richiesti. A tal proposito, lo standard ISO 9126 può essere utilizzato come riferimento nei rapporti contrattuali tra produttori ed acquirenti, soprattutto per eliminare eventuali fraintendimenti. Vi sono paesi, come il Giappone, che utilizzano questo modello come uno standard nazionale. Comunque sia, vi sono alcuni aspetti che il modello 9126 non copre, quali: alcuni concetti si sovrappongono; la scelta delle misure è ambigua; architettura talvolta poco chiara; mancanza di linee guida nel gestire i risultati delle valutazioni. 35

45 Capitolo 3 Usabilità 3.8 Lo standard ISO/IEC La norma ISO/IEC 14598, descrive il processo di valutazione della qualità del software, in accordo con la norma ISO/IEC La norma, composta di 6 parti, è utilizzabile per valutare il software in fase di sua acquisizione, durante lo sviluppo, in fase di assessment. Il modello di valutazione proposto nella norma si intende applicabile sia ai prodotti commercial-off-theshelf, sia a quelli sviluppati su commessa in base a specifici requisiti utente (custom software o software ad hoc). Dalla norma ISO vanno sottolineate le seguenti definizioni: Valutazione della qualità: esame sistematico del livello con il quale una entità risponde ai requisiti stabiliti Verifica: Conferma attraverso un esame e la rilevazione di evidenze oggettive che uno specifico requisito è stato rispettato Validazione: Conferma attraverso un esame e la rilevazione di evidenze oggettive che uno specifico requisito relativo ad un particolare obiettivo d utilizzo è stato rispettato. Figura 12: Schema del processo di valutazione 36

46 Capitolo 3 Usabilità Figura 13: Fasi e attività del processo di valutazione L operazione di valutazione può essere eseguita sia sul prodotto finito sia sulle fasi intermedie del ciclo di sviluppo. I motivi che spingono ad una valutazione sul prodotto finito sono molteplici, infatti questo tipo di analisi permetterà di decidere se un prodotto è da considerarsi accettabile, soprattutto se confrontato con altri prodotti concorrenti. Un altro motivo può essere quello di vagliare l eventuale rimpiazzo del prodotto con un altro o magari anche semplicemente modificare il prodotto, al fine di adattarlo meglio a nuove esigenze. Anche i motivi che spingono alla valutazione nelle fasi intermedie possono essere molteplici, ad esempio: decidere se uno stato intermedio è da considerarsi completo oppure necessita di essere ulteriormente sviluppato o modificato, ad esempio se si riscontrassero delle incompatibilità rispetto al progetto iniziale, ma ovviamente anche la possibilità di prevedere la qualità del prodotto finito. Va sottolineato che un prodotto software assume diverse forme nelle diverse fasi 37

47 Capitolo 3 Usabilità del ciclo di vita, ed è per questo che anche la valutazione che si può effettuare, varia di pari passo con lo stato di lavorazione; ad esempio: la qualità in uso sarà valutabile solamente quando il prodotto sarà operativo ed utilizzabile dall utente, mentre le caratteristiche interne ed esterne potranno essere già valutate nelle fasi intermedie. Il modello base di riferimento per definire le caratteristiche da valutare è quello ISO/IEC In genere, non è richiesto che il prodotto presenti di tutte le caratteristiche specificate nello standard; bensì, vanno inserite solamente quelle che l utente considera rilevanti. Allo scopo, va rilevato il profilo di qualità atteso dall'utente. Si costruisce questo profilo intervistando un campione, proprio come è stato effettuato nel progetto Qualipso. Al profilo risultante dall analisi, potranno poi essere applicati dei fattori di aggiustamento i quali tengono conto di ulteriori elementi del contesto, quali il budget, il tempo disponibile,. Un aspetto che non deve essere assolutamente trascurato è il livello di criticità del prodotto. Per determinarlo, ma soprattutto per gestirlo, è utile redigere una tabella che mette in corrispondenza i livelli qualitativi e le classi di rischio Metodo di valutazione Nelle specifiche di valutazione vanno definite: fonti: necessarie per derivare tutte quelle informazioni che serviranno per la valutazione; tecniche: necessarie per effettuare la valutazione; 38

48 Capitolo 3 Usabilità metriche: necessarie per rilevare misure sul software. Le valutazioni possono essere svolte con differenti livelli di accuratezza, infatti, sta al valutatore il compito di scegliere il campione che più si confà al budget disponibile, al contesto ed alla criticità del prodotto. Purtroppo, può anche presentarsi l eventualità che compiendo una scelta, si vada in contrasto con la possibilità di indagare su tutti gli aspetti desiderati. Fonti Le fonti di valutazione sono sostanzialmente due: l'entità in esame; l'utente che ne fa uso. Nel caso in cui la fonte è l'utente si parla di valutazione della qualità "percepita" e bisogna considerare l'influenza di fattori soggettivi che potrebbero condizionare la valutazione Tecniche di valutazione Le tecniche utilizzate per la valutazione devono essere applicabili a tutti gli ambiti di un progetto, dalla documentazione tecnica al codice sorgente, dalla qualità in uso al manuale utente. Ovviamente la scelta di una tecnica piuttosto che di un altra dipende dal valutatore e dagli obiettivi che si pone; ad esempio: se si prefigge lo scopo di valutare la qualità interna, utilizzerà delle metodologie differenti rispetto a che se dovesse valutare la qualità in uso Metriche per la valutazione A seconda del tipo di valutazione che ci si prefigge di attuare, bisogna utilizzare le opportune metriche. Al riguardo è bene riferirsi a quanto specificato nello 39

49 Capitolo 3 Usabilità standard ISO Elaborazione Una volta che i dati sono stati raccolti, è necessario elaborarli. Di norma per poter compiere una valutazione che sia corretta e soprattutto consistente, è necessario utilizzare una serie di misure e non una misura soltanto. Nella fase di elaborazione si ritaglia un ruolo di primo piano il rating, che è quel processo che consente di trasformare le misure rilevate in una misura derivata Rating In letteratura esistono svariati metodi per effettuare il rating, ma nessuno di essi è riconosciuto ed accettato come standard universale. Per porre rimedio a questo problema, nello standard ISO viene fornita una descrizione del metodo da seguire per mappare misure quantitative su una scala qualitativa. Vediamone un esempio pratico: il valore minore della scala è associato al valore più basso; il valore maggiore della scala è associato al valore più altro; si suddivide l intervallo (minimo-massimo) in intervalli regolari. Ad esempio se devo misurare l altezza dei ragazzi di un aula e si nota che il più alto misura 200cm e il più basso 150cm, assegnerò l attributo altissimo al primo ragazzo e l attributo piccolo al secondo ragazzo e poi dividerò lo spazio tra le due misure così da far rientrare anche tutte le altre misure rilevate. Va detto che il passaggio da una scala a rapporti ad una scala ordinale (quella utilizzata per esprimere il giudizio) non ha un fondamento "scientifico". Ad esempio, nel caso di una valutazione della qualità su scala ordinale, è difficile dimostrare che l usabilità di un prodotto è esattamente il doppio, o la metà di quella di un altro. 40

50 Capitolo 3 Usabilità Figura 14: Relazioni Il progetto MiLE+ Nel seguente paragrafo verrà analizzato un progetto di ricerca che, basandosi su una serie di indicatori, di euristiche e di possibili scenari di utilizzo, punta alla valutazione dell usabilità di un portale web Cos è il progetto MiLE+ Il progetto MiLE+ [11] (Milano-Lugano Evaluation Method), nato dalla collaborazione tra il Politecnico di Milano e l Università di Lugano, è da considerarsi come un architettura per la valutazione dell usabilità a metà strada tra metodi di valutazione euristici e le tecniche note come task-driven tecniques. MiLE+ [11] mette a disposizione una serie di strumenti e di procedure per la valutazione e le operazioni di testing, così da poter soddisfare tutte le possibili esigenze e vincoli a cui i clienti devono sottostare. Per questo motivo, il progetto MiLE+ [11] propone due diverse tipologie di attività di ispezione: Technical Inspection; User Experience Inspection. 41

51 Capitolo 3 Usabilità Prima di vedere più nel dettaglio queste due tecniche, è bene soffermarsi sui tre componenti principali del progetto MiLE+ [11]: Scenari; Euristiche; Usability Evaluation Kits (U-KITs). Figura 15: Le 3 attività del progetto MiLE+ Scenari MiILE+ [11] usa gli scenari come strumenti per la valutazione dell usabilità, in quanto essi rivestono un ruolo chiave in questo tipo di valutazione. Infatti, se non si possiede una chiara e ben delineata idea dei bisogni e degli obiettivi che l utente si prefigge, è difficile, se non impossibile, effettuare una valutazione efficace dell usabilità. Gli scenari hanno inoltre il vantaggio di aiutare gli ispettori a prevedere quali saranno le intenzioni e le motivazioni che spingono l utente finale ad interagire in un particolar modo col sito web, quali sono le conseguenze e gli effetti di questa interazione, nonché l impatto sul sistema nel suo complesso. Perciò va riconosciuto che conoscere il dominio in cui si va ad operare aiuta notevolmente l attività di valutazione. Va inoltre aggiunto, che al fine di effettuare una valutazione che sia il più consistente possibile, i valutatori devono cerare loro stessi dei possibili scenari di utilizzo. Questi 42

52 Capitolo 3 Usabilità ultimi sono solitamente composti da 3 elementi base: Profilo utente: per definire il profilo utente (user profile), si può attingere sia ad aspetti socio-demografici (età, mansione svolta, paese di provenienza, ) che ad aspetti più tecnologici o webographic come vengono definiti in [11] (conoscenza di internet, velocità delle connessione, livello tecnologico, ): Obiettivo; Task. Chiaramente lo scenario non è unico, nel senso che possono essere definibili una elevata varietà di scenari, a seconda che si adotti una visione ad alto o basso livello. Ad esempio, quando si adotta un approccio ad alto livello si parla di macro-scenari, viceversa quando il livello è più specifico si parla di scenari dettagliati. Tabella 1: Esempio di scenario Euristiche Le euristiche sono da considerarsi come gli strumenti utilizzati per la valutazione vera e propria. In particolare, nel progetto MiLE [11] sono previste due differenti tipologie di euristiche: Technical Heuristics: queste sono una serie di euristiche utili per valutare la 43

53 Capitolo 3 Usabilità qualità del design in tutte le sue sfaccettature; User Experience Indicators (UEIs): vi sono aspetti dell usabilità che non possono essere valutati da soggetti che non sono l utente finale. Questi aspetti sono altamente soggettivi e dipendono anche dall esperienza dell utente che ne fa uso. Nello specifico, gli UEI permettono di anticipare i possibili problemi nei quali l utente finale può incorrere utilizzando il sito. Usability Evaluation Kits (U-KITs) Al fine di agevolare le operazioni di controllo e valutazione dell usabilità di un portale, il progetto MiLE+, mette a disposizione una serie di tools (noti come U-KIT, ossia Usability Evaluation Kits) e di linee guida per crearli. Nell U-KIT è compresa anche una libreria di possibili scenari (profili utente, obiettivi e task), così da agevolare le operazioni di valutazione; nel caso in cui, però, non fossero sufficienti gli scenari presenti e sorgesse la necessità di crearne altri più specifici, allora l U-KIT mette a disposizione anche degli strumenti che permetteranno al valutatore di cerare lo scenario che più si confà alle sue esigenze. La flessibilità delle libreria MiLE+, unita al fatto che sono tutte open source, consente al valutatore di creare l U-KIT che meglio lo soddisfa, con particolare attenzione al tempo e al budget a disposizione. Ad esempio, se il tempo e il budget a disposizione del valutatore sono molto ridotti, si può optare per un analisi basata solamente su macroscanari e alcune euristiche; viceversa, se il tempo e il denaro a disposizione è molto, allora si può procedere ad un analisi più approfondita e completa, la quale prevede l utilizzo di più scenari, più euristiche e più User Experience Indicators Analisi Tecnica La fase di analisi tecnica, punta ad individuare e correggere i punti deboli di un sito, nonché i guasti nei quali si è incorso durante l implementazione. Durante questa fase il valutatore prende in esame una serie di fattori, quali: Contenuto: in questo passaggio si analizza la qualità del contenuto e si verifica che corrispondano alle aspettative del cliente; 44

54 Capitolo 3 Usabilità Navigabilità: in questa fase si analizza la navigabilità all interno del portale; Design dell interfaccia; o Semiotica: durante la navigazione, l utente deve essere in grado di comprendere facilmente i messaggi che gli vengono proposti; o Grafica: si analizza il design e il layout; o Aspetti cognitivi: la capacità dell utente di memorizzare e capire mentre legge o interagisce col sito; Tecnologia:qui si valutano le scelte che sono state fatte in ambito tecnologico, nonché lo stile implementativi utilizzato. Figura 16: L'analisi tecnica è la seconda fase del processo di valutazione dell usabilità. 45

55 Capitolo 3 Usabilità Tabella 2: Esempio di tabella di valutazione tecnica User Experience Inspection La User Experience Inspection è una valutazione basata sugli scenari; questo significa che il valutatore deve essere in grado di prevedere, con una certa precisione, chi effettivamente utilizzerà l applicazione. Proprio per questo motivo, egli deve provvedere alla realizzazione dello User Experience KIT, il quale comprende: Una libreria di scenari; Una libreria di User ExperienceIndicators. 46

56 Capitolo 3 Usabilità Figura 17: La User Experience Inspection è la seconda fase del processo di valutazione dell usabilità. Tabella 3: Esempio di tabella di valutazione per uno specifico task 47

57 Capitolo 3 Usabilità 3.10 Il decalogo di Nielsen In questo paragrafo verranno riportati i 10 capi saldi dell usabilità di un sito e di un portale web. Il decalogo, redatto dall informatico danese Jakob Nielsen, è composto dalle seguenti euristiche [37]: 1) Visibilità dello stato del sistema: il sistema deve sempre tenere informato l utente su cosa sta facendo, fornendo un adeguato feedback in un tempo ragionevole. Nella Figura 18 si evince in modo chiaro lo stato del sistema, così facendo, l utente saprà sempre in che parte del sito si trova [18]. Figura 18: Esempio di visibilità gerarchica dello stato del sistema [37] 2) Corrispondenza tra sistema e mondo reale: il sistema deve parlare il linguaggio dell utente, con parole, frasi e concetti a lui familiari. Inoltre deve preferibilmente utilizzare le convenzioni del mondo reale, presentando le informazioni secondo un naturale ordine logico [18]. 3) Controllo e libertà: Gli utenti spesso si imbattono per errore in funzioni del sistema che non intendevano usare o in pagine web di cui non hanno bisogno. Bisogna fornire loro vie d uscita ben chiare e visibili, senza costringerli a lunghe interazioni col sistema [19]. Quindi è preferibile evitare procedure costrittive troppo lunghe, percorsi predefiniti senza possibili scorciatoie e azioni non volute dall utente (come ad esempio, l apertura automatica di pagine non richieste).[18] 4) Consistenza e standard: l utente deve aspettarsi che le convenzioni del sistema siano valide per tutta l interfaccia. Come specificato in [19], i comandi, i pulsanti, i link che hanno la stessa funzione devono apparire nella stessa collocazione e nello stesso ordine in tutte le schermate o finestre di dialogo. 48

58 Capitolo 3 Usabilità Inoltre, gli standard più consolidati devono essere violati solo se c è un chiaro valore aggiunto. Figura 19: Non cambiare l'ordinestandard degli elementi. 5) Prevenzione dell errore 1 : niente di più azzeccato del detto popolare prevenire è meglio che curare ; infatti, alla base di tutto ci sta un buon design che consente di prevenire l errore piuttosto che curarlo. Un accortezza necessaria a prevenire gli errori, può essere quella di avvisare l utente della dimensione del file che si accinge a scaricare. Figura 20: È spesso importante specificare tempi e dimensione del download. [19] 6) Riconoscimento anziché ricordo: le istruzioni per l uso del sistema devono essere ben visibili e facilmente recuperabili. [18] Perciò è bene produrre layout semplici e schematici e quindi non contare mai sulla capacità dell utente di 1 Le persone fanno errori di continuo. Nemmeno un minuto di normale conversazione passa senza un intoppo, una ripetizione, un a frase interrotta e lasciata in sospeso o rettificata.il linguaggio offre meccanismi speciali per rendere le correzioni talmente automatiche che i partecipanti non le notano quasi; anzi, rimangono sorpresi quando qualcuno fa notare gli errori. I dispositivi artificiali non hanno la stessa tolleranza: premete il tasto sbagliato e può essere il caos. [18] 49

59 Capitolo 3 Usabilità ricordare il posizionamento degli oggetti che caratterizzano le pagine. Come detto anche in [18], fare in modo che l utente non debba riscoprire ogni volta l interfaccia. Figura 21: L'icona del calendario aiuta l'utente a destreggiarsi nel sito.[19] 7) Flessibilità d uso: offrire all utente la possibilità di un uso differenziale (a seconda della sua esperienza) dell interfaccia. Offrire una navigazione gerarchica per i meno esperti e offrire delle scorciatoie per i più esperti. [18] Figura 22: I comandi da tastiera sono un buon esempio di flessibilità d'uso. [19] 8) Design ed estetica minimalista: dare maggior importanza al contenuto che all estetica. Evitare di accentuare oggetti irrilevanti o raramente necessari 50

60 Capitolo 3 Usabilità (immagini grandi, etc.). Evitare che il contenuto informativo della pagina sia messo in secondo piano. Evitare che l utente si distragga o si confonda. [18] 9) Aiuto all utente: aiutare l utente a riconoscere, diagnosticare e recuperare l errore. I messaggi di errore devono essere espressi in linguaggio comprensibile (senza codici). I messaggi di errore devono indicare in modo preciso il problema e suggerire una soluzione. Chiedere conferma per un azione importante. [18] Figura 23: Il messaggio aiuta l'utente a capire dove ha sbagliato e come correggere l'errore. [19] 10) Documentazione: anche se il sistema dovrebbe essere usabile senza documentazione è preferibile che essa sia disponibile. Deve essere facile da reperire. Focalizzata sul compito dell utente Conclusioni In questo capitolo s è parlato dell usabilità dell OSS, di cos è e quali euristiche esistono per misurarla; senza però dimenticare che usabilità, fruibilità, sono tutti aspetti che, in un modo o nell altro, sfociano nel campo del marketing. Che piaccia o meno, se un prodotto risponde alle esigenze di usabilità degli utenti, se questi lo riescono ad usare 51

61 Capitolo 3 Usabilità senza problemi, se non si confondono nell utilizzarlo e se è dotato di quel qualcosa che alla concorrenza manca, allora è quasi certo che quel prodotto avrà successo sul mercato. E vero, questo non è sicuro e dipende da molti fattori, ma se è vero che il mercato è fatto da utenti, allora dovrà essere anche altrettanto vero che soddisfacendoli, si è già a metà dell opera. 52

62 Capitolo 4 IL MARKETING DEL ELL OSS L OSS I l marketing di un prodotto, che sia esso un OSS o un prodotto di consumo, è fondamentale per l azienda produttrice che ha intenzione di far conoscere il proprio prodotto. Qualsiasi operazione di marketing è regolamentata da un apposito piano operativo, che in gergo tecnico è noto come piano di marketing. Come detto in [26] il piano di marketing rappresenta la traduzione sul piano operativo degli obiettivi e delle strategie di marketing, ovvero è lo strumento formale di pianificazione delle decisioni, la cui formulazione e stesura consentono al management di definire in modo puntuale gli obiettivi, le strategie e gli strumenti operativi con i quali l azienda ha intenzione di operare. In particolare, esso viene redatto una volta all anno e sintetizza in quale modo l'impresa intende raggiungere obbiettivi strategici mediante programmi di marketing a livello di business unit (es. prodotti da forno) o singolo prodotto/marca (Kinder Ferrero) [27]. Come detto da Pegan in [27] la forma scritta è essenziale perché consente una più facile e rapida condivisione del piano a livello organizzativo, stabilisce con chiarezza le diverse responsabilità per il raggiungimento degli obiettivi, fornisce una memoria storica delle strategie di un prodotto. Quando il piano diventa operativo, i manager monitorano i risultati, li confrontano con le previsioni, analizzano eventuali discrepanze e, se necessario, intraprendano azioni correttive. A tal fine, è indispensabile stabilire le modalità di misurazione dei progressi che solitamente si basano sul budget, su schemi di pianificazione temporale o su standard di risultato. Tra le varie strategie di marketing esistente, due rivestono un ruolo molto importante: Definizione del mercato: Questa categoria comprende i seguenti aspetti: 53

63 Capitolo 4 Il marketing di un software Open Source o Ricerca dei mercati attrattivi 2 : in questa fase l azienda concentra la sua attenzione nella ricerca di mercati che siano interessati al suo prodotto; così che l offerta sia corrisposta da una congrua domanda; o Studio dei concorrenti: in questa fase è fondamentale analizzare il mercato per scoprire se vi sono delle società che producono dei software concorrenti e se vi sono, analizzare i prodotti per cercare di carpirne i punti deboli e per farlo ci si può anche avvalere di ciò che gli utenti scrivono sui forum e sui vari gruppi di discussione. o Identificazione di un servizio superiore: fondamentale nell analisi della concorrenza è quella di scovare quali aspetti del proprio prodotto risultano migliori rispetto a quelli delle aziende concorrenti e fare leva su questa superiorità. Nel far questo, si possono cercare di descrivere come nevralgiche al compimento di un task, le qualità che il nostro software possiede; o Analisi del fattore innovazione: definire quale aspetto del prodotto lo rende innovativo se paragonato agli altri e soprattutto indicare quali benefici, quest innovazione, porta all utente; tutto questo perché non bisogna dimenticarsi che il destinatario finale del prodotto sarà l utente che lo acquista e quindi l obiettivo dell azienda dovrà essere quello di dare al cliente l idea che si sta lavorando anche per massimizzare i suoi benefici; o Vuoti del mercato: nell analizzare il mercato, può capitare che ci si 2 Esempio di mercati attrattivi: Pubbliche amministrazioni; Ospedali; Enti/gestori discariche; Strutture alberghiere; Servizi di trasporto pubblico; Imprese edili; Aziende. 54

64 Capitolo 4 Il marketing di un software Open Source accorga che il prodotto che si sta commercializzando è unico nel suo genere. È indiscutibile che questo aspetto dev essere una leva per la commercializzazione del prodotto; se non altro perché va a colmare un vuoto del mercato; o Identificazione clienti: è importante capire quali saranno i destinatari dei nostri prodotti, poiché in base alle loro caratteristiche si può capire su quali aspetti far leva per commercializzare il prodotto. Ad esempio, la differenza tra end-users e developers sta sostanzialmente nel backgroud culturale/tecnologico, questa differenza porta l azienda a mettere in evidenza delle caratteristiche del prodotto che variano a seconda della categoria di utenti alla quele si rivolge. Ad un developers, infatti, interessa un grado di dettaglio maggiore rispetto all end-user. Identificazione dei benefici chiave: Questa categoria comprende: o identificazione dei bisogni del cliente: è fondamentale identificare quali sono i bisogni del cliente che vanno sopperiti. Questi bisogni possono essere ovvi, espliciti o impliciti, ma devono essere tutti analizzati con attenzione se si vuole che abbia successo il prodotto che si sta commercializzando ; o comunicazione dei plus del nostro prodotto: come detto anche in precedenza, oltre a identificare gli aspetti vincenti del nostro prodotto, è bene che questi siano resi noti, soprattutto nel confronto con la concorrenza, così che l utente finale si renda conto della superiorità del nostro prodotto. 4.1 Le 3 fasi di evoluzione del marketing Esistono 3 fasi di evoluzione del marketing all interno di un impresa: Marketing Analitico: il marketing analitico consiste in un insieme di tecniche e metodologie volte ad analizzare con metodi quantitativi -ed in qualche misura dunque oggettivi- il mercato, nella sua accezione più larga (dei clienti finali, o degli intermediari, ecc.) per mappare i desideri del cliente, od i suoi 55

65 Capitolo 4 Il marketing di un software Open Source comportamenti, e per conoscere gli ambiti di mercato già eventualmente occupati dai rivali diretti e indiretti. Il marketing analitico rappresenta dunque una della fasi di acquisizione della conoscenza, nell'ambito dei più generali processi di marketing. Marketing Strategico: il marketing strategico si basa sull'analisi dei bisogni degli individui e delle organizzazioni. Questo primo aspetto del processo di marketing riguarda anzitutto l'individuazione, all'interno del mercato di riferimento, dei prodotti-mercato e dei segmenti già esistenti o potenziali. Di questi il marketing strategico misura l'attrattività in termini quantitativi, qualitativi (con riferimento all'accessibilità al mercato) e dinamici (con riferimento alla durata economica che è rappresentata dal ciclo di vita del prodotto). Marketing Operativo: il marketing operativo è la parte finale dell'intero processo di marketing, a monte del quale ci sono le fasi di marketing analitico e marketing strategico. La componente operativa del marketing ha il compito di realizzare concretamente le strategie definite nelle fasi precedenti. Figura 24: I due aspetti del processo di marketing. [28] 56

66 Capitolo 4 Il marketing di un software Open Source Figura 25: Il processo di pianificazione di marketing. [28] Figura 26: Matrice di Ansoff. [28] 57

67 Capitolo 4 Il marketing di un software Open Source Figura 27: Classifica dei mercati - Mercato di Acquisto. [28] Figura 28: Classifica dei mercati - Mercato Potenziale. [28] 4.2 Il piano di marketing Il piano di marketing è un documento scritto che descrive la strategia di marketing che l azienda ha deciso di intraprendere per l anno in corso ma, più in generale, per il raggiungimento degli obiettivi che si è prefissata. Coem descritto in [26], il processo di stesura e di gestione del Piano di Marketing può essere rappresentato con uno schema circolare, noto come PDCA (vedi Figura 29). Acronimo di Plan, Do, Check, Act, questo schema comprende le seguenti fasi [26]: Pianificazione (Plan): in cui si definiscono gli obiettivi e si redige il documento; Implementazione (Do): nel corso della quale si sperimentano le decisioni di marketing mix; Controllo (Check): in cui si verifica l andamento del Piano di Marketing ed eventualmente si prevedono interventi correttivi; Esecuzione (Act): in cui si attua effettivamente il piano di marketing. 58