Università degli Studi dell Insubria

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università degli Studi dell Insubria"

Transcript

1 Università degli Studi dell Insubria FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea in Informatica Studio e applicazione di metodi agili nello sviluppo di prodotti Software Open Source Tesi di Laurea di: Relatore: Prof. Luigi Lavazza MARCO BINDA Prof. Sandro Morasca Matricola: Correlatore: Davide Taibi Anno Accademico

2 Riassunto Nello studio dell ingegneria del software si possono dividere i processi di sviluppo in due categorie: processi di sviluppo classici e processi di sviluppo agili. Quando si prende in considerazione un processo di sviluppo classico ci si riferisce a modelli come quello a cascata o a spirale, in cui la modalità di lavoro è fortemente orientata all esecuzione di passi sequenziali dove si pianifica, si progetta e si sviluppa l intero sistema software, con a volte la presunzione di implementare oltre alle funzionalità richieste quelle future. Questo modo di operare, ben si orienta allo sviluppo di progetti Closed Source Software (CSS). I processi di sviluppo Agili, come ad esempio Extreme Programming (XP) o SCRUM, si contrappongono a quelli classici. Questi modelli sono composti da una serie di fasi iterative, dove viene presa in considerazione una parte di progetto alla volta, piccola e ben definita. I processi di sviluppo Agili propongono un modo di lavorare fortemente orientato al risultato che ben si adatta allo sviluppo di progetto Open Source Software. In questo lavoro di tesi si è applicato un processo di sviluppo Agile, in particolare una versione modificata di SCRUM, ad uno strumento OSS contenuto all interno del progetto Qualipso, in dettaglio allo strumento MACXIM. Gli obiettivi che ci siamo proposti all inizio di questo lavoro sono quelli di valutare se sia possibile inserire il processo di sviluppo SCRUM in un progetto OSS già in fase di sviluppo, se sia possibile far cooperare un team di programmatori geograficamente distribuiti e se SCRUM ha contribuito effettivamente a migliorare la qualità del prodotto e la produttività del processo. SCRUM è stato studiato, modificato e adattato per poter essere applicato allo sviluppo di MACXIM. Sono state raccolte una serie di misure quantitative e qualitative prima e dopo l introduzione di SCRUM nel processo di sviluppo, che hanno permesso una valutazione oggettiva ed empirica dell applicazione di SCRUM a progetti OSS. ii

3 Sommario 1 INTRODUZIONE OBIETTIVI DELLA TESI STRUTTURA DELLA TESI I PROCESSI DI SVILUPPO PROCESSI DI SVILUPO CLASSICI IL PROCESSO DI SVILUPPO A CASCATA IL PROCESSO DI SVILUPPO ITERATIVO: A SPIRALE IL PROCESSO DI SVILUPPO UNIFIED PROCESS I PROCESSI DI SVILUPPO AGILI EXTREME PROGRAMMING SCRUM FEATURE DRIVEN DEVELOPMENT DYNAMIC SYSTEM DEVELOPMENT METHOD APPLICAZIONE DI SCRUM A PROGETTI OSS LIGHT SCRUM CASO DI STUDIO MACXIM PROCESSO DI SVILUPPO APPLICAZIONE DI LIGHT SCRUM A MACXIM RISULTATI CONCLUSIONI E SVILUPPI FUTURI BIBLIOGRAFIA Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO AGILE Appendice B - PRATICHE iii

4 1 INTRODUZIONE Nel corso degli anni 90 si sono concretizzate ed hanno avuto modo di evolvere una serie di metodologie per lo sviluppo software denominato Agile. Queste discipline si focalizzano sul conseguimento di un obiettivo alla volta, breve e ben definito, realizzando con un processo iterativo l intero sistema. Talvolta queste metodologie possono essere impiegate per sviluppare prodotti software Open Source (OSS)[13]. Normalmente lo sviluppo di prodotti OSS avviene con criteri molto elastici, in cui gli sviluppatori sono distribuiti geograficamente, decidono il proprio lavoro e come distribuirlo alla comunità. Questa tipologia di sviluppo è in aperto contrasto con le metodologie Closed Source Software (CSS), dove vi sono dei paradigmi molto rigidi, come ad esempio quelli implementati nel modello Waterfall [14], in cui i programmatori devono seguire schemi di sviluppo rigorosi e ben impostati. Questo lavoro di tesi prende in esame due considerazioni principali: 1. Il processo di sviluppo dei prodotti OSS è molto simile al processo di sviluppo adottato nelle metodologie Agili 2. I prodotti CSS sviluppati con processi classici non hanno avuto modo in questi anni di abbracciare le metodologie Agili emergenti, mantenendo paradigmi di sviluppo rigidi. 1

5 Presa visione di queste due considerazioni, ho sviluppato il mio lavoro di tesi applicando una metodologia Agile ad uno strumento OSS nel progetto Qualipso [18], effettuando delle misurazioni prima e dopo l impiego di tale processo di sviluppo, per valutare se sia possibile ottimizzare la produttività del team di sviluppo ed aumentare la qualità dei prodotti OSS, attraverso un ambito più inquadrato rispetto a quello completamente non strutturato che caratterizza i progetti OSS. Dopo aver preso visione delle diverse metodologie Agili, valutando pregi e difetti di ciascuna, abbiamo applicato il processo di sviluppo SCRUM [1] per lo sviluppo di MACXIM (Model And Code Xml-based Integrated Meter), uno strumento OSS che estrae misure quantitative e oggettive da codice sorgente Java. Terminata questa esperienza abbiamo confrontato i dati raccolti prima e dopo l introduzione di SCRUM e ne abbiamo ricavato delle osservazioni su come applicare SCRUM ai prodotti OSS. Dai risultati ottenuti è emerso che SCRUM non ha alterato significativamente la produttività del nostro team di sviluppo e la qualità del nostro prodotto. Tuttavia è stato possibile controllare meglio il processo di sviluppo rispetto al periodo di non sviluppo con la metodologia SCRUM. 2

