Realizzazione di una Wiki orientata ai Servizi

Transcript

1 Realizzazione di una Wiki orientata ai Servizi Progetto di Ingegneria del Software Alessandro Caponi Enrico Sasdelli Jacopo Zingoni

2 Realizzazione di una Wiki orientata ai Servizi: Progetto di Ingegneria del Software di Alessandro Caponi, Enrico Sasdelli, e Jacopo Zingoni Bozza di Relazione per la valutazione incrociata del 14 gennaio Pubblicato 14/01/2008

3

4 Sommario I. Bozza di Relazione - Progettazione di una Wiki Orientata ai Servizi Analisi dei Requisiti... 4 Prima Revisione dei Requisiti... 4 Obiettivo Generale e prima Analisi del Dominio... 4 Dichiarazione d Intento... 4 Requisiti Funzionali... 4 Requisiti Non Funzionali... 5 Analisi del dominio applicativo Decisioni iniziali & fase di Pre-Processo... 7 Prime Impressioni sull'architettura... 7 Confronto fra modelli... 7 Scelta della Famiglia del modello di processo... 7 AUP - Agile Unified Process Piano di Processo Iniziale Piano di Processo nella fase di Inception Scelta della piattaforma: DOKUWIKI e alternative analizzate Disamina delle alternative Stime Stima nella fase di Inception Stima del codice Stima dello Sforzo Analisi dei rischi Stima dei rischi Viste Architetturali - Modellazione base della piattaforma Analisi Strutturale Model View Controller Model View Controller Diagramma di sequenza I Requisiti Funzionali in dettaglio ACL Descrizione Specifica Controllo del Dominio Descrizione Specifica Recupero Password Descrizione Specifica Gestione dei privilegi utente ed upload allegati Descrizione Specifica Gruppi di utenti Descrizione Specifica Meccanismo di Versioning delle pagine Wiki Descrizione Specifica XHTML Descrizione Specifica Mailing List Descrizione Specifica iv

5 Realizzazione di una Wiki orientata ai Servizi Servizio di Trasformazione Allegati LaTeX e TEX in PDF... Descrizione... Trasformazione Allegati da LaTeX a PDF... Notifiche... Descrizione... Specifica... Templates... Descrizione... Specifica Qualcosa... Realizzazione ACL... Realizzazione del Controllo sul dominio di iscrizione... Realizzazione del sistema di recupero password... Realizzazione del sistema di gestione privilegi utenti e upload allegati... Allegare Documenti... Modifica dei permessi... Realizzazione del controllo gruppi utenti... Realizzazione del controllo Revisioni... Realizzazione del supporto alla sintassi XHTML... Realizzazione gestore mailing list... Realizzazione... Requisiti... Interfaccia... Funzionamento... Realizzazione sistema di notifiche utente... Realizzazione sistema per i template... Casi d'uso Project Management a Posteriori... Piano di Processo nella fase di Post-Architecture... Analisi dei Rischi a Posteriori Diari... Diario di Gruppo... Diario di Alessandro Caponi... Diario di Jacopo Zingoni... Diario di Enrico Sasdelli Controllo Qualità... Schede per il Controllo Qualità... Glossario... Bibliografia... v

6 Lista delle Tabelle 5.1. Early design cost driver Scale Factor Rischi di Progetto Rischi Tecnici Diario Diario Project Manager Diario Quality Engineer Diario Tool Specialist... vi

7 Parte I. Bozza di Relazione - Progettazione di una Wiki Orientata ai Servizi Progetto di Ingegneria del Software - Gruppo 10

8 Sommario 1. Analisi dei Requisiti... 4 Prima Revisione dei Requisiti... 4 Obiettivo Generale e prima Analisi del Dominio... 4 Dichiarazione d Intento... 4 Requisiti Funzionali... 4 Requisiti Non Funzionali... 5 Analisi del dominio applicativo Decisioni iniziali & fase di Pre-Processo... 7 Prime Impressioni sull'architettura... 7 Confronto fra modelli... 7 Scelta della Famiglia del modello di processo... 7 AUP - Agile Unified Process Piano di Processo Iniziale Piano di Processo nella fase di Inception Scelta della piattaforma: DOKUWIKI e alternative analizzate Disamina delle alternative Stime Stima nella fase di Inception Stima del codice Stima dello Sforzo Analisi dei rischi Stima dei rischi Viste Architetturali - Modellazione base della piattaforma Analisi Strutturale Model View Controller Model View Controller Diagramma di sequenza I Requisiti Funzionali in dettaglio ACL Descrizione Specifica Controllo del Dominio Descrizione Specifica Recupero Password Descrizione Specifica Gestione dei privilegi utente ed upload allegati Descrizione Specifica Gruppi di utenti Descrizione Specifica Meccanismo di Versioning delle pagine Wiki Descrizione Specifica XHTML Descrizione Specifica Mailing List Descrizione Specifica Servizio di Trasformazione Allegati LaTeX e TEX in PDF

