Feature Driven Development: differenze tra le versioni

Versione delle 12:50, 2 apr 2007

Versione attuale delle 16:34, 23 apr 2024

(26 versioni intermedie di 21 utenti non mostrate)

Riga 1:

ÈIl '''feature driven development''' è una [[metodologia agile]], ideata da [[Jeff De Luca]] e [[Peter Coad]], che propone una robusta fase di analisi e progettazione integrata con un modello di sviluppo agile.

Come s'intuisce dal nome è una forma di sviluppo ''guidata dalle funzionalità'' richieste e necessarie del programma. Sono disponibili diversi strumenti di supporto free, alcuni anche [[open source]], essendopur strettamente basata sull'utilizzo del [[Unified Modeling Language|UML]] e naturalmente sulla versione ''colorata'' del UML ideata dagli autori. Inoltre esiste una community molto attiva che si occupa di questa metodologia e degli strumenti utili per automatizzarne l'utilizzo, sviluppandoli e confrontandosi.

È forse il miglior compromesso e la miglior soluzione agile possibile, ma è molto meno conosciuta di [[Extreme Programming]], pur essendo indicata nell'[[Agile Manifesto]]. [[Serguei Khramtchenko]] fa un confronto diretto (vedi Bibliografia) dal quale emerge sorprendentemente che Feature Driven Development è addirittura più flessibile di Extreme Programming anche se la prima ha una fase di progettazione ''classica'' che la seconda elimina proprio per guadagnarne in flessibilità.

==Le fasiStoria di sviluppo==

FDD è stato inventato da [[Jeff De Luca]] nel 1997, che propose un insieme di cinque processi che riguardavano lo sviluppo completo basato sulle features. Tale modello era fortemente basato sulle idee di Peter Coad e integrato dall'esperienza personale. La prima forma strutturata di FDD fu presentata nel libro ''Java Modeling in Color with UML'' dello stesso Coad, Eric Lefebvre and Jeff De Luca nel 1999; in seguito una versione più generale fu pubblicata nel libro di Stephen Palmer e Mac Felsing ''A Practical Guide to Feature-Driven Development'' . Ulteriori informazioni storiche si possono trovare nel sito personale di Jeff De Luca.

== Le fasi di sviluppo ==

Il progetto viene diviso in cinque fasi, dette processi:

* '''sviluppare un modello generale'''

Line 30 ⟶ 33:

** ''criteri d'ingresso'': è stato portato a termine il processo ''pianificare per funzionalità'' ed è stato ispezionato con successo il progetto in tutti i suoi aspetti funzionali e temporali;

** ''attività'': il team delle funzionalità implementa classi e metodi, ispeziona il codice ed effettua i test unitari; il capo-programmatore decide (dopo i test unitari) insieme al team delle funzionalità quali classi siano ''promuovibili'' come utili alla costruzione del progetto in riguardo alle funzionalità richieste;

** ''verifica'': il capo-programmatore sovrintende affinché siano completate effettivamente in tutti i punti dal team delle funzionalità l'ispezione dei codici ede la soddisfazione dei test unitari;

** ''criteri d'uscita'': avere ottenuto classi e metodi che siano stati ispezionati e testati con successo, infine promossi all'integrazione nel progetto (ovviamente a copertura di tutte le funzionalità previste).

Line 43 ⟶ 46:

* Release meeting (le funzionalità implementate vengono "promosse" al processo di integrazione).

== Il processo di sviluppo ==

La collezione dei requisiti dell'utente e delle specifiche, avviene coinvolgendo il cliente anche durante lo sviluppo del progetto e non solo in una fase iniziale. Inizialmente si ottengono una lista di funzionalità richieste, che diventerà la base della timeline del progetto, ed uno o più diagrammi UML che definiscano il dominio del problema. Partendo da questa base, cliente e sviluppatori lavoreranno insieme ai requisiti in brevi iterazioni che coprano frammenti di business.