6 1.1 OBIETTIVI DELLA TESI In questo progetto di tesi si è applicata una metodologia si sviluppo Agile allo strumento MACXIM. MACXIM è sviluppato nel contesto delle attività del progetto Qualipso [18] che è dedicato alla valutazione della qualità di progetti OSS, insieme a una serie di altri strumenti. Considerando che il nostro interesse è rivolto alla qualità dei prodotti OSS, è stato quindi naturale includere MACXIM nella serie di prodotti OSS da valutare. Come conseguenza la qualità di ciascuna emissione di MACXIM è stata accuratamente misurata. Gli obiettivi che ci siamo prefissati prima di procedere all applicazione del processo di sviluppo SCRUM allo strumento OSS MACXIM sono convogliati nello rispondere ai seguenti quesiti: 1. È possibile passare con successo da SCRUM a un processo OSS in fase di sviluppo? 2. È possibile applicare SCRUM a una serie di sviluppatori geograficamente distribuiti? 3. Può SCRUM contribuire a migliorare la qualità del prodotto e la produttività del processo? Per poter rispondere alle tre domande precedenti, abbiamo individuato una serie di misure e confrontato i dati ottenuti prima e dopo l introduzione di SCRUM nel processo di sviluppo dello strumento MACXIM. I dati raccolti dopo essere stati analizzati e confrontati hanno permesso una valutazione quantitativa e qualitativa dell applicazione si SCRUM a dei progetti OSS. 3

7 1.2 STRUTTURA DELLA TESI In questo capitolo è stata presentata un introduzione al lavoro di tesi svolto. Nel secondo capitolo vengono presentate i principali processi di sviluppo classici, andando ad evidenziare le principali caratteristiche legate ad ogni modello analizzato. Nel terzo capitolo vengono presentati i principali modelli di sviluppo Agili, presi in considerazione per poter portare a termine con successo gli obiettivi prefissati. Nel quarto capitolo viene spiegato come il processo di sviluppo SCRUM è stato scelto e adattato allo sviluppo dello strumento MACXIM. Nel quinto capitolo viene descritto lo strumento MACXIM, il processo di sviluppo adottato, come è stato applicato LIGHT SCRUM allo strumento MACXIM ed i risultati ottenuti a fine lavoro. 4

8 2 I PROCESSI DI SVILUPPO Nell ingegneria del software esistono vari processi di sviluppo. Possiamo suddividere i processi di sviluppo in due categorie: i processi classici ed i processi agili. 2.1 PROCESSI DI SVILUPO CLASSICI Nel corso degli anni sono stati sviluppati diversi processi di sviluppo del software. In questo capitolo ne verranno presentati alcuni tra i più noti. A cascata. A spirale. Unified Process IL PROCESSO DI SVILUPPO A CASCATA Il processo di sviluppo a cascata (waterfall) è stato il primo processo di sviluppo studiato nell ingegneria del software (Fig. 1). Il processo di sviluppo a cascata è strutturato secondo una serie di fasi. Le fasi di questo processo di sviluppo sono lo studio di fattibilità, descrizione del problema, progettazione della soluzione, sviluppo e test di unità, integrazione e test del sistema, deployment e manutenzione. Vengono svolte in forma sequenziale: ogni fase per poter iniziare, deve attendere la conclusione di quella precedente. 5

9 Fig. 1 Modello a cascata Vi sono dei problemi evidenti in questo processo di sviluppo: pur avendo una struttura semplice che permette di semplificare il lavoro degli sviluppatori, accade spesso che in una di queste fasi ci si rende conto che sarebbe necessario tornare a quella precedente. Ad esempio, come spesso accade in fase di sviluppo, emergono alcuni aspetti del sistema non noti in una prima fase di analisi, che rendono quindi necessario tornare alla fase precedente per poter chiarire questi nuovi aspetti. Un ulteriore problema del processo di sviluppo a cascata è di non sposarsi bene con progetti dove i requisiti utente cambiano con una frequenza alta. 6

10 Questo processo di sviluppo è più adatto allo sviluppo di grossi progetti software, come ad esempio i primi sistemi operativi IL PROCESSO DI SVILUPPO ITERATIVO: A SPIRALE Nel corso degli anni sono stati ideati altri processi di sviluppo con l intenzione di affrontare e risolvere gli aspetti problematici di quello a cascata. È nato cosi il processo di sviluppo iterativo, ancora oggi ampiamente usato. Il processo di sviluppo iterativo è composto da una serie di iterazioni al termine delle quali è sempre prodotto un particolare deliverable. Le iterazioni sono mini-progetti formati da una ripetizione di fasi: le attività e i deliverable prodotti cambiano in funzione dello stato di avanzamento del progetto. Il più famoso processo di sviluppo iterativo è quello a spirale (Fig. 2). Fig. 2 Modello a spirale 7

11 Il processo di sviluppo a spirale conserva gli aspetti sistematici di quello a cascata, ma cerca di ridurre la possibilità di errori. Per far questo, il processo di sviluppo a spirale prevede la realizzazione del prodotto software attraverso più rilasci incrementali. Le attività che portano alla creazione di un rilascio, sono ciclicamente ripetute per ogni versione successiva, secondo una spirale. Il processo di sviluppo a spirale è caratterizzato da una struttura composta da task region. Ogni task region è costituita da un insieme di attività. Uno dei vantaggi principali di questo modello è l introduzione dell analisi del rischio a ogni livello di iterazione. La presenza dell analisi del rischio influenza in modo significativo le decisioni prese nel progetto IL PROCESSO DI SVILUPPO UNIFIED PROCESS Uno dei modelli iterativi più significativi è lo Unified Process (UP) e il suo esempio più famoso, il Rational Unified Process (RUP). UP è un modello che definisce una struttura generica di processo: tale struttura è poi specializzata per un ampia classe di sistemi software. UP è iterativo e incrementale: è scomposto in progetti di dimensione e complessità minori da svolgere in singole iterazioni. Al termine di ogni iterazione è necessario un momento di verifica e, se l esito è positivo, il progetto passa all iterazione successiva. Inoltre viene mantenuto un feedback di quanto fatto nel 8

12 corso dell iterazione, in modo da assecondare eventuali cambiamenti occorsi durante il progetto. Il modello UP è strutturato secondo due diverse dimensioni: 1. una dimensione temporale suddivisa in fasi che determina la vita e la maturità del progetto (è la sequenza di iterazioni citate in precedenza); 2. una dimensione di workflow del processo, articolata in attività ripetute in ogni iterazione di ciascuna fase (definisce la struttura di ogni singola iterazione). Le fasi del modello UP vengono illustrate in Fig. 3 e sono inception, elaboration, construction e transition. Mentre le attività individuate a ogni iterazione sono requirements, analysis, design, implementation, test. Fig. 3 Fasi del modello Unified Process A volte queste fasi assumono un peso ritenuto fin troppo rilevante. Per questo motivo negli ultimi anni 9

