Realizzazione di una Wiki orientata ai Servizi

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Joomla! 2.5:Utenti e permessi - Il wiki di Joomla.it

Joomla! 2.5:Utenti e permessi - Il wiki di Joomla.it Pagina 1 di 6 Joomla! 2.5:Utenti e permessi Da Il wiki di Joomla.it. Traduzione (http://cocoate.com/it/j25it/utenti) dal libro Joomla! 2.5 - Beginner's Guide (http://cocoate.com/j25/users-permissions)

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

Guida al livellamento delle risorse con logica Critical Chain (1^ parte)

Guida al livellamento delle risorse con logica Critical Chain (1^ parte) Paolo Mazzoni 2011. E' ammessa la riproduzione per scopi di ricerca e didattici se viene citata la fonte completa nella seguente formula: "di Paolo Mazzoni, www.paolomazzoni.it, (c) 2011". Non sono ammesse

Dettagli

Alcune semplici definizioni

Alcune semplici definizioni Alcune semplici definizioni Un CMS (Content management system), in italiano Sistema di gestione dei contenuti è uno strumento software che si installa generalmente su un server web, il cui compito è facilitare

Dettagli

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

Dettagli

LA SOLUZIONE PER LA GESTIONE DINAMICA DELLE INFORMAZIONI IN UN PORTALE

LA SOLUZIONE PER LA GESTIONE DINAMICA DELLE INFORMAZIONI IN UN PORTALE LA SOLUZIONE PER LA GESTIONE DINAMICA DELLE INFORMAZIONI IN UN PORTALE WEBVISION APPARTIENE ALLA FAMIGLIA DEI CONTENT MANAGEMENT SYSTEM PER LA GESTIONE DINAMICA DELLE INFORMAZIONI E DEL LORO LAYOUT ALL

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

I modelli normativi. I modelli per l eccellenza. I modelli di gestione per la qualità

I modelli normativi. I modelli per l eccellenza. I modelli di gestione per la qualità 1 I modelli di gestione per la qualità I modelli normativi I modelli per l eccellenza Entrambi i modelli si basano sull applicazione degli otto principi del TQM 2 I modelli normativi I modelli normativi

Dettagli

Windchill PDMLink 9.0/9.1 Guida al curriculum

Windchill PDMLink 9.0/9.1 Guida al curriculum Windchill PDMLink 9.0/9.1 Guida al curriculum NOTA: per una rappresentazione grafica del curriculum in base al ruolo professionale, visitare la pagina: http://www.ptc.com/services/edserv/learning/paths/ptc/pdm_90.htm

Dettagli

Content Management Systems

Content Management Systems Content Management Systems L o Guido Porruvecchio Tecnologia e Applicazioni della Rete Internet Definizione Un Content Management System (CMS) è letteralmente un sistema per la gestione dei contenuti Definisce

Dettagli

Gestione dello sviluppo software Modelli Agili

Gestione dello sviluppo software Modelli Agili Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A4_3 V1.1 Gestione dello sviluppo software Modelli Agili Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

Differenza tra wordpress.com e CMS

Differenza tra wordpress.com e CMS Cosa è WordPress? 1 Differenza tra wordpress.com e CMS Il team di WP ha creato 2 siti differenti: wordpress.com ovvero un portale dove chiunque può creare un blog (gratuitamente) wordpress.org dove possiamo

Dettagli

La ricerca delle informazioni nei siti web di Ateneo con Google Search Appliance Progetto, implementazione e sviluppi

La ricerca delle informazioni nei siti web di Ateneo con Google Search Appliance Progetto, implementazione e sviluppi La ricerca delle informazioni nei siti web di Ateneo con Google Search Appliance Progetto, implementazione e sviluppi Il progetto del sistema di ricerca delle informazioni L'esigenza del sistema di ricerca

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesi di Laurea AUTENTICAZIONE PER APPLICAZIONI WEB Relatore

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 15: P.M.: metodologie di progetto Prof.ssa R. Folgieri email: folgieri@dico.unimi.it folgieri@mtcube.com 1 Modelli di conduzione

Dettagli

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso Agile mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software Sviluppo Agile: metaprocesso Molti progetti software falliscono Sì parte dagli anni 2000 Millennium

Dettagli

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti Sviluppo Agile [Cockburn 2002] Extreme Programming (XP) [Beck 2000] Sono più importanti auto-organizzazione, collaborazione, comunicazione tra membri del team e adattabilità del prodotto rispetto ad ordine

Dettagli

ISO Testing. Paolo Sammicheli precisamente dell'iso Testing.

ISO Testing. Paolo Sammicheli <xdatap1@ubuntu.com> precisamente dell'iso Testing. ISO Testing Paolo Sammicheli 2 Adesso parleremo dei TEST precisamente dell'iso Testing. in Ubuntu, e CICLI DI RILASCIO 3 Prima però, alcune premesse, per chi non fosse esperto di come

Dettagli

REPORT FINALE SUL PROGETTO CLUSTER OPEN SOURCE

REPORT FINALE SUL PROGETTO CLUSTER OPEN SOURCE REPORT FINALE SUL PROGETTO CLUSTER OPEN SOURCE Premessa Il presente report illustra il progetto Cluster Open Source, progetto che mira a sviluppare dinamiche distrettuali all interno del sistema produttivo

Dettagli

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito LEZIONE 3 Il pannello di amministrazione di Drupal, configurazione del sito Figura 12 pannello di controllo di Drupal il back-end Come già descritto nella lezione precedente il pannello di amministrazione

Dettagli

OGGETTO: Offerta per l integrazione Contenuti Festival del Lavoro sito Cdlpa.it

OGGETTO: Offerta per l integrazione Contenuti Festival del Lavoro sito Cdlpa.it Palermo, 30/01/2015 Spettabile CDL PALERMO c.a. Consigliere Alessi OGGETTO: Offerta per l integrazione Contenuti Festival del Lavoro sito Cdlpa.it Siamo lieti di presentarvi, nell offerta in oggetto, la

Dettagli

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo Progetto software 2008/2009 Docente Marianna Nicolosi Asmundo Obiettivi del corso Coinvolgervi nello sviluppo di un progetto software in cui mettere a frutto le conoscenze che avete acquisito durante i

Dettagli

MediaWiki. Giuseppe Frisoni

MediaWiki. Giuseppe Frisoni MediaWiki Giuseppe Frisoni MediaWiki: costruire insieme 1/2 L'enorme successo di Wikipedia, la nota enciclopedia online, è sotto gli occhi di tutti; cosa meno nota, invece, è la piattaforma con cui è progettata.

Dettagli

Componenti Web: client-side e server-side

Componenti Web: client-side e server-side Componenti Web: client-side e server-side side Attività di applicazioni web Applicazioni web: un insieme di componenti che interagiscono attraverso una rete (geografica) Sono applicazioni distribuite logicamente

Dettagli

catalogo corsi di formazione 2015/2016

catalogo corsi di formazione 2015/2016 L offerta formativa inserita in questo catalogo è stata suddivisa in quattro sezioni tematiche che raggruppano i corsi di formazione sulla base degli argomenti trattati. Organizzazione, progettazione e

Dettagli

Guida rapida all uso di Moodle per i docenti

Guida rapida all uso di Moodle per i docenti Guida rapida all uso di Moodle per i docenti Avvertenze: 1) Questo NON è un manuale completo di Moodle. La guida è esplicitamente diretta a docenti poco esperti che devono cimentarsi per la prima volta