9 Bozza di Relazione - Progettazione di una Wiki Orientata ai Servizi Descrizione... Trasformazione Allegati da LaTeX a PDF... Notifiche... Descrizione... Specifica... Templates... Descrizione... Specifica Qualcosa... Realizzazione ACL... Realizzazione del Controllo sul dominio di iscrizione... Realizzazione del sistema di recupero password... Realizzazione del sistema di gestione privilegi utenti e upload allegati... Allegare Documenti... Modifica dei permessi... Realizzazione del controllo gruppi utenti... Realizzazione del controllo Revisioni... Realizzazione del supporto alla sintassi XHTML... Realizzazione gestore mailing list... Realizzazione... Requisiti... Interfaccia... Funzionamento... Realizzazione sistema di notifiche utente... Realizzazione sistema per i template... Casi d'uso Project Management a Posteriori... Piano di Processo nella fase di Post-Architecture... Analisi dei Rischi a Posteriori Diari... Diario di Gruppo... Diario di Alessandro Caponi... Diario di Jacopo Zingoni... Diario di Enrico Sasdelli

10 Capitolo 1. Analisi dei Requisiti Prima Revisione dei Requisiti Obiettivo Generale e prima Analisi del Dominio Si richiede la specifica e la progettazione di un wiki orientato ai servizi, utile per far collaborare docenti e studenti del corso di Ingegneria del software. Per wiki orientato ai servizi è da intendersi un wiki capace di automatizzare alcune operazioni fino a gestire veri e propri workflow. Dichiarazione d Intento Il gruppo punterà a realizzare la specifica e la progettazione di un wiki orientato ai servizi basandosi sull integrazione, tramite web services appropriati, delle funzionalità di una wiki lightweight. Requisiti Funzionali Funzionalità Base Accesso in lettura alla conoscenza immagazzinata nel wiki Editing on-the-fly delle varie entry del wiki, utilizzando un linguaggio di markup semplificato Creazione di link per connettere le varie entry della wiki Visualizzazione dei backlink (riferimenti) relativi ad ogni voce Funzionalità di ricerca per trovare una wiki-entry di interesse specifico. Timestamp associati ad ogni voce. Sistema di controllo degli accessi con funzionalità di registrazione e autenticazione utenti. Sistema di Versioning con possibilità di visionare la history delle pagine e ripristinare vecchie versioni Inserimento di immagini e tabelle all interno delle voci Funzionalità di amministrazione (super-utente) Funzionalità Avanzate Possibilità di creare gruppi di utenti Possibilità di associare diversi permessi di lettura/scrittura ad una specifica voce a seconda dell utente o del suo gruppo di appartenenza Sistema di visualizzazione delle differenze fra due diverse versioni della stessa pagina wiki Funzionalità di editing avanzate (ad es. creazione automatica di una TOC) Possibilità di effettuare upload di file binari e di associarli ad una specifica pagina wiki Possibilità di avere permalink per una specifica entry 4

