Corso di Ingegneria del Software a.a. 2009/2010 push0 g 0...

Corso di Ingegneria del Software a.a. 2009/2010 Modelli di produzione del software

Corso di Ingegneria del Softwarea.a. 2009/2010

Modelli di produzione del software

Mario Vacca

[email protected]


Modelli agili


Sommario

1. Concetti di base

2. Modelli del ciclo vita del software

2.1 Modello a cascata2.2 Modelli incrementali2.3 Modelli evolutivi2.4 Comparazione dei modelli

2.5 Modelli agili

3. Bibliografia


Modelli agili

Modelli AgiliLe assunzioni

I requisiti del cliente evolvono continuamente durante un progetto e quindiil processo da seguire non e completamente prevedibile e non puo esserecompletamente predefinito.

I fondamenti

I E inutile svolgere una onerosa attivita di analisi e progettazioneprima della codifica, in quanto gran parte di questo lavoro sarebbesprecato.

I Meglio mantenere una documentazione essenziale, ovvero lo stessocodice, scritto in modo standard.

I E piu facile e rapido modificare il codice quando il cliente lo chiede(ovvero spesso!).


Modelli agili

Modelli Agili

I fondamenti

Le metodologie Agili sono centrate sulla facilita di modificare il software.

Agile Alliance

Attorno ai principi delle metodologie AGILI e nata un’alleanza disviluppatori (Agile Alliance), che ha pubblicato un manifesto.


Modelli agili

Modelli Agili

Il manifesto per lo sviluppo agile


Modelli agili

Modelli Agili - I Principi sottostanti al Manifesto Agile1. La nostra massima priorita e soddisfare il cliente per mezzo di tempestivi e continui rilasci di software di valore.

2. Siano benvenuti i cambiamenti nelle specifiche , anche a stadi avanzati dello sviluppo. I processi agili sfruttano il

cambiamento a favore del vantaggio competitivo del cliente.

3. Rilascia software funzionante frequentemente , da un paio di settimane a un paio di mesi, con preferenza per i periodi brevi.

4. Manager e sviluppatori devono lavorare insieme quotidianamente lungo il progetto.

5. Basa i progetti su individui motivati . Dai loro l’ambiente e il supporto di cui necessitano e confida nella loro capacita di

portare il lavoro a termine.

6. Il metodo piu efficiente ed efficace di trasmettere informazione verso e all’interno di un team di sviluppo e

la conversazione faccia a faccia .

7. Il software funzionante e la misura primaria di progresso.

8. I processi agili promuovono uno sviluppo sostenibile . Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di

mantenere un ritmo costante indefinitamente.

9. L’attenzione continua per l’eccellenza tecnica e il buon design esaltano l’agilita.

10. La semplicita - l’arte di massimizzare l’ammontare di lavoro non svolto - e essenziale.

11. Le migliori architetture, specifiche e design emergono da team auto-organizzati .

12. A intervalli regolari il team riflette su come diventare piu efficace, dopodiche mette a punto e aggiusta il suo comportamento diconseguenza.


Modelli agili

Modelli AgiliCaratteristiche dello sviluppo Agile

I Adattabilita alle modifiche

Il software va progettato per consentirne la facile modificabilita durante il corsodel progetto (ma anche dopo il rilascio in uso al cliente).

I Iterativita, incrementalita e semplicita

Le fasi di pianificazione, codifica e test sono compresse in tempi molto piu ridottirispetto a quelli previsti nelle metodologie tradizionali. Ci si deve concentrare supochi problemi alla volta, di limitate dimensioni e ben definiti.

I Rilasci frequenti

I team devono sviluppare versioni dei semilavorati in tempi ridotti.

I Testing

Il test va svolto continuamente, durante tutte le fasi del progetto e su tutti isemilavorati prodotti.

I Documentazione

Conversazione faccia a faccia

I Team di lavoro

Auto-organizzazione


Modelli agili

Modelli Agili“Lesson learnt” dai metodi agili

I il pair programmingMigliora la comunicazione nel team e porta ad un elevato numero diispezioni del software.

I il focus sulla produzione di programmiI metodi agili hanno inoltre riportato l’attenzione sul codice,piuttosto che sulla documentazione accessoria, che spesso assorbegran parte del tempo degli sviluppatori.

I la partecipazione attiva del committente e dell’utenteClima meno formale e piu collaborativoPiu proficuo di un atteggiamento burocratico che vede il clientesolamente in funzione di un contratto.La partecipazione degli utenti finali contribuisce a rendere il softwarepiu efficace, in quanto la costruzione viene fatta attorno a chi userail software.