13 sono stati definiti nuovi processi di sviluppo, identificati con l espressione Agile Software Development. 10

14 3 I PROCESSI DI SVILUPPO AGILI L Agile Software Development è un approccio che punta l attenzione verso la capacità di rispondere in modo veloce ed efficace ai cambiamenti che caratterizzano il processo di sviluppo del software. Nel 2001 è stato pubblicato un manifesto dell Agile Software Development che ne descrive i principi fondanti e i valori. Il termine agile fa riferimento, in generale, alla capacità di reazione al cambiamento, come ad esempio la capacità di adattare la soluzione software in base ai cambiamenti dei requisiti richiesti dall utente, e alla flessibilità del lavoro del team durante l intero progetto. In Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO AGILEvengono riportati i dodici principi che stanno dietro la stesura del manifesto mentre in [2] i firmatari del documento. Nel manifesto sono indicati quattro aspetti che differenziano il processo di sviluppo agile rispetto ai modelli esistenti: Lo sviluppo agile si focalizza sulle persone e sull interazione piuttosto che sul processo e i tool. L enfasi è sulla realizzazione del software piuttosto che sulla redazione di una documentazione esaustiva. L aspetto essenziale è la collaborazione con l utente e non la negoziazione del contratto. 11

15 È essenziale rispondere al cambiamento piuttosto che seguire in modo rigido un piano di progetto preordinato. Sulla base di questi principi e dei dodici punti del Manifesto Agile, sono nate un insieme di metodologie agili, all interno delle quali è possibile applicare una o più pratiche in base all esigenza del committente del progetto. Con il termine pratica si indica un modo di operare associato alla metodologia. Le singole pratiche applicabili alle metodologie agili sono decine e nella loro scelta si deve tener conto delle caratteristiche di ogni pratica, per i benefici che apporta e le conseguenze che comporta. Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie come riportato in Appendice B - PRATICHE. Qui di seguito verranno descritte le metodologie agili più significative: Extreme Programming. SCRUM. Feature Driven Development. DSDM. Lean Software Development. Tutte le metodologie agili condividono una serie di caratteristiche comuni e fondamentali come adattabilità, iteratività, rilasci frequenti, testing, orientamento alle persone e applicabilità a progetti dove i requisiti utente cambiano in continuazione. Operativamente, quindi, le metodologie agili 12

16 ridimensionano l importanza e lo sforzo impiegato nelle attività preliminari del progetto, come ad esempio la raccolta dei requisiti, la progettazione della soluzione e in particolare dell architettura di base. Ciò non significa che queste attività non siano eseguite, ma che il tempo e lo sforzo dedicati sono minori rispetto ai processi di sviluppo software classici. 13

17 3.1.1 EXTREME PROGRAMMING Nel 1999 fu pubblicato Extreme Programming Explained nel quale l autore Kent Beck presenta un nuovo modo di sviluppare software, che permette di limitare i rischi di fallimento strettamente legati alla fase di progettazione. L Extreme Programming (XP) è una metodologia agile, come tale cerca di rispondere agli obiettivi fissati dal manifesto agile. In particolare mira alla realizzazione di un processo di sviluppo leggero e flessibile, adatto a rispondere in tempi brevi e con costi ridotti, alle mutevoli richieste del committente anche in fase avanzata del progetto. XP propone l utilizzo di dodici pratiche agili, e suggerisce di utilizzarle al massimo delle loro potenzialità, da qui il termine Extreme. Tra le pratiche consigliate troviamo progettare con il cliente, test funzionali e unitari, refactoring (riscrivere il codice senza alterarne le funzionalità esterne), progettare al minimo, descrivere il sistema con una metafora, proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto), scegliere ed utilizzare un preciso standard di scrittura del codice, integrare continuamente i cambiamenti al codice, il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali), open workspace, quaranta ore di lavoro settimanali, pair programming (due programmatori lavorano insieme su un solo computer). Inoltre XP è caratterizzato da quattro valori chiave: semplicità, feedback, comunicazione e coraggio. Questo approccio si focalizza su una progettazione della 14

18 soluzione il più semplice, inclusiva delle sole funzionalità che di volta in volta il team deve rilasciare al committente. L ideazione e la pianificazione della soluzione avvengono tramite user story. Una user story è la descrizione, semplice e breve, di una particolare funzionalità richiesta dal committente: il team di sviluppo analizza tutte le user story e decide in che ordine implementarle. Il feedback è ottenuto dal testing continuo eseguito sul codice: spesso i casi di test sono pensati prima dell implementazione del codice che viene quindi realizzato per rispondere al test definito. Il team, ricevendo i frequenti feedback del committente, può adattare i rilasci successivi in modo flessibile. XP riscuote molto successo nel mondo dello sviluppo e dell ingegneria del software, ma ha anche i suoi detrattori. Essi evidenziano alcuni fattori critici del metodo, sostenendo che XP funzioni solo con programmatori di alto profilo (programmatori senior), capaci di progettare applicazioni scalabili da subito o in grado di applicare un buon refactoring. Inoltre sostengono che il pair programming dimezzi il numero di task eseguibili in parallelo e individuano nel test driven development del lavoro aggiunto, in quanto costringe a scrive e mantenere altro codice. L estremismo di questo metodo non sempre è apprezzato, ma gli va riconosciuto il merito di evidenziare pratiche agili di successo, tra queste può valere la pena sperimentare in ambiente produttivo quelle che più si avvicinano alla filosofia aziendale. 15

19 3.1.2 SCRUM SCRUM è stato creato da Ken Schwaber, Jeff Sutherland e Mike Beedle. La parola SCRUM non è un acronimo, viene utilizzato cosi come si presenta dalle aziende per indicare l attuazione del processo stesso. Deriva probabilmente dai primi documenti pubblicati da Ken Schwaber che portavano nel titolo la parola in maiuscolo SCRUM. È un termine che deriva dal Rugby ed indica il pacchetto di mischia, dove ogni componente del team di sviluppo deve spingere nella stessa direzione, agendo come un entità coordinata. Di seguito in Fig. 4 viene mostrato il ciclo di vita del processo SCRUM relativo allo svolgimento di un Sprint Backlog. Fig. 4 Ciclo di vita del processo SCRUM Prima di descrivere il processo stesso, analizziamo le parti che lo compongono. SCRUM è composto da tre ruoli, tre cerimonie e tre artefatti. 16