11 Analisi dei Requisiti Sistema di templates, ovvero pagine speciali prefabbricate rese disponibili per velocizzare e standardizzare la creazione di contenuti Servizi Gestione automatizzata della registrazione e della mailing list, fornita di sistemi anti-bot e di prevenzione dello spam. Sistema di notifica delle revisioni apportate ad un specifico insieme di pagine, configurabile a seconda delle esigenze e degli interessi dell utente. Sistema automatico di conversione dei file precedentemente uploadati (es: LaTeX2Pdf) Sistema di intercomunicazione fra più wiki Interfacciamento con un servizio di versioning (quali CVS o SVN) eventualmente messo a disposizione dal dipartimento. Supporto per plugin ed eventuali altre funzionalità aggiuntive Requisiti Non Funzionali La wiki deve rispondere alle esigenze di collaborazione docenti e studenti in un corso di Ingegneria del Software. Dovrebbe pertanto: Rispondere alle esigenze di gestione dei workflow tipici di un corso di studi Aderire a tutti gli standard riconosciuti nell ambito del Web. Fare un uso appropriato dei livelli di indirezione in modo da avere un architettura della parte serviceoriented tale da consentirne il riuso nel caso di cambiamenti del motore wiki utilizzato. Inoltre si auspica che il sistema progettato possa essere: Contraddistinto dalla facilità d uso per tutte le categorie di utenti, in modo da diminuire il carico cognitivo necessario per la sua utilizzazione da parte di ognuno degli stakeholders. Semplice da installare, integrare con i servizi dipartimentali e mantenere, nonché da re-istanziare ad ogni successivo anno del corso. Analisi del dominio applicativo Prima di iniziare la progettazione software è necessario aver chiaro il contesto e la natura del problema che si sta affrontando. Il contesto del quale farà parte questo software è quello di un corso di ingegneria del software. Il software deve permettere la comunicazione asincrona fra studenti e docenti, presentando documenti che riguardano le lezioni, i progetti degli studenti relativi al corso e discussioni sugli argomenti trattati. Inoltre si deve dare la possibilità agli studenti di avere spazi personali da gestire o quant'altro sia necessario per il buon svolgimento dell'attività didattica. Il progetto inoltre consiste nel migliorare questo software community oriented aggiungendo degli automatismi che permettano di velocizzare e migliorare l'interfaccia tra gli utenti (studenti,docenti,amministratori) ed il software. Viste, dunque le necessità appena descritte e visto che negli ultimi anni si sono viste le ottime capacità in questo senso, anche nel contesto universitario, si è scelto che la piattaforma devbba essere Wiki. Wiki è un sito web (o comunque una collezione di documenti ipertestuali) che permette a ciascuno dei suoi utilizzatori di aggiungere contenuti, come in un forum, ma anche di modificare i contenuti esistenti inseriti da altri utilizzatori. Wiki è nato etimologicamente dalla parola hawaiiana Wiki Wiki che significa rapido. Infatti è proprio la velocità con cui si inseriscono i contenuti che lo rende 5

12 Analisi dei Requisiti particolarmente indicato per essere utilizzato in un contesto universitario e, con le modifiche da apportare in questo progetto, renderlo veloce anche nell'eseguire quei task che sono frequenti in un wiki legato ad un corso di ingegneria del software 6

13 Capitolo 2. Decisioni iniziali & fase di Pre-Processo Scelta del modello di processo e prime speculazioni sull'architettura Prime Impressioni sull'architettura In concomitanza con questa prima analisi dei requisiti, abbiamo iniziato a pensare a grandi linee a quale dovesse essere l'architettura della nostra wiki orientata ai servizi. Considerando che al momento di questa prima fase di brainstorming i requisiti erano ancora in attesa di definizione, il gruppo non era nella condizione di prendere già decisioni informate, ma era possibile comunque fare delle ipotesi. Abbiamo infatti supposto che la maggior parte delle funzionalità richieste potessero già essere disponibili fra le feature dei software wiki pubblicamente disponibili, e che i requisiti non soddisfatti da quanto già a nostra disposizione potessero essere da noi progettati sotto forma di moduli aggiuntivi da integrare tramite SOA o un altro classico meccanismo di estensione. Ipotizzando quindi di trovare una wiki dalla struttura leggera e modulare, il nostro sforzo sarebbe pertanto dovuto andare in due direzioni. Infatti la comprensione e la modellazione della piattaforma architetturale di base (inclusa una verifica delle sue funzionalità), ci sarebbe stato necessario per poter comprendere come meglio progettare i servizi aggiuntivi da fornire, e come interfacciare queste estensioni con la wiki principale. Abbiamo pertanto escluso di dover progettare fin dalla partenza un intero software wiki, anche perchè, non comprendendo il progetto alcuna parte implementativa, ci sarebbe stato il concreto rischio della minimizzazione di funzioni o moduli invece necessari, mentre l'idea di vedere e confrontare un codice già testato con le nostre idee ci sembrava didatticamente più significativa. Questa prima asserzione, per quanto possa sembrare scontata, ci è stata necessaria per fare una prima stima (a grandissime linee) del carico di lavoro che ci attendeva, e per regolarci nella prima importante decisione del progetto: quella del modello di processo a cui attenersi Confronto fra modelli Scelta della Famiglia del modello di processo Data come ovvia l'indispensabilità di aderire ad un qualche tipo di modello di processo di sviluppo software nel corso di questo progetto, si poneva il problema di quale scegliere. Al fine di effettuare una scelta informata e ponderata che risultasse la migliore per il nostro progetto, ci siamo attentamente informati e documentati sulle alternative disponibili. In ogni caso, il primo passo sarebbe consistito nello scegliere la tipologia di modello di processo da adottare, ovvero la famiglia di modelli di sviluppo di riferimento. Riepiloghiamo qui le alternative principali Modelli a Cascata Come ad esempio i modelli Waterfall e Sharktooth, si tratta di modelli processo in cui le fasi di specifica, progettazione e sviluppo sono rigidamente formalizzate e soprattutto nettamente separate l'una dalle altre. Solitamente sono piuttosto sequenziali, e non prevedono di ritornare a riesaminare aspetti dello sviluppo già dichiarati come conclusi. Modelli a Spirale I modelli a spirale come il noto RUP - Rational Unified Process hanno invece una filosofia completamente differente. In questi modelli il processo di sviluppo software è visto come un ciclo continuo suddivisibile in diverse iterazioni, e le 7

