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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CONCETTI DI BASE PER LA QUALITA

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

Dettagli

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

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Progetto di Informatica III

Progetto di Informatica III Progetto di Informatica III Sviluppo Agile (Agile Software Development) Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Metodologia agile Agile Manifesto Che cos è l agilità

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

Corso di Ingegneria del Software. Modelli di produzione del software

Corso di Ingegneria del Software. Modelli di produzione del software Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali

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

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

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

Ottimizzare Agile per la. agility made possible. massima innovazione

Ottimizzare Agile per la. agility made possible. massima innovazione Ottimizzare Agile per la agility made possible massima innovazione Agile accelera l'offerta di innovazione Lo scenario aziendale attuale così esigente e in rapida evoluzione ha enormemente amplificato

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

Feedback report ISTITUTO D ISTRUZIONE SUPERIORE ISTITUTO TECNICO AGRARIO E PROFESSIONALE FIRENZE

Feedback report ISTITUTO D ISTRUZIONE SUPERIORE ISTITUTO TECNICO AGRARIO E PROFESSIONALE FIRENZE Feedback report ISTITUTO D ISTRUZIONE SUPERIORE ISTITUTO TECNICO AGRARIO E PROFESSIONALE FIRENZE 4 GIUGNO 2014 Feedback report Nome dell organizzazione: Indirizzo: Referente: ISTITUTO D ISTRUZIONE SUPERIORE

Dettagli

Il Processo Software

Il Processo Software Il Processo Software 03/04/13 Prodotto Software Prodotto di qualità Tempi e costi determinati Processo Software Attività portanti Famiglia di compiti Attività ausiliari Quadro di riferimento Processo Software

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

* Che cos è un processo software

* Che cos è un processo software Luca Cabibbo Analisi e Progettazione del Software Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2013 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano

Dettagli

Il metodo extreme Programming in sintesi

Il metodo extreme Programming in sintesi extreme Programming Approach Il metodo extreme Programming in sintesi Piergiuliano Bossi Coach Marina Morgagni Engagement Manager Quinary SpA Copyright 2001-2004 Quinary SpA Tutti i diritti sono riservati.

Dettagli

LA GESTIONE QUANTITATIVA DI

LA GESTIONE QUANTITATIVA DI LA GESTIONE QUANTITATIVA DI PROGETTI SOFTWARE DOMENICO CLERICI LUIGI PETRUZZELLI Dalla IV di copertina... La gestione quantitativa di progetti software - Presentazione Gli autori del libro si sono proposti

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

Rilevazione gradimento servizio di Management Didattico Aprile 2014

Rilevazione gradimento servizio di Management Didattico Aprile 2014 Rilevazione gradimento servizio di Management Didattico Aprile 2014 Nel 2014 il servizio di Management Didattico è stato valutato da complessivamente 3540 studenti (rispetto a 3.999 nel 2012) che hanno

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 6

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

Dettagli

Ref: 2013-1-ES1-LEO05-66260

Ref: 2013-1-ES1-LEO05-66260 Ref: 2013-1-ES1-LEO05-66260 Buone pratiche nell uso di ambienti di apprendimento collaborativo quali strumenti per favorire la creatività ed identificazione di modelli di successo nel settore metalmeccanico

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

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

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA Il project management nella scuola superiore di Antonio e Martina Dell Anna 2 PARTE I PROCESSI AZIENDALI E PROGETTI UDA 3 I PRINCIPI DEL PROJECT MANAGEMENT

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

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

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

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

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

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

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Prof. Andrea Borghesan & Dr.ssa Francesca Colgato venus.unive.it/borg borg@unive.it Ricevimento: mercoledì dalle 10.00 alle 11.00 Modalità

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

Quali passi per introdurre l Agile in azienda?

Quali passi per introdurre l Agile in azienda? Quali passi per introdurre l Agile in azienda? Garantire reattività e prontezza in uno scenario sempre più dinamico Quali passi per introdurre l Agile in azienda? White Paper Nell attuale contesto di mercato,

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

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

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 20 gennaio 2009 INDICE Sezione Contenuto 1. Il programma Responsible Care: scopo e campo di applicazione

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

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

Gestire un progetto di introduzione di sistemi informativi di SCM. 1 Marco Bettucci Gestione della produzione II - LIUC

Gestire un progetto di introduzione di sistemi informativi di SCM. 1 Marco Bettucci Gestione della produzione II - LIUC Gestire un progetto di introduzione di sistemi informativi di SCM 1 Che cos è un progetto? Una serie complessa di attività in un intervallo temporale definito... finalizzate al raggiungimento di obiettivi

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

Comunicare, condividere e cooperare attraverso tecnologie digitali

Comunicare, condividere e cooperare attraverso tecnologie digitali Comunicare, condividere e cooperare attraverso tecnologie digitali Via Asiago, 33/1 36030 Sarcedo (Vi) tel 0445 381199 fax 0445 381199 Chi siamo Globalcomm spa fa parte del gruppo aziendale di ATP Telecomunicazioni:

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

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

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

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

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

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

Test e collaudo del software Continuous Integration and Testing

Test e collaudo del software Continuous Integration and Testing Test e collaudo del software Continuous Integration and Testing Relatore Felice Del Mauro Roma, Cosa è la Continuous Integration A software development practice where members of a team integrate their

Dettagli

UNIVERSITÀ DEGLI STUDI DELL INSUBRIA SETTORE ORIENTAMENTO - Ufficio Orientamento e Diritto allo Studio

UNIVERSITÀ DEGLI STUDI DELL INSUBRIA SETTORE ORIENTAMENTO - Ufficio Orientamento e Diritto allo Studio FACOLTÀ DI SCIENZE MM.FF.NN. COMO Scienze e Tecnologie dell Informazione Corso di laurea triennale - Classe n. 26 Scienze e tecnologie informatiche Caratteristiche e obiettivi del corso Il corso di Laurea

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Groupware e workflow

Groupware e workflow Groupware e workflow Cesare Iacobelli Introduzione Groupware e workflow sono due parole molto usate ultimamente, che, a torto o a ragione, vengono quasi sempre associate. Si moltiplicano i convegni e le

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

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

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

Comunicare, condividere e cooperare attraverso tecnologie digitali

Comunicare, condividere e cooperare attraverso tecnologie digitali Comunicare, condividere e cooperare attraverso tecnologie digitali Via Asiago, 33/1 36030 Sarcedo (Vi) tel. 0445 381199 - fax 0445 381179 Chi siamo Globalcomm SpA fa parte del gruppo aziendale di ATP Telecomunicazioni:

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

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

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

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

Dettagli

Ingegneria del Software. Introduzione ai pattern

Ingegneria del Software. Introduzione ai pattern Ingegneria del Software Introduzione ai pattern 1 Definizione di pattern [dal [dal vocabolario vocabolario Garzanti] Garzanti] Alcuni esempi: Pattern architetturale Pattern di circuito stampato Pattern

Dettagli

Lezione 12 Applicazioni: Internet stock, fusioni ed acquisizioni

Lezione 12 Applicazioni: Internet stock, fusioni ed acquisizioni Lezione 12 Applicazioni: Internet stock, fusioni ed acquisizioni Analisi degli Investimenti 2014/15 Lorenzo Salieri Internet Stock In concomitanza alla crescente popolarità del settore Internet osservata

Dettagli

Assistenza e consulenza per tesi di laurea

Assistenza e consulenza per tesi di laurea Assistenza e consulenza per tesi di laurea Sede: Cosenza (in aula ed in videoconferenza) Destinatari Studenti universitari/laureandi per assistenza e consulenza per tesi di laurea in tutte le materie giuridiche

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

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