Dettagli

PROGETTAZIONE DI UN SITO WEB

PROGETTAZIONE DI UN SITO WEB PROGETTAZIONE DI UN SITO WEB PROGETTAZIONE DI UN SITO WEB Fasi di progettazione Software: Analisi dei requisiti Analisi dei Requisiti Progettazione (Design) Progettazione (design) Sviluppo Test Manutenzione

Dettagli

Java e solidarietà: il progetto Jug4Tenda

Java e solidarietà: il progetto Jug4Tenda Java e solidarietà: il progetto Jug4Tenda www.jugancona.it Jug Marche Relatore: Andrea Del Bene Java e solidarietà: il progetto Jug4Tenda Agenda Storia del progetto Architettura Processo di sviluppo Riferimenti

Dettagli

Laboratorio Matematico Informatico 2

Laboratorio Matematico Informatico 2 Laboratorio Matematico Informatico 2 (Matematica specialistica) A.A. 2006/07 Pierluigi Amodio Dipartimento di Matematica Università di Bari Laboratorio Matematico Informatico 2 p. 1/1 Informazioni Orario

Dettagli

La metodologia del test con gli utenti adottata per Sapienza Università di Roma

La metodologia del test con gli utenti adottata per Sapienza Università di Roma La metodologia del test con gli utenti adottata per Sapienza Università di Roma Questo paper ha la finalità di illustrare come gli utenti web dell Università Sapienza di Roma abbiano partecipato al percorso