14 Decisioni iniziali & fase di Pre-Processo attività di specifica e sviluppo sono accorpate e reiterate fino al raggiungimento del risultato desiderato. Modelli Agili I modelli di sviluppo agile, come il Feature Driven Development o l'agile Unified Process sono quella famiglia di modelli che si rifanno ai principi dell'agile Manifesto. Si tratta principalmente di modelli che enfatizzano il principio di adattività (rispetto ai cambiamenti) piuttosto che la pre-pianificazione. Condividono con i modelli a spirale il concetto di iterazione delle attività di specifica, progettazione e sviluppo, ma di solito sono caratterizzati da una minore formalzizazione e rigidità in queste iterazioni. In questa categoria viene solitamente inserito anche l'extreme Programming, anche se è una pratica di sviluppo sostanzialmente diversa dagli altri modelli agili. Modelli a Sviluppo Formale e Modelli orientati alla qualità Trattasi di modelli o basati su una modellazione matematica del sistema poi trasformata in implementazione, come ad esempio Z, oppure su una precisa quantificazione di alcuni fattori del modello di sviluppo tramite l'uso di standard internazionali, come ad esempio gli standard ISO. Scartati a priori come non adatti al nostro progetto. Modelli non strutturati Tutti gli altri tipi di processo di sviluppo software non strutturati, come ad esempio il famigerato ciclo edit-compiletest. Scartati a priori come non significativi o perchè troppo orientati verso la pratica del cosiddetto cowboy coding Dopo una prima analisi della situazione, abbiamo deciso di escludere dalla rosa delle potenziali scelte anche i modelli sequenziali a cascata. Riteniamo che, essendo questi modelli solitamente usati per progetti di grandi dimensioni e molto strutturati, dove anche il processo di sviluppo deve rispettare precise norme qualitative o legislative imposte dal committente, non siano i più adatti per un lavoro come il nostro, che invece è un progetto di piccole dimensioni pensato per essere portato avanti da un piccolo team. A questo punto le possibilità si erano ridotte fra la famiglia dei modelli iterativi a spirale, il cui candidato principale era il Rational Unified Process o RUP, già presentato e analizzato durante il ciclo di lezioni, oppure un metodo appartenente alla tipologia dei modelli agili. Ci sono alcune considerazione da fare riguardo a RUP: Prima di tutto, non si tratta di un modello di processo già pronto per essere usato, quanto piuttosto di un completo framework adatto a modellare un processo di sviluppo software secondo una filosofia riconducibile ai modelli a spirale. Consente quindi di essere adattato per un singolo progetto a seconda del suo tipo e delle sue dimensioni (al contrario, ad esempio, della maggior parte dei modelli a cascata). Tuttavia, il modello RUP è più frequentemente adottato nel corso di progetti software di notevoli dimensioni, poichè, seppure con le sue positive caratteristiche quali un eccellente sistema di risk management, la grande chiarezza della documentazione e l'ampia disponibilità di letteratura specifica, non sempre viene visto di buon occhio dagli sviluppatori. Infatti fra le comuni critiche rivolte a RUP: Eccessivamente burocratico: un processo per ogni attività, è molto strutturato e rigoroso. Gran numero di artefatti e deliverables intermedi richiesti per soddisfare i requisiti del modello. E' molto poco adattivo rispetto ai cambiamenti rispetto ai modelli agili. Nello specifico, le procedure per effettuare dei cambiamenti o dei refactoring in RUP coinvolgono tutte le discipline, e non sempre sono risolvibili in una singola iterazione. Overhead eccessivo causato da quella che viene definita una "dogmatizzazione cerimoniale" del modello di processo: lunghi periodi dedicati a razionalizzare, motivare, documentare e relazionare sulle attività. 8