E. Capra “Sviluppo del software: metodi agili o metodi tradizionali?”


Modelli agili

Modelli Agili

Criticita dei metodi agili - 1/2

La minimizzazione della documentazione (non standardizzata)(la conoscenza del prodotto e degli sviluppatori)

I problemi di comprensione dell’organizzazione del sistema quando ilprogetto e di grande dimensioni (la comunicazione interna con piu di20 persone diventa difficile)

I difficolta nel caso di rotazione e cambiamenti delle risorse del team

I la realizzazione delle interfacce e rallentata dall’assenza didocumentazione standard e condivisa.

L’attenzione posta al ruolo delle personestimola la creativita e la produttivita personalema rende particolarmente critiche la qualita e le skill dei programmatori.



Modelli agili

Modelli Agili

Criticita dei metodi agili - 2/2

La definizione delle specifiche attraverso i testI test descrivono un campione finito di possibili comportamenti, lasciandoindefiniti aspetti e comportamenti che potrebbero presentarsi.I metodi agili si rivelano poco efficaci nello sviluppo di applicazioni safety-critical, che richiedono una certificazione del prodotto.

La validazione dei requisiti solamente attraverso l’esecuzione di ver-sioni parziali dell’applicazione rischia inoltre di degenerare in processi di“code&fix” senza fine, rendendo critica l’evoluzione del prodotto.

La semplificazione volta a snellire il processo, riduce la possibilita diesplorare soluzioni alternative.



Modelli agili

Programmazione estrema

Modelli Agili

eXtreme Programming (XP) - I fondamenti

Il metodo dell’eXtreme Programming e stato proposto da Kent Beck nel1999.I fondamenti del metodo XP:

I evitare la produzione di semilavorati non strettamente necessari alla realizzazionedell’applicazione

Gli sviluppatori sono invitati a concentrarsi sul codice, la produzione didocumentazione di supporto e considerata come una perdita di tempo.

I non e possibile analizzare e pianificre la produzione di un’applicazione a priori

La produzione di un’applicazione e paragonata da Beck alla guida diun’automobile: la condotta complessiva e il risultato di un gran numero diminimi cambiamenti di rotta che il pilota decide in base alla sua istantaneapercezione di curve e ostacoli.

I il processo e il risultato di un gran numero di cambiamenti da decidere di volta involta


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Perche “estrema”?

L’XP porta i principi e le pratiche derivate dal buon senso a livello estremo.(Beck - Programmazione estrema, pag. 10)


Pratiche corrette:

I revisione del codice

I test del codice

I progettazione

I semplicita

I architettura

I verifiche di integrazione

I iterazioni brevi


Modelli agili


Modelli Agili


Pratiche estremizzate:

I programmazione a coppie (revisione del codice)

I test unitari e test funzionali (test del codice)

I refactoring (progettazione)

I semplicita

I metafora (architettura)

I integrazione continua (verifiche di integrazione)

I Planning Game (iterazioni brevi)


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Attivita fondamentali

Il lavoro del team di sviluppo e organizzato in quattro attiv-ita fondamentali (reiterate durante il progetto dopo i feedback deicommittenti):

I listeningosservazione dell’ambiente (desideri e bisogni del committente +opportunita tecnologiche e del mercato)

I designprogetto e integrazione dell’applicazione

I codingscrittura del codice dell’applicazione

I testingverifica delle funzionalita


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Planning Game

Obiettivo del Planning Game: permettere a clienti, manager e sviluppa-tori di confrontarsi attorno alle date e ai contenuti dei rilasci di software,usando come “metrica” di confronto 5 variabili:

I Portata del progetto (funzionalita da realizzare)

I Qualita attesa

I Priorita Composizione dei rilasci parziali.

I Tempo (date dei rilasci).

I Costo del progetto.


Modelli agili


Modelli Agili


Le variabili definite da clienti e manager sono:

I Portata del progetto (funzionalita da realizzare)

I Qualita attesa

I Priorita n Composizione dei rilasci parziali.

I Tempo (date dei rilasci).


Modelli agili


Modelli Agili


Le variabili definite dagli sviluppatori sono:

I Tempo necessario a sviluppare una funzionalita.

I Costo di realizzazione delle funzioni.


Modelli agili


Modelli Agili