20 I tre ruoli sono ricoperti da Product Owner, colui che commissiona, finanzia il progetto ed ha la responsabilità di definire le caratteristiche del prodotto e di decidere la data di rilascio ed il contenuto. Lo ScrumMaster deve garantire che il team di lavoro sia funzionale e produttivo, una stretta cooperazione in tutti i ruoli e le funzioni e che il processo sia eseguito in ogni sua cerimonia, inoltre deve schermare il team da interferenze esterne. L ultimo ruolo ma non meno importante è il team di sviluppo. Esso si occupa di selezionare e portare a termine l obiettivo di ogni Sprint, inoltre si organizza il proprio lavoro, mostrando i risultati ottenuti per mezzo di demo al Product Owner. La prima delle tre cerimonie è lo sprint planning meeting, un incontro della durata di circa quattro ore, in cui il Product Owner e il team di lavoro negoziano su quali caratteristiche devono essere implementate durante l iterazione (Sprint), basando questa decisione su quali caratteristiche con la massima priorità e un alto valore commerciale è possibile portare a termine in quel periodo. La seconda cerimonia è il daily scrum meeting, un incontro mattutino della durata di quindici minuti, in cui ogni componente del team di lavoro rende noto cosa ha fatto nella giornata precedente, cosa farà durante quella giornata e che problemi ha incontrato. La terza cerimonia è data dallo sprint review meeting, un incontro di quattro ore, in cui il team di lavoro presenta al Product Owner ciò che è stato implementato durante lo Sprint, inoltre viene deciso cosa implementare nello Sprint successivo, ristabilendo le priorità di ciascuna caratteristica. 17

21 I tre artefatti utilizzati in questo processo sono: il product backlog, che consiste in una lista di caratteristiche che definisco il prodotto finale. Lo sprint backlog, è la lista di caratteristiche che il team di lavoro deve implementare durante lo Sprint. La burndown chart, contiene il lavoro che non è stato svolto dal team durante lo Sprint. In una fase di pre-processo si effettua uno sprint planning meeting, tra il Product Owner e il team di lavoro, in cui viene definito il product backlog e lo sprint backlog. Dopo questa fase avviene il primo sprint della durata di quattro settimane, in cui quotidianamente avviene il daily scrum meeting, presidiato dallo ScrumMaster. Al termine di questo periodo si effettua lo sprint review meeting, in cui ciò che non è stato completato viene aggiunto alla burndown chart, mentre la parte di lavoro portata a termine viene presentata tramite una demo al Product Owner. 18

22 3.1.3 FEATURE DRIVEN DEVELOPMENT La feature driven development (FDD) è stata ideata da Jeff De Luca e Peter Coad. Questa metodologia agile basa la propria forma di sviluppo sulle funzionalità richieste dal programma. Per poter applicare FDD è necessario dividere il progetto in cinque fasi chiamate processi. Qui di seguito in Fig. 5 viene mostrato il ciclo di vita del processo FDD con le rispettive fasi Fig. 5 Ciclo di vita del processo FDD La prima fase riguarda lo sviluppo di un modello complessivo. Questa fase viene svolta da un team di modellatori, persone altamente qualificate della materia da trattare. Hanno il compito di sviluppare un modello complessivo del dominio del problema. Questo modello viene aggiornato iterativamente, sulla base dei risultati ottenuti dal quarto processo. La seconda fase consiste nella costruzione di una lista di funzionalità, dove il modello complessivo è suddiviso in aree più grandi. Ogni area ottenuta viene 19

23 a sua volta divisa in singole attività (funzionalità o features), organizzate successivamente in una lista con una struttura gerarchica. La terza fase è una pianificazione del processo di sviluppo sulla base delle funzionalità ottenute precedentemente, in cui vengono considerate le attività da svolgere e le relative priorità. Questo processo coinvolge il capo del progetto, il responsabile dello sviluppo e i capi programmatori. Nella quarta fase vengono elaborate le funzionalità. Lo svolgimento di questa parte è supervisionata dai capi programmatori, i quali identificano e coordinano i singoli programmatori per fargli sviluppare una singola funzionalità. Nella quinta fase vengono testate le funzionalità sviluppate al passo precedente utilizzando dei test di unità e successivamente revisionate dai capi programmatori. Una volta terminate queste due operazioni, il codice viene inserito nel repository del codice di progetto per poter essere condiviso da tutti gli sviluppatori e quindi pronto per il rilascio. 20

24 3.1.4 DYNAMIC SYSTEM DEVELOPMENT METHOD Il Dynamic System Development Method (DSDM) è stato sviluppato in Gran Bretagna ed ora divenuto uno standard europeo. L evoluzione del processo agile DSDM è gestito da un consorzio, che ne permette la distribuzione gratuita. Sviluppare un progetto con il processo DSDM, consiste nel dividere tale sviluppo in tre fasi: pre-project, ciclo di vita e post-project. Di seguito viene rappresentata in Fig. 6 la fase ciclo di vita. Fig. 6 Ciclo di vita del processo DSDM Il processo DSDM si compone di tre fasi sequenziali, dove nella fase di pre-project deve essere concretizzato il finanziamento al progetto e successivamente vengono individuati i candidati per portarlo a termine. Nella fase ciclo di vita, composta da cinque tappe, il progetto è realmente sviluppato. 21

25 La prima e la seconda tappa sono chiamate Studio, si dividono rispettivamente in uno studio di fattibilità, che consiste nel valutare se il processo DSDM è idoneo per poter realizzare il progetto analizzato e in uno studio businnes dove viene definito un elenco di requisiti con le rispettive priorità. La terza tappa chiamata modello funzionale d iterazione, consiste nello sviluppare un modello funzionale contenente le funzionalità ricavate dal elenco dei requisiti, accordarsi sugli orari d incontro, sviluppare un prototipo funzionale sulla base del modello e controllarne la correttezza. La quarta tappa denominata progettazione e costruzione d iterazione, è applicata per produrre una prima release funzionate da consegnare agli utenti finali per essere utilizzata come test. Nella tappa finale chiamata attuazione, vengono raccolti i feedback degli utenti, utilizzati come test, per proseguire con un successivo raffinamento del prodotto. Nella terza fase di post-progetto, viene effettuata una manutenzione del prodotto, effettuando una nuova iterazione della seconda fase. 22