15 Decisioni iniziali & fase di Pre-Processo Prima di poter iniziare ad usare RUP è necessario adattarlo con precisione al proprio progetto, altrimenti si rischiano di ottenere risultati controproducenti. Non è quindi un modello di processo utilizzabile immediatamente ("out of the box"), ed errori nell'adattare il framework di RUP alle proprie esigenze possono avere gravi conseguenze. Per le ragioni sopra elencate, abbiamo deciso di esaminare le alternative presentate dai modelli sviluppo agile. I modelli di sviluppo agile sono appunto più adattivi, ed hanno dimostrato di essere molto efficaci in ambiti di dimensioni ridotte (in termini di dimensioni del codice e del team di sviluppo) più assimilabili al nostro. Perchè un modello agile? Perchè cerchiamo di ovviare ai difetti sopra presentati e sfruttrare invece alcune delle caratteristiche vincenti dei modelli agili: I modelli agili sono sempre basati su un approccio iterativo ed incrementale allo sviluppo software, ma sono molto meno basati sulla pianificazione a monte, quanto piuttosto sulla loro capacità di adattamento rispetto alle richieste degli stakeholders. I processi risultano altamente collaborativi, enfatizzano l'interazione con il committente e sono focalizzati su piccoli team in grado di organizzarsi da soli ed in grado di rispondere in breve tempo a cambiamenti nei requisiti. Adottano la filosofia del "quello che basta" (just enough) in termini di burocrazia, artefatti intermedi prodotti, al fine di ridurre il più possibile l'overhead della fase di management. Non vanno confusi con metodi non strutturati, in quanto hanno comunque delle pratiche ben definite e degli approcci standardizzati di risoluzione dei problemi. La fase di modellazione e progettazione NON è trascurata o assente. Enfatizzano la velocità nel produrre release o piccoli deliverable in brevi lassi di tempo, (settimane anzichè mesi) e puntano tanto sulla cost-effectiveness del processo quanto sulla rapidità dello sviluppo. La nostra scelta è quindi ricaduta sui modelli agili, ma in particolare su un modello agile che pur aderendo completamente ai principi dell'agile manifesto, presenta molte similitudini con il RUP (di cui cerca di conservare pregi e struttura base). Si tratta infatti di una "agilizzazione" ed una semplificazione del modello RUP: stiamo parlando di AUP - Agile Unified Process AUP - Agile Unified Process L'Agile Unified Process, così come descritto dal suo ideatore, Scott Ambler, descrive un approccio semplice e di facile comprensione allo sviluppo software usando tecniche e metodologie agili, come ad esempio l'agile Modeling o l'agile Change Management, ma allo stesso tempo applicandole a quelli che sono i concetti base del RUP, la cui struttura di base viene mantenuta, anche se in maniera semplificata Come il RUP, l'aup è basato su un modello a spirale Serial in the large, Iterative in the small. La filosofia di base è sempre quella di dividere il processo di sviluppo in varie fasi, ognuna affrontata in molteplici cicli di sviluppo che coinvolgono diverse discipline. Le fasi del processo sono le stesse di RUP, ovvero: 1. Inception: Il cui obiettivo è identificare i goal e le dimensioni del progetto, nonchè una potenziale architettura per il sistema 2. Elaboration: In cui l'obiettivo è modellare e progettare l'architettura del software 3. Construction: In cui l'obiettivo è di fornire release successive del sistema software, incrementando man mano il grado di funzionalità ed il numero di feature presenti, nell'ordine di importanza stabilito dagli stakeholders. 4. Transition: In cui il progetto viene concluso con la validazione delle funzionalità e la consegna agli stakeholders. 9

