Realizzazione di una Wiki orientata ai Servizi

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

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

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

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

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

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

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

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

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

Le funzionalità principali della piattaforma

Le funzionalità principali della piattaforma Istituto di Scienza e Tecnologie dell'informazione A Faedo (ISTI) - Laboratorio di domotica Quimby: Le funzionalità principali della piattaforma Dario Russo (dario.russo@isti.cnr.it) Obiettivi del progetto

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

porte aperte sull e-learning di Gianluca Affinito gianluca.affinito@gmail.com

porte aperte sull e-learning di Gianluca Affinito gianluca.affinito@gmail.com porte aperte sull e-learning di Gianluca Affinito gianluca.affinito@gmail.com Cos è Moodle Moodle è un software per la gestione di corsi a distanza utilizzato a livello mondiale nelle Università, nelle

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

Software Project Management Plan 1.0

Software Project Management Plan 1.0 Software Project Management Plan 1.0 17 maggio 2010 Gruppo CiDeFaRo Progetto di Laboratorio Sistemi e Processi Organizzativi 2010 ALMA MATER STUDIORUM - Universitá di Bologna Facolt di Scienze Matematiche

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

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

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

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software 5 Gestione dei progetti software. Dopo aver completato lo studio del ciclo di vita del software, in questa parte vengono discussi gli aspetti gestionali della produzione del software. Vengono esaminate

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. 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) 2. Ciclo di Vita e Processi di

Dettagli

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo Luca Cabibbo Analisi e Progettazione del Software Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2015 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano

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

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

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

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

La piattaforma Moodle dell' ISFOL

La piattaforma Moodle dell' ISFOL La piattaforma Moodle dell' ISFOL Un CMS per la condivisione della conoscenza nei Gruppi di Lavoro e di Ricerca dell'istituto Franco Cesari - ISFOL Gruppi di Lavoro e di Ricerca come Comunità di Pratica

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

Dettagli

Corso di Progettazione di sistemi multimediali

Corso di Progettazione di sistemi multimediali Corso di Progettazione di sistemi multimediali prof. Pierluigi Feliciati a.a.2012/13 Modulo 0 Progettare, sistemi, multimedialità: Definizioni, strumenti, ciclo di vita dei progetti, figure professionali

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

Dettagli

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES è una metodologia per implementare rapidamente sistemi informativi aziendali complessi,

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

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

Introduzione. Capitolo 1

Introduzione. Capitolo 1 Capitolo 1 Introduzione Architecture is the set of design decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other.

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

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

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE Pag. 1/1 Sessione ordinaria 2010 Seconda prova scritta Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE CORSO DI ORDINAMENTO Indirizzo: INFORMATICA

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Piattaforma e-learning Moodle. Manuale ad uso dello studente. Vers. 1 Luglio 09

Piattaforma e-learning Moodle. Manuale ad uso dello studente. Vers. 1 Luglio 09 Piattaforma e-learning Moodle Manuale ad uso dello studente Vers. 1 Luglio 09 Sommario 1. Introduzione...2 1.1 L ambiente...2 1.2 Requisiti di sistema...4 2. Come accedere alla piattaforma...4 2.1 Cosa

Dettagli

BiblioTech - Personal Digital Library

BiblioTech - Personal Digital Library Albana Gaba Alessandro Pegoraro Mirco Bocedi Fabio Giuseppe Strozzi Gruppo 8 Obiettivo Creare un software efficiente per la catalogazione di documenti digitali in categorie personalizzabili dall utente.

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

système de publication pour l internet Sistema di pubblicazione per internet

système de publication pour l internet Sistema di pubblicazione per internet système de publication pour l internet Sistema di pubblicazione per internet Non solo un CMS (Content Management System) Gestire i contenuti è un compito che molti software svolgono egregiamente. Gestire

Dettagli

E.T.L. (Extract.Tansform.Load) IBM - ISeries 1/8