Nella fase di pianificazione clienti/managers e sviluppatori “contrattano”sui valori da assegnare alle variabili (e.g. se i primi definiscono i tempi, glisviluppatori scelgono quali storie realizzare per quella data e il loro costo.(GAME)


Modelli agili


Modelli Agili


I LA STRATEGIAInvestire il meno possibile per mettere in produzione il piu prestopossibile le funzionalita piu importanti, riducendo il rischio.

I I COMPONENTII componenti del Planning Game sono le schede contenenti le storiedi funzionamento del sistema.

I I GIOCATORIsviluppatori (responsabili della implementazione) e management(persone che decidono cosa deve fare il sistema).

I LE FASI E LE MOSSEEsplorazione: scoprire cosa il sistema potrebbe fare.Impegno: decidere quale sottoinsieme di tutti i possibili requisiti realizzare nellafase successiva.Gestione: dirigere lo sviluppo in base a come la realta influenza il piano.

Le mosse di ciascuna fase avvengono di solito nella fase stessa.


Modelli agili


Modelli Agili


Il Planning Game prevede 3 fasi, da eseguire in sequenza, e da iterarepiu volte.

I Esplorazione: scoprire le cose che il sistema software potrebbe fareper il cliente.

I Impegno: definire quali impegni prendere nel breve periodo, ovveroquali funzioni realizzare nel prossimo intervallo di tempo (pianificarei rilasci).

I Gestione: gestire in corso dıopera le attivita realizzative in funzionedella realta operativa del progetto (ritardi disponibilita risorsevariazione requisiti etc ) (aggiornamento del piano di lavoro)


Modelli agili


Modelli Agili


Le mosse della fase di esplorazione:

1. Scrittura di una storiail management scrive una storia che descrive una funzionalita delsistema.

2. Stima della durata di una storiagli sviluppatori stimano il tempo necessario per implementare lastoria.

3. Suddivisione di una storia


Modelli agili


Modelli Agili

eXtreme Programming (XP) - User story

Le user stories rappresentano in modo discorsivo le caratteristiche e lefunzioni che gli utenti si aspettano dal software.Le user stories vengono scritte su delle schede di limitate dimensioni (perlimitarne la lunghezza).Il cliente assegna ad ogni storia un valore (che dipende dallıimportanzadella user story per il suo business).


Modelli agili


Modelli Agili



Modelli agili


Modelli Agili


Le User Story sono scenari di funzionamento del sistema software darealizzare, descritti in modo sintetico e discorsivo (eventualmente con usecase UML) che devono:

I avere un valore economico per il cliente,

I essere comprensibili per il programmatore,

I essere stimabili come tempo di realizzazione/costo,

I essere semplici


Modelli agili


Modelli Agili


Le mosse della fase di impegno:

1. Ordinamento per importanza (a cura del mnagement)storie indispensabili, storie importanti (economicamente), storiecomode, accessorie

2. Ordinamento per rischio (a cura degli sviluppatori)stimabili con precisione, con ragionevole sicurezza, non stimabili

3. Stabilire la velocita (a cura degli sviluppatori)

4. Scelta delle funzionalita (a cura del management)scelta delle storie da implementare per il prossimo rilascio.


Modelli agili


Modelli Agili


Le mosse della fase di gestione:

1. Iterazione (a cura del management)scelta delle storie da implementare nell’iterazione. L’implemetazionee un sistema funzionante.

2. Recupero (a cura del management)scelta delle storie da mantenere nel rilascio in corso se ci sonoproblema di sovrastima della velocita di implemtazione.

3. Nuova storia (a cura del management e degli sviluppatori)Il management puo introdurre una nuova storia (e cancellarne altre).Gli sviluppatori stimano la nuova storia.

4. Nuove stime (a cura degli sviluppatori)gli sviluppatori possono fare una nuova stima delle storie rimanentise capiscono che la stima non e piu realistica.


Modelli agili


Modelli Agili


short releaseI rilasci frequenti (2-4 settimane) mirano a tenere conto di cambi diprospettiva, nuovi requisiti o imprecisioni nelle fasi precedenti.


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Progettazione

In XP la documentazione della fase di progettazione consiste nellaproduzione di schede CRC (Classe, Responsabilita, Collaborazione).Si individuano i componenti che costituiranno lıarchitettura funzionale delsistema software, le “classi” e per ogni classe si scrive una scheda cheindividua:

I le responsabilita che ha nell’ambito dell’architettura (cosa fa nelsistema)

I le azioni / compiti che esegue (utile fare riferimento ai “verbi” usatidal cliente per descrivere i requisiti) (“metodi”)

I le altre classi che devono collaborare con questa per soddisfare leresponsabilita, definendo le gerarchie di ereditarieta.


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Progrettazione

I project metaphorLa progettazione in XP e guidata da metafore:Ad es. il sistema software deve realizzare le funzioni di una“scrivania virtuale” o di un “foglio” di lavoro elettronico scrivaniavirtuale foglio etc.).Il sistema software da costruire deve essere descritto attraversometafore semplici e comprensibili a tutte le persone coinvolte nelprogetto, in modo da poter condividere lo stesso vocabolario e lastessa percezione di quanto si sta per realizzare.In XP le metafore sostituiscono le architetture logiche.


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Progettazione

