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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Il consulente aziendale di Richard Newton, FrancoAngeli 2012

Il consulente aziendale di Richard Newton, FrancoAngeli 2012 Introduzione Chiedete a qualunque professionista di darvi una definizione dell espressione consulente aziendale, e vedrete che otterrete molte risposte diverse, non tutte lusinghiere! Con tale espressione,

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

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

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

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

COMUNE DI RICCIONE Provincia di Rimini

COMUNE DI RICCIONE Provincia di Rimini COMUNE DI RICCIONE Provincia di Rimini Sistema di valutazione della performance individuale del personale dipendente Allegato 2 1 di 9 Oggetto della valutazione Il sistema di valutazione della performance

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

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

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

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 Controllo di gestione nella piccola impresa

Il Controllo di gestione nella piccola impresa Stampa Il Controllo di gestione nella piccola impresa admin in A cura di http://www.soluzionipercrescere.com La piccola impresa presenta generalmente un organizzazione molto snella dove l imprenditore

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

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

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

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

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

Six Sigma Handbook Gli strumenti sei sigma per raggiungere obiettivi, organizzativi e di qualità, ad alto impatto economico con l ausilio di Excel

Six Sigma Handbook Gli strumenti sei sigma per raggiungere obiettivi, organizzativi e di qualità, ad alto impatto economico con l ausilio di Excel Six Sigma Handbook Gli strumenti sei sigma per raggiungere obiettivi, organizzativi e di qualità, ad alto impatto economico con l ausilio di Excel di Rinaldo Tartari Consulente Qualità e Affidabilità Excel

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

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

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

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

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

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

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

In caso di catastrofe AiTecc è con voi!

In caso di catastrofe AiTecc è con voi! In caso di catastrofe AiTecc è con voi! In questo documento teniamo a mettere in evidenza i fattori di maggior importanza per una prevenzione ottimale. 1. Prevenzione Prevenire una situazione catastrofica

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

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

Codici Numerici. Modifica dell'informazione. Rappresentazione dei numeri.

Codici Numerici. Modifica dell'informazione. Rappresentazione dei numeri. Codici Numerici. Modifica dell'informazione. Rappresentazione dei numeri. A partire da questa lezione, ci occuperemo di come si riescono a codificare con sequenze binarie, quindi con sequenze di 0 e 1,

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

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

RACCORDO TRA LE COMPETENZE CONFRONTO E RACCORDO TRA IL PROFILO DI FINE QUINTA INIZIO PRIMA MEDIA FINE PRIMA

RACCORDO TRA LE COMPETENZE CONFRONTO E RACCORDO TRA IL PROFILO DI FINE QUINTA INIZIO PRIMA MEDIA FINE PRIMA RACCORDO TRA LE COMPETENZE Poiché l'informatica nella scuola media è trasversale si punterà maggiore attenzione sulla tecnologia. Competenze primaria Competenza secondaria di primo grado 1. UTILIZZA OGGETTI

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

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

Mining Positive and Negative Association Rules:

Mining Positive and Negative Association Rules: Mining Positive and Negative Association Rules: An Approach for Confined Rules Alessandro Boca Alessandro Cislaghi Premesse Le regole di associazione positive considerano solo gli item coinvolti in una

Dettagli

ESERCITAZIONI per il corso di ECONOMIA DELL ARTE E DELLA CULTURA 1 1 MODULO (prof. Bianchi) a.a. 2007-2008

ESERCITAZIONI per il corso di ECONOMIA DELL ARTE E DELLA CULTURA 1 1 MODULO (prof. Bianchi) a.a. 2007-2008 ESERCITAZIONI per il corso di ECONOMIA DELL ARTE E DELLA CULTURA 1 1 MODULO (prof. Bianchi) a.a. 2007-2008 A. Il modello macroeconomico in economia chiusa e senza settore pubblico. A.1. Un sistema economico

Dettagli

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi Project Management Modulo: Introduzione prof. ing. Guido Guizzi Definizione di Project Management Processo unico consistente in un insieme di attività coordinate con scadenze iniziali e finali, intraprese

Dettagli

Caso Pratico Stili di Direzione

Caso Pratico Stili di Direzione In questo caso, vi proponiamo di analizzare anche 4 situazioni relative alla presa di decisioni. Questa documentazione, come sapete già, è centrata su modelli di stili di direzione e leadership, a seconda

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

SPC e distribuzione normale con Access

SPC e distribuzione normale con Access SPC e distribuzione normale con Access In questo articolo esamineremo una applicazione Access per il calcolo e la rappresentazione grafica della distribuzione normale, collegata con tabelle di Clienti,

Dettagli

TNT IV. Il Diavolo è meno brutto di come ce lo dipingono!!! (Guarda il video)