26 4 APPLICAZIONE DI SCRUM A PROGETTI OSS In genere lo sviluppo di prodotti Software Open Source (OSS), non segue il tradizionale sviluppo software proveniente dai paradigmi descritti nei libri di testo dell ingegneria del software. In contrapposizione allo sviluppo OSS, vi sono i paradigmi di sviluppo classici, pensati e progettati per sviluppare Closed Source Software (CSS). L OSS ha ereditato caratteristiche che hanno reso questi paradigmi difficilmente conciliabili. Per esempio, OSS è spesso sviluppato da una comunità distribuita di sviluppatori ed è liberamente distribuito, come codice sorgente aperto e disponibile sia per gli sviluppatori che per gli utilizzatori finali, sotto specifiche licenze. Come stiamo descrivendo in questo lavoro di tesi, l analisi di alcune caratteristiche intrinseche dell OSS [13] da un lato confermano che i paradigmi rigidi di sviluppo, come ad esempio il modello Waterfall [14], non sono applicabili all OSS, mentre, da un altro lato sembra suggerire che i paradigmi Agili [15] possano aiutare gli sviluppatori OSS a migliorare la qualità dei loro prodotti. Questo è il risultato del fatto che i principi generali dietro il Manifesto Agile [1] sono riflessi nel modo in cui la maggior parte dei progetti OSS sono sviluppati e rilasciati agli utenti finali. Ciò che caratterizza molti progetti OSS è di non avere una visione commerciale a breve termine, questo implica che le attività di analisi del sistema e di progettazione, di solito non sono pre-programmate nello sviluppo OSS. Inoltre molti progetti OSS sono stati 23

27 avviati per risolvere il particolare problema di un utente, ma a volte finiscono innovando profondamente il campo del software (questo è il caso di Linux, Perl e Word Wide Web) anche se non hanno avuto una visione a lungo termine almeno alla loro nascita. La necessità di una profonda evoluzione della maggior parte dei progetti OSS è generalmente percepita dopo che sono stati utilizzati con successo da una vasta comunità di utenti. Il successo di un prodotto OSS è di solito imprevedibile. Esso è direttamente connesso al grado di attrattività e di utilità che il prodotto ha nella comunità degli utenti nel corso del tempo. È quindi molto difficile pianificare in anticipo le nuove versioni di un sistema, fatta eccezione per il breve termine. Queste osservazioni rispecchiano i primi due principi del Manifesto Agile: 1. Soddisfare il cliente attraverso la consegna rapida e continua di software di valore. 2. Consegnare frequentemente il software prodotto. Inoltre OSS è caratterizzato da un ambiente di lavoro non strutturato, dove la maggior parte degli sviluppatori OSS sono volontari, che, non si impegnano a rispettare tempi di consegna e ad avere assegnati dei compiti specifici. Nei progetti CSS, ai membri del team sono assegnati compiti specifici, mentre nei progetti OSS sono i membri del team che scelgono i propri compiti. A causa di queste libertà le attività che sono viste come fattori nocivi, quali la definizione del piano di progetto, la progettazione del sistema di valutazione e 24

28 l analisi dei requisiti, non possono essere eseguite seguendo paradigmi tradizionali nella comunità degli sviluppatori OSS. In molti contesti di sviluppo utilizzando processi Agili, i requisiti che non sono stati definiti in anticipo dagli analisti qualificati sono continuamente discussi dagli sviluppatori. I rischi vengono monitorati e gestiti nel corso del ciclo di vita del progetto, in modo naturale, come parte del normale sviluppo di lavoro. Queste caratteristiche dell OSS riflettono il principio Agile: Le architetture migliori, i requisiti e i disegni, emergono da gruppi auto-organizzati. L OSS è sviluppato in modo organizzativo e distribuito [8]. I sistemi OSS sono sviluppati in un ampio contesto di scala cooperativa, dove diverse squadre di utenti privati, nuclei di sviluppatori appassionati e comunità virtuali, creano la società non strutturata (ad esempio Rymond lo ha soprannominato il Bazaar ) contribuiscono allo sviluppo del progetto. Internet e il desktop, sono il ponteggio per queste organizzazioni virtuali di sviluppo del software, dove gli sviluppatori sono coordinati dalle politiche di licenza semplice, senza meccanismi di controllo gerarchico, altrettanto rigorosi nello sviluppo CSS. Di conseguenza gli sviluppatori OSS non seguono quasi mai metodologie di sviluppo, come ad esempio quelle definite e seguite dagli sviluppatori CSS. Inoltre lo sviluppo di progetti OSS è caratterizzato da una crescita più rapida [16] e più creativa rispetto allo sviluppo di progetti CSS [17], con l obbiettivo di soddisfare e rispondere più rapidamente alle esigenze degli utilizzatori. 25

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

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

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

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1 Scrum Caratteristiche, Punti di forza, Limiti versione del tutorial: 1.0 Pag. 1 Scrum è uno dei processi agili (www.agilealliance.com) il termine è derivato dal Rugby, dove viene chiamato Scrum il pacchetto

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

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

METODI AGILI IL CONTROLLO DI GESTIONE PER. Loredana G. Smaldore

METODI AGILI IL CONTROLLO DI GESTIONE PER. Loredana G. Smaldore METODI AGILI PER IL CONTROLLO DI GESTIONE 1 Fonte: Smaldore, L.G. (2014), Metodi «Agili» per il Controllo di Gestione, in Busco C., Giovannoni E. e Riccaboni A. (a cura di), Il controllo di gestione. Metodi,

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

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

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

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

Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite. Agile Group DIEE, Università di Cagliari www.agile.diee.unica.

Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite. Agile Group DIEE, Università di Cagliari www.agile.diee.unica. Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite Agile Group DIEE, Università di Cagliari www.agile.diee.unica.it Agile Group Agile Group, gruppo di ricerca su Ingegneria del SW,

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

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

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

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Processi di Sviluppo Agile Origini dello Sviluppo Agile Proposta di un gruppo di sviluppatori che rilevava una serie di criticità degli approcci convenzionali: Troppa rigidità dei

Dettagli

The Scrum Guide. La Guida Definitiva a Scrum: Le Regole del Gioco. Ottobre 2011. Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland

The Scrum Guide. La Guida Definitiva a Scrum: Le Regole del Gioco. Ottobre 2011. Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland The Scrum Guide La Guida Definitiva a Scrum: Le Regole del Gioco Ottobre 2011 Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland Indice Scopo della Guida Scrum... 3 Overview di Scrum... 3 Scrum Framework...

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

Seminario Metodi Agili per la gestione dei progetti per Decision Makers

