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

Transcript

Corso di Ingegneria del Software a.a. 2009/2010
Modelli di produzione del software
Corso di Ingegneria del Software
a.a. 2009/2010
Mario Vacca
[email protected]
Modelli agili
Sommario
1. Concetti di base
2. Modelli del ciclo vita del software
2.1
2.2
2.3
2.4
2.5
Modello a cascata
Modelli incrementali
Modelli evolutivi
Comparazione dei modelli
Modelli agili
3. Bibliografia
Modelli agili
Modelli Agili
Le assunzioni
I requisiti del cliente evolvono continuamente durante un progetto e quindi
il processo da seguire non è completamente prevedibile e non può essere
completamente predefinito.
I fondamenti
I
È inutile svolgere una onerosa attività di analisi e progettazione
prima della codifica, in quanto gran parte di questo lavoro sarebbe
sprecato.
I
Meglio mantenere una documentazione essenziale, ovvero lo stesso
codice, 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 di
sviluppatori (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 Agile
1.
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
6.
Il metodo più efficiente ed efficace di trasmettere informazione verso e all’interno di un team di sviluppo è
portare il lavoro a termine.
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
9.
L’attenzione continua per l’eccellenza tecnica e il buon design esaltano l’agilità.
mantenere un ritmo costante indefinitamente.
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 di
conseguenza.
Modelli agili
Modelli Agili
Caratteristiche dello sviluppo Agile
I Adattabilità alle modifiche
Il software va progettato per consentirne la facile modificabilità durante il corso
del 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̀ ridotti
rispetto a quelli previsti nelle metodologie tradizionali. Ci si deve concentrare su
pochi 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 i
semilavorati 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 programming
Migliora la comunicazione nel team e porta ad un elevato numero di
ispezioni del software.
I
il focus sulla produzione di programmi
I metodi agili hanno inoltre riportato l’attenzione sul codice,
piuttosto che sulla documentazione accessoria, che spesso assorbe
gran parte del tempo degli sviluppatori.
I
la partecipazione attiva del committente e dell’utente
Clima meno formale e più collaborativo
Più proficuo di un atteggiamento burocratico che vede il cliente
solamente in funzione di un contratto.
La partecipazione degli utenti finali contribuisce a rendere il software
più efficace, in quanto la costruzione viene fatta attorno a chi userà
il 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 il
progetto è di grande dimensioni (la comunicazione interna con più di
20 persone diventa difficile)
I
difficoltà nel caso di rotazione e cambiamenti delle risorse del team
I
la realizzazione delle interfacce è rallentata dall’assenza di
documentazione standard e condivisa.
L’attenzione posta al ruolo delle persone
stimola la creatività e la produttività personale
ma 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 test
I test descrivono un campione finito di possibili comportamenti, lasciando
indefiniti aspetti e comportamenti che potrebbero presentarsi.
I metodi agili si rivelano poco efficaci nello sviluppo di applicazioni safetycritical, che richiedono una certificazione del prodotto.
La validazione dei requisiti solamente attraverso l’esecuzione di versioni 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̀ di
esplorare soluzioni alternative.
Modelli agili
Programmazione estrema
Modelli Agili
eXtreme Programming (XP) - I fondamenti
Il metodo dell’eXtreme Programming è stato proposto da Kent Beck nel
1999.
I fondamenti del metodo XP:
I evitare la produzione di semilavorati non strettamente necessari alla realizzazione
dell’applicazione
Gli sviluppatori sono invitati a concentrarsi sul codice, la produzione di
documentazione 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 di
un’automobile: la condotta complessiva è il risultato di un gran numero di
minimi cambiamenti di rotta che il pilota decide in base alla sua istantanea
percezione di curve e ostacoli.
I il processo è il risultato di un gran numero di cambiamenti da decidere di volta in
volta
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
iterazioni brevi
I
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 attività fondamentali (reiterate durante il progetto dopo i feedback dei
committenti):
I
listening
osservazione dell’ambiente (desideri e bisogni del committente +
opportunità tecnologiche e del mercato)
I
design
progetto e integrazione dell’applicazione
I
coding
scrittura del codice dell’applicazione
I
testing
verifica delle funzionalità
Modelli agili
Modelli Agili
eXtreme Programming (XP) - Planning Game
Obiettivo del Planning Game: permettere a clienti, manager e sviluppatori 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
I
Tempo necessario a sviluppare una funzionalità.
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, gli
sviluppatori scelgono quali storie realizzare per quella data e il loro costo.
(GAME)
Modelli agili
Modelli Agili
I
LA STRATEGIA
Investire il meno possibile per mettere in produzione il più presto
possibile le funzionalità più importanti, riducendo il rischio.
I
I COMPONENTI
I componenti del Planning Game sono le schede contenenti le storie
di funzionamento del sistema.
I
I GIOCATORI
sviluppatori (responsabili della implementazione) e management
(persone che decidono cosa deve fare il sistema).
I
LE FASI E LE MOSSE
Esplorazione: scoprire cosa il sistema potrebbe fare.
Impegno: decidere quale sottoinsieme di tutti i possibili requisiti realizzare nella
fase 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 iterare
più volte.
I
Esplorazione: scoprire le cose che il sistema software potrebbe fare
per il cliente.
I
Impegno: definire quali impegni prendere nel breve periodo, ovvero
quali funzioni realizzare nel prossimo intervallo di tempo (pianificare
i rilasci).
I
Gestione: gestire in corso dı́opera le attività realizzative in funzione
della realtà operativa del progetto (ritardi disponibilità risorse
variazione requisiti etc ) (aggiornamento del piano di lavoro)
Modelli agili
Modelli Agili
Le mosse della fase di esplorazione:
1. Scrittura di una storia
il management scrive una storia che descrive una funzionalità del
sistema.
2. Stima della durata di una storia
gli sviluppatori stimano il tempo necessario per implementare la
storia.
3. Suddivisione di una storia
Modelli agili
Modelli Agili
eXtreme Programming (XP) - User story
Le user stories rappresentano in modo discorsivo le caratteristiche e le
funzioni che gli utenti si aspettano dal software.
Le user stories vengono scritte su delle schede di limitate dimensioni (per
limitarne la lunghezza).
Il cliente assegna ad ogni storia un valore (che dipende dallı́importanza
della user story per il suo business).
Modelli agili
Modelli Agili
Modelli agili
Modelli Agili
Le User Story sono scenari di funzionamento del sistema software da
realizzare, descritti in modo sintetico e discorsivo (eventualmente con use
case 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), storie
comode, 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’implemetazione
è un sistema funzionante.
2. Recupero (a cura del management)
scelta delle storie da mantenere nel rilascio in corso se ci sono
problema 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 rimanenti
se capiscono che la stima non è più realistica.
Modelli agili
Modelli Agili
short release
I rilasci frequenti (2-4 settimane) mirano a tenere conto di cambi di
prospettiva, nuovi requisiti o imprecisioni nelle fasi precedenti.
Modelli agili
Modelli Agili
eXtreme Programming (XP) - Progettazione
In XP la documentazione della fase di progettazione consiste nella
produzione di schede CRC (Classe, Responsabilità, Collaborazione).
Si individuano i componenti che costituiranno lı́architettura funzionale del
sistema software, le “classi” e per ogni classe si scrive una scheda che
individua:
I
le responsabilità che ha nell’ambito dell’architettura (cosa fa nel
sistema)
I
le azioni / compiti che esegue (utile fare riferimento ai “verbi” usati
dal cliente per descrivere i requisiti) (“metodi”)
I
le altre classi che devono collaborare con questa per soddisfare le
responsabilità, definendo le gerarchie di ereditarietà.
Modelli agili
Modelli Agili
eXtreme Programming (XP) - Progrettazione
I
project metaphor
La 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 scrivania
virtuale foglio etc.).
Il sistema software da costruire deve essere descritto attraverso
metafore semplici e comprensibili a tutte le persone coinvolte nel
progetto, in modo da poter condividere lo stesso vocabolario e la
stessa 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 design
La struttura dell’applicazione deve essere il più possibile semplice, in
quanto l’architettura del sistema deve essere facilmente
comprensibile da tutte le persone coinvolte nel progetto. Viene
sviluppato solo quanto è strettamente necessario a soddisfare lo
scenario in esame, eventuali evoluzioni future non vengono
considerate.
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 programming
La programmazione avviene a coppie, con lo scopo di favorire il
controllo reciproco del codice prodotto e di stimolare la generazione
di soluzioni innovative tramite il confronto tra persone diverse. Le
coppie vengono riassortite molto frequentemente, cercando di
affiancare persone con esperienze diverse, in modo da incentivare un
apprendimento continuo.
Le statistiche raccolte dimostrano che la tecnica del pair
programming, pur dilatando i tempi di realizzazione del codice dal
20% al 50% permette di produrre rispetto alle
I
I
I
software di migliore qualità,
programmi meno voluminosi (dal 10 al 25% in meno della media),
un numero di difetti inferiore nel codice (meno 10- 20%)
Modelli agili
Modelli Agili
I
collective ownership
Collettivizzazione del codice: il codice dell’applicazione deve essere
accessibile e manipolabile da tutti gli sviluppatori.
Per rendere possibile ciò è necessario che esistano semplici regole
condivise da tutte. La collettivizzazione contribuisce in maniera
indiretta a semplificare il codice, in quanto le parti più oscure,
incomprensibili a tutti fuorché agli autori, hanno un alta probabilità
di essere eliminate.
I
standard di codifica coding standards)
L’assenza della documentazione di supporto tipica dei metodi
tradizionali rende necessari degli standard di codifica (coding
standards), condivisi e validi solo all’interno del team, che
permettano di scrivere il codice in modo omogeneo e uniforme.
Modelli agili
Modelli Agili
I
refactoring
L’applicazione necessita di continue riprogettazioni per adattare il
sistema alle nuove esigenze ed integrare fra loro le parti relative alle
varie storie. Il refactoring è la ristrutturazione continua del codice al
fine 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 è
continua 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 singola
unità. I test di sistema sono costruiti sulla base delle storie concordate con
il committente, i test di unità solitamente sono supportati da strumenti
automatici che rendono la verifica molto efficiente. Il metodo XP addirittura prescrive che i test vadano scritti prima della codifica. La validazione
del software è ridotta alla verifica che esso superi tutti i test che sono
stati ideati: Beck ha una concezione di stampo “popperiano”, secondo la
quale un’applicazione è funzionante finché non viene trovato un test che
dimostra il contrario.
Modelli agili
Modelli Agili
eXtreme Programming (XP) - Prassi organizzative
I
ambiente di lavoro
L’ambiente di lavoro deve essere gradevole e informale, con zone
adibite al relax e allo scambio di opinioni fra i membri del team
I
rinuncia al lavoro straordinario
Si tende ad evitare evitare il lavoro straordinario.
I
partecipazione del committente (insite customer)
Forte partecipazione del committente (insite customer). Il
committente è infatti l’unica fondamentale fonte di convalida del
sistema, deve perciò partecipare non solo alla definizione delle storie,
ma anche alla definizione dei test e alle fasi di verifica. Inoltre è la
principale fonte di informazioni sul dominio di applicazione, per cui
la sua presenza full-time con il team è ritenuta essenziale. Il
committente è un collaboratore, non un’entità verso cui si hanno
solo 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 cosa
programmare.“
I
Il programmatore
I
Il cliente
I
I
Il collaudatore (tecnico dei test)
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 troppo
piccole 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 non
sviluppare 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 da
vicino con gli altri programmatori per avere successo.
I
semplicità
Implica
I
I
I
selezionare le richieste NECESSARIE.
scrivere codice semplice e comprensibile facilmente
tecnica
Implica
I
I
capacità di riorganizzare il codice (refactoring).
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 una
parte del codice in favore della proprietà condivisa dell’intero sistema.
I
coraggio
essere pronti a riconoscere le proprie paure
I
I
I
I
di sembrare stupido
essere ritenuto inutile
diventare superato
non essere abbastanza bravo
per far parte di un gruppo che si diverte a scrivere ottimo
software.
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 decisioni
Importanza 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 funzionali
creare i dati per un test con l’obiettivo di stabilire condizioni
sufficienti 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 funzionali
e 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 stime
Le dipendono dalla esperienza e dal feedback. Il tracker deve fare un
gran numero di stime, per poi vedere come la realtà si concilia con
esse.
I
contribuisce al miglioramento delle stime fatte del gruppo
è responsabile di osservare il quadro generale
A metà di un’iterazione il tracker deve essere capace di dire al
gruppo se ce la farà o se si debba cambiare qualcosa. Dopo un paio
d’iterazioni nel piano degli impegni, il tracker dovrebbe essere in
grado di stabilire se il gruppo riuscirà a portare a termine il prossimo
rilascio senza grandi cambiamenti.
I
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 gruppo
Conserva
I
I
I
un diario ufficiale dei punteggi dei test funzionali.
un diario ufficiale contente i difetti riportati, i nomi di chi ha
accettato la responsabilità per ciascuno di essi, e quali test sono stati
aggiunti in relazione a ciascun difetto.
ha l’abilità di raccogliere le informazioni senza disturbare più del
necessario 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 del
gruppo, e richiama l’attenzione di tutti sul problema.
“Il ruolo del coach diminuisce man mano che il gruppo matura. Concordemente ai principi del controllo distribuito e dell’accettazione
delle responsabilità, il “processo” dovrebbe essere responsabilità di tutti. All’inizio del passaggio all’XP, questo è troppo da chiedere a ogni
programmatore.” (Beck - Programmazione estrema, cap 22)
Modelli agili
Modelli Agili
XP - I ruoli delle persone: il consulente
Pair programming, semplicità generano gruppi estremamente flessibile, ma
poco specialistici.
Di qui la necessità di consulenti esterni
L’obiettivo dei membri del gruppo è di far sÏ che il consulente gli insegni
come 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 le
cose si stanno discostando dal piano, in modo che possa avere il
maggior tempo possibile per reagire.
I
il gruppo spiega le conseguenze dei cambiamenti nella situazione
attuale.
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 con
queste modalità:
I
Ritardi nelle consegne: XP prevede cicli di sviluppo brevi, con
iterazioni di durata limitata (3-4 settimane al massimo).
I
Degrado della qualità: XP prevede che vengano eseguiti di
continuo test sui semilavorati, sia pensati dai programmatori che
dagli utenti stessi (per le funzioni).
I
Fraintendimento requisiti: in XP il cliente è parte integrante del
gruppo di lavoro. Le specifiche di progetto vengono continuamente
riviste insieme al cliente durante il progetto, procedendo per
raffinamenti successivi. I cicli di lavorazione sono rapidi, con
frequenti feedback da parte del cliente, che effettua anche
direttamente i test funzionali.
Modelli agili
Modelli Agili
XP - Risoluzione dei rischi
I
Variabilità dei requisiti: XP accorcia i tempi dei rilasci e prevede di
procedere per incrementi graduali nello sviluppo in modo da gestire
nuove richieste dei clienti e sviluppo, le modifiche ai requisiti senza
che impattino su porzioni troppo ampie di software già sviluppato.
I
Turn over delle risorse: XP dà responsabilità ai programmatori (si
pianificano essi stessi il lavoro da svolgere e coprono l’intero ciclo di
lavorazione, dalla progettazione alla codifica e testing). Definisce
pratiche innovative di lavoro, che danno fiducia e motivazione al
personale e creano spirito di gruppo (planning game, lavoro di
coppia)
Bibliografia
Sommario
1. Concetti di base
2. Modelli del ciclo vita del software
2.1
2.2
2.3
2.4
2.5
Modello a cascata
Modelli incrementali
Modelli evolutivi
Comparazione dei modelli
Modelli agili
3. Bibliografia
Bibliografia
Bibliografia
Riferimenti bibliografici - Generali
1. R. Pressman “Ingegneria del software” Mc Graw Hill Italia, 5a
edizione, 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: Programmazione
estrema o revisionismo estremista?”, Mondo Digitale n. 4, 2002.
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

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

Transcript

Documenti analoghi

05(Agile e XP)

20100428Programma (20100428ProgrammaFesta)

Entra a far parte di LIDL Italia

notice to graduating students pc

STAMPAGGIO AD INIEZIONE ASSISTITO DA GAS (GAIM)

Attività

Bando 2010 CAMPUS@MICRON

Stage Data Scientist

Mobilità e applicazioni per i “runners”.

Gideon Kunda: L`ingegneria della cultura. Controllo, appartenenza e

Piano di studi ufficiale del Canale Online del corso di Laurea