Dettagli

[Tips & Tricks] 8 settembre 2011

[Tips & Tricks] 8 settembre 2011 10 punti da non sottovalutare per aggiornare con WebSite X5 Evolution 9 i siti realizzati con WebSite X5 Evolution 8 Introduzione Uno dei dubbi che nascono quando viene rilasciata la nuova versione di

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

Maxpho Commerce 11. Gestione CSV. Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl

Maxpho Commerce 11. Gestione CSV. Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl Maxpho Commerce 11 Gestione CSV Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl Indice generale 1 - Introduzione... 3 1.1 - Il file CSV...3 1.2 - Modulo CSV su Maxpho... 3 1.3 - Modulo CSV Pro

Dettagli

11. Evoluzione del Software

11. Evoluzione del Software 11. Evoluzione del Software Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 11. Evoluzione del Software 1 / 21 Evoluzione del Software - generalità Cosa,

Dettagli

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA Service Oriented Architecture Ormai tutti, nel mondo dell IT, conoscono i principi di SOA e i benefici che si possono ottenere

Dettagli

13. Ciclo di Vita e Processi di Sviluppo

13. Ciclo di Vita e Processi di Sviluppo 13. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 13. Ciclo di Vita e Processi

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

Web Programming Specifiche dei progetti

Web Programming Specifiche dei progetti Web Programming Specifiche dei progetti Paolo Milazzo Anno Accademico 2010/2011 Argomenti trattati nel corso Nel corso di Web Programming sono state descritti i seguenti linguaggi (e tecnologie): HTML

Dettagli

Giuseppe Santucci. Qualità nella Produzione del Software

Giuseppe Santucci. Qualità nella Produzione del Software Giuseppe Santucci Qualità nella Produzione del Software 03 Revisione del contratto (Contract review) & Piani di sviluppo e qualità (Development and quality plans) 03CR&DQP.1 Contract review? Una cattiva

Dettagli

Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM.

Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM. Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM. La sfida Certificare il corretto montaggio dell impianto elettrico, escludendo la presenza di cortocircuiti

Dettagli

Plone all Università di Ferrara - Case Study

Plone all Università di Ferrara - Case Study Plone all Università di Ferrara - Case Study Francesco Margutti, Cesare Stefanelli, Luca Tebaldi Università di Ferrara, Italia {francesco.margutti, cesare.stefanelli, luca.tebaldi}@unife.it 1. L Università

Dettagli

Novell Vibe 3.3. Novell. 5 giugno 2012. Riferimento rapido. Avvio di Novell Vibe

Novell Vibe 3.3. Novell. 5 giugno 2012. Riferimento rapido. Avvio di Novell Vibe Novell Vibe 3.3 5 giugno 2012 Novell Riferimento rapido Quando si inizia a utilizzare il software Novell Vibe, è innanzitutto necessario configurare lo spazio di lavoro personale e creare uno spazio di

Dettagli

Altri metodi di indicizzazione

Altri metodi di indicizzazione Organizzazione a indici su più livelli Altri metodi di indicizzazione Al crescere della dimensione del file l organizzazione sequenziale a indice diventa inefficiente: in lettura a causa del crescere del

Dettagli

Soluzione Immobiliare

Soluzione Immobiliare SOLUZIONE IMMOBILIARE SOLUZIONE IMMOBILIARE è un software studiato appositamente per la gestione di una Agenzia. Creato in collaborazione con operatori del settore, Soluzione si pone sul mercato con l