Seminario Metodi Agili per la gestione dei progetti per Decision Makers Seminario Metodi Agili per la gestione dei progetti per Decision Gestire la complessità, adattarsi al cambiamento. Velocemente. Questa è la sfida quotidiana di ogni manager, sia in campo IT che in tutti

Dettagli

Un team agile allo sprint. 28 Febbraio 2013 Emiliano Soldi

Un team agile allo sprint. 28 Febbraio 2013 Emiliano Soldi Un team agile allo sprint 28 Febbraio 2013 Emiliano Soldi una questione di leggerezza COMPLESSITÀ VARIABILITÀ SPRECHI SOVRA-ALLOCAZIONI COLLI DI BOTTIGLIA DEBITO BUSINESS/TECNICO RIDURRE TEMPI ATTESA RIDURRE

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

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

Verifica e Validazione del Simulatore

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

Dettagli

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

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

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

Dettagli

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

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

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

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

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard Quality gate Nei punti chiave del processo di sviluppo del software, viene integrato un insieme di quality gate per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al

Dettagli

Sviluppo Agile. Prof. Filippo Lanubile. Processo software

Sviluppo Agile. Prof. Filippo Lanubile. Processo software Sviluppo Agile I processi (di sviluppo) del software bisogni nuovi o modificati Processo software Prodotto software nuovo o modificato Un processo software descrive quali sono le attività che concorrono

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

Perché una technology agency.

Perché una technology agency. Perché una technology agency. Creatività Strategia UX design Seo WEB PROJECT Partner layer CMS abstract Un progetto web moderno è composto da elementi diversi come creatività, strategia e business che

Dettagli

Ciclo di vita dimensionale

Ciclo di vita dimensionale aprile 2012 1 Il ciclo di vita dimensionale Business Dimensional Lifecycle, chiamato anche Kimball Lifecycle descrive il framework complessivo che lega le diverse attività dello sviluppo di un sistema

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

PROCESSI IT: Ottimizzazione e riduzione degli sprechi - Approccio Lean IT

PROCESSI IT: Ottimizzazione e riduzione degli sprechi - Approccio Lean IT CDC -Corte dei conti DGSIA Direzione Generale Sistemi Informativi Automatizzati SGCUS Servizio per la gestione del Centro Unico dei Servizi PROCESSI IT: Ottimizzazione e riduzione degli sprechi - Approccio

Dettagli

Introduzione all Ingegneria del Software

Introduzione all Ingegneria del Software Introduzione all Ingegneria del Software Alessandro Martinelli alessandro.martinelli@unipv.it 10 Dicembre 2013 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Fare software nel 2008: l Open Source e il ruolo delle imprese

Fare software nel 2008: l Open Source e il ruolo delle imprese Dipartimento di Elettronica e Informazione Fare software nel 2008: l Open Source e il ruolo delle imprese Eugenio Capra eugenio.capra@polimi.it IBM Softwareland, Monza, 18 settembre 2008 Cos è l Open Source?

Dettagli

Diffusione delle metodologie di Agile Software Development

Diffusione delle metodologie di Agile Software Development Università degli Studi di Padova FACOLTÀ DI INGEGNERIA Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Magistrale Diffusione delle metodologie di Agile Software Development Risultati

Dettagli

Domenico Clerici Luigi Petruzzelli La gestione quantitativa di progetti software

Domenico Clerici Luigi Petruzzelli La gestione quantitativa di progetti software Domenico Clerici Luigi Petruzzelli La gestione quantitativa di progetti software Edizioni Della Vigna Indice PREFAZIONE... XIII RICHIAMI DI PROJECT MANAGEMENT... 19 1.1 - Introduzione al project management...

Dettagli

Il peer-coaching all interno del progetto SUSTAIN

Il peer-coaching all interno del progetto SUSTAIN REPORT DI SINTESI sul PEER-COACHING Il peer-coaching all interno del progetto SUSTAIN Nel progetto SUSTAIN il peer coaching (coaching reciproco tra pari) è stato ideato come parte integrante della fase

Dettagli

Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta. Quadri sulla gestione

Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta. Quadri sulla gestione 6 Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta Quadri sulla gestione Impiegati con responsabilità direttive Dirigenti di imprese private e organizzazioni pubbliche, interessati

Dettagli

TU METTI LE IDEE.. NOI LE SOLUZIONI!!

TU METTI LE IDEE.. NOI LE SOLUZIONI!! TU METTI LE IDEE.. NOI LE SOLUZIONI!! MISSION La mission di CSR Solution è quella di supportare soluzioni software avanzate nei settori della progettazione e della produzione industriale per le aziende

Dettagli

SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE

SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE La sicurezza delle applicazioni web si sposta a un livello più complesso man mano che il Web 2.0 prende piede.

Dettagli

Indice. Prefazione all edizione italiana

Indice. Prefazione all edizione italiana Indice Prefazione all edizione italiana XV Capitolo 1 Il software e l ingegneria del software 1 1.1 L evoluzione del ruolo del software 3 1.2 Il software 5 1.3 La natura mutevole del software 8 1.4 Il

Dettagli

Gestione dei Progetti (2005-2006)