16 Decisioni iniziali & fase di Pre-Processo Invece, una delle principali differenze fra RUP ed AUP sta nel numero di discipline modellate. Entrambi mantengono lo stesso numero di discipline di supporto da tenere in considerazione, ovvero Configuration Management, Project Management ed Environmental Management (o Environment) ma invece cambia il numero di discipline di progettazione vere e proprie, che viene ridotto da 6 a 4. Con più precisione, le discipline di Business Modelling, Requirements e Analyis vengono tutte accorpate nell'unica disciplina chiamata Model. Di seguito, un brevissimo riassunto sulle discipline principali di AUP: Model Il cui scopo è comprendere il modello realizzativo, il dominio applicativo, analizzare i requisiti richiesti, e di identificare e progettare soluzioni che consentano di raggiungere gli obiettivi richiesti. Implementation Il cui scopo è di trasformare i modelli strutturali in codice eseguibile e di effettuare i testing più basilari, in particolare lo unit test. Test Il cui scopo è di accertarsi della qualità del risultato finale, e di trovare ed eliminare difetti da correggere nelle iterazioni successive Deployment Il cui scopo è pianificare la consegna (o l'installazione) del software nei confronti degli utenti finali Altre caratteristiche di AUP sono il ridotto numero di artefatti richiesto rispetto al RUP, la focalizzazione su un ridotto numero di release (di due tipi, development e public) ma ad intervalli regolari e man mano più ravvicinati, secondo il principio della consegna di release dalle funzionalità incrementali nel tempo. Inoltre, fra le altre filosofie di AUP troviamo la la semplicità nella documentazione, principio per il quale una attività è descritta in poche pagine, non migliaia, e l'aderenza ai principi dell'agile alliance e dell'agile manifesto. L'Agile Unified Development ha poi altri pregi, vuoi nell'ambito dei modelli agili che rispetto al RUP. Innanzitutto, è completamente customizzabile ed adattabile alle esigenze del progetto, ed è possibile quindi rimodellarne il framework principale a seconda delle proprie necessità (proprio come RUP), ma a differenza di RUP è un sistema già pronto per essere usato anche con pochissimi cambiamenti. Inoltre è completamente Tool-indipendent, sia che si tratti di linguaggio di programmazione, strumenti di sviluppo, o specifiche tecnologie utilizzate. 10

17 Capitolo 3. Piano di Processo Iniziale Piano di Processo nella fase di Inception Dopo aver deciso che il modello di processo seguito è quello dell'aup si è ripartito il progetto in attività, compiti chiave per il corretto svolgimento del processo produttivo. Lo scopo del progetto ed il modello scelto, hanno permesso di poter avere una discreta libertà di azione, difatti si sono presentate poche dipendenze reciproche tra le varie attività del progetto. Le unità lavoro nel piano iniziale sono state assegnate in base ai limiti imposti dal cliente, che, oltre ad aver fissato la scadenza del progetto, ha fissato alcune delle scadenze chiave del progetto, dettando con ciò la tempistica stessa delle macroattività. Il meccanismo di feedback della situazione nelle varie mansioni è stato costante, attraverso lo scambio di e riunioni. Il Work Breakdown Structure che segue descrive i prodotti, i requisiti e le caratteristiche del piano di processo che è stato adottato: Segue il Gantt di pianificazione iniziale: 11

18 Piano di Processo Iniziale I deliverable di questo piano sono le documentazioni prodotte e alla fine di quale fase o macrofase: Elicitazione e valutazione dei requisiti, Stima dei costi/tempi, diagrammi UML dei casi d'uso e attività. Inception Valutazione dei rischi. Definizione dei rischi Diagrammi Architetturali. Identificazione e validazione architettura dell'architettura Diagrammi UML Classi e sequenza. Modellazione 12