Dettagli

CONTENT MANAGEMENT SYSTEM

CONTENT MANAGEMENT SYSTEM CONTENT MANAGEMENT SYSTEM P-2 PARLARE IN MULTICANALE Creare un portale complesso e ricco di informazioni continuamente aggiornate, disponibile su più canali (web, mobile, iphone, ipad) richiede competenze

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Novell Vibe OnPrem 3.1

Novell Vibe OnPrem 3.1 Novell Vibe OnPrem 3.1 27 giugno 2011 Novell Riferimento rapido Quando si inizia a utilizzare il software Novell Vibe OnPrem, è innanzitutto necessario configurare lo spazio di lavoro personale e creare

Dettagli

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Nel corso degli anni, nel passaggio dalla visione artigianale alla visione industriale del software, si è compreso che il processo andava formalizzato attraverso: un insieme

Dettagli

INTERNET EXPLORER. Breve manuale d'uso

INTERNET EXPLORER. Breve manuale d'uso INTERNET EXPLORER Breve manuale d'uso INDICE INTRODUZIONE... 3 COME IMPOSTARE LA PAGINA INIZIALE...3 LA WORK AREA... 3 LE VOCI DI MENU... 5 IL MENU FILE... 5 IL MENU MODIFICA... 6 IL MENU VISUALIZZA...

Dettagli

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

Dettagli

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Rischi 1 Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

L istruzione degli utenti e la promozione dei servizi delle biblioteche. Blog e wiki