Gestione dei Progetti (2005-2006) Gestione dei Progetti (2005-2006) Alessandro Agnetis DII Università di Siena (Alcune delle illustrazioni contenute nella presentazione sono tratte da PMBOK, a guide to the Project Management Body of Knowledge,

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

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano.

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. di: Enrico MASTROFINI Ottobre 2004 Nella formulazione iniziale del Piano Ict sono di solito inseriti

Dettagli

ORGANIZZAZIONE AZIENDALE. Le forme gerarchico-funzionali e la loro evoluzione

ORGANIZZAZIONE AZIENDALE. Le forme gerarchico-funzionali e la loro evoluzione ORGANIZZAZIONE AZIENDALE Le forme gerarchico-funzionali e la loro evoluzione Prof. Armando Urbano - A.A. 2011-2012 PASSAGGIO DA FORMA SEMPLICE A FORMA GERARCHICO-FUNZIONALE La forma semplice è caratterizzata

Dettagli

Linee guida per la redazione della tesi di laurea Corsi di laurea specialistica e magistrale A.A. 2007/08

Linee guida per la redazione della tesi di laurea Corsi di laurea specialistica e magistrale A.A. 2007/08 Linee guida per la redazione della tesi di laurea Corsi di laurea specialistica e magistrale A.A. 2007/08 Indice Presentazione 4 Norme per il Corso di laurea specialistica in Disegno industriale del prodotto

Dettagli

SCOPRI G2 AUTOMOTIVE L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS.

SCOPRI G2 AUTOMOTIVE L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS. SCOPRI G2 AUTOMOTIVE L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS. Efficiente, rapido, su misura. G2 Automotive è l innovativo sistema di gestione specifico

Dettagli

Metriche del software

Metriche del software Sviluppo di Software Applicativo Metriche del software Come misurare le diverse caratteristiche del software: dimensioni, qualità, impegno richiesto per lo sviluppo, ecc. Ercole Colonese IBM Global Services

Dettagli

Introduzione. Articolazione della dispensa. Il sistema del controllo di gestione. Introduzione. Controllo di Gestione

Introduzione. Articolazione della dispensa. Il sistema del controllo di gestione. Introduzione. Controllo di Gestione Introduzione Perché il controllo di gestione? L azienda, come tutte le altre organizzazioni, è un sistema che è rivolto alla trasformazione di input (risorse tecniche, finanziarie e umane) in output (risultati

Dettagli

Coordinamento e comunicazione

Coordinamento e comunicazione Team Agili I membri del team devono fidarsi gli uni degli altri. Le competenze dei membri del team deve essere appropriata al problema. Evitare tutte le tossine che creano problemi Il team si organizza

Dettagli

COMUNE DI MONTE COLOMBO

COMUNE DI MONTE COLOMBO COMUNE DI MONTE COLOMBO SISTEMA DI VALUTAZIONE DELLA PERFORMANCE INDIVIDUALE DEL PERSONALE DIPENDENTE MANUALE PER LA VALUTAZIONE INDICE Finalità della valutazione Pag. 3 Oggetto della valutazione Pag.

Dettagli

Le fasi di un percorso di consultazione online

Le fasi di un percorso di consultazione online Progetto PerformancePA Ambito A - Linea 1 - Una rete per la riforma della PA Le fasi di un percorso di consultazione online Autore: Angela Creta, Laura Manconi Creatore: Formez PA, Progetto Performance

Dettagli

Relazione annuale sulla valutazione della didattica da parte degli studenti A.A. 2009/2010

Relazione annuale sulla valutazione della didattica da parte degli studenti A.A. 2009/2010 UNIVERSITA DEGLI STUDI DEL PIEMONTE ORIENTALE Relazione annuale sulla valutazione della didattica da parte degli studenti A.A. 2009/2010 Aprile 2011 Indice Premessa 1. La metodologia adottata. 3 2. Lo

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

IL FAI DA TE NEL SOFTWARE DIDATTICO

IL FAI DA TE NEL SOFTWARE DIDATTICO IL FAI DA TE NEL SOFTWARE DIDATTICO La realizzazione delle tastiere virtuali didattiche - 3 a parte Prosegue l articolo in cui l autore chiarisce che l individuazione o l impostazione della struttura logica

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

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

Dettagli

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

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

Dettagli

La Guida a Scrum. La Guida Definitiva a Scrum: Le Regole del Gioco. Luglio 2013. Sviluppata e mantenuta da Ken Schwaber Jeff Sutherland

La Guida a Scrum. La Guida Definitiva a Scrum: Le Regole del Gioco. Luglio 2013. Sviluppata e mantenuta da Ken Schwaber Jeff Sutherland La Guida a Scrum La Guida Definitiva a Scrum: Le Regole del Gioco Luglio 2013 Sviluppata e mantenuta da Ken Schwaber Jeff Sutherland Table of Contents Scopo della Guida a Scrum... 3 Definizione di Scrum...

Dettagli

Lo Studio di Fattibilità

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

Dettagli

e.toscana Compliance visione d insieme

e.toscana Compliance visione d insieme Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Ingegneria dei Sistemi Informativi e della Comunicazione I.T.S.A.E. e.toscana Compliance visione d insieme Gennaio 2007 Versione

Dettagli

Dalla classe alla rete, l esperienza come tutor di un gruppo di insegnanti

Dalla classe alla rete, l esperienza come tutor di un gruppo di insegnanti Dalla classe alla rete, l esperienza come tutor di un gruppo di insegnanti Morena Terraschi Lynx Srl via Ostiense 60/D 00154 Roma morena@altrascuola.it http://corsi.altrascuola.it Corsi Altrascuola è la

Dettagli

SCOPRI G2 AUTOMOTIVE. L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS.

SCOPRI G2 AUTOMOTIVE. L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS. SCOPRI G2 AUTOMOTIVE. L ESCLUSIVO SISTEMA PERSONALIZZATO CHE GESTISCE IL TUO PARCO CLIENTI. E GENERA NUOVO BUSINESS. Efficiente, rapido, su misura. G2 Automotive è l innovativo sistema di gestione specifico

Dettagli

Il modello RAD 1. Rapid Application Development punta a un ciclo di sviluppo molto breve

Il modello RAD 1. Rapid Application Development punta a un ciclo di sviluppo molto breve Il modello RAD 1 Rapid Application Development punta a un ciclo di sviluppo molto breve adattamento del modello a cascata in cui l obiettivo di uno sviluppo rapido è raggiunto grazie a strategie costruttive

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

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab.

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab. Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Gli elementi che caratterizzano il Sistema Qualità e promuovono ed influenzano le politiche di gestione delle risorse

Dettagli

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

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

Dettagli

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

LearnIT project PL/08/LLP-LdV/TOI/140001

LearnIT project PL/08/LLP-LdV/TOI/140001 LearnIT project PL/08/LLP-LdV/TOI/140001 Caro Lettore, Siamo lieti di presentare il sesto numero della newsletter LearnIT. In questo numero spiegheremmo lo sviluppo del i corsi LearnIT, la selezione dei

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

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

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

Sequence Alignment Algorithms

Sequence Alignment Algorithms Sequence Alignment Algorithms Algoritmi per l Allineamento di Sequenze Relatore: Prof. Giancarlo Mauri Correlatore: Prof. Gianluca Della Vedova Tesi di Laurea di: Mauro Baluda Matricola 038208 Part of

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

METODI E STRUMENTI PER LA GESTIONE E IL CONTROLLO DELLA QUALITÀ NELL EROGAZIONE DI SERVIZI DI PUBBLICA UTILITÀ: IL CASO METRONAPOLI

METODI E STRUMENTI PER LA GESTIONE E IL CONTROLLO DELLA QUALITÀ NELL EROGAZIONE DI SERVIZI DI PUBBLICA UTILITÀ: IL CASO METRONAPOLI Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di laurea in Ingegneria Gestionale Abstract di tesi di laurea in GESTIONE AZIENDALE METODI E STRUMENTI PER LA GESTIONE E IL CONTROLLO

Dettagli

La creazione del valore. Un approccio agile alla trasformazione dell IT

La creazione del valore. Un approccio agile alla trasformazione dell IT Università degli Studi di Padova Dipartimento di Ingegneria dell Informazione Corso di Laurea in Ingegneria Informatica Relazione finale di tirocinio La creazione del valore. Un approccio agile alla trasformazione

Dettagli

1. Il ruolo della pianificazione nella gestione del progetto

1. Il ruolo della pianificazione nella gestione del progetto 11 1. Il ruolo della pianificazione nella gestione del progetto Poiché ciascun progetto è un processo complesso ed esclusivo, una pianificazione organica ed accurata è indispensabile al fine di perseguire

Dettagli

7.1 Livello di completezza degli esempi

7.1 Livello di completezza degli esempi Luca Cabibbo Analisi e Progettazione del Software Capitolo 7 marzo 2013 Buono, poco costoso, rapidamente. Puoi scegliere due di queste caratteristiche. Anonimo 1 *** AVVERTENZA *** I lucidi messi a disposizione

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

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

EPULIA - Enjoy Puglia using Ubiquitous technology in Landscape Interactive Adventures

EPULIA - Enjoy Puglia using Ubiquitous technology in Landscape Interactive Adventures UNIONE EUROPEA FONDO EUROPEO DI SVILUPPO REGIONALE. MINISTERO SVILUPPO ECONOMICO REGIONE PUGLIA AREA POLITICHE PER LO SVILUPPO IL LAVORO E L INNOVAZIONE PO FESR PUGLIA 2007-2013 Asse I Linea di Intervento

Dettagli

RILEVARE LA SODDISFAZIONE DEI DIPENDENTI

RILEVARE LA SODDISFAZIONE DEI DIPENDENTI RILEVARE LA SODDISFAZIONE DEI DIPENDENTI EMPLOYEE (PEOPLE) SATISFACTION Non bisogna mai dimenticare che i primi clienti di un organizzazione sono i collaboratori interni e che un indicatore molto importante

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Nota informativa ISO/IEC 27001 Il processo di valutazione

Nota informativa ISO/IEC 27001 Il processo di valutazione Nota informativa ISO/IEC 27001 Il processo di valutazione Introduzione Questa nota informativa ha lo scopo di introdurre le fasi principali del processo di valutazione LRQA riferito al Sistema di Gestione

Dettagli

Collaborazione: gli entusiasti ed i ritardatari

Collaborazione: gli entusiasti ed i ritardatari Collaborazione: gli entusiasti ed i ritardatari Obiettivi di apprendimento Sono sempre di più le aziende interessate ad approfondire la conoscenza degli strumenti di collaborazione per migliorare la propria

Dettagli

I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI

I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI I. ORGANIZZARE E GESTIRE PROGETTI: ASPETTI INTRODUTTIVI 1. Lavorare per progetti La parola, oltre ad avere il significato del lessico comune, significa anche approccio manageriale, soprattutto da quando

Dettagli

La seduta di allenamento tecnico tattico. Corso Allenatore di primo grado Cremona 10 Aprile 2011

La seduta di allenamento tecnico tattico. Corso Allenatore di primo grado Cremona 10 Aprile 2011 La seduta di allenamento tecnico tattico Corso Allenatore di primo grado Cremona 10 Aprile 2011 La capacità di prestazione sportiva rappresenta il grado di formazione di una determinata prestazione motoria

Dettagli

REALIZZARE PROCESSI DI VENDITA CHE SOSTENGANO UNA CRESCITA PROFITTEVOLE

REALIZZARE PROCESSI DI VENDITA CHE SOSTENGANO UNA CRESCITA PROFITTEVOLE REALIZZARE PROCESSI DI VENDITA CHE SOSTENGANO UNA CRESCITA PROFITTEVOLE SALESFORCE EFFECTIVENESS 1. [ GLI OBIETTIVI ] PERCHÉ DISPORRE DI PROCESSI COMMERCIALI PIÙ COMPETITIVI? Realizzare nel tempo una crescita

Dettagli

Fase di offerta. Realizzazione del progetto

Fase di offerta. Realizzazione del progetto Linee guida per un buon progetto Commissione dell informazione e dei Sistemi di Automazione Civili e Industriali CONTENUTI A) Studio di fattibilità B) Progetto di massima della soluzione C) Definizione