I simple designLa struttura dell’applicazione deve essere il piu possibile semplice, inquanto l’architettura del sistema deve essere facilmentecomprensibile da tutte le persone coinvolte nel progetto. Vienesviluppato solo quanto e strettamente necessario a soddisfare loscenario in esame, eventuali evoluzioni future non vengonoconsiderate.


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Codifica

In XP la codifica e l’attivita principale.XP prevede diverse pratiche a supporto di questa attivita:

I Programmazione a coppie.

I Proprieta collettiva.

I Intregrazione continua.

I Standard di codifica.

I Refactoring


Modelli agili


Modelli Agili


I pair programmingLa programmazione avviene a coppie, con lo scopo di favorire ilcontrollo reciproco del codice prodotto e di stimolare la generazionedi soluzioni innovative tramite il confronto tra persone diverse. Lecoppie vengono riassortite molto frequentemente, cercando diaffiancare persone con esperienze diverse, in modo da incentivare unapprendimento continuo.Le statistiche raccolte dimostrano che la tecnica del pairprogramming, pur dilatando i tempi di realizzazione del codice dal20% al 50% permette di produrre rispetto alle

I software di migliore qualita,I programmi meno voluminosi (dal 10 al 25% in meno della media),I un numero di difetti inferiore nel codice (meno 10- 20%)


Modelli agili


Modelli Agili


I collective ownershipCollettivizzazione del codice: il codice dell’applicazione deve essereaccessibile e manipolabile da tutti gli sviluppatori.Per rendere possibile cio e necessario che esistano semplici regolecondivise da tutte. La collettivizzazione contribuisce in manieraindiretta a semplificare il codice, in quanto le parti piu oscure,incomprensibili a tutti fuorche agli autori, hanno un alta probabilitadi essere eliminate.

I standard di codifica coding standards)L’assenza della documentazione di supporto tipica dei metoditradizionali rende necessari degli standard di codifica (codingstandards), condivisi e validi solo all’interno del team, chepermettano di scrivere il codice in modo omogeneo e uniforme.


Modelli agili


Modelli Agili


I refactoringL’applicazione necessita di continue riprogettazioni per adattare ilsistema alle nuove esigenze ed integrare fra loro le parti relative allevarie storie. Il refactoring e la ristrutturazione continua del codice alfine di renderlo sempre piu chiaro, semplice, facilmente modificabile,eliminare parti superflue, senza modificare la sua funzione.

I integrazione continua (continuous integration)Non sono previste sessioni particolari per l’integrazione, che econtinua nel tempo (continuous integration).


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Testing

La fase di testing e molto accurata, sia a livello di sistema che di singolaunita. I test di sistema sono costruiti sulla base delle storie concordate conil committente, i test di unita solitamente sono supportati da strumentiautomatici che rendono la verifica molto efficiente. Il metodo XP addirit-tura prescrive che i test vadano scritti prima della codifica. La validazionedel software e ridotta alla verifica che esso superi tutti i test che sonostati ideati: Beck ha una concezione di stampo “popperiano”, secondo laquale un’applicazione e funzionante finche non viene trovato un test chedimostra il contrario.


Modelli agili


Modelli Agili

eXtreme Programming (XP) - Prassi organizzative

I ambiente di lavoroL’ambiente di lavoro deve essere gradevole e informale, con zoneadibite al relax e allo scambio di opinioni fra i membri del team

I rinuncia al lavoro straordinarioSi tende ad evitare evitare il lavoro straordinario.