L istruzione degli utenti e la promozione dei servizi delle biblioteche. Blog e wiki L istruzione degli utenti e la promozione dei servizi delle biblioteche Blog e wiki Biblioteca 2.0 la biblioteca sta cambiando l impatto del Web 2.0 (Open Acess, Wikis, Google book, blogosfera, Flickr,

Dettagli

WEB 2.0 PER CRESCERE. Sfruttare le potenzialità del Web 2.0 per far conoscere la Lunigiana

WEB 2.0 PER CRESCERE. Sfruttare le potenzialità del Web 2.0 per far conoscere la Lunigiana WEB 2.0 PER CRESCERE Sfruttare le potenzialità del Web 2.0 per far conoscere la Lunigiana Web 2.0 L'insieme di tutte quelle applicazioni online che permettono uno spiccato livello di interazione tra il

Dettagli

Presentazione della famiglia openshare 2.2. 4/30/2003 Infosquare.com 1

Presentazione della famiglia openshare 2.2. 4/30/2003 Infosquare.com 1 Presentazione della famiglia 2.2 4/30/2003 Infosquare.com 1 La piattaforma Un ambiente completo e versatile per la costruzione di portali aziendali Una piattaforma integrata di content management per raccogliere,

Dettagli

Corso: La pianificazione e la gestione dei progetti con Microsoft Project 2010 Codice PCSNET: AAAA-0 Cod. Vendor: - Durata: 3

Corso: La pianificazione e la gestione dei progetti con Microsoft Project 2010 Codice PCSNET: AAAA-0 Cod. Vendor: - Durata: 3 Corso: La pianificazione e la gestione dei progetti con Microsoft Project 2010 Codice PCSNET: AAAA-0 Cod. Vendor: - Durata: 3 Obiettivi Alla fine del corso i partecipanti saranno in grado di: Comprendere

Dettagli

L interfaccia di Mo-Net Rete Civica di Modena

L interfaccia di Mo-Net Rete Civica di Modena L interfaccia di Mo-Net Rete Civica di Modena L interfaccia di Mo-Net nasce dal recepimento degli stimoli e delle indicazioni prodotte a livello nazionale, europeo e internazionale in tema di accessibilità

Dettagli

Progetto DOCUMENTAZIONE MULTIMEDIALE ESPERIENZE DI PROGETTAZIONE CURRICOLARE. Tecnico-ricercatore referente: Claudia Perlmuter

Progetto DOCUMENTAZIONE MULTIMEDIALE ESPERIENZE DI PROGETTAZIONE CURRICOLARE. Tecnico-ricercatore referente: Claudia Perlmuter Progetto DOCUMENTAZIONE MULTIMEDIALE ESPERIENZE DI PROGETTAZIONE CURRICOLARE Tecnico-ricercatore referente: Claudia Perlmuter Le esperienze da multimedializzare Nell ambito del percorso di lavoro Documentare

Dettagli

PTDR Disaster Recovery for oracle database

PTDR Disaster Recovery for oracle database PTDR Disaster Recovery for oracle database INTRODUZIONE... 3 INTRODUZIONE... 3 I MECCANISMI BASE DI ORACLE DATA GUARD... 3 COSA SONO I REDO LOG?... 4 IMPATTO SULL'ARCHITETTURA COMPLESSIVA... 4 CONCLUSIONI...

Dettagli

Piattaforma ilearn di Hiteco. Presentazione Piattaforma ilearn

Piattaforma ilearn di Hiteco. Presentazione Piattaforma ilearn Presentazione Piattaforma ilearn 1 Sommario 1. Introduzione alla Piattaforma Hiteco ilearn...3 1.1. Che cos è...3 1.2. A chi è rivolta...4 1.3. Vantaggi nell utilizzo...4 2. Caratteristiche della Piattaforma

Dettagli

anthericacms Il sistema professionale per la gestione dei contenuti del tuo sito web Versione 2.0

anthericacms Il sistema professionale per la gestione dei contenuti del tuo sito web Versione 2.0 anthericacms Il sistema professionale per la gestione dei contenuti del tuo sito web Versione 2.0 Email: info@antherica.com Web: www.antherica.com Tel: +39 0522 436912 Fax: +39 0522 445638 Indice 1. Introduzione

Dettagli

proposte di progetto interpretare le proposte

proposte di progetto interpretare le proposte proposte di progetto a.a. 2003-2004 interpretare le proposte vengono date delle tracce su cui discutere è compito dei gruppi raffinare la proposta o modificarla durante la fase di inception un buon progetto

Dettagli

Relazione Su Soluzione Open Source Per Il Terzo Settore. a cura del Corso Sviluppatori Open Source per il Terzo Settore Polo di Bari

Relazione Su Soluzione Open Source Per Il Terzo Settore. a cura del Corso Sviluppatori Open Source per il Terzo Settore Polo di Bari Relazione Su Soluzione Open Source Per Il Terzo Settore a cura del Corso Sviluppatori Open Source per il Terzo Settore Polo di Bari Versione 1 Indice 1 Obiettivi......2 1.1 Problematiche del Terzo Settore....2

Dettagli

Six Sigma Handbook Gli strumenti sei sigma per raggiungere obiettivi, organizzativi e di qualità, ad alto impatto economico con l ausilio di Excel

Six Sigma Handbook Gli strumenti sei sigma per raggiungere obiettivi, organizzativi e di qualità, ad alto impatto economico con l ausilio di Excel Six Sigma Handbook Gli strumenti sei sigma per raggiungere obiettivi, organizzativi e di qualità, ad alto impatto economico con l ausilio di Excel di Rinaldo Tartari Consulente Qualità e Affidabilità Excel

Dettagli

Indice della presentazione. 1. Obiettivo del progetto. 2. Identificazione degli attori coinvolti. 3. Fasi del progetto. Tecnologie e Strumenti

Indice della presentazione. 1. Obiettivo del progetto. 2. Identificazione degli attori coinvolti. 3. Fasi del progetto. Tecnologie e Strumenti OGGETTO: PROGETTO TECO A ATTIVITÀ CINECA AUTORE: MAURO MOTTA Indice della presentazione 1. Obiettivo del progetto 2. Identificazione degli attori coinvolti 3. Fasi del progetto Tecnologie e Strumenti Il

Dettagli

Il modello di ottimizzazione SAM

Il modello di ottimizzazione SAM Il modello di ottimizzazione control, optimize, grow Il modello di ottimizzazione Il modello di ottimizzazione è allineato con il modello di ottimizzazione dell infrastruttura e fornisce un framework per

Dettagli

connessioni tra i singoli elementi Hanno caratteristiche diverse e sono presentati con modalità diverse Tali relazioni vengono rappresentate QUINDI

connessioni tra i singoli elementi Hanno caratteristiche diverse e sono presentati con modalità diverse Tali relazioni vengono rappresentate QUINDI Documenti su Internet LINGUAGGI DI MARKUP Internet permette (tra l altro) di accedere a documenti remoti In generale, i documenti acceduti via Internet sono multimediali, cioè che possono essere riprodotti

Dettagli

Alfresco ECM. La gestione documentale on-demand

Alfresco ECM. La gestione documentale on-demand Alfresco ECM La gestione documentale on-demand Alfresco 3.2 La gestione documentale on-demand Oltre alla possibilità di agire sull efficienza dei processi, riducendone i costi, è oggi universalmente conosciuto

Dettagli

Case Study. 2014 Deskero All rights reserved www.deskero.com

Case Study. 2014 Deskero All rights reserved www.deskero.com Case Study 2014 Deskero All rights reserved www.deskero.com Overview About Easydom Per adattarsi meglio alle esigenze specifiche del team tecnico Easydom, Deskero è stato completamente personalizzato,

Dettagli

INTERNET EXPLORER Breve manuale d uso

INTERNET EXPLORER Breve manuale d uso INTERNET EXPLORER Breve manuale d uso INDICE INTRODUZIONE... 3 COME IMPOSTARE LA PAGINA INIZIALE... 3 LA WORK AREA... 3 LE VOCI DI MENU... 5 IL MENU FILE... 5 IL MENU MODIFICA... 6 IL MENU VISUALIZZA...

Dettagli

PROGETTAZIONE B.I.M.

PROGETTAZIONE B.I.M. PROGETTAZIONE B.I.M. Building Information Modeling INTRODUZIONE: Negli ultimi anni, in architettura, ingegneria e nel mondo delle costruzioni è avvenuto un radicale cambiamento negli strumenti e nei metodi

Dettagli

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa La mia scuola ha un sito Web Presentazione del corso Contenuti e obiettivi del corso Imparare a lavorare con le metodologie dell ingegneria del

Dettagli

Sviluppo di applicazioni internet:

Sviluppo di applicazioni internet: Sviluppo di applicazioni internet: Rad versus approccio formale Mario Quirico 2 Come si fa a introdurre l'uso di tecniche formali nello sviluppo delle applicazioni internet senza incappare nelle spire

Dettagli

La prossima ondata di innovazione aziendale introdotta da Open Network Environment

La prossima ondata di innovazione aziendale introdotta da Open Network Environment Panoramica della soluzione La prossima ondata di innovazione aziendale introdotta da Open Network Environment Panoramica La crescente importanza dei ruoli assunti da tecnologie come cloud, mobilità, social

Dettagli

Vision. highlights. la soddisfazione di ampliare i confini dell azienda. Un portale che fa!

Vision. highlights. la soddisfazione di ampliare i confini dell azienda. Un portale che fa! la soddisfazione di ampliare i confini dell azienda Un portale che fa! Il portale aziendale è un luogo di lavoro. Gemino è un Portal Application ricco di contenuti applicativi pronti all uso! highlights

Dettagli

Moodle per docenti. Indice:

Moodle per docenti. Indice: Abc Moodle per docenti Indice: 1. 2. 3. 4. ACCEDERE ALL INTERNO DELLA PIATTAFORMA MOODLE. pag 1 INSERIRE UN FILE (es. Piano di lavoro e Programmi finali)... pag 4 ORGANIZZARE UN CORSO DISCIPLINARE (inserire

Dettagli

Obiettivi di accessibilità per l anno 2014

Obiettivi di accessibilità per l anno 2014 COMUNE DI BRUSAPORTO PROV. DI BG Obiettivi di accessibilità per l anno 2014 Redatto ai sensi dell articolo 9, comma 7 del decreto legge 18 ottobre 2012, n. 179. Redatto A MARZO 2014 Sommario Obiettivi

Dettagli

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Oggi più che mai, le aziende italiane sentono la necessità di raccogliere,

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

Generazione Automatica di Asserzioni da Modelli di Specifica UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore:

Dettagli

SISTEMA EDITORIALE WEBMAGAZINE V.2.2

SISTEMA EDITORIALE WEBMAGAZINE V.2.2 SISTEMA EDITORIALE WEBMAGAZINE V.2.2 1 - Il funzionamento di Web Magazine Web Magazine è un applicativo pensato appositamente per la pubblicazione online di un giornale, una rivista o un periodico. E'

Dettagli

Consulenza, servizi su misura e tecnologia a supporto del business.

Consulenza, servizi su misura e tecnologia a supporto del business. Consulenza, servizi su misura e tecnologia a supporto del business. ACCREDITED PARTNER 2014 Consulenza, servizi su misura e tecnologia a supporto del business. Gariboldi Alberto Group Srl è una realtà

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

OGGETTO DELLA FORNITURA...4

OGGETTO DELLA FORNITURA...4 Gara d appalto per la fornitura di licenze software e servizi per la realizzazione del progetto di Identity and Access Management in Cassa Depositi e Prestiti S.p.A. CAPITOLATO TECNICO Indice 1 GENERALITÀ...3

Dettagli

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

New Fire System. Manuale di istruzioni (Rev. 1.2)

New Fire System. Manuale di istruzioni (Rev. 1.2) New Fire System Manuale di istruzioni (Rev. 1.2) Indice 1. Accesso al sistema di Gestione Docente 3 Gestione dei moduli: Corsi Integrati 4 Logout 7 2. Avvisi Urgenti - NEWS 8 3. Orario delle lezioni 10

Dettagli

Leveling delle attività

Leveling delle attività Leveling delle attività Metodi per risolvere i conflitti di allocazione delle attività Allocare in modo non-uniforme Ritardare un attività Prima le attività con slack più alto Nel caso di attività con

Dettagli

02: Project Management

02: Project Management 02: Project Management Le tre P del project management Persone motivate / esperte SEI PM-CMM (People Management Capability Maturity Model) assunzione / selezione addestramento / cultura di gruppo stipendio

Dettagli

Configuratore di Prodotto Diapason

Configuratore di Prodotto Diapason Configuratore di Prodotto Diapason Indice Scopo di questo documento...1 Perché il nuovo Configuratore di Prodotto...2 Il configuratore di prodotto...3 Architettura e impostazione tecnica...5 Piano dei

Dettagli

Basi di Dati. Programmazione e gestione di sistemi telematici

Basi di Dati. Programmazione e gestione di sistemi telematici Basi di Dati. Programmazione e gestione di sistemi telematici Coordinatore: Prof. Paolo Nesi Docenti: Prof. Paolo Nesi Dr.sa Michela Paolucci Dr. Emanuele Bellini UML La prima versione ufficiale risale

Dettagli

Guida Ariel Studenti

Guida Ariel Studenti TECNOLOGIE E LA DIDATTICA UNIVERSITARIA MULTIMEDIALE E A DISTANZA Guida Ariel Studenti La logica della piattaforma e i suoi strumenti 9 agosto 2012 CTU -CENTRO DI SERVIZIO PER LE Struttura ad albero Ogni

Dettagli

Content Management Systems

Content Management Systems Content Management Systems Gabriele D Angelo http://www.cs.unibo.it/~gdangelo Università degli Studi di Bologna Dipartimento di Scienze dell Informazione Aprile, 2005 Scaletta della lezione

Dettagli

CICLO DELLE PRENOTAZIONI

CICLO DELLE PRENOTAZIONI CICLO DELLE PRENOTAZIONI UNA SFIDA ANTICA Quando nuove tecnologie raggiungono un alto livello di diffusione, si aprono solitamente nuovi campi di applicazione. La combinazione della diffusione della Telefonia

Dettagli

Creazione e gestione di indagini con Limesurvey. Sito online: www.limesurvey.org/en/

Creazione e gestione di indagini con Limesurvey. Sito online: www.limesurvey.org/en/ Creazione e gestione di indagini con Limesurvey Sito online: www.limesurvey.org/en/ Cos è Limesurvey? Il Software Limesurvey è un'applicazione open source che consente ai ricercatori (o a chiunque voglia

Dettagli