Dettagli

D4.1 Curriculum iniziale per i digital curators

D4.1 Curriculum iniziale per i digital curators D4.1 Curriculum iniziale per i digital curators Autori: Laura Molloy (HATII) Leo Konstantelos (HATII) Ann Gow (HATII) David Wilson (HATII) Seamus Ross (ischool, utoronto) Nathan Moles (ischool, utoronto)

Dettagli

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

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Sistema informativo per la gestione dei processi

Dettagli

ANALISTA PROGRAMMATRICE e PROGRAMMATORE

ANALISTA PROGRAMMATRICE e PROGRAMMATORE Aggiornato il 9 luglio 2009 ANALISTA PROGRAMMATRICE e PROGRAMMATORE 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono

Dettagli

Il Processo Software

Il Processo Software Il Processo Software 29-03-2012 Prodotto Software Prodotto di qualità Tempi e costi determinati Processo Software Attività portanti Famiglia di compiti Attività ausiliari Quadro di riferimento Processo

Dettagli

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami Echi da Amsterdam Sintesi del Leadership Meeting e dell EMEA Congress 2009 Titolo: Sintesi presentazioni Metodologia Agile Relatore: Bruna Bergami PMI NIC - Tutti i diritti riservati Milano, 19 Giugno

Dettagli

Processo di referaggio collana punto org

Processo di referaggio collana punto org Caro Referee, grazie in anticipo per aver accettato di referare per la collana punto org. Il Suo è un ruolo delicato: appartiene a una comunità di studiosi, docenti e professionisti che forniscono ai colleghi

Dettagli

Traduzione non ufficiale

Traduzione non ufficiale Traduzione non ufficiale Proposta di RACCOMANDAZIONE DEL PARLAMENTO EUROPEO E DEL CONSIGLIO sulla costituzione del Quadro europeo delle Qualifiche per l apprendimento permanente (testo con attinenza all

Dettagli