E.T.L. (Extract.Tansform.Load) IBM - ISeries 1/8 E.T.L. (Extract.Tansform.Load) IBM - ISeries Quick-EDD/ DR-DRm ETL 1/8 Sommario ETL... 3 I processi ETL (Extraction, Transformation and Loading - estrazione, trasformazione e caricamento)... 3 Cos è l

Dettagli

La Login in Prestito!!Disponbilità Tesi. Categorie di Progetti di Ingegneria del Software

La Login in Prestito!!Disponbilità Tesi. Categorie di Progetti di Ingegneria del Software Draft versione 1.1 Categorie di Progetti di Ingegneria del Software Tutti i temi Progettuali proposti rientrano in una delle seguenti categorie. 1. Temi sull'elaborazione di Dati Multimediali Temi su Audio,

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

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

LA PROFESSIONE DEL WEB DESIGNER

LA PROFESSIONE DEL WEB DESIGNER LA PROFESSIONE DEL WEB DESIGNER Lezione 1 1 Web Design Lafiguracentralenelprogettodiunsitowebèilwebdesigner:eglisioccupadell'aspetto visivo e del coinvolgimento emotivo di siti Web business to business

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

Pattern Architetturali e Analisi Architetturale

Pattern Architetturali e Analisi Architetturale Pattern Architetturali e Analisi Architetturale Ingegneria del Software parte II Andrea Bei Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale di un sistema software

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Breve introduzione allo sviluppo WEB. a cura di Ciro Attanasio - ciro.attanasio@email.cz

Breve introduzione allo sviluppo WEB. a cura di Ciro Attanasio - ciro.attanasio@email.cz Breve introduzione allo sviluppo WEB a cura di Ciro Attanasio - ciro.attanasio@email.cz Partiamo (1 di 1) Come funziona il WEB e quali tecnologie lo compongono Cos è un Client (1 di 2) Un client, in informatica,

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

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

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

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

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

Content Management Systems e

Content Management Systems e AA 2010/2011 Content Management Systems e Corso di Progetto di Sistemi Web Based Università degli Studi di Roma Tor Vergata Argomenti della lezione 1. Breve evoluzione storica dei siti internet cos è un

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

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

Manuale Piattaforma Didattica

Manuale Piattaforma Didattica Manuale Piattaforma Didattica Ver. 1.2 Sommario Introduzione... 1 Accesso alla piattaforma... 1 Il profilo personale... 3 Struttura dei singoli insegnamenti... 4 I Forum... 5 I Messaggi... 7 I contenuti

Dettagli

Cos è anahita. La filosofia di design di anahita. Installare Anahita su Joomla! Presente e futuro di anahita. Ohanah Event Engine

Cos è anahita. La filosofia di design di anahita. Installare Anahita su Joomla! Presente e futuro di anahita. Ohanah Event Engine Anahita 1 2 Cos è anahita La filosofia di design di anahita Installare Anahita su Joomla! Presente e futuro di anahita Ohanah Event Engine Rastin Mehr / Arash Sanieyan / Johan Janssens / Mathias Verraes

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

-Sistemi per il rilevamento di flussi di persone- Progetto:

-Sistemi per il rilevamento di flussi di persone- Progetto: -Sistemi per il rilevamento di flussi di persone- Progetto: Sistema per il rilevamento e l analisi dei flussi dei clienti in un megastore di 1 piano di 1250m 2, composto da 20 corsie di 1m di lunghezza

Dettagli

Software project management. www.vincenzocalabro.it

Software project management. www.vincenzocalabro.it Software project management Software project management Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate rispondendo a determinati standard

Dettagli

Framework Rich Client Application

Framework Rich Client Application Framework Rich Client Application RELATORE: Paolo Giardiello Savona, 30 settembre 2010 Agenda La Sogei Le applicazioni client Sogei Le caratteristiche Le soluzioni possibili Java Web Start Eclipse La scelta:

Dettagli

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

hdone 1 Overview 2 Features hdone Team 13 dicembre 2007

