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

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

13. Ciclo di Vita e Processi di Sviluppo

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

Dettagli

Metodologie 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

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

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

2. Ciclo di Vita e Processi di Sviluppo

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

Dettagli

Ingegneria del Software 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

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

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

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

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

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

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

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

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

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

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

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

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

DEFINIZIONE DEL CONCEPT DI PRODOTTO

DEFINIZIONE DEL CONCEPT DI PRODOTTO DEFINIZIONE DEL CONCEPT DI PRODOTTO 92 Generazione dei concetti di prodotto Individuazione dei bisogni dei clienti Eseguire l analisi economica Analizzare i prodotti della concorrenza Costruire e collaudare

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

Processo di referaggio collana punto org

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

Dettagli

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

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

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

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

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

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

Misure della dispersione o della variabilità

Misure della dispersione o della variabilità QUARTA UNITA Misure della dispersione o della variabilità Abbiamo visto che un punteggio di per sé non ha alcun significato e lo acquista solo quando è posto a confronto con altri punteggi o con una statistica.

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

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

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

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache... Appunti di Calcolatori Elettronici Concetti generali sulla memoria cache Introduzione... 1 Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

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

Qualificare i fornitori attraverso un sistema analitico di rating

Qualificare i fornitori attraverso un sistema analitico di rating articolo n. 3 giugno 2014 Qualificare i fornitori attraverso un sistema analitico di rating MASSIMILIANO MARI Responsabile Acquisti, SCANDOLARA s.p.a. Realizzare un sistema di rating costituisce un attività

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

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

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

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

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

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

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

I questionari del Protocollo eglu per valutare i servizi web

I questionari del Protocollo eglu per valutare i servizi web Progetto PerformancePA Ambito A - Linea 1 - Una rete per la riforma della PA I questionari del Protocollo eglu per valutare i servizi web Autore: Maurizio Boscarol Creatore: Formez PA, Progetto Performance

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

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

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

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

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

Dettagli

Nota informativa ISO/IEC 27001 Il processo di valutazione

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

Dettagli

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

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

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

Dettagli

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

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA. Service Oriented Architecture SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA Service Oriented Architecture Ormai tutti, nel mondo dell IT, conoscono i principi di SOA e i benefici che si possono ottenere

Dettagli

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

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

Modelli matematici avanzati per l azienda a.a. 2010-2011

Modelli matematici avanzati per l azienda a.a. 2010-2011 Modelli matematici avanzati per l azienda a.a. 2010-2011 Docente: Pasquale L. De Angelis deangelis@uniparthenope.it tel. 081 5474557 http://www.economia.uniparthenope.it/siti_docenti P.L.DeAngelis Modelli

Dettagli

ARIES. Architettura per l implementazione rapida dei sistemi aziendali

ARIES. Architettura per l implementazione rapida dei sistemi aziendali ARIES Architettura per l implementazione rapida dei sistemi aziendali P r e s e n ta z i o n e d e l l a m e t o d o l o g i a a r i e s ARIES è una metodologia che consente di implementare rapidamente

Dettagli

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO QUESTIONARIO SUGLI STILI DI APPRENDIMENTO Le seguenti affermazioni descrivono alcune abitudini di studio e modi di imparare. Decidi in quale misura ogni affermazione si applica nel tuo caso: metti una

Dettagli

Lo Studio di Fattibilità

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

Dettagli

2. e i risultati che si vogliono conseguire

2. e i risultati che si vogliono conseguire L obiettivo di questo intervento consiste nel mostrare come trarre la massima efficienza nelle operazioni multi-canale di vendita e sincronizzazione online. Per efficienza si intende la migliore coniugazione

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

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

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

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

IMPARARE AD IMPARARE DISCIPLINE DI RIFERIMENTO: TUTTE

IMPARARE AD IMPARARE DISCIPLINE DI RIFERIMENTO: TUTTE IMPARARE AD IMPARARE DISCIPLINE DI RIFERIMENTO: TUTTE IMPARARE AD IMPARARE Imparare a imparare è l abilità di perseverare nell, di organizzare il proprio anche mediante una gestione efficace del tempo

Dettagli

IL PERFORMANCE MANAGEMENT

IL PERFORMANCE MANAGEMENT IT PROFESSIONAL SERVICES UNA SOLUZIONE PER IL PERFORMANCE MANAGEMENT for Enterprise Gestire il portfolio applicativo monitorando qualità, produttività e costi dello sviluppo applicativo Overview ARGOMENTI:

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Tecnologie per il Web e lo Sviluppo Multimediale L Analisi Preliminare

Tecnologie per il Web e lo Sviluppo Multimediale L Analisi Preliminare Tecnologie per il Web e lo Sviluppo Multimediale L Analisi Preliminare Luca Pulina Corso di Laurea in Scienze della Comunicazione Università degli Studi di Sassari A.A. 2015/2016 Luca Pulina (UNISS) Progettazione

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

Tecniche strategie e metodologie del processo di insegnamento-apprendimento. a cura della Dott.ssa Donata Monetti

Tecniche strategie e metodologie del processo di insegnamento-apprendimento. a cura della Dott.ssa Donata Monetti Tecniche strategie e metodologie del processo di insegnamento-apprendimento a cura della Dott.ssa Donata Monetti Gli elementi di base della dinamica insegnamento - apprendimento LA PROGRAMMAZIONE DEGLI

Dettagli

MATEMATICA TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE COMUNI A TUTTI GLI INDICATORI

MATEMATICA TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE COMUNI A TUTTI GLI INDICATORI INFANZIA I bambini esplorano continuamente la realtà e imparano a riflettere sulle proprie esperienze descrivendole, rappresentandole, riorganizzandole con diversi criteri. Pongono così le basi per la

Dettagli

WORD 97 SCRIVERE UNA TESI DI LAUREA

WORD 97 SCRIVERE UNA TESI DI LAUREA WORD 97 SCRIVERE UNA TESI DI LAUREA PASSO 1 Per prima cosa pensiamo al formato generale della pagina: i margini richiesti da una tesi sono quasi sempre più ampi di quelli di un testo normale. Apriamo ora

Dettagli

Crescita della produttività e delle economie

Crescita della produttività e delle economie Lezione 21 1 Crescita della produttività e delle economie Il più spettacolare effetto della sviluppo economico è stata la crescita della produttività, ossia la quantità di prodotto per unità di lavoro.

Dettagli

Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi.

Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi. PROGETTO SeT Il ciclo dell informazione Alla ricerca dell algoritmo. Scoprire e formalizzare algoritmi. Scuola media Istituto comprensivo di Fagagna (Udine) Insegnanti referenti: Guerra Annalja, Gianquinto

Dettagli

FINESTRE INTERCULTURALI

FINESTRE INTERCULTURALI Scuola Classe 1C FINESTRE INTERCULTURALI DIARIO DI BORDO 2013 / 2014 IC Gandhi - Secondaria di primo grado Paolo Uccello Insegnante / materia Anelia Cassai/lettere Data Febbraio Durata 4h TITOLO DELLA

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

CAPITOLO 4 LA CREAZIONE DI TABELLE D ATTIVITÀ E SCHEDE DI SPESA

CAPITOLO 4 LA CREAZIONE DI TABELLE D ATTIVITÀ E SCHEDE DI SPESA CAPITOO 4 A CREAZIONE DI TABEE D ATTIVITÀ E SCHEDE DI SPESA 55 A CREAZIONE DI TABEE D ATTIVITÀ E SCHEDE DI SPESA 57 Questo capitolo descrive l uso del Q per sviluppare budget e piani di lavoro basati sul

Dettagli

Materiale elaborato, su incarico del Bologna Follow Up Group, dall apposito Bologna Working Group on Qualifications Frameworks

Materiale elaborato, su incarico del Bologna Follow Up Group, dall apposito Bologna Working Group on Qualifications Frameworks Estratto dal documento A Framework for Qualifications of the European Higher Education Area (Il Quadro dei Titoli dello Spazio Europeo dell Istruzione Superiore), disponibile sul sito www.processodibologna.it/documentieuropei

Dettagli

Istituto Comprensivo Scuola dell Infanzia, Primaria e Secondaria di I Grado 86048 Sant Elia a Pianisi (CB)

Istituto Comprensivo Scuola dell Infanzia, Primaria e Secondaria di I Grado 86048 Sant Elia a Pianisi (CB) Prot. N.3548 a/19 Atti Albo Pretorio Sito web PER I DOCENTI SCUOLA PRIMARIA (SECONDO BIENNIO) E SECONDARIA DI PRIMO GRADO Estratto da articolo di Cornoldi e al., 2010: Il primo strumento compensativo per

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

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

Studio dei casi Scuole medie superiori

Studio dei casi Scuole medie superiori Valutazione dei progetti: Valutazione formativa Studio dei casi Scuole medie superiori Allegorie in una classe di quinto superiore Gli studenti del quinto superiore nella classe della professoressa Marta

Dettagli

La Leadership efficace

La Leadership efficace La Leadership efficace 1 La Leadership: definizione e principi 3 2 Le pre-condizioni della Leadership 3 3 Le qualità del Leader 4 3.1 Comunicazione... 4 3.1.1 Visione... 4 3.1.2 Relazione... 4 pagina 2

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

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

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

Dettagli

ANALISI DELLE FREQUENZE: IL TEST CHI 2

ANALISI DELLE FREQUENZE: IL TEST CHI 2 ANALISI DELLE FREQUENZE: IL TEST CHI 2 Quando si hanno scale nominali o ordinali, non è possibile calcolare il t, poiché non abbiamo medie, ma solo frequenze. In questi casi, per verificare se un evento

Dettagli

GUIDA VELOCE PER TRAINER

GUIDA VELOCE PER TRAINER GUIDA VELOCE ~ 6 ~ GUIDA VELOCE PER TRAINER Perché usare il toolkit di EMPLOY? In quanto membro del personale docente, consulente di carriera, addetto al servizio per l impiego o chiunque interessato ad

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

La comunicazione per il successo nella vita e nel lavoro. Corso a cura di Agape Consulting

La comunicazione per il successo nella vita e nel lavoro. Corso a cura di Agape Consulting La comunicazione per il successo nella vita e nel lavoro Corso a cura di Agape Consulting La comunicazione per il successo nella vita e nel lavoro La capacità di comunicare e di negoziare è il principale

Dettagli

Titolo dell'attività (max 255 caratteri, spazi compresi) Sintesi dell'attività (max 1000 caratteri, spazi compresi)

Titolo dell'attività (max 255 caratteri, spazi compresi) Sintesi dell'attività (max 1000 caratteri, spazi compresi) RIFLESSIONE SULLA PROGETTAZIONE Titolo dell'attività (max 255 caratteri, spazi compresi) Fare Scienze con un approccio innovativo: l Apparato Circolatorio. Sintesi dell'attività (max 1000 caratteri, spazi

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

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

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

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

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

Dettagli

Capitolo 13: L offerta dell impresa e il surplus del produttore

Capitolo 13: L offerta dell impresa e il surplus del produttore Capitolo 13: L offerta dell impresa e il surplus del produttore 13.1: Introduzione L analisi dei due capitoli precedenti ha fornito tutti i concetti necessari per affrontare l argomento di questo capitolo:

Dettagli

MEDIATECA PROVINCIALE DI MATERA. La mediateca incontra le scuole Matera, 21 febbraio 2006 LINGUAGGI E CREATIVITA :

MEDIATECA PROVINCIALE DI MATERA. La mediateca incontra le scuole Matera, 21 febbraio 2006 LINGUAGGI E CREATIVITA : MEDIATECA PROVINCIALE DI MATERA La mediateca incontra le scuole Matera, 21 febbraio 2006 LINGUAGGI E CREATIVITA : Il giornalino on line Il vero viaggio di ricerca non consiste nel cercare nuove terre,

Dettagli