TNT IV. Il Diavolo è meno brutto di come ce lo dipingono!!! (Guarda il video) TNT IV Il Diavolo è meno brutto di come ce lo dipingono!!! (Guarda il video) Al fine di aiutare la comprensione delle principali tecniche di Joe, soprattutto quelle spiegate nelle appendici del libro che

Dettagli

Premesse alla statistica

Premesse alla statistica Premesse alla statistica Versione 22.10.08 Premesse alla statistica 1 Insiemi e successioni I dati di origine sperimentale si presentano spesso non come singoli valori, ma come insiemi di valori. Richiamiamo

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

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

Artability. Tlab - 2 interim report

Artability. Tlab - 2 interim report Artability Tlab - 2 interim report Introduzione Il progetto Artability è un progetto biennale che promuove lo scambio di buone pratiche per motivare le persone con disabilità a partecipare al processo

Dettagli

Il modello veneto di Bilancio Sociale Avis

Il modello veneto di Bilancio Sociale Avis Il modello veneto di Bilancio Sociale Avis Le organizzazioni di volontariato ritengono essenziale la legalità e la trasparenza in tutta la loro attività e particolarmente nella raccolta e nell uso corretto

Dettagli

"L impatto dell Information Technology sulle aziende del terziario in Italia"

L impatto dell Information Technology sulle aziende del terziario in Italia "L impatto dell Information Technology sulle aziende del terziario in Italia" Sintesi per la stampa Ricerca promossa da Microsoft e Confcommercio realizzata da NetConsulting Roma, 18 Marzo 2003 Aziende

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

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

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

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

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

Capitolo V. I mercati dei beni e i mercati finanziari: il modello IS-LM

Capitolo V. I mercati dei beni e i mercati finanziari: il modello IS-LM Capitolo V. I mercati dei beni e i mercati finanziari: il modello IS-LM 2 OBIETTIVO: Il modello IS-LM Fornire uno schema concettuale per analizzare la determinazione congiunta della produzione e del tasso

Dettagli

WebRatio. Per il settore Energy e Utilities. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 7

WebRatio. Per il settore Energy e Utilities. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 7 WebRatio Per il settore Energy e Utilities Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 7 Il divario tra Business e IT nel settore Energy e Utilities Il settore Energy e Utilities è in grande

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

PROGRAMMAZIONE EDUCATIVA E DIDATTICA

PROGRAMMAZIONE EDUCATIVA E DIDATTICA Ministero dell Istruzione, dell Università e della Ricerca Istituto Comprensivo Statale D. Alighieri Scuola dell'infanzia/primaria/secondaria di primo grado Via per Duno, 10-21030 CUVEGLIO (VA) tel. 0332.650200/650152

Dettagli

Principio 1 Organizzazione orientata al cliente. Principio 2 Leadership. Principio 3 - Coinvolgimento del personale

Principio 1 Organizzazione orientata al cliente. Principio 2 Leadership. Principio 3 - Coinvolgimento del personale Gli otto princìpi di gestione per la qualità possono fornire ai vertici aziendali una guida per migliorare le prestazioni della propria organizzazione. Questi princìpi, che nascono da esperienze collettive

Dettagli

Istituto San Tomaso d Aquino

Istituto San Tomaso d Aquino Istituto San Tomaso d Aquino alba pratalia aràba Linee di progetto per l utilizzo delle tecnologie nella didattica a.s. 2013 2014 a.s. 2014 2015 0 Linee di progetto per l utilizzo delle tecnologie nella

Dettagli

Prot.n.8095/C12 Tarcento, 17 ottobre 2014

Prot.n.8095/C12 Tarcento, 17 ottobre 2014 Ministero dell Istruzione, dell Università e della Ricerca ISTITUTO COMPRENSIVO DI TARCENTO Viale G. Matteotti, 56 33017 Tarcento (UD) Cod. fisc. 94071050309 - Tel. 0432/785254 Fax 0432/794056 segreteria@ictarcento.com

Dettagli

Costi della Qualità. La Qualità costa! Ma quanto costa la non Qualità? La Qualità fa risparmiare denaro. La non Qualità fa perdere denaro.

Costi della Qualità. La Qualità costa! Ma quanto costa la non Qualità? La Qualità fa risparmiare denaro. La non Qualità fa perdere denaro. Costi della Qualità La Qualità costa! Ma quanto costa la non Qualità? La Qualità fa risparmiare denaro. La non Qualità fa perdere denaro. Per anni le aziende, in particolare quelle di produzione, hanno

Dettagli

3 DECALOGO DELLA QUALITÀ

3 DECALOGO DELLA QUALITÀ GENERALITÀ 1 / 10 Sommario Generalità 1 Politica della Qualità 3 DECALOGO DELLA QUALITÀ 4 Politica Ambientale PREVENZIONE 7 FORMAZIONE CULTURA ED ATTEGGIAMENTO 8 COMUNICAZIONE 8 COLLABORAZIONE CON FORNITORI