hdone 1 Overview 2 Features hdone Team 13 dicembre 2007 hdone hdone Team 13 dicembre 2007 1 Overview hdone è una web application che fornisce il supporto necessario a tutte le aziende che si occupano di fornire servizi di assistenza al cliente. Dopo gli anni

Dettagli

Macchine per l elaborazione dell informazion e. Sistemi di Elaborazione delle Informazioni. Informatica II

Macchine per l elaborazione dell informazion e. Sistemi di Elaborazione delle Informazioni. Informatica II Macchine per l elaborazione dell informazion e Sistemi di Elaborazione delle Informazioni Informatica II Ing. Mauro Iacono Seconda Università degli Studi di Napoli Facoltà di Studi Politici e per l Alta

Dettagli

Non è ora di cambiare le equazioni del tuo IT?

Non è ora di cambiare le equazioni del tuo IT? Non è ora di cambiare le equazioni del tuo IT? Da sempre l'uomo desidera dedicarsi alle attività creative e crea macchine affinché svolgano i compiti ripetitivi al posto suo. Perché per lo sviluppo di

Dettagli

Linee guida per la gestione del rischio nei progetti di sviluppo e manutenzione dei sistemi

Linee guida per la gestione del rischio nei progetti di sviluppo e manutenzione dei sistemi Linee guida per la gestione del rischio nei progetti di sviluppo e manutenzione dei sistemi Quaderno N. 25 Ercole Colonese ercole@colonese.it Roma, 17 dicembre 2007 Argomenti trattati Valutazione del rischio

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

Processi per lo sviluppo rapido del software

Processi per lo sviluppo rapido del software Lezione 3 Processi per lo sviluppo rapido del software Sviluppo Rapido del Software Slide 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.17 R. Pressman- Principi di

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

Specifiche tecnico-funzionali sistema web di registrazione, gestione delle schede informative e ricerca delle associazioni per il portale IcaroPrato

Specifiche tecnico-funzionali sistema web di registrazione, gestione delle schede informative e ricerca delle associazioni per il portale IcaroPrato Specifiche tecnico-funzionali sistema web di registrazione, gestione delle schede informative e ricerca delle associazioni per il portale IcaroPrato Indice Articolo 1. Articolo 2. Articolo 3. Articolo

Dettagli

Ingegneria del Software. Processi di Sviluppo

Ingegneria del Software. Processi di Sviluppo Ingegneria del Software Processi di Sviluppo Ingegneria del Software: Tecnologia Stratificata tools metodi processi Focus sulla qualità Ingegneria del Software: Tecnologia Stratificata (2) Qualità Elemento

Dettagli

Introduzione. Le origini di PHP. Cos è PHP?

Introduzione. Le origini di PHP. Cos è PHP? Introduzione Ecco a voi un altro libro sul linguaggio di scripting PHP, la cui peculiarità è data dal fatto che dedica la massima attenzione a materiali di alto livello e agli argomenti più evoluti e attuali.

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

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

REQUISITO DI ACCESSIBILITA

REQUISITO DI ACCESSIBILITA ISTITUTO COMPRENSIVO Pascoli - Crispi Via Gran Priorato, 11-98121 Messina Via Monsignor D'Arrigo, 18-98122 Messina Tel/Fax. 09047030 090360037 e-mail: meic87300t@istruzione.it / meee00800r@istruzione.it

Dettagli

Automazione dei processi con SharePoint: Windows SharePoint Foundation 2010 Workflow o Josh, il sistema di Business Process Management?

Automazione dei processi con SharePoint: Windows SharePoint Foundation 2010 Workflow o Josh, il sistema di Business Process Management? Automazione dei processi con SharePoint: Windows SharePoint Foundation 2010 Workflow o Josh, il sistema di Business Process Management? di Gabriele Del Giovine (Tech. Strategist, it Consult) e Giovanni

Dettagli

MRC: Nuova Architettura

