Feature driven design FDD
3 likes4,629 views
FDD is an agile methodology that focuses on developing small, customer-valued features rapidly. It involves 5 key steps: 1) Developing an overall model of the system and business activities, 2) Building a features list, 3) Planning development by feature, 4) Designing each feature, and 5) Building each feature. Key practices include domain modeling, feature-based development teams, and class ownership. While not imposing rigid timeboxes, FDD aims to deliver features frequently to provide early value. Documentation is valued to support scalability.
![Feature Driven Design
Feature Driven Design is an agile methodology that centers
attention on small scale requirements—dubbed ‘features’—
that can be rapidly deployed to create customer value.
Everyone can't know everything about everything—that is brittle and it can't scale.
Jeff De Luca
Feature Driven Design, FDD,1 is one of the agile methodologies developed empirically in the late
1990’s. In a word, a feature is a small scale functional need in the general format of
<action><object><result>, like “calculate order total”.2 Jeff De Luca is the acknowledged
inventor of FDD, although De Luca himself credits others with significant contributions—people
like Peter Coad, a well known leader in object oriented [OO] coding, who introduced a prominent
practice to the methodology: fine grain object modeling.3
The founding project was a troubled about the recommended methodology steps
software implementation at a large bank in that FDD can not be applied outside an OO
Singapore in the late 1990’s. De Luca, an implementation. At a high level of
Australian with a proven track record at abstraction, there is nothing that prohibits
IBM, was hired to rescue the project, an taking FDD ideas outside of software.
endeavor that was foundering with
traditional software engineering methods. FDD is designed to be scalable; indeed the
De Luca’s rescue was a medium scale effort first project in Singapore was large by agile
with a few dozen programmers; it lasted for standards. One of De Luca’s scaling points
more than a year.4 is object ownership by individual
developers. Unlike XP, there is not
De Luca organized the project around his collective ownership of development objects
ideas that became known as FDD. He because collective ownership is not scalable
became acquainted with Peter Coad when he in De Luca’s view.6 And another is the
recruited Coad to assist with object emphasis on up-front modeling of the
modeling on the project. In 1999, De Luca, business story or business domain led by an
Coad, and Eric Lefebvre wrote a widely read architect or experienced modeler.
book, “Java Modeling in Color with UML,”
which, among other ideas, described FDD Domain modeling, as it is called in FDD, is
and gave it a public introduction.5 equivalent to architecture commonly
described in the literature. The model is
De Luca et al assume an OO practice intended to show all the major system
framework for FDD; consequently, much of elements and their interaction. De Luca
the jargon that surrounds FDD is from OO; proposes that there be architecture for each
however, there is nothing so fundamental ‘aspect’ of the system, like the presentation
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 2 of 12](https://image.slidesharecdn.com/wav1featuredrivendesign08092009rev2-120510103855-phpapp02/85/Feature-driven-design-FDD-2-320.jpg)
![methods, attributes, and data are not
identified and defined.
The model is generally relational between
For purposes of simple presentation the business steps and classes: one business step
hierarchy for the model for one aspect is feature can require several classes; one class
shown in the panel below. The step-one may support more than one feature. There
model usually goes no farther than are usually many methods within each class.
identifying business activities and the Indeed, moving the feature identification
classes that will be building blocks for and feature lists to step two in the
features. methodology is one of the process
refinements made since 1999. An example is
Model hierarchy given in Table WP1-1:
Business Domain Subject Areas
Business Activities Business Steps
[features] Classes Methods
Table WP1-1 Model Example
Model Level Example
Business Domain In-bound Sales
Subject Area In-bound Orders
Business Activity Order Processing
Business Step [feature] Calculate Order Total
Class [person, place, or
Order Line
thing in the abstract]
Method [behavior or
calculateLineTotal
action]
Various modeling tools such as text, use do its own model; the model results are
cases diagrams, data models, entity- combined in Delphi fashion to reach a
relationship diagrams, user guides, and high- consensus.
level sequence diagrams are applicable.
Critics of the FDD approach liken this
To develop a model, a Delphi-like approach modeling to a ‘big design up front’, BDUF.
is recommended: led by a chief architect or a However, the domain model is not more
chief modeler, the whole team is assembled than the minimally required architecture
and given an explanation of the business needed to frame all subsequent
story—in effect, a domain walkthrough. development.
Smaller multi-functional, business-
developer teams are formed, and each is to
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 4 of 12](https://image.slidesharecdn.com/wav1featuredrivendesign08092009rev2-120510103855-phpapp02/85/Feature-driven-design-FDD-4-320.jpg)
![like that in SCRUM and as presented in objects, if not many more, this is a lot of
Appendix I. Scorecards keep up with the six scorekeeping! Table WP1-4 gives a
development stages for each object in each summarization of some of the key practices.
two week iteration; these are called ‘parking
lot charts’. Obviously, with hundreds of
Table WP1-4 FDD Practices
Practice Commentary
• Up-front architecture model of the system, its
aspects, and the business activities
Domain Model
• Later refined to include classes and feature [sets of
classes with a business relationship]
• Peer review of models and design to achieve
Walkthrough
understanding and catch logical and functional holes
Inspection • Peer review of developer deliverables
• Developer assignment for design and development of
a class
Class ownership
• Ownership is not changed during the course of the
project
• Set of classes to be developed into features in one
Work package
iteration; assigned to a chief programmer
• Graphical or spreadsheet portrayal of object and
Scorecard
release status
• Teams formed for the duration of an iteration to
Feature Teams
deliver work packages
• Production of work packages every two weeks, or
Frequent release
sooner
• Technique for independent thinkers to arrive at a
Delphi
consensus
Summary and take-away points
• Our theme is that Feature Driven Design is an agile methodology that centers attention on
small scale requirements dubbed ‘features’ that can be rapidly deployed to create customer
value.
• There are five process steps that lead from a top-level model of the business story to the
production deployment of packages of features. There are several key practices that make
FDD work; for the most part, these practices are not new in the software industry. What is
©Copyright 2009 Square Peg Consulting, All rights reserved
www.sqpegconsulting.com
Page 8 of 12](https://image.slidesharecdn.com/wav1featuredrivendesign08092009rev2-120510103855-phpapp02/85/Feature-driven-design-FDD-8-320.jpg)
Feature driven design FDD
- 1. Feature Driven Design A whitepaper by John C Goodpasture, PMP November, 2009 ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 1 of 12
- 2. Feature Driven Design Feature Driven Design is an agile methodology that centers attention on small scale requirements—dubbed ‘features’— that can be rapidly deployed to create customer value. Everyone can't know everything about everything—that is brittle and it can't scale. Jeff De Luca Feature Driven Design, FDD,1 is one of the agile methodologies developed empirically in the late 1990’s. In a word, a feature is a small scale functional need in the general format of <action><object><result>, like “calculate order total”.2 Jeff De Luca is the acknowledged inventor of FDD, although De Luca himself credits others with significant contributions—people like Peter Coad, a well known leader in object oriented [OO] coding, who introduced a prominent practice to the methodology: fine grain object modeling.3 The founding project was a troubled about the recommended methodology steps software implementation at a large bank in that FDD can not be applied outside an OO Singapore in the late 1990’s. De Luca, an implementation. At a high level of Australian with a proven track record at abstraction, there is nothing that prohibits IBM, was hired to rescue the project, an taking FDD ideas outside of software. endeavor that was foundering with traditional software engineering methods. FDD is designed to be scalable; indeed the De Luca’s rescue was a medium scale effort first project in Singapore was large by agile with a few dozen programmers; it lasted for standards. One of De Luca’s scaling points more than a year.4 is object ownership by individual developers. Unlike XP, there is not De Luca organized the project around his collective ownership of development objects ideas that became known as FDD. He because collective ownership is not scalable became acquainted with Peter Coad when he in De Luca’s view.6 And another is the recruited Coad to assist with object emphasis on up-front modeling of the modeling on the project. In 1999, De Luca, business story or business domain led by an Coad, and Eric Lefebvre wrote a widely read architect or experienced modeler. book, “Java Modeling in Color with UML,” which, among other ideas, described FDD Domain modeling, as it is called in FDD, is and gave it a public introduction.5 equivalent to architecture commonly described in the literature. The model is De Luca et al assume an OO practice intended to show all the major system framework for FDD; consequently, much of elements and their interaction. De Luca the jargon that surrounds FDD is from OO; proposes that there be architecture for each however, there is nothing so fundamental ‘aspect’ of the system, like the presentation ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 2 of 12
- 3. layer or tier, application layer, data system, descending order: project, aspects, subject service layers, and so on.7 In some respects, areas, and business activities framed by De Luca’s ‘aspect’ is much like a ‘view’. milestones to give a temporal dimension. What you see depends upon your point of view. The idea that architecture – and a Otherwise, FDD is pretty minimal in its domain model is architecture – should have, prescription, consisting of five process steps, or could have different views is accepted a few key players, a minimum set of doctrine among system architects.8 required responsibilities, a high reliance on model diagrams to capture requirements, The ‘core structure’ of the model is loosely and spreadsheet pipelines and status grids to coupled and hierarchical, as given in visually document project progress. FDD is very pictorial • FDD is intended to be scalable • Although FDD values personal communications over formal documentation, as do all agile methods, documentation is valued for its support for scalability A Project Management Tip • FDD values diagrams for domain models, fine grain object models, and supports a number of project management scorecards on a project dashboard and information portal FDD is defined by its process steps More so than SCRUM, XP, and Crystal, FDD is known for and characterized by its process steps. The original definitions of each step were published in “Java Modeling in Color with UML”. Subsequently, they have been refined with experience; De Luca has documented the updates on his website.9 Within each step is a somewhat unique mix of conventional practices, although each practice has been picked for its effectiveness and reinforcement of the process step. Develop an Overall Model The first process step is perhaps the most to identify the ‘subject areas’ and ‘business controversial and the one that separates FDD activities’ that comprise the business story. from other agile methods: “Develop an De Luca calls this step-one model a ‘model Overall Model”. In this step, the business shape’; it’s more than a framework because story, which is called the business domain in the major object classes and their the FDD literature, is modeled ‘just enough’ interrelationships are defined, but it’s less than a complete model because all the class ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 3 of 12
- 4. methods, attributes, and data are not identified and defined. The model is generally relational between For purposes of simple presentation the business steps and classes: one business step hierarchy for the model for one aspect is feature can require several classes; one class shown in the panel below. The step-one may support more than one feature. There model usually goes no farther than are usually many methods within each class. identifying business activities and the Indeed, moving the feature identification classes that will be building blocks for and feature lists to step two in the features. methodology is one of the process refinements made since 1999. An example is Model hierarchy given in Table WP1-1: Business Domain Subject Areas Business Activities Business Steps [features] Classes Methods Table WP1-1 Model Example Model Level Example Business Domain In-bound Sales Subject Area In-bound Orders Business Activity Order Processing Business Step [feature] Calculate Order Total Class [person, place, or Order Line thing in the abstract] Method [behavior or calculateLineTotal action] Various modeling tools such as text, use do its own model; the model results are cases diagrams, data models, entity- combined in Delphi fashion to reach a relationship diagrams, user guides, and high- consensus. level sequence diagrams are applicable. Critics of the FDD approach liken this To develop a model, a Delphi-like approach modeling to a ‘big design up front’, BDUF. is recommended: led by a chief architect or a However, the domain model is not more chief modeler, the whole team is assembled than the minimally required architecture and given an explanation of the business needed to frame all subsequent story—in effect, a domain walkthrough. development. Smaller multi-functional, business- developer teams are formed, and each is to ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 4 of 12
- 5. Build a Features List The chief programmer, CP, a prominent player in FDD, leads process step 2. In this step, all the fine grain business steps – that is, features – are identified. No prioritization is made of features; there are too many: typically hundreds, perhaps thousands, so no prioritization scheme is meaningful. Table WP1-2 illustrates the FDD feature compared to the use case and user story: Table WP1-2 Feature Comparison Fixture Commentary Specifies actors, initial conditions, triggers, actions, extended Use Case actions, included actions, and results. Actor <name> acting in role <role label> according to action <action verb> with attributes <skills, security, time of day, etc> User Story has expectation <result of action> because <motivation for action, or reason for storyline, or dependencies or triggers> FDD Feature <action><object><result> Plan by Feature Planning is done for release milestones. Features are assembled into release packages according to a number of business criteria. The project manager is a key player in the planning, along with the chief programmer. Rolling wave planning is applicable. In one class. Collective ownership, an XP building the release schedule, features must practice, is not allowed because it limits be sequenced; consideration for customer scale. importance and urgency, impact on the benefit stream, impact on market Planning is not time-boxed! Features are competitiveness, and other business factors, intended to be developed in less than two as well as technical sequencing go into the weeks duration, however, there is no rigidity planning. In this step, important ownership around the two week goal—the duration assignments are made that enable scale. could be much shorter or a little bit longer, First, business activities are assigned to but not much longer or else the feature chief programmers as the responsible requires more decomposition. Feature manager for required development. Second, development duration is further dissected each class is assigned to a developer as its into six sequential development tasks, owner. Class ownership does not change beginning with a feature walk-though and over time; a developer may own more than ending with a promotion to production.10 ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 5 of 12
- 6. Design by Feature: Borrowing the script from the WBS, features are assembled into work packages led by the CP. Generally, a work package is the smallest unit identified on a WBS. A Features Breakdown Structure—FDD’s consisting of the CP and class owners, with name for the WBS—is built up from all the business user subject matter experts as work package content. Care is taken to not required. In a stark departure from other split classes between work packages that are agile methods, feature teams are situational: simultaneously in development since that they are formed from class owners just in would split developers between chief time, and then adjourned when the feature is programmers. production ready. New teams are formed dynamically around each feature. Feature teams are formed with responsibility to own the features—that is, As a construction step, actual design begins to speak for the required functionality, in this step. The object model and sequence interpret business needs, and develop the diagrams are refined, and all the object feature into a product unit. The feature methods are defined, as well as attributes teams are multi-functional primarily and data requirements. Build by Feature: This process step is the second construction inspection. Integration testing of multiple step; in this step the objects are coded, objects to prove and verify feature tested, and put into production. In another performance is planned by the chief departure with other agile methods, and programmer and the developer. especially XP, code inspections by person- to-person walk-through are more valued Pair programming is not promoted, but not than unit tests. That is, even though an prohibited. The material in Table WP1-3 object has passed a unit test it is not sums up the process discussion. promoted to production until it passes a code Table WP1-3 Process Summary FDD Process Step Commentary Develop an Overall • Equivalent to architecture; identify the essential elements Model of the system and their interrelationships • Identify the business steps with business activities; features are functional and customer-valued. Build a Features List • Features are typically designed and built in less than 2 weeks • Organize sets of features into release packages according Plan by Features to technical sequencing constraints and customer priority ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 6 of 12
- 7. Table WP1-3 Process Summary FDD Process Step Commentary • Assign ownership responsibilities • Organize feature sets into work packages and assign work packages to chief programmers who are the team Design by Feature leads for feature development teams • Add detail and richness to the fine grain object model • Code, test, and inspect the product Build by Feature • Release product to production FDD is scalable • Documentation is valued for scalability • Class ownership is favored over collective ownership A Project Management Tip • The two construction processes are amenable to fixed price work order contracting • Rigid time-boxes are not imposed on the contractor FDD relies on key practices In the discussion so far, we’ve spoken to several of the key practices in FDD: domain modeling— what we call architecture—fine grain object modeling, development by feature, and class ownership. Other practices are code inspections, sooner, recovering not only investment but walkthroughs at every level from domain also adding value to the business. model to class methods, and dynamic feature teams. Although not regulated by Of importance to the project manager are the time-boxes, FDD does promote frequent, scorecards recommended by De Luca and responsive product delivery, sequenced his disciples. At a high level, each process according to customer priority, and put into step is gated by the so-called ETVX— production as determined by business Entry, Task, Verify, and Exit—set of sub- preparation. Like all agile methods, processes that are scored for completion. frequent delivery starts the benefit stream There is, of course, a burn-down chart much ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 7 of 12
- 8. like that in SCRUM and as presented in objects, if not many more, this is a lot of Appendix I. Scorecards keep up with the six scorekeeping! Table WP1-4 gives a development stages for each object in each summarization of some of the key practices. two week iteration; these are called ‘parking lot charts’. Obviously, with hundreds of Table WP1-4 FDD Practices Practice Commentary • Up-front architecture model of the system, its aspects, and the business activities Domain Model • Later refined to include classes and feature [sets of classes with a business relationship] • Peer review of models and design to achieve Walkthrough understanding and catch logical and functional holes Inspection • Peer review of developer deliverables • Developer assignment for design and development of a class Class ownership • Ownership is not changed during the course of the project • Set of classes to be developed into features in one Work package iteration; assigned to a chief programmer • Graphical or spreadsheet portrayal of object and Scorecard release status • Teams formed for the duration of an iteration to Feature Teams deliver work packages • Production of work packages every two weeks, or Frequent release sooner • Technique for independent thinkers to arrive at a Delphi consensus Summary and take-away points • Our theme is that Feature Driven Design is an agile methodology that centers attention on small scale requirements dubbed ‘features’ that can be rapidly deployed to create customer value. • There are five process steps that lead from a top-level model of the business story to the production deployment of packages of features. There are several key practices that make FDD work; for the most part, these practices are not new in the software industry. What is ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 8 of 12
- 9. unique is how the practices are used to support each of the five processes. • However, several practices common to other agile methods are missing: time-boxing, pair programming, collective object ownership, and user stories to name the most visible. • FDD is designed to be a scalable methodology although its focus on snips of functionality — that is to say, features—challenges cohesiveness in the larger picture. Documentation sufficient to support architecture and planning is valued for its support for scale. • Overall, FDD is a respected member of the agile family of methodologies with a track record extending back to the late 1990’s. ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 9 of 12
- 10. Endnotes 1 Feature Driven Development, FDD, FDDI, and the FDD logo, are trademarks of Nebulon Pty. Ltd. FDDI is FDD Interchange, a library of tools and specifications 2 See Palmer, S. and Felsing, J. “A Practical Guide to Feature Driven Design” Prentice-Hall, Upper Saddle River, NJ, 2002, pg 46. De Luca actually defines two feature formats: one identical to Palmer’s definition and one that is slightly more complex: <action> the <result> <by|for|of|to> a(n) <object> as given in “Feature Driven Development Overview”, Nebulon.com, 2005, http://nebulon.com/articles/fdd/fddoverpres.html, retrieved August 2009 3 Interview with Jeff De Luca: Roock, S. “Jeff De Luca on Feature Driven Development” http://www.it- agile.com/fileadmin/docs/FDD-Interview_en_final.pdf, April 2007, retrieved August 2009 Other contributors: Stephen Palmer, editor of the COAD Letter, M. A. Rajashima who inspired the ETVX – entry, task, verify, exit – gates of the process steps, and Lim Bak Wee, Paul Szego, and Jon Kern. See: http://www.informit.com/articles/article.aspx?p=26055&seqNum=7, retrieved August 2009 4 See a short history in Jim Highsmith’s article in Crosstalk: Highsmith, J. “What is Agile Development?” Crosstalk, the Journal of Defense Software Engineering, October, 2002, http://www.stsc.hill.af.mil/crosstalk/2002/10/highsmith.html, retrieved August, 2009 5 De Luca, J., Coad, P., and Lefebvre, E. “Java Modeling in Color with UML – Enterprise Components and Process” Prentice-Hall, Upper Saddle River, NJ, 1999, Chapter 6 6 Interview with Jeff De Luca: Roock, S. “Jeff De Luca on Feature Driven Development” http://www.it- agile.com/fileadmin/docs/FDD-Interview_en_final.pdf, April 2007, retrieved August 2009 7 Editor, “FDD Interchange Specification 20060119”, Nebulon Pty, Ltd, January 19, 2006 8 See IEEE 1471:2000 “IEEE Recommended Practice for Architectural Description of Software- Intensive Systems” IEEE, March 2006, Chapter 5.4 Also known as ISO/IEC 42010:2007, “Recommended Practice for Architectural Description of Software-Intensive Systems” July 2007. 9 The latest FDD processes are documented at http://nebulon.com/articles/fdd/latestfdd.html, retrieved August, 2009 ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 10 of 12
- 11. 10 See “Feature Driven Development Overview”, Nebulon.com, 2005, pg 13, http://nebulon.com/articles/fdd/fddoverpres.html, retrieved August 2009 ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 11 of 12
- 12. About the author John C. Goodpasture, PMP and managing principal at Square Peg Consulting, is a program manager, coach, author, and project consultant specializing in technology projects, strategic planning, project office operations. He is the author of books, articles, and web logs in the field of project management. He blogs at johngoodpasture.com, provides presentations at www.slideshare.com/jgoodpas, and his work products are found in the library at www. sqpegconsulting.com. ©Copyright 2009 Square Peg Consulting, All rights reserved www.sqpegconsulting.com Page 12 of 12