19 Capitolo 4. Scelta della piattaforma: DOKUWIKI e alternative analizzate Scrivere e Raccontare qui quello che abbiamo fatto Disamina delle alternative Fin da quando l'argomento del progetto, ovvero la creazione di una wiki orientata ai servizi, è stato reso di dominio pubblico, il nostro team ha iniziato a vagliare alcune alternative su cui basare il nostro lavoro. Si rende innanzitutto necessario scegliere quale sistema wiki arricchire dei nuovi servizi. Quindi, in attesa che i requisiti venissero definitivamente approvati da tutti i gruppi, abbiamo iniziato una fase di documentazione sull'oggetto del nostro lavoro, ovvero i sistemi per wiki, in modo da procedere in parallelo con la nostra parte di revisione dei requisiti del progetto. Avevamo quindi una serie di alternative da analizzare, alla ricerca di un wiki che potesse adattarsi alle nostre esigenze. Queste sono riassumibili in una serie di caratteristiche che un ideale wiki alla base del nostro progetto avrebbe dovuto avere: Open Source: Per i nostri scopi avere accesso al sorgente del software è assolutamente indispensabile, come d'altronde è facile intuire, essendo fra i nostri obiettivi anche la descrizione dell'architettura del wiki. E' altresì fondamentale che il wiki da noi esaminato non sia un progetto incompleto o ormai abbandonato. Architettura Espandibile: Dovendo progettare un piccolo insieme di web services aggiuntivi, sarebbe meglio se il wiki che useremo come punto di partenza per il nostro lavoro avesse una struttura già predisposta ad un estensione delle sue funzionalità, almeno per quanto possibile. In generale, un wiki che abbia un supporto nativo per il meccanismo dei plugin, o che abbia una architettura software caratterizzata da moduli con un basso grado di accoppiamento. Lightweight: Fin dai requisiti iniziali del progetto è detto chiaramente che si tratta di un wiki «per far collaborare docenti e studenti di un corso di Ingegneria del Software». Si tratta quindi di specificare e progettare un wiki di dimensioni medio-piccole, che possibilmente disponga di una serie di feature utili per il suo utilizzo nell'ambito previsto, ma non appesantito da una pletora di funzionalità o caratteristiche poco significative (una piattaforma integrata per CMS-wiki-blogging è probabilmente un software interessante, ma non è una buona base per il nostro progetto). Proprio per queste ragioni abbiamo ritenuto utile focalizzare la nostra ricerca su un wiki di tipo lightweight (letteralmente: di peso leggero), nella speranza di trovare un sistema funzionale e minimale allo stesso tempo, che però mantenesse tutte le caratteristiche richieste, senza quindi scendere in una situazione di mancanza di funzionalità. Un sistema lightweight riduce anche il carico di risorse richieste per poter operare. Documentazione (Interna ed Esterna): Al fine di facilitare il nostro lavoro, il wiki da noi scelto come punto di partenza dovrebbe avere un quantitativo di documentazione (sia interna che esterna al codice) tale da facilitarci nella comprensione del suo funzionamento, della sua architettura, ed in generale in tutta quell'opera di reverse engineering che siamo chiamati a svolgere durante il progetto. Facilità di Installazone, Uso e Manutenzione: E' abbastanza auspicabile che un sistema software sia facilmente utilizzabile, sia per i suoi utenti che per i suoi amministratori. Questo è tanto più vero quando si sta esaminando un wiki il cui ambiente d'uso prefigurato è all'interno di un ambiente didattico: minore è la complessità cognitiva richiesta per padroneggiare lo strumento, maggiore sarà il tempo che gli utenti di ogni ordine e grado potranno investire nell'attività didattiche vere e proprie. In aggiunta, un sistema che abbia bassi requisiti hardware appesantirà meno le risorse dipartimentali. Grado di supporto nativo per i requisiti (funzionali e non): Ritenendo che non sia molto sensato «"reinventare la ruota"», abbiamo ovviamente cercato di trovare un software wiki che soddisfacesse 13

