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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-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

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

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

Caratteristiche per la valutazione di un sistema wcm

Caratteristiche per la valutazione di un sistema wcm Caratteristiche per la valutazione di un sistema wcm Note per la compilazione Indicare se la caratteristica richiesta sia presente o meno, ovvero se sia integrabile/sviluppabile e con che tipo di intervento

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

CMS Open Source Evento Open Source Asolo Golf Club - 29 giugno 2005

CMS Open Source Evento Open Source Asolo Golf Club - 29 giugno 2005 CMS Open Source Evento Open Source Asolo Golf Club - 29 giugno 2005 Fabio Bottega (f.bottega@tecnoteca.it) I punti focali: CMS = comunicazione Gli attori coinvolti Scelta di un CMS Open Source CMS di riferimento

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

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

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

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

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

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

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

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

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

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

Moodle 2: nuova generazione e nuovi scenari

Moodle 2: nuova generazione e nuovi scenari Moodle 2: nuova generazione e nuovi scenari Andrea Bicciolo Fondatore e direttore tecnico di MediaTouch 2000 s.r.l. Moodle Partner,, Coordinatore traduzione italiana di Moodle, Facilitatore dei forum italiani

Dettagli

Portafoglio Silk: soluzioni leggere per test, sviluppo e gestione

Portafoglio Silk: soluzioni leggere per test, sviluppo e gestione Portafoglio : soluzioni leggere per test, sviluppo e gestione Leggere Includono solo le funzionalità effettivamente necessarie Convenienti Gratuite e con licenze flessibili Potenti Soluzioni software intuitive

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

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Reingegnerizzazione di un Content Management System verso l accessibilità secondo la normativa italiana

Reingegnerizzazione di un Content Management System verso l accessibilità secondo la normativa italiana Università degli Studi di Bologna Sede di Cesena FACOLTÀ À DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea in Scienze dell Informazione Reingegnerizzazione di un Content Management System verso

Dettagli

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro Processi di Sviluppo Software Introduzione Giuseppe Calavaro Processi di sviluppo software - Agenda Differenza tra Programmazione e Progettazione SW I Processi di Sviluppo Software Waterfall Spirale RUP

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

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

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

3. SOFTWARE MANAGEMENT

3. SOFTWARE MANAGEMENT 3. SOFTWARE MANAGEMENT Introdurre caratteristiche e problematiche della direzione di progetto software (software management) Discutere la pianificazione di un progetto e la temporizzazione (scheduling)

Dettagli

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

Obiettivi della Lezione. Project Management. Software Project Management. Che cos è un progetto

Obiettivi della Lezione. Project Management. Software Project Management. Che cos è un progetto Project Management Dott. Andrea F. Abate e-mail: abate@unisa.it Web: http://www.dmi.unisa.it/people/abate Gestione di Progetti Software: Pianificazione delle attività e rappresentazioni grafiche Obiettivi

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

Content Development e Open Source Pierluigi Boda Università La Sapienza di Roma

Content Development e Open Source Pierluigi Boda Università La Sapienza di Roma Content Development e Open Source Università La Sapienza di Roma Contenuti: Cos è il content management Aspetti critici nello sviluppo dei CMS Opzioni tecnologiche per il CM Peculiarità dell opzione open

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

Piattaforma e-learning Moodle. Manuale ad uso del Docente

Piattaforma e-learning Moodle. Manuale ad uso del Docente Piattaforma e-learning Moodle Manuale ad uso del Docente Vers. 1 - Maggio 2009 1 MODULO 1 - INTRODUZIONE 1- Introduzione a Moodle La piattaforma di e-learning è uno strumento didattico, con accesso ed

Dettagli

White Paper 1. INTRODUZIONE...2 2. TECNOLOGIE SOFTWARE IMPIEGATE...2 3. APPROCCIO PROGETTUALE...10 3. RISULTATI...10

White Paper 1. INTRODUZIONE...2 2. TECNOLOGIE SOFTWARE IMPIEGATE...2 3. APPROCCIO PROGETTUALE...10 3. RISULTATI...10 Soluzioni software di EDM "Electronic Document Management" Gestione dell archiviazione, indicizzazione, consultazione e modifica dei documenti elettronici. Un approccio innovativo basato su tecnologie

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

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

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

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

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

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

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

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

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

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

CMS & WIKI & web 2.0. Marco P. Locatelli locatelli@disco.unimib.it Presentazione originale: Marco Loregian

CMS & WIKI & web 2.0. Marco P. Locatelli locatelli@disco.unimib.it Presentazione originale: Marco Loregian CMS & WIKI & web 2.0 Marco P. Locatelli locatelli@disco.unimib.it Presentazione originale: Marco Loregian Eventi interessanti Service Oriented Computing (per informatici) Mercoledì 28 (domani) 10:30-12:30

