Confronto e analisi di tre processi di sviluppo del Software: Modelli a Cascata, a Spirale e Extreme Programming

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Confronto e analisi di tre processi di sviluppo del Software: Modelli a Cascata, a Spirale e Extreme Programming"

Transcript

1 Confronto e analisi di tre processi di sviluppo del Software: Modelli a Cascata, a Spirale e Extreme Programming Studio realizzato a partire dei progetti realizzati nel ambito del corso di Ingenieria del Software Caroline Dos 19 settembre 2012, Bologna

2 Indice 1 Cascata, Spirale e Extrem Programming a confronto Breve presentazione dei tre processi Il modello a cascata Il modello a Spirale il modello Extrem Programming Differenze principale tra i Processi Differenze organizzazionali La soddisfazione del cliente e le priorità dei cicli Qualità interna e costo del cambiamento Produttività nelle varie attività Analisi dei risultati empirici Esposizioni dei parametri, del metodo e delle ipotesi iniziali dell analisi Parametri del progetto Selezionamento dei dati rilevanti e strumenti statistici Ipotesi Esposizione dei risultati Durata e sforzo impiegato Documentazione prodotta Qualità del software Conclusioni e limiti dell analisi Ipotesi e risultati a confronto: Durata e sforzo: Quantita di documentazione fornita Qualità della documentazione fornita Qualità esterna del softaware Qualità interna del software Conclusione Elenco delle figure 32 1

3 Elenco delle tabelle 34 Bibliografia 35 2

4 Introduzione La scelta del modello di sviluppo è una delle più importanti decisioni che un project manager deve prendere prima di cominciare un progetto. Il processo di sviluppo inizialmente selezionato, condizionerà l organizzazione, le priorità e quindi il lavoro dell intera squadra implicata nel ciclo di vita del software. Esiste una vasta letteratura sull argomento, e molti scienziati hanno collaborato al fine di definire approcci alternativi, cercando di evidenziarne i difetti e le qualità di ciascuno. Però sono pochi gli studi empirici che hanno potuto essere realizzati al fine di comprendere e analizzare l impatto reale di tale processo, a causa della difficoltà nel raccogliere dati significativi. Infatti, per essere sfruttabili, tali dati devono essere tratti da progetti che condividono molte variabili in comune, quali la complessità, le dimensioni del progetto, il contesto di lavoro, il numero di componenti delle squadre, e tanti altri parametri che non enumereremo qui, ma che sono altrettanto importanti. Questo lavoro, realizzato nell ambito del corso di Ingegneria del Software, si propone di condurre questa analisi. Infatti, grazie al lavoro di 84 studenti ripartiti in 21 squadre di 4 persone, siamo stati capaci di raccogliere i dati necessari allo studio. A ciascuna squadra è stato imposto uno dei modello di sviluppo seguenti: il modello a Cascata il modello a Spirale il modello Extreme Programming Questi tre modelli sono stati formalizzati in periodi differenti e corrispondono all evoluzione della riflessione sul ciclo di sviluppo. Prima di presentare i risultati ottenuti dai vari gruppi di studenti, faremo una breve esposizione di questi processi, confrontandoli al fine di evidenziare le differenze e le somiglianze tra gli stessi. Facendo riferimento alla letteratura esistente proveremo a mostrare quali difetti e quali pregi possiedono, permettendoci di formulare varie ipotesi che andremo a verificare in seguito, mentre eseguiremo l analisi empirica. Infine, dopo tali analisi, proveremo a trarne delle conclusioni, tenendo conto dei limiti dei risultati e dei vari parametri dell esperienza.

5 1 Cascata, Spirale e Extrem Programming a confronto 1.1 Breve presentazione dei tre processi Il modello a cascata All inizio degli anni 70, grazie al progresso della tecnologia e all abbassamento del costo del materiale, i progetti di software diventano sempre più grandi e complessi. In questa maniera, il modello che Boehm[5] chiama il code-and-fix model non è più adatto. Royce[18] è il primo a formalizzare un nuovo modello chiamato Waterfall model o modello a Cascata, che risponde al nuovo bisogno di pianificazione ed organizzazione del lavoro. È stato dato tale nome poiché il suo approccio è sequenziale: infatti questo modello raccomanda di procedere nell avanzamento del progetto per fasi successive, che sono: l analisi dei requisiti l analisi la progettazione l implementazione del codice il testing e l integrazione del software e la sua messa in produzione la manutenzione Ciascuna fase può cominciare quando la fase precedente è validata. Se non è validata, solo la fase immediatamente precedente può essere rielaborata. Il suo approccio sistematico, ispirato dalle organizzazioni burocratiche, porta alla produzione di una copiosa documentazione: in effetti, per ciascuna fase deve essere rilasciato un documento che se validato verrà congelato. In questo modello, il cliente è quindi consultato un unica volta all inizio del processo, e il prodotto finale risponderà ai suoi bisogni iniziali. 1

