FEATURE DRIVEN

DEVELOPMENT
METHODOLOGY
LEADER: MIKEE O. SECRETARIA
MEMBERS: JULIA E. BAYBAY
: JASMINE T. RIVERA
: MELANIE V. LAROYA
: CECIL C. EMPERADOR
 DESCRIPTION OF FEATURE DRIVEN
DEVELOPMENT (FDD) METHODOLOGY

•Feature Driven Development (FDD) is a customer

centric software development methodology known for
short iteration and frequent releases. Like Scrum, FDD
requires the customer, also known as the project business
owner. By releasing new features in an incremental
fashion, developers are able to prioritize client requests,
respond to requests on time and keep clients satisfied.
 DESCRIPTION OF FEATURE DRIVEN
DEVELOPMENT (FDD) METHODOLOGY

•Jeff De Luca and Peter Coad are

credited with developing the concept of
FDD as they worked on a product for a
Singapore bank in 1997.
DIAGRAM/MODEL OF THE
METHODOLOGY
PHASES OF THE METHODOLOGY
DEFINITION & OUTPUTS

• Phase 1: Develop an Initial Model

•Each define a model that reflects their
shared understanding of the important
objects in the new system.
PHASES OF THE METHODOLOGY
DEFINITION & OUTPUTS
•Phase 2: Develop a Feature List
•Remember that in FDD feature are
similar to user stories so think about the
development activities which will need
to happen to bring your product or
software to life.
PHASES OF THE METHODOLOGY
DEFINITION & OUTPUTS
•Phase 3: Plan by feature
•The planning phase is essential in FDD.
Here, teams should allocate reasonable
estimates to each feature, assign them to a
team member and work out what needs to
happen for these deadlines to be met.
PHASES OF THE METHODOLOGY
DEFINITION & OUTPUTS
•Phase 4: Design by Feature
• Developers and domain experts, helped by
the chief architect and chief programmer as
needed, use modeling techniques such as
class diagrams, sequence diagrams, and state
transition diagrams to specify what the
feature will do and how it’ll do it.
PHASES OF THE METHODOLOGY
DEFINITION & OUTPUTS
•Phase 5: Build by Feature
•Again, team members should work on their
individual build responsibilities at the same
time on visual designers on the UI,
programmers on coded components, etc.
 PROS & CONS
• PROS
• Gives the team a very good understanding of the
project’s scope and context.
• Requires fewer meetings.
• Uses a user-centric approach.
• Works well with large-scale, long-term, or
ongoing projects.
 PROS & CONS
• PROS
• Breaks feature sets into smaller chunks and
regular iterative releases, which makes it easier to
track and fix coding errors.
 PROS & CONS
• CONS
• FDD is not ideal on smaller projects.
• Does not work for projects where there is only one developer
because it is hard for one or very few people to take on the
various roles without help.
• Places a high dependency on a chief programmer.
• Emphasizes individual code ownership instead of a shared
team ownership.
 CONCLUSION
•1. FDD is more adaptable to change compared
to some other software development models.
•2. In FDD, teams are created according to the
needs of the next feature that will be
developed.
•3. FDD is both architecture-centric and agile.
THANK
YOU!