Dettagli

La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software

La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software Ingegneria del software (software engineering) La branca dell'ingegneria che si occupa della realizzazione di sistemi software. La disciplina che cura un approccio sistematico, disciplinato e quantificabile

Dettagli

Software solido e usabile: come integrare ingegneria dell usabilità e del software

Software solido e usabile: come integrare ingegneria dell usabilità e del software Software solido e usabile: come integrare ingegneria dell usabilità e del software Giorgio Brajnik e Andrea Baruzzo Dip. di Matematica e Informatica Università di Udine e Interaction Design Solutions srl

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

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

Ingegneria del Software 2

Ingegneria del Software 2 Politecnico di Milano Anno Accademico 2010/2011 Ingegneria del Software 2 Corso della Prof.ssa Elisabetta Di Nitto Stefano Invernizzi Facoltà di Ingegneria dell Informazione Corso di Laurea Magistrale

Dettagli

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE INTRODUZIONE L ingegneria del software è la disciplina tecnologica e gestionalerelativa alla realizzazione sistematica e alla manutenzione di un software rispettando

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

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

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

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al.

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al. Modello Code and fix Processo parte III Leggere Sez. 7.4 Ghezzi et al. Modello iniziale Iterazione di due passi scrittura del codice correzione degli errori Problemi: dopo una serie di cambiamenti, la

Dettagli

LEZIONE 9 - Linguaggi di Modellazione & UML

LEZIONE 9 - Linguaggi di Modellazione & UML Laboratorio di Ingegneria del Software a.a. 2013-2014 LEZIONE 9 - Linguaggi di Modellazione & UML Catia Trubiani Gran Sasso Science Institute (GSSI), L Aquila catia.trubiani@gssi.infn.it Cosa sono? 2 1

Dettagli

Mash Up applicativo con l'opensource per l'accesso ai servizi aziendali

Mash Up applicativo con l'opensource per l'accesso ai servizi aziendali Mash Up applicativo con l'opensource per l'accesso ai servizi aziendali Marco Celotti m.celotti@tecnoteca.com Davide Pavan - d.pavan@tecnoteca.com 2 Mashup applicativo Una esigenza aziendale sempre più

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

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

SCHEDA TECNICA CMS SIMPLIT ASMENET 2.0

SCHEDA TECNICA CMS SIMPLIT ASMENET 2.0 SCHEDA TECNICA CMS SIMPLIT ASMENET 2.0 Denominazione CMS SIMPLIT ASMENET 2.0 Amministrazione Asmenet Campania scarl Note e considerazioni sul riuso L aggiornamento dei siti internet è una criticità molto

Dettagli

Introduzione a Wordpress. Corso completo alla conoscenza e all uso del CMS Open Source WP (incontro 1/6)

Introduzione a Wordpress. Corso completo alla conoscenza e all uso del CMS Open Source WP (incontro 1/6) Introduzione a Wordpress Corso completo alla conoscenza e all uso del CMS Open Source WP (incontro 1/6) Indice Rilevazione aspettative e competenze in ingresso Patto formativo Presentazione di WP Premesse

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

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

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

Microsoft Project 2010 si basa sulle fondamenta di Microsoft Project 2007 per offrire soluzioni di gestione del lavoro flessibili e strumenti di

Microsoft Project 2010 si basa sulle fondamenta di Microsoft Project 2007 per offrire soluzioni di gestione del lavoro flessibili e strumenti di Microsoft Project 2010 si basa sulle fondamenta di Microsoft Project 2007 per offrire soluzioni di gestione del lavoro flessibili e strumenti di collaborazione adatti ai project manager professionisti

Dettagli

Strumenti per il supporto alla formazione a distanza e la didattica

Strumenti per il supporto alla formazione a distanza e la didattica Sommario Strumenti per il supporto alla formazione a distanza e la didattica Introduzione al portale SSIS infofactory - Laboratorio di Intelligenza Artificiale - Univ. degli Studi di Udine 3-4 Dicembre

Dettagli

IL CRM di Platinumdata

IL CRM di Platinumdata IL CRM di Platinumdata Cos è un CRM? Il Customer relationship management (CRM) o Gestione delle Relazioni coi Clienti è legato al concetto di fidelizzazione e gestione dei clienti. Attualmente il mercato

Dettagli

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Da Wikipedia, l'enciclopedia libera. L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività

Dettagli

Annuncio software IBM per Europa, Medio Oriente e Africa ZP11-0281, 6 giugno 2011

Annuncio software IBM per Europa, Medio Oriente e Africa ZP11-0281, 6 giugno 2011 ZP11-0281, 6 giugno 2011 IBM Rational Team Concert V3.0.1 offre la gestione dei cambiamenti e della configurazione all'interno di IBM Rational Collaborative Lifecycle Management per i team di sviluppo

Dettagli