6 1.1.2 Il modello a Spirale Il modello a Spirale viene formalizzato da Boehm[5] in 1988, quindi quasi 20 anni dopo, e si propone come una sorta di compromesso tra diversi metodi quali il modello di Royce e il modello evolutivo basato sulle produzione di prototipi. Ha per principale motivazione l analisi e la riduzione dei rischi. È un modello ciclico, nel quale ogni ciclo è composto di 4 fasi: la definizione degli obiettivi, delle restrizioni e delle possibili alternative che rispondono a questi obiettivi l analisi del rischio di ciascuna delle alternative e l identificazione della soluzione che comporta il minor numero di rischi lo sviluppo della soluzione scelta e la sua verifica (si può adottare il modello a Cascata per questa fase se è ritenuto adeguato). la pianificazione della fase successiva Alla fine di ciascun ciclo, il cliente viene incontrato e la soluzione sviluppata (che sia cartacea o software) gli viene mostrata. Il successivo ciclo della Spirale ripete le fasi sopra indicate tenendo conto della reazione del cliente, e sviluppando in maniera incrementale (abbordando nuove funzionalità) e iterativa (sempre più nel dettaglio) la soluzione precedentemente creata. Ciascun ciclo ha una durata media che va da 6 mesi a due anni il modello Extrem Programming Nel 1999, Kent Beck[4], nel suo libro Extrem Programming Explained. Embrace Change, ha esposto le basi di un modello di sviluppo ormai diventato famoso: Extreme Programming o XP, che è sia un processo che una metodologia. Infatti, da raccomandazione sia sulla maniera di navigare tra le diverse fasi dello sviluppo, sia su come muoversi all interno di ciascuna fase. Beck è diventato uno dei membri della Agil Alliance formatasi nel Il processo di sviluppo di XP propone uno sviluppo iterativo, incrementale e adattativo ai possibili cambiamenti che si possono verificare durante la vita del progetto. In questo processo, il cliente ha un ruolo centrale e deve essere disponibile a tempo pieno. Un progetto XP comincia con le seguenti fasi: l esplorazione, che consiste per il client nello stabilire i principali requisiti funzionali dell applicazione attraverso la redazione degli user stories, che sono requisiti scritti nel linguaggio del client, e per il team nello stabilire gli strumenti da usare la pianificazione, che consiste per il client nell esporre ed indicare le priorità dei requisiti e per il team nel valutare in maniera astratta il costo di ciascuna delle implementazioni e il tempo di realizzazione di ciascuna delle user stories iniziali. 2

7 la produzione della prima release entro un termine molto breve (non più di un mese dall inizio del progetto) In seguito, saranno eseguite iterazioni successive di corta durata che riprenderanno successivamente la pianificazione (nella quale il cliente definirà le nuove user stories accompagnate dal feedback delle precedenti release ) e le fasi di produzione. In ciascuna iterazione vengono eseguiti, in funzione dei bisogni, l analisi dei requisiti, l analisi, la progettazione, l implementazione e i test corrispondenti alla nuova user story specificata. Ciascuna release integra quindi le nuove funzionalità, permettendo al cliente di vedere l avanzamento del progetto. Quando il progetto conterrà abbastanza funzionalità, il software entrerà in fase di produzione, raccogliendo il feedback di più utilizzatori. Le iterazioni corrispondenti a questa fase saranno quindi dedicate sia al aggiunta di nuove funzionalità all applicazione,sia al miglioramento delle funzionalità implementate in precedenza. La fase di maintenance sarà poi dedicata al rilascio di release aggiornate. Infine, la fase di morte congelerà la release finale. Figura 1.1: Ciclo di vita di un processo XP[1] Figura 1.2: Sviluppo di una singola iterazione[4] 3

8 XP non si accontenta di fornire un piano di processo. Indica anche, come precedentemente detto, un insieme di metodologie chiamate good practices che permettono di fornire un software di qualità che risponda ai bisogni del cliente e nello stesso momento di aumentare la produttività. Il pair programming, la possibilità per ogni sviluppatore di modificare il codice, l adozione di standard di codifica, la breve riunione giornaliera all inizio della giornata di lavoro o l utilizzo di una metafora permettono alla squadra di incitare il brainstorming e di essere più coesa, e quindi più produttiva. Le piccole release, il refactoring, l adozione della soluzione di progettazione più semplice, lo sviluppo di classe di test automatici, o l integrazione continua permettono di migliorare sempre più il codice e di permettere in seguito un più facile avanzamento. 4

9 1.2 Differenze principale tra i Processi Ci si può quindi rendere conto attraverso questa breve esposizione che questi tre modelli presentano molte differenze Differenze organizzazionali Prima di tutto,come lo mostra la figura 1.3, la differenza principale risiede nel numero e nella dimensione dei cicli di sviluppo. Mentre c è ne solo uno per il modello a Cascata, il modello a Spirale ne prevede diversi, mentre XP ne prevede molti di breve durata. Figura 1.3: I cicli dei tre processi a confronto La soddisfazione del cliente e le priorità dei cicli Il cliente, al centro del processo? L atteggiamento rispetto ai bisogni evolutivi del cliente è anche una delle principali differenze tra questi tre modelli. Waterfall parte del presupposto che i requisiti iniziali saranno quelli definitivi, mentre Spirale e XP, (quest ultimo ad un grado ancora più elevato), tengono conto dell evoluzione dei bisogni del cliente. D altro canto, questi ultimi due processi richiedono una disponibilità più grande da parte di quest ultimo, soprattutto XP che necessita della sua continua partecipazione al progetto. Soddisfare il cliente, evitare situazioni rischiose per l impresa di produzione del software, o sviluppare una ricca documentazione? Anche le priorità per ogni processo sono diverse. Mentre il modello Waterfall considera come primordiale la produzione di una documentazione ricca per ciascuna fase del processo, Spirale 5