I partecipazione del committente (insite customer)Forte partecipazione del committente (insite customer). Ilcommittente e infatti l’unica fondamentale fonte di convalida delsistema, deve percio partecipare non solo alla definizione delle storie,ma anche alla definizione dei test e alle fasi di verifica. Inoltre e laprincipale fonte di informazioni sul dominio di applicazione, per cuila sua presenza full-time con il team e ritenuta essenziale. Ilcommittente e un collaboratore, non un’entita verso cui si hannosolo obblighi contrattuali.


Modelli agili


Modelli Agili

eXtreme Programming (XP) - I ruoli delle persone

Importanza dei ruoli: la metafora della squadra.Dualismo cliente-programmatore della programmazione estrema:“Il programmatore sa come programmare. Il cliente sa che cosaprogrammare.“

I Il programmatore

I Il cliente

I Il collaudatore (tecnico dei test)

I Il tracker

I Il coach

I Il consulente

I Il grande capo

Beck - Programmazione estrema. pag. 148


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il programmatore

Il programmatore e il cuore dell’XP.Il valore principale e la comunicazione con le altre persone.Attivita del programmatore XP:

I scrivere test che mostrano aspetti vitali del software

I dividere il programma in parti piu piccole, o assemblare parti troppopiccole in componenti piu grandi e piu coerenti.

I trovare un sistema di nomi significativi.

I sviluppare il software di maggior valore per il cliente, e di nonsviluppare niente che non sia di valore.


Modelli agili


Modelli Agili


Abilita del programmatore XP:

I programmare a coppie (pair programming)La progrmmazione a coppie implica comunicare e coordinarsi davicino con gli altri programmatori per avere successo.

I semplicitaImplica

I selezionare le richieste NECESSARIE.I scrivere codice semplice e comprensibile facilmente

I tecnicaImplica

I capacita di riorganizzare il codice (refactoring).I di scrivere test unitari per il codice


Modelli agili


Modelli Agili


Abilita del programmatore XP:

I mettere da parte la propensione alla proprieta individuale di unaparte del codice in favore della proprieta condivisa dell’intero sistema.

I coraggioessere pronti a riconoscere le proprie paure

I di sembrare stupidoI essere ritenuto inutileI diventare superatoI non essere abbastanza bravo

per far parte di un gruppo che si diverte a scrivere ottimosoftware.


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il cliente

Il cliente XP deve:

I influenzare un progetto senza essere in grado di controllarlo

I prendere delle decisioniImportanza delle storie e loro sufficienza a descrivere il problema.Eliminazione delle storie non importanti.

I deve imparare a scrivere le storie

I deve imparare a scrivere test funzionalicreare i dati per un test con l’obiettivo di stabilire condizionisufficienti per il funzionamento.

I deve anche dimostrare coraggio


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il tester

Il collaudatore (tecnico dei test) e focalizzato sul cliente.Il tester ha il compito

I di aiutare il cliente a scegliere e a scrivere i test funzionali

I (responsabilita) dell’esecuzione a intervalli regolari dei test funzionalie dell’affissione dei risultati in un posto visibile a tutti

I di assicurarsi che gli strumenti di collaudo funzionino bene.


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il tracker

Il lavoro del tracker e quello di chiudere il ciclo di feedback.Il tracker

I fa le stimeLe dipendono dalla esperienza e dal feedback. Il tracker deve fare ungran numero di stime, per poi vedere come la realta si concilia conesse.

I contribuisce al miglioramento delle stime fatte del gruppo

I e responsabile di osservare il quadro generaleA meta di un’iterazione il tracker deve essere capace di dire algruppo se ce la fara o se si debba cambiare qualcosa. Dopo un paiod’iterazioni nel piano degli impegni, il tracker dovrebbe essere ingrado di stabilire se il gruppo riuscira a portare a termine il prossimorilascio senza grandi cambiamenti.


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il tracker

Il lavoro del racker e quello di chiudere il ciclo di feedback.Il tracker

I e lo storico del gruppoConserva

I un diario ufficiale dei punteggi dei test funzionali.I un diario ufficiale contente i difetti riportati, i nomi di chi ha

accettato la responsabilita per ciascuno di essi, e quali test sono statiaggiunti in relazione a ciascun difetto.

I ha l’abilita di raccogliere le informazioni senza disturbare piu delnecessario l’intero processo


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il coach

e responsabile dell’intero processo.Si accorge quando le persone deviano dal regolare funzionamento delgruppo, e richiama l’attenzione di tutti sul problema.“Il ruolo del coach diminuisce man mano che il gruppo matura. Con-cordemente ai principi del controllo distribuito e dell’accettazionedelle responsabilita, il “processo” dovrebbe essere responsabilita di tut-ti. All’inizio del passaggio all’XP, questo e troppo da chiedere a ogniprogrammatore.” (Beck - Programmazione estrema, cap 22)


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il consulente

