Feature Driven Development: differenze tra le versioni

Versione delle 11:42, 13 lug 2014

Versione attuale delle 16:34, 23 apr 2024

(5 versioni intermedie di 4 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 [[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 ==

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 80:

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 99:

* Mese in basso: deadline per lo sviluppo del blocco di funzionalità.

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

== Bibliografia ==

* 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 ==

Line 105 ⟶ 108:

* [[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]]