20 Scelta della piattaforma: DOKUWIKI e alternative analizzate il maggior sottinsieme possibile dei requisiti funzionali, dandoci così modo di focalizzare i nostri sforzi sullo sviluppo dei servizi veri e proprio, piuttosto che sulla rimodellazione delle funzionalità base. Abbiamo inoltre adattato le nostre scelte man mano che i requisiti funzionali venivano revisionati e finalizzati dall'insieme dei gruppi partecipanti al progetto. Linguaggio di Programmazione: Anche il linguaggio di programmazione usato per l'implementazione del wiki è un fattore da considerare. Il wiki dovrebbe essere quindi implementato usando un linguaggio che almeno consenta un certo grado di impostazione Object-Oriented, pertanto linguaggi come Perl e, in misura minore, Python sono stati ritenuti inadatti. Allo stesso modo sono stati esclusi tutti quei linguaggi che risultano poco familiari ai componenti del team di sviluppo, come ad esempio Ruby, VB.Net o Lisp. Aderenza agli Standard: Visto il ruolo didattico che la wiki andrà a svolgere, ci è sembrato necessario orientarci fin da subito un un sistema software che aderisse agli standard web, aspettandoci inoltre che questa caratteristica venisse inserita (come poi è successo) fra i requisiti non-funzionali del progetto. Alcuni suggerimenti erano già stati offerti dal committente nel corso delle lezioni o nella prima bozza dei requisiti. Fra questi, merita sicuramente di essere citato il noto MediaWiki, che è il motore wiki usato dalla fondazione Wikimedia e da Wikipedia. Sicuramente Mediawiki è uno dei wiki più diffusi, meglio documentati e con alle spalle una delle comunità più attive del panorama open-source, e recentemente ha ricevuto una sostanziale revisione che lo ha portato ad adottare php5 come base dell'implementazione (pur mantenendo parti scritte in OCaml). Tuttavia MediaWiki è anche la wiki più "pesante" e complessa a disposizione, tanto che (come recita d'altronde l'articolo autoreferenziale presente su wikipedia) spesso viene utilizzata anche come content management system. Mediawiki è un progetto di grandi dimensioni, sia in termine di righe di codice, che di complessità, ed ha dei requisiti piuttosto elevati per funzionare, necessitando sia di php5 che di un database SQL, che viene usato come storage delle pagine wiki. Insomma, è tutto tranne che "lightweight". Per dirla con le parole del nostro PM «"Usare MediaWiki mi sembra come sparare ai canarini con un cannone"», e riteniamo sia una metafora efficace per indicare la nostra perplessità nell'usare questo wiki come base per il lavoro. Elencate tutte queste ragioni, abbiamo deciso di proseguire nella nostra ricerca e di considerare MediaWiki come extrema ratio nel caso la nostra ricerca non ci avesse fornito migliori soluzioni. Altre alternative proposte erano TWiki e Deki Wiki. La prima è la wiki attualmente utilizzata dal nostro corso, verso la quale un po' tutti noi siamo abbastanza critici, sia per alcune sue carenze, sia per la sua usabilità alquanto discutibile (ad esempio nella visualizzazione delle revisioni). Inoltre, essendo implementata in PERL, non soddisfa uno dei nostri requisiti interni. Deki Wiki invece non è altro che un fork (meno mantenuto) del progetto di Media Wiki, ed è stato rigettato proprio per questa sua parentela, nonchè per una nostra preferenza nell'usare i filoni di sviluppo principali di un progetto, piuttosto che dei rami alternativi o dei wiki-clone. Un altro progetto interessante dai noi esaminato è stato TikiWiki, ma comunque le sue caratteristiche sono molto simili a quelle di MediaWiki, pregi e difetti relativi al nostro ambito d'uso inclusi. PhPWiki, un clone PhP del primo software wiki, è stato altresì scartato, così come MoinMoin, quest'ultima perchè scritta in Python Proseguendo nelle ricerche, siamo riusciti a trovare alcuni software wiki che potessero potenzialmente corrispondere al nostro wiki ideale (o che almeno rispondessero il più possibile a quelle caratteristiche precedentemente elencate). In particolare abbiamo deciso di porre particolare enfasi a quelle wiki che potessero essere considerate più lightweight delle altre. L'idea di fondo era di avere a disposizione un piccolo wiki core che contenesse tutte le funzionalità base richieste dai requisiti (ancora non finalizzati), che allo stesso tempo avesse la possibilità di essere esteso tramite uno più plugin da noi progettati al fine di fornire i web services richiesti. Fra questi tipi di wiki, sono emersi tre candidati principali: TiddlyWiki, assimilabile al genere delle cosiddette Guerrilla Wiki, è una wiki realizzata in javascript (tecnologia AJAX) in cui tutti le funzioni ed i dati sono contenuti all'interno di un 14