Line 60 ⟶ 63:

Date le numerose riunioni effettuate prima di cominciare a scrivere il codice, questa attività diventa qualcosa di meccanico, infatti Feature Driven Development scoraggia l'uso di pratiche tipo il [[Refactoring]] mentre incoraggia la condivisione del codice prodotto (in maniera particolare della documentazione relativa) fra i diversi programmatori.

Per la revisione del codice si va oltre il [[Pair Programmingprogramming]] visto che la condivisione all'interno del team dell'iterazione permette una verifica molto più ampia. In ogni caso è proprio per permettere la miglior revisione possibile del codice che i team di sviluppo devono essere poco numerosi e che le iterazioni devono essere brevi, fra 1 e 3 settimane.

Il rilascio delle versioni è previsto per la fine di ogni iterazione, raramente di più iterazioni, ma ciò permette di coinvolgere molto di meno il cliente rispetto a quanto facciano le altre metodologie leggere. E permette anche di non consegnare alcune versioni intermedie quando le condizioni al contorno non lo rendano possibile, ad esempio in caso di software medici embedded.

Line 74 ⟶ 77:

Partendo da questi dati, [[Jeff De Luca]] afferma che cambiamenti fino al 10% dei requisiti durante il corso del progetto non incidono in maniera tale da inficiare la deadline prevista.

== Strumenti a supporto ==

Benché tutta la struttura organizzativa ed ogni processo di Feature Driven Development possano essere eseguiti manualmente, esistono diversi strumenti a supporto di questa metodologia. In particolare si possono trovare strumenti free, ed anche open source, tramite la community FDD. Riteniamo però più utile soffermarsi sugli oggetti e le attività, rispetto ai singoli, differenti, strumenti che le supportano.

==== UML colors= ===

Per '''UML colorato''' si intende un [[Unified Modeling Language|UML standard]] con le classi divise in quattro categorie individuate da quattro colori diversi:

* giallo (indica un Ruolo, ricoperto da persona o da organizzazione, come ad esempio i differenti tipi di utente di un servizio);

* blu (indica una Descrizione modello-catalogo, ad esempio il tipo di oggetto in un database ma non il singolo oggetto);

* verde (indica un Luogo o un Oggetto, ad esempio il singolo oggetto del database di prima);

* rosa (indica i Tempi, un momento o un intervallo associati ad un processo, ad esempio ad un 'azione su di un oggetto del database).

Le classi ausiliari e le interfacce restano standard e non sono colorate.

==== Progress Report= ===

Un '''Progress Report''' è definito e rappresentato con un modello esclusivo di Feature Driven Development, i diagrammi ''a parcheggio''. Ogni ''posto auto'' rappresenta un set di funzionalità e la sua lettura è piuttosto semplice ed immediata.

* Sfondo verde: funzionalità completate;

Line 97 ⟶ 100:

Lo stesso Progress Report ha un livello di dettaglio maggiore in una tabella con la timeline per singola funzionalità. Sono previste le milestone di ogni passo dell'iterazione mentre i colori indicano semplicemente: verde (tutto secondo i piani), rosso (lo sviluppo della funzionalità è in ritardo rispetto allo scheduling previsto).

==Voci correlateBibliografia ==

* Serguei Khramtchenko –, '''Comparing eXtreme Programming and Feature Driven Development in academic and regulated environments''' – ''Harvard University, CSCIE-275: Software Architecture and Engineering'' – 2004.

== Voci correlate ==

* [[Metodologia agile]]

* [[Extreme Programming]]

* [[Presenter first]]

[[Categoria:MetodologieMetodi di sviluppo software]]

==Bibliografia==

Serguei Khramtchenko – '''Comparing eXtreme Programming and Feature Driven Development in academic and regulated environments''' – ''Harvard University, CSCIE-275: Software Architecture and Engineering'' – 2004

[[Categoria:Metodologie di sviluppo]]