10 si concentra sull analisi dei rischi e XP, come tutte le metodologie agili, sulla soddisfazione del cliente e la comunicazione all interno del team 1. Il fatto che l enfasi non sia messa sulla produzione di documentazione nel modello a Spirale e in XP non vuole dire che questa non sia sviluppata. Al contrario, siccome Spirale può seguire all interno di ogni ciclo il modello Waterfall, il risultato spesso ottenuto è un ampliamento della documentazione. In effetti tale documentazione relativa all analisi dei rischi viene aggiunta mentre in ciascun ciclo le tradizionali fasi vengono reiterate. La tabella 1.4 tratta dal lavoro di Carolyn Mizell e Linda Malone[16] del 2009 basato su un precedente studio di Boehm mostra che lo sforzo dedicato all implementazione e sopratutto all integrazione del codice è significativamente meno importante in termini di ripartizione che per il metodo Waterfall. Lo sforzo si riporta su attività come l analisi del rischio e la pianificazione del prossimo ciclo, mentre attività come l analisi dei requisiti, l analisi e la progettazione sono globalmente paragonabili. XP produce anche una ricca documentazione, ma alla condizione Figura 1.4: Ripartizione dello sforzo:waterfall e Spirale a confronto[16] di non rubare tempo all implementazione. Si deve ad esempio preferire descrivere i modelli dei diagrammi sulla lavagna e farne successivamente delle fotografie, piuttosto che impegnare tempo a realizzare disegni accurati. Alla stessa maniera, se l analisi dei rischi in Cascata avviene solo all inizio del processo, XP non ignora l importanza di tale analisi. La fase di pianificazione, all inizio di ogni iterazione permette di valutare i rischi grazie ad una breve riunione dove si identificano le priorità del cliente e dove viene stimato per il team il costo di ciascuna funzionalità. Durante l iterazione, verrà raffinato questa valutazione, permettendo quindi rapidamente di identificare le situazioni rischiose. Ad esempio, se una funzionalità è troppo costosa,ed allo stesso tempo la sua priorità per il cliente è bassa, essa verrà abandonata. 1 I principi proclamati nell home page del Agile Alliance sono molto espliciti: Individuals and interactions over processes and tools; Working software over comprehensive documentatio; Customer collaboration over contract negotiation; Responding to change over following a plan[2] 6

11 Figura 1.5: XP e Spirale a confronto[10]: risultato del tasso di errori per iterazioni nei due progetti-tabella Figura 1.6: XP e Spirale a confronto[10]: risultato del tasso di errori per iterazione nei due progetti-grafico.(case 1:Spirale, Case 2:XP) Qualità interna e costo del cambiamento Qualità interna La qualità interna del software viene influenzata anche da questi vari processi. Mentre la separazione rigida della fase d implementazione dalla fase di testing in Waterfall può provocare la scoperta tardiva di errori che influenzano l intero sistema, e che sono a questo punto difficili da risolvere, XP con i suoi continui test e la sua continua integrazione evita questo pericolo. Un altra conseguenza della separazione di queste due fasi nel modello a Cascata, può essere una riduzione della fase di test. In effetti, uno dei miti dello sviluppatore consiste nel fatto che lo sforzo più elevato viene eseguita nella fase di sviluppo: la conseguenza di questa credenza è che, una volta arrivato alla fase di test quindi, quest ultimo non è più spinto ad esplorare tutte le possibili incrinature del sistema. Studi realizzati per paragonare la qualità di software sviluppati con il processo XP o Spirale, tendono a mostrare che non ci sono significative influenze sulla qualità dell operato. È però vero che principi come il Pair Programming e il refactoring, tendono a fare abbassare il tasso di errori prodotti. La tabella 1.5 riassume i risultati ottenuti dallo studio[10] di Sajid Ibrahim Hashmi and Jongmoon Baik nel loro articolo Software Quality Assurance in XP and Spiral - A Comparative Study. Questo studio mostra che Spirale produce un tasso di errore per ogni migliaio di linee di codice più elevato di XP. Il risultato dello studio è però da considerare con cautela a causa delle dimensioni differenti dei progetti (più importanti per Spirale che per XP). Un risultato sicuramente significativo di quest analisi è quello di illustrare la positiva influenza del pair programming. Mentre per le tre prime iterazioni gli studenti hanno lavorato in coppia, nella quarta hanno preferito il lavoro individuale. Il risultato 7

12 ottenuto è un incremento importante del tasso di errore. Altri studi hanno però evidenziato che i continui cambiamenti apportati dal cliente potevano influenzare la qualità finale del software. D altro canto hanno evidenziato che XP non era adatto a team troppo grandi. Infatti, pratiche come la modifica del codice per ogni membro del team necessita di una comunicazione facilitata tra tutti i membri della squadra. Se la comunicazione è resa impossibile, allora sicuramente la pratiche incoraggiate da XP porteranno a risultati disastrosi. Per queste tipologie di progetti, è preferibile un approccio più disciplinato come il modello a Spirale. Costo del cambiamento Una delle conseguenze più note dell influenza del processo sulla qualità del software, è la ripercussione sul costo del cambiamento, ovvero della manutenzione che verrà necessariamente eseguita una volta rilasciata una versione messa in produzione. Questo aspetto è stato considerato a partire dalla creazione del modello XP. In effetti, la tradizionale curva del costo del cambiamento disegnata da Boehm (figura 1.7), cresce esponenzialmente man mano che il progetto stesso evolve, fino a raggiungere costi così alti che la manutenzione del software diventa impossibile. Questo é quindi un avvertimento da parte di Boehm. Si deve concepire il software oggi in maniera che accolga i cambiamenti domani. Secondo il suo modello della Spirale, la fase di maintenance viene eseguita attraverso un successivo ciclo di Spirale, nel quale viene analizzato il rischio dovuti ai cambiamenti. Attraverso tale analisi, in cui viene eseguito uno studio di fattibilità, le soluzioni più costose sono evitate. Il modello limita i costi però non pretende di invertire la loro tendenza all aumento. Beck, cosciente di questa tendenza, ha pensato quindi il suo metodo per evitare questo pro- Figura 1.7: Il costo del cambiamento dei processi tradizionali secondo Boehm blema primordiale. Identificando i problemi all inizio del ciclo, i costi sono ridotti. È quindi uno dei principali argomenti per eseguire i test sistematici e l integrazione continua insieme a pratiche come il Pair Programming, o il refactoring.la curva disegnata da Boehm diventa quindi quella della figura