Pair programming, semplicita generano gruppi estremamente flessibile, mapoco specialistici.Di qui la necessita di consulenti esterniL’obiettivo dei membri del gruppo e di far sI che il consulente gli insegnicome risolvere i loro problemi.


Modelli agili


Modelli Agili

XP - I ruoli delle persone: il grande capo

Comunicazione onesta con il gruppo:

I il gruppo deve volere che il capo sappia prima possibile quando lecose si stanno discostando dal piano, in modo che possa avere ilmaggior tempo possibile per reagire.

I il gruppo spiega le conseguenze dei cambiamenti nella situazioneattuale.

I il gruppo puo invitare il capo a ridurre la portata del progetto.

I il capo insiste affinche il gruppo faccia cio che ha dichiarato di fare.


Modelli agili


Modelli Agili

XP - Risoluzione dei rischi

XP affronta i principali rischi dei progetti di sviluppo software conqueste modalita:

I Ritardi nelle consegne: XP prevede cicli di sviluppo brevi, coniterazioni di durata limitata (3-4 settimane al massimo).

I Degrado della qualita: XP prevede che vengano eseguiti dicontinuo test sui semilavorati, sia pensati dai programmatori chedagli utenti stessi (per le funzioni).

I Fraintendimento requisiti: in XP il cliente e parte integrante delgruppo di lavoro. Le specifiche di progetto vengono continuamenteriviste insieme al cliente durante il progetto, procedendo perraffinamenti successivi. I cicli di lavorazione sono rapidi, confrequenti feedback da parte del cliente, che effettua anchedirettamente i test funzionali.


Modelli agili


Modelli Agili

XP - Risoluzione dei rischi

I Variabilita dei requisiti: XP accorcia i tempi dei rilasci e prevede diprocedere per incrementi graduali nello sviluppo in modo da gestirenuove richieste dei clienti e sviluppo, le modifiche ai requisiti senzache impattino su porzioni troppo ampie di software gia sviluppato.

I Turn over delle risorse: XP da responsabilita ai programmatori (sipianificano essi stessi il lavoro da svolgere e coprono l’intero ciclo dilavorazione, dalla progettazione alla codifica e testing). Definiscepratiche innovative di lavoro, che danno fiducia e motivazione alpersonale e creano spirito di gruppo (planning game, lavoro dicoppia)


Bibliografia


Sommario

1. Concetti di base

2. Modelli del ciclo vita del software

2.1 Modello a cascata2.2 Modelli incrementali2.3 Modelli evolutivi2.4 Comparazione dei modelli2.5 Modelli agili

3. Bibliografia


Bibliografia

Bibliografia

Riferimenti bibliografici - Generali

1. R. Pressman “Ingegneria del software” Mc Graw Hill Italia, 5aedizione, 2007, capitolo 4.

2. P. Jalote “A Concise Introduction to Software Engineering”Springer, 2008, capitolo 2.


Bibliografia

Bibliografia

Riferimenti bibliografici - Specifici

1. K. Beck “Programmazione estrema”, Addison-Wesley, 2000,(capitolo 22).

2. E. Capra “Sviluppo del software: metodi agili o metodi tradizionali?”(http://home.dei.polimi.it/ghezzi/_PRIVATE/Capra.pdf)

3. C. Ghezzi, M. Monga, “eXtreme Programming: Programmazioneestrema o revisionismo estremista?”, Mondo Digitale n. 4, 2002.

http://home.dei.polimi.it/ghezzi/_PRIVATE/Capra.pdf


Bibliografia

Bibliografia

Riferimenti bibliografici - Siti utili

1. http://www.Agilealliance.org

2. http://www.Agilemanifesto.org

3. http://wwww.extremeprogramming.org

4. http://www.refactoring.com

5. http://www.agiledata.org/essays/databaseRefactoring.html

http://www.Agilealliance.org

http://www.Agilemanifesto.org

http://wwww.extremeprogramming.org

http://www.refactoring.com

http://www.agiledata.org/essays/databaseRefactoring.html

http://www.agiledata.org/essays/databaseRefactoring.html

Corso di Ingegneria del Software a.a. 2009/2010 push0 g 0...

Documents

Transcript of Corso di Ingegneria del Software a.a. 2009/2010 push0 g 0...