MRC: Nuova Architettura MRC: Nuova Architettura Release: 1.0 16 febbraio 2014 Autore: Andrea Gualducci MRC: Nuova Architettura Pag. 1 di 12 SOMMARIO MRC: Nuova Architettura... 1 Introduzione...3 Efficienza...3 Deployement...3

Dettagli

Sommario. ELSE D 6.2 Pagina 2 di 10

Sommario. ELSE D 6.2 Pagina 2 di 10 Sommario 1 Aggiornamento del sito web... 3 2... 4 3 Piano di trasferimento... 5 3.1 Social Network... 5 3.2 Siti accademici... 7 3.3 Formazione professionale in ambito medico sanitario... 7 3.4 Comunità

Dettagli

ADA. E learning e open source

ADA. E learning e open source 1 ADA. E learning e open source ADA 1.7.1 Come cresce un Ambiente Digitale per l'apprendimento open source Maurizio Graffio Mazzoneschi 2 Cos'è il software libero Libertà 0, o libertà fondamentale: la

Dettagli

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Business white paper Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Indice 3 Sommario esecutivo 3 Introduzione 3 Best practice a livello aziendale 5 Best practice a

Dettagli

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

Dettagli

PRESENTAZIONE SERVIZI P.M.I.

PRESENTAZIONE SERVIZI P.M.I. PRESENTAZIONE SERVIZI P.M.I. Profilo La Società Hermes nasce nel 2010 per portare sul mercato le esperienze maturate da un team di specialisti e ricercatori informatici che hanno operato per anni come

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

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

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

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

Project Planning. Politecnico di Milano. Progetto di Ingegneria del Software 2. 15 novembre 2011. Elisabetta Di Nitto Raffaela Mirandola

Project Planning. Politecnico di Milano. Progetto di Ingegneria del Software 2. 15 novembre 2011. Elisabetta Di Nitto Raffaela Mirandola Politecnico di Milano Progetto di Ingegneria del Software 2 Project Planning Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 15 novembre

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

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

Relazione finale del progetto Sito Alunni Segrè

Relazione finale del progetto Sito Alunni Segrè Relazione finale del progetto Sito Alunni Segrè 1. Descrizione di contenuti, tempi, luoghi, fasi, modalità, strumenti e protagonisti Il progetto ha previsto la realizzazione da parte degli alunni dell

Dettagli

La Piattaforma Moodle

La Piattaforma Moodle 5 Luglio 2006 Moodle: Modular Object-Oriented Dinamic Learning Environment LCMS (Learning Content Management System): prodotto software per produrre e gestire corsi distribuiti via Internet Gestire l utente:

Dettagli

CONTENT MANAGMENT SYSTEMS

CONTENT MANAGMENT SYSTEMS CONTENT MANAGMENT SYSTEMS ESTRATTO DA: Ileana D'Incecco, Progettare la comunicazione web per organizzazioni non-profit con strumenti open source: ideazione e realizzazione del sito web della Casa delle

Dettagli

ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN

ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN PORTALE WEB NELL AMBITO DELLA MISURA 2.6. DEL POI ENERGIA FESR 2007 2013

Dettagli

Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT. Paolo Salvaneschi B1_1 V1.0. Strumenti software

Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT. Paolo Salvaneschi B1_1 V1.0. Strumenti software Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi B1_1 V1.0 Strumenti software Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale

Dettagli

I vantaggi del CAD 3D parametrico e diretto

I vantaggi del CAD 3D parametrico e diretto I vantaggi del CAD 3D parametrico e diretto Cinque aree in cui la modellazione parametrica può essere utilizzata per completare un ambiente di modellazione diretta Introduzione Per troppo tempo l'uso del

Dettagli

La progettazione del software nelle piccole o micro imprese

La progettazione del software nelle piccole o micro imprese La progettazione del software nelle piccole o micro imprese Il contenuto di questo documento è strettamente confidenziale, la visione dello stesso è consentita solo al personale di FadeOut Snc e della

Dettagli