13 Figura 1.8: Il costo del cambiamento con XP secondo Beck Oltre alla detezione degli errori relativi alla qualità interna del software, gli errori relatvi alla qualità esterna del software, cioè la mancanza alla soddisfazione dei requisiti del cliente, vengono prima evidenziati grazie come precedentemente detto, alla participazione attiva del cliente nell progetto, e alla brevità delle iterazioni durante l intero processo, permettendo quindi di riorientare il lavoro se si è avanzato sulla strada sbagliata.la figura 1.9 disegnata da Ambler[3] permette di evidenziare la differenza d approcio tra le metodologie agile e quelli tradizionali. Figura 1.9: Come aumentare/diminuire il costo del cambiamento secondo Ambler[3] 9

14 1.2.4 Produttività nelle varie attività Infine la produttività viene anche considerevolmente influenzata dalla scelta del processo. Lo studio di Carolyn Mizell e Linda Malone[16] mette in evidenza che progetti di tipo Spirale richiedono un sforzo e una durata complessiva superiore ad un modello a Cascata. Questo si spiega sia a causa di cicli ripetitivi, nei quali possibili parti del prototipo saranno rifatte nella Spirale successiva, sia a causa di fasi aggiuntive (analisi del rischio e pianificazione della fase successiva). La tabella 1.10 illustra i risultati ottenuti. Figura 1.10: Durata e sforzo tra progetti seguendo Waterfall e Spirale [16] Beck ha voluto evitare questo incremento dei tempi e dello sforzo. L abitudine di procedere per incrementi sottomessi a test continui, refactoring, o integrazione continua permette a ciascuna release di ottenere un software robusto le cui funzionalità saranno definitive per la maggior parte di loro. Il team non sarà quindi tenuto ad eseguire revisioni dell operato creato in ciascun nuovo ciclo, come avviene nel modello a Spirale. L analisi di Lucas Layman, Laurie Williams, Lynn Cunningham, nel loro studio Exploring Extreme Programming in Context: An Industrial Case Study[14], pubblica risultati ottenuti in un contesto industriale: la produttività è significativamente più elevata nella nuova versione eseguita con un modello XP rispetto alla vecchia, nella quale era stato impiegato il metodo Waterfall assieme a qualche pratica XP. Figura 1.11: XP e Waterfall a confronto: Condizioni del analisi eseguita [14] 10

15 Figura 1.12: XP e Waterfall a confronto: Risultati del analisi eseguita [14] 11

16 2 Analisi dei risultati empirici Grazie a questa breve presentazione e a questo confronto tra i vari processi sopra citati, abbiamo potuto sottolineare le loro differenze e le aspettative che si possono avere riguardo ad ognuno di essi. Analizzeremo adesso i risultati ottenuti al fine di mettere a fuoco l impatto reale di questi metodi di sviluppo sul lavoro di una popolazione di studenti, che quindi hanno ancora poca esperienza, su di un breve periodo,poiché il progetto cominciato il 7 Marzo 2012, doveva essere consegnato il 25 Maggio dello stesso anno. 2.1 Esposizioni dei parametri, del metodo e delle ipotesi iniziali dell analisi Parametri del progetto Ciascun gruppo, composto di 4 studenti doveva realizzare un software di gestione che poteva essere uno dei seguenti: un gestore di sala di cinema, un gestore di studio medico, un gestore ospedaliero o ancora un gestore di car-pooling. Ciascun team era cliente di un altro gruppo insieme al suo iniziale ruolo di produttore. Doveva quindi, in quanto cliente, valutare i documenti e l operato rilasciato, e rispettare il modello adottato dal suo produttore. Questo modello non è stato scelto ma imposto dai docenti, in modo casuale. Ogni gruppo, indipendentemente dal modello doveva consegnare in date precise documenti relativi al piano di processo, all analisi dei requisiti, all analisi e alla progettazione Selezionamento dei dati rilevanti e strumenti statistici L approccio adottato per realizzare tale analisi è stato di seguire il metodo Goal-Questions- Metrics (figura 2.1). Per rispondere a ciascuna domanda abbiamo identificato una serie di metriche tratte dalla letteratura considerata generalmente più rilevante nell analisi dello sviluppo di progetti di software. Per quanto riguarda la durata e lo sforzo, abbiamo considerato le tradizionali misure in giorni e mese-persona. Per misurare la quantità della documentazione, abbiamo usato il numero di pagine prodotto per 12

17 Figura 2.1: Modello Goal-Questions-Metrics ciascun gruppo. Questa fase è stata un po delicata, perché obbligava talvolta alla riclassificazione dei documenti. In effetti alcuni gruppi a causa del modello imposto non hanno effettuato una chiara distinzione tra ciascun documento. Una fase di lettura e d analisi di ciascun documento è quindi stata necessaria. La valutazione della qualità di ciascun documento si basa sui voti rilasciati dai docenti ai singoli gruppi. Nella stessa maniera abbiamo potuto valutare la qualità esterna del prodotto grazie alla valutazione dei professori, ai voti dati dagli studenti ai loro colleghi e in fine al numero di codice prodotto. Per quanto riguarda quest ultima misura, avremmo preferito utilizzare i function points di ciascun progetto, ma il loro calcolo per ognuno di questi progetti sarebbe stato un lavoro molto soggettivo. Il numero di linee di codice, più oggettivo, dà comunque buone informazioni per quanto riguarda l implementazione delle funzionalità, soprattutto mettendolo in confronto con i voti dati dai docenti per la fase d implementazione. La qualità interna è stata valutata in termini di linee di codice, di quantità di linee di commenti per riga di codice e di complessità ciclomatica. Quest ultima metrica è stata molto utile, e più volte siamo andati a verificare i risultati ottenuti dai singoli gruppi nel codice da loro prodotto. I metodi con complessità alta erano effettivamente quelli contenenti più cammini possibili e quindi più responsabilità, e comportavano un accoppiamento più alto con altri classi. Come si vedrà piu avanti, per la maggior parte dei risultati abbiamo calcolato la media dell insieme dei dati classificati per processo. Siccome vi sono esattamente 7 progetti per modello di processo, non abbiamo avuto bisogno di calcolare la media ponderata. Abbiamo inoltre calcolato ed esposto la deviazione standard, che ci ha permesso di realizzare un analisi successiva più accurata, tenendo quindi conto della stabilità dei risultati. 13

