Feature Driven Development: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
+link interno |
Nessun oggetto della modifica |
||
| (18 versioni intermedie di 14 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]],
È 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à.
==
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
** ''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 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.
===
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);
Line 85 ⟶ 88:
Le classi ausiliari e le interfacce restano standard e non sono colorate.
===
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).
==
* Serguei Khramtchenko
== Voci correlate ==
* [[Metodologia agile]]
* [[Extreme Programming]]
* [[Presenter first]]
▲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]]
| |||