Feature Driven Development: differenze tra le versioni

Versione delle 10:57, 15 giu 2014

Versione attuale delle 16:34, 23 apr 2024

(6 versioni intermedie di 5 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à.

== Storia ==

FDD è stato inventato da [[:en:Jeff De Luca|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'''

Riga 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).

Riga 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.

Riga 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);

Riga 88:

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;

Riga 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]]