18 2.1.3 Ipotesi Le tabelle 2.1, 2.2, 2.3, 2.4 espongono un riassunto delle ipotesi precedentemente esposte nella letteratura scientifica. A ciascuna ipotesi corrisponde un insieme di misure che permette di verificarle. Tabella 2.1: Influenza dei processi sulla durata e lo sforzo Ipotesi Misure - Spirale richiede più sforzo e più tempo di Cascata - Media della differenza tra tempo impartito e tempo effettivo - XP è il più produttivo: richiede meno sforzo di - Media della stima dello sforzo richiesto Cascata Tabella 2.2: Influenza sulla produzione della documentazione: Ipotesi Misure - Cascata è il processo il più orientato alla - Media del numero di pagine di ciascuna produzione di documentazione documentazione rilasciata - XP è il processo meno orientato alla produzione di documentazione - Media dei voti ottenuti per ciascun tipo di documento rilasciato - L analisi dei requisiti iniziali è molto sviluppata per Cascata. Spiral e XP aggiungono documenti relativi ai requisiti durante tutto il ciclo di vita del software. - È più difficile per XP organizzare la documentazione(riunione in piedi, in modo informale..). La qualità complessiva di questa documentazione può essere compromessa Tabella 2.3: Influenza dei processi sulla qualità esterna del software Ipotesi Misure - Con Spiral e soprattutto con XP, il software - Media della valutazione finale del cliente(voto corrisponde ai bisogni del cliente(funzionalità piu studenti) avanzate, interfaccia grafica piu currata...) - Ci sono meno errori nei software XP che nei - Media della qualità esterna del software (voto software Spiral. docenti) -Spiral ha piu rischio di contenere errori di Cascata, perchè la fase d integrazione è più corta che in - Media della lunghezza del codice Cascata 14

19 Tabella 2.4: Influenza dei processi sulla qualità interna del software Ipotesi Misure - La qualità interna del software è migliore con - Media della qualità interna del codice attraverso XP grazie al refactoring, al Pair Programming la misura della complessità ciclomatica dei metodi,all integrazione ed ai test continui. - L aspetto sequenziale del processo in Cascata può - Media della lunghezza del codice essere la causa di gravi errori d implementazione. - La manutenzione è facilitata per XP, mentre per - Media del rapporto linee di commenti/linee di Spiral e Cascata comporta un costo alto codice 2.2 Esposizione dei risultati Durata e sforzo impiegato Il primo criterio valutato è stato quello della durata e dello sforzo impiegato per ciascun progetto. La tabella seguente riflette i risultati ottenuti: Tabella 2.5: Durata e sforzo: Risultati ottenuti Processi Media del ritardo(in Sforzo previsto (in Sforzo effettivo (in giorni) mp) mp) Cascata Spirale XP Durata Mentre, in media, i progetti che hanno seguito il modello XP hanno rispettato il tempo imposto dai docenti, i progetti che seguivano il modello a Cascata e a Spirale non hanno potuto consegnare in tempo. Il modello a Spirale è quello che in media ha richiesto più tempo anche se questo risultato viene limitato. In effetti, la deviazione standard per questo processo è la più elevata, il che significa che questo tipo di processo porta a risultati non omogenei: tra i gruppi che hanno seguito Spirale, uno ha potuto consegnare con ben 11 giorni di anticipo, mentre un altro con 40 giorni di ritardo. Sforzo Lo sforzo impiegato segue quest andamento. È stato però difficile misurarlo in maniera precisa, poiché i gruppi non hanno eseguito un conteggio preciso delle ore dedicate al lavoro. Abbiamo calcolato quindi una stima basata sull impegno che uno studente può ragionevolmente dedicare al progetto a partire dalle date di consegna. Si può notare che lo sforzo reale è molto meno importante dello sforzo inizialmente calcolato nel team. 15

20 Figura 2.2: Ritardo medio per processo della consegna del progetto Figura 2.3: Deviazione standart del ritardo della consegna per processo Figura 2.4: Sforzo previsto dai team (media per processo) in mesi-personna Figura 2.5: Sforzo effetivo (media per processo) in mesi-personna Documentazione prodotta Quantità di documentazione Il secondo criterio è stato quello di valutare la quantità di documentazione prodotta per ciascuno dei differenti processi. Le tabelle 2.6, 2.7, e le figure 2.6, 2.8, 2.9 illustrano i risultati ottenuti. 16

21 Tabella 2.6: Documentazione fornita in numero di pagine (media per processo) Processi Pian. An.Req. An.Req. Analisi Proget. Test Altro Totale iniziale finale Cascata Spirale XP Tabella 2.7: Ripartizione della documentazione di ciascun processo(in %) Processi Pian. An.Req. An.Req. Analisi Proget. Test Altro iniziale finale Cascata Spirale XP Figura 2.6: Numero totale di pagine di documentazione in media per ciascun processo Ciascun gruppo ha prodotto, nell insieme, la stessa quantità di documentazione. Ci sono però delle lievi differenze da rilevare, anche perché confermano ciò che è stato precedentemente supposto. Mentre il processo XP è stato il processo meno espansivo in termini di documentazione, Cascata è stato quello che ne ha prodotta di più. Mentre inizialmente i documenti di pianificazione ed analisi dei requisiti rilasciati sono stati più ampiamente descritti per il processo a Cascata, successivamente si è ottenuto un arricchimento progressivo della documentazione (con ad esempio user stories supplementari) che ha portato i gruppi di tipo XP a produrre più documentazione di quanta ne avevano prodotta i gruppi con modello Waterfall. Anche in Spirale la documentazione viene arricchita, ma soprattutto per ciò che riguarda la pianificazione e l analisi del rischio. L analisi iniziale del dominio è globalmente eseguita in maniera più dettagliata nel modello a Cascata, mentre per la progettazione i tre processi hanno realizzato in media un sforzo equivalente. Questo si può spiegare sia, ancora una volta, grazie agli incrementi fatti nei vari cicli, sia con l approccio diverso dei tre processi. Mentre Cascata è orientato verso la documentazione(e quindi ogni fase, e più particolarmente quelle che sono a monte del ciclo di vita del software, devono essere documentate con lo stesso grado di precisione), Spirale e soprattutto XP mirano all obiettivo finale della realizzazione del software. In effetti, siccome in Spirale e in XP si deve sviluppare 17

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

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

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

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

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

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

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

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

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

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

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

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