Dettagli

TECNICHE DI VALUTAZIONE DEL RISCHIO

TECNICHE DI VALUTAZIONE DEL RISCHIO Per conto di AICQ CN 1 - Autore Giovanni Mattana - Consigliere di Giunta AICQ CN Presidente della Commissione UNI per i Sistemi di Qualità La norma è intesa come un supporto per la Iso 31000 e fornisce

Dettagli

Studiare nuovi prodotti è oggi una questione LEAN INNOVATION M I X. NEL RISPETTO DELLA DISCIPLINA 6 σ

Studiare nuovi prodotti è oggi una questione LEAN INNOVATION M I X. NEL RISPETTO DELLA DISCIPLINA 6 σ LEAN INNOVATION LA PROGETTAZIONE DI UN NUOVO PRODOTTO NEL RISPETTO DELLA DISCIPLINA 6 σ M I X L articolo vuole mostrare come con il lavoro di gruppi interfunzionali e con l utilizzo di tecniche e metodologie

Dettagli

AT&S Aumenta l Efficienza e l Agilità del Business Tramite il Miglioramento della Gestione IT

AT&S Aumenta l Efficienza e l Agilità del Business Tramite il Miglioramento della Gestione IT CUSTOMER SUCCESS STORY Ottobre 2013 AT&S Aumenta l Efficienza e l Agilità del Business Tramite il Miglioramento della Gestione IT PROFILO DEL CLIENTE Settore: Manifatturiero Azienda: AT&S Dipendenti: 7500

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

Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM.

Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM. Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM. La sfida Certificare il corretto montaggio dell impianto elettrico, escludendo la presenza di cortocircuiti

Dettagli

INDAGINE DI CUSTOMER SATISFACTION SUAP COMUNE DI SASSARI Giugno 2014

INDAGINE DI CUSTOMER SATISFACTION SUAP COMUNE DI SASSARI Giugno 2014 STUDIO Q QUALITÀ TOTALE SRL organizzazione formazione marketing INDAGINE DI CUSTOMER SATISFACTION SUAP COMUNE DI SASSARI Giugno 2014 INDICE 1 INTRODUZIONE 3 2 METODOLOGIA 4 3 IL TARGET E IL CAMPIONE D

Dettagli

Marzo 2014. OrphaNews Italia Questionario di Gradimento. www.orpha.net/actor/cgi-bin/oahome.php?ltr=italianews

Marzo 2014. OrphaNews Italia Questionario di Gradimento. www.orpha.net/actor/cgi-bin/oahome.php?ltr=italianews Marzo 2014 OrphaNews Italia Questionario di Gradimento www.orpha.net/actor/cgi-bin/oahome.php?ltr=italianews Indice Introduzione... 3 Metodologia... 3 Conclusioni... 14 Ringraziamenti... 15 Questionario

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

PROGETTO REGIONALE MISURAZIONE E VALUTAZIONE DELLE BIBLIOTECHE VENETE

PROGETTO REGIONALE MISURAZIONE E VALUTAZIONE DELLE BIBLIOTECHE VENETE PROGETTO REGIONALE MISURAZIONE E VALUTAZIONE DELLE BIBLIOTECHE VENETE Analisi dinamica dei dati dei questionari per le biblioteche di pubblica lettura. GLI INDICATORI Gli indicatori sono particolari rapporti

Dettagli

Che cos è un prototipo? Prototipazione. Perchè creare prototipi? Insidie. I processi corrono in parallelo

Che cos è un prototipo? Prototipazione. Perchè creare prototipi? Insidie. I processi corrono in parallelo Che cos è un? Prototipazione Un modello approssimato o parziale del sistema che vogliamo sviluppare che simula o esegue alcune funzioni del sistema finale, realizzato allo scopo di valutarne le caratteristiche

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

Istruzioni, indicatori e strumenti di valutazione per i consigli di classe (Allegato 2 Decr MIUR 22 agosto 2007)

Istruzioni, indicatori e strumenti di valutazione per i consigli di classe (Allegato 2 Decr MIUR 22 agosto 2007) ISTITUTO PROFESSIONALE DI STATO PER I SERVIZI COMMERCIALI, TURISTICI, GRAFICI, ALBERGHIERI E SOCIALI L. EINAUDI Istruzioni, indicatori e strumenti di valutazione per i consigli di classe (Allegato 2 Decr

Dettagli

La norma ISO 50001 per il risparmio energetico delle aziende

La norma ISO 50001 per il risparmio energetico delle aziende La norma ISO 50001 per il risparmio energetico delle aziende La norma UNI CEI EN ISO 50001:2011 Sistemi di gestione dell energia Requisiti e linee guida per l uso è la versione ufficiale italiana della

Dettagli