2. Ciclo di Vita e Processi di Sviluppo

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

Dettagli

La nuova ISO 9001 e le aziende di sviluppo software

La nuova ISO 9001 e le aziende di sviluppo software La nuova ISO 9001 e le aziende di sviluppo software Giovanni A. Cignoni, Dip. di Informatica, Univ. di Pisa Davide Morano, SIAS - Gruppo KataWeb Ottobre 2000 Sommario L impostazione della nuova ISO 9001,

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

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

SCD IS. Processi software. Processi Software. UniPD - 2009 - Ingegneria del Software mod. A 1. Definizioni. Modelli di ciclo di vita

SCD IS. Processi software. Processi Software. UniPD - 2009 - Ingegneria del Software mod. A 1. Definizioni. Modelli di ciclo di vita Processi software Anno accademico 2009/10 Ingegneria del mod. A Tullio Vardanega, tullio.vardanega@math.unipd.it SCD IS Definizioni Ciclo di vita Copre l evoluzione di un prodotto dal concepimento al ritiro

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

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

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

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

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

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

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

Ciclo di vita del software

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

Dettagli

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

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

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

Dettagli

11. Evoluzione del Software

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

Dettagli

extreme Programming in un curriculum universitario

extreme Programming in un curriculum universitario extreme Programming in un curriculum universitario Lars Bendix Department of Computer Science Lund Institute of Technology Sweden Università di Bologna, 18 giugno, 2002 Extreme Programming On-site customer

Dettagli

PIANIFICAZIONE DI PROGETTO DI SISTEMI INFORMATIVI

PIANIFICAZIONE DI PROGETTO DI SISTEMI INFORMATIVI PIANIFICAZIONE DI PROGETTO DI SISTEMI INFORMATIVI OBIETTIVI 1. Descrivere approcci e attività tipiche per pianificare e impostare il progetto di un S.I. 2. Identificare problemi chiave 3. Illustrare alcuni

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

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

Introduzione all Agile Software Development

Introduzione all Agile Software Development IBM Rational Software Development Conference 5RPDRWWREUH 0LODQR RWWREUH Introduzione all Agile Software Development 0DULDQJHOD2UPH Solution Architect IBM Rational Services PRUPH#LWLEPFRP 2008 IBM Corporation

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

Sistemi Informativi I Lezioni di Ingegneria del Software

Sistemi Informativi I Lezioni di Ingegneria del Software 1 Introduzione all Ingegneria del Software. In questa prima parte viene definita l Ingegneria del Software o Software Engineering (SWE), vengono presentate le caratteristiche del ciclo di vita di un prodotto

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

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

12. Evoluzione del Software

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

Dettagli

Lezione 1 Ingegneria del Software II- Introduzione e Motivazione. Ingegneria del Software 2 Introduzione e Richiami 1

Lezione 1 Ingegneria del Software II- Introduzione e Motivazione. Ingegneria del Software 2 Introduzione e Richiami 1 Lezione 1 Ingegneria del Software II- Introduzione e Motivazione Ingegneria del Software 2 Introduzione e Richiami 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.1 R.

Dettagli

SCHEDA TUTORIALE TEMA: PRENDERE APPUNTI IN CLASSE

SCHEDA TUTORIALE TEMA: PRENDERE APPUNTI IN CLASSE SCHEDA TUTORIALE TEMA: PRENDERE APPUNTI IN CLASSE GIUSTIFICAZIONE: Una maniera pratica ed efficace di mantenere l'attenzione in classe mentre il professore spiega è il prendere appunti. Prendere appunti

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

LINEA PROJECT MANAGEMENT

LINEA PROJECT MANAGEMENT LINEA PROJECT MANAGEMENT ITIL FOUNDATION V3 46.10.3 3 giorni Il corso, nell ambito della Gestione dei Servizi IT, mira a: 1. Comprendere Struttura e Processi di ITIL V3 - Information Technology Infrastructure

Dettagli

Gestione del gruppo di lavoro: motivazione e coaching

Gestione del gruppo di lavoro: motivazione e coaching Gestione del gruppo di lavoro: motivazione e coaching Il team Un gruppo di persone che: condividono uno scopo, hanno un obiettivo in comune collaborano, moltiplicando le loro risorse condividono i vantaggi

Dettagli

SCORE-it 2015 Italian Student COntest in software Engineering 37th International Conference on software Engineering (ICSE)

SCORE-it 2015 Italian Student COntest in software Engineering 37th International Conference on software Engineering (ICSE) SCORE-it 2015 Italian Student COntest in software Engineering 37th International Conference on software Engineering (ICSE) L Italian Student Contest in Software Engineering (SCORE-it - http://score-contest.it)

Dettagli

Extreme programming e metodologie agili

Extreme programming e metodologie agili Extreme programming e metodologie agili Università degli Studi di Brescia, 8 Giugno 2007 Ing. Daniele Armanasco daniele@armanasco.it Ing. Emanuele DelBono emanuele@codiceplastico.com Enti organizzatori

Dettagli

GESTIONE DEI PROGETTI. Inizio

GESTIONE DEI PROGETTI. Inizio GESTIONE DEI PROGETTI Problema del management Fallimento negli anni 60, inizio 70 Non tanto dovuto alla competenza Un buon management non garantisce il successo ma un cattivo management risulta spesso

Dettagli

DOMENICO CLERICI LUIGI PETRUZZELLI

DOMENICO CLERICI LUIGI PETRUZZELLI DOMENICO CLERICI LUIGI PETRUZZELLI 2006-10-31 TICLE Srl - www.ticle.it Pag. 1/9 Dalla IV di copertina... Knowledge Based Project Management - Presentazione Questo libro nasce da un esperienza ventennale

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

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

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

ROB THOMSETT EXTREME PROJECT MANAGEMENT WORKSHOP ROMA 7-9 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

ROB THOMSETT EXTREME PROJECT MANAGEMENT WORKSHOP ROMA 7-9 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA ROB THOMSETT EXTREME PROJECT MANAGEMENT WORKSHOP ROMA 7-9 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it EXTREME

Dettagli

Innovazione di processo e di prodotto in un azienda del settore domotica

Innovazione di processo e di prodotto in un azienda del settore domotica Innovazione di processo e di prodotto in un azienda del settore domotica Marco Catuozzo (Responsabile R&D, sede di Erba) Mauro Sarchi (Project Leader applicazioni multimediali embedded, sede di Erba) Bticino

Dettagli

introduzione al corso di ingegneria del software

introduzione al corso di ingegneria del software introduzione al corso di ingegneria del software a.a. 2003-2004 contatti con i docenti Maurizio Pizzonia pizzonia@dia.uniroma3.it orario ricevimento: mercoledì 17:30 (presentarsi entro le 18:00) Valter

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

Approcci agili per affrontare la sfida della complessità

Approcci agili per affrontare la sfida della complessità Approcci agili per affrontare la sfida della complessità Firenze, 6 marzo 2013 Consiglio Regionale della Toscana Evento organizzato dal Branch Toscana-Umbria del PMI NIC Walter Ginevri, PMP, PgMP, PMI-ACP

Dettagli

3. SOFTWARE MANAGEMENT

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

Dettagli

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP.

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. INTERVISTA 13 settembre 2012 ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. Intervista ad Ermanno Pappalardo, Lead Solution Consultant HP Software

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

LA TECHNOLOGY TRANSFER PRESENTA LARISSA. al Data Warehousing e alla Business Intelligence

LA TECHNOLOGY TRANSFER PRESENTA LARISSA. al Data Warehousing e alla Business Intelligence LA TECHNOLOGY TRANSFER PRESENTA LARISSA MOSS EXTREME SCOPING TM Approcci Agili al Data Warehousing e alla Business Intelligence ROMA 26-27 APRILE 2010 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Presupposti per una sana gestione di progetti

Presupposti per una sana gestione di progetti Presupposti per una sana gestione di progetti Conferenza Hermes Manno, 16 novembre 2006 Sonia Boutari, PMP Indice 1 2 I progetti: più successi o più fallimenti? Management di progetto: il COSA (WHAT) 3

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

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

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

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

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

4th International Conference in Software Engineering for Defence Applications SEDA 2015

4th International Conference in Software Engineering for Defence Applications SEDA 2015 me Ho CALL FOR PAPERS: 4th International Conference in Software Engineering for Defence Applications SEDA 2015 Software Engineering aims at modeling, managing and implementing software development products

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

Metodologia Classica di Progettazione delle Basi di Dati

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

Dettagli

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

LARISSA MOSS. Agile Project Management per progetti di Business Intelligence e Data Warehouse

LARISSA MOSS. Agile Project Management per progetti di Business Intelligence e Data Warehouse LA TECHNOLOGY TRANSFER PRESENTA LARISSA MOSS Agile Project Management per progetti di Business Intelligence e Data Warehouse ROMA 15-16 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

SIMCO E LA SIMULAZIONE

SIMCO E LA SIMULAZIONE SIMCO E LA SIMULAZIONE: Chi non vorrebbe avere la possibilità di sperimentare il differente comportamento di tutte le alternative di progetto prima di averle realizzate, per identificare la combinazione

Dettagli

COMPETENZE DI BASE ICF Aggiornamento 2009

COMPETENZE DI BASE ICF Aggiornamento 2009 COMPETENZE DI BASE ICF Aggiornamento 2009 Le 11 competenze di base del coaching sono state sviluppate per permettere una migliore comprensione delle competenze e degli approcci utilizzati nell ambito della

Dettagli

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

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

Dettagli

QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO

QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO Report globale e suggerimenti Gennaio 2013 Autore: Filigree Consulting Promosso da: SMART Technologies Executive

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

GESTIONE DEI PROGETTI

GESTIONE DEI PROGETTI GESTIONE DEI PROGETTI Problema del management Fallimento negli anni 60, inizio 70 Non tanto dovuto alla competenza Un buon management non garantisce il successo ma un cattivo management risulta spesso

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA CAPERS JONES SOFTWARE EXCELLENCE DAL WATERFALL AD AGILE E OLTRE

LA TECHNOLOGY TRANSFER PRESENTA CAPERS JONES SOFTWARE EXCELLENCE DAL WATERFALL AD AGILE E OLTRE LA TECHNOLOGY TRANSFER PRESENTA CAPERS JONES SOFTWARE EXCELLENCE NEL 2014 DAL WATERFALL AD AGILE E OLTRE ROMA 5-6 GIUGNO 2014 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

Gestione parte IIC. Diagrammi di Gantt. Esempio. Schemi di scomposizione delle attività

Gestione parte IIC. Diagrammi di Gantt. Esempio. Schemi di scomposizione delle attività Schemi di scomposizione delle attività Gestione parte IIC Work Breakdown Structures (WBS) Struttura ad albero: radice: attività principale i nodi figli rappresentano la scomposizione del nodo padre le

Dettagli

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità Qualità del software Tecniche di Programmazione Lez. 05 Università di Firenze a.a. 2009/10, I semestre 1/33 contenuti Qualità? Definizioni Il prodotto software Modelli della qualità per il sw: ISO/IEC

Dettagli

Il processo di sviluppo

Il processo di sviluppo Il processo di sviluppo Processo di sviluppo software = framework all'interno del quale si svolgono le attività necessarie per produrre software di alta qualità. E' il modo in cui viene organizzato e praticato

Dettagli

Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup

Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup Giuseppe Chiazzese CNR - Istituto per le tecnologie didattiche Modulo: Introduzione agli strumenti web per

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

Ingegneria del Software I Prova parziale del 27/4/2015 - ESERCIZI

Ingegneria del Software I Prova parziale del 27/4/2015 - ESERCIZI Cognome Nome Matricola Ingegneria del Software I Prova parziale del 27/4/2015 - ESERCIZI Durata: 1h 15' Esercizio 1 (6 pt.). Si supponga di dover implementare un sistema di lettura ed elaborazione automatica

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

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

Strategie didattiche per gli studenti dislessici in tutti i gradi di scuola tratto dal sito AID -Sezione di Roma

Strategie didattiche per gli studenti dislessici in tutti i gradi di scuola tratto dal sito AID -Sezione di Roma Strategie didattiche per gli studenti dislessici in tutti i gradi di scuola tratto dal sito AID -Sezione di Roma (testo tradotto da Accommodating students with dyslexia in all classroom settings International

Dettagli

Fase 3: Mettere a fuoco il disegno della Valutazione

Fase 3: Mettere a fuoco il disegno della Valutazione Fase 3: Mettere a fuoco il disegno della Valutazione Per usare il tempo e le risorse nel modo più efficiente possibile, la valutazione deve essere concentrata sui problemi di grande interesse per i committenti

Dettagli

RANDY RICE ROMA 15-17 GIUGNO 2009 ROMA 18-19 GIUGNO 2009 ARESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

RANDY RICE ROMA 15-17 GIUGNO 2009 ROMA 18-19 GIUGNO 2009 ARESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA RANDY RICE STRUCTURED USER ACCEPTANCE TESTING APPROCCI INNOVATIVI AL SOFTWARE TESTING ROMA 15-17 GIUGNO 2009 ROMA 18-19 GIUGNO 2009 ARESIDENZA DI RIPETTA - VIA DI RIPETTA,

Dettagli

Processi per lo sviluppo rapido del software

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

Dettagli

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

Revisioni sistematiche Metanalisi Linee guida Health Technology Assessment report

Revisioni sistematiche Metanalisi Linee guida Health Technology Assessment report LE PUBBLICAZIONI SECONDARIE Sono così definite perché i ricercatori prendono i dati da studi già pubblicati (o anche non pubblicati), ne riassumono ed analizzano i risultati combinati, traggono conclusioni

Dettagli

Prepararsi al Cambiamento Passaggio alla ISO 9001:2015

Prepararsi al Cambiamento Passaggio alla ISO 9001:2015 Prepararsi al Cambiamento Passaggio alla ISO 9001:2015 Come è ormai noto a quanti operano nel campo della qualità, è stata pubblicata la nuova revisione della ISO 9001. Le Norme ISO toccano numerosi ambiti

Dettagli

Sviluppo di applicazioni internet:

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

Dettagli

Bach Centre: criteri per il riconoscimento per i Corsi di Livello 2

Bach Centre: criteri per il riconoscimento per i Corsi di Livello 2 Bach Centre: criteri per il riconoscimento per i Corsi di Livello 2 Introduzione Questo documento stabilisce gli standard minimi ai quali i Corsi di Livello 2 approvati dal Bach Centre devono uniformarsi.

Dettagli

Classificazione Nuovo Esame PMP

Classificazione Nuovo Esame PMP Notizie sul nuovo esame PMP a partire dal Agosto 0 Classificazione Nuovo Esame PMP Questo è il link al documento del PMI: Crosswalk Between Current and New PMP Classifications del PMI Di seguito trovi

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA. a Software Improvement. Better, Faster, Cheaper ROMA 21-22 GIUGNO 2010 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

LA TECHNOLOGY TRANSFER PRESENTA. a Software Improvement. Better, Faster, Cheaper ROMA 21-22 GIUGNO 2010 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA GARY GACK MANAGING HIGH RISK PROJECTS a Software Improvement Workshop Better, Faster, Cheaper ROMA 21-22 GIUGNO 2010 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 info@technologytransfer.it

Dettagli

CURRICOLO MATEMATICA OBIETTIVI E COMPETENZE

CURRICOLO MATEMATICA OBIETTIVI E COMPETENZE CURRICOLO MATEMATICA OBIETTIVI E COMPETENZE CLASSE OBIETTIVI COMPETENZE PRIMA Conoscere ed operare con i numeri Contare oggetti o eventi, con la voce e mentalmente, in senso progressivo e regressivo. Leggere

Dettagli

Interfaccia Utente. Prototipi. Sviluppo SW - Usabilità. Sviluppo SW a cascata. Il ciclo di vita a stella (Hix & Hartson)

Interfaccia Utente. Prototipi. Sviluppo SW - Usabilità. Sviluppo SW a cascata. Il ciclo di vita a stella (Hix & Hartson) Interfaccia Utente An interface is a bridge between the world of the product or system and the world of the user. It is the means by which the users interact with the product to achieve their goals. It

Dettagli