Feature Driven Development

Presented by

Gayal G.S. MS14904356

Ruhaim Izmeth MS14901218

I.D.I.P.KUMARA MS13904142
 Agenda

•Background
•Roles in FDD
•FDD Practices
•FDD Processes
•Project Reporting
•Advantages and Disadvantages
•Conclusion & Summery
•Q/A
 Introduction

Feature Driven Development (FDD) is one of the Agile

Software Development Methodologies.

Came into view in last 15 years as an alternative to traditional

Waterfall development.
 Birth of FDD

Jeff De Luca
Published in a book
in 1999,

Introduced in 1997

Peter Coad

by
Peter Coad
 Why do we have to use FDD ?
1. Communication
Consider developers as nodes in a communication network, all potentially linked to each other by
communication channels. The number of potential communication channels increase dramatically as
more number of developers are added

2. Complexity
FDD decomposes the entire problem domain into tiny problems, which can be solved in a small
period of time, usually 2 weeks decomposed problems independent to each other reduces the
need of communication.
FDD splits the project into iterations so that the distance in time between analysis and test is
reduced early discovery of errors reduces the cost of fixing the errors.

3. Quality
Different persons have different perception of software quality
This makes necessary to view quality as a spectrum, with internal quality at one end and external
quality at other end.
 Roles in FDD
Key Roles
1. Project Manager (PM)

2. Chief Architect (CA)

3. Development Manager (DM)

Supporting Roles
4. Chief Programmers 1. Release Manager

5. Class Owners 2. Language Guru

3. Build Engineer
6. Domain Experts Additional Roles
4. Toolsmith
1. Testers

5. System Administrator 2. Deployers

3. Technical Writer
 FDD - Practices
Domain Object Modeling

The Problem is broken down into the significant objects involved.

The design and implementation of each object or

class identified in the model is a smaller problem to solve.

Completed classes are combined,

Form the solution to the larger problem

Best technique for domain object modeling is,

Modeling In Color
 FDD - Practices
UML in Color
All classes are divided into different categories with its own color code.

a role being played.

by a person or an organization, example: a user of an online auction may play different roles as a
buyer or seller.

a catalogue like description.

example: a description of smart phones that sells in auction.

a party, place or thing.

example: the smart phones in stock would be modeled as green. This class usually has some
identifying attributes such as serial no, persons name, etc.

a moment in time or time associated with some business process.

example: the fact of purchase may be shown a pink class, since it has a time of sale which is
tracked by the online store,
 FDD - Practices
UML in Color
All classes are divided into different categories with its own color code.

a role being played.

a catalogue like description.

a party, place or thing.

a moment in time or
time associated with
some business process.
 FDD - Practices
What is a Feature ?
A feature is a small, client valued function that can be implemented in two weeks
Any function that is too complex to be implemented within two weeks is further decomposed into smaller
functions until each sub-problem is small enough to be called a feature.

Major Feature Feature set Feature

 FDD - Practices
Developing by Feature

The feature naming template

<action> the <result> <by | for | of | to><a(n)><object>

Example of features:

Calculate <action> the total <result> of a sale <object>

Calculate the total of a sale

 FDD - Practices
Class (code) Ownership
In a development process, class (code) ownership is indicates who is
ultimately responsible for the content of a class (piece of code).

Feature Team
Implementation of a feature may involve more than one class and more than
one class owner
 Processes
FDD consist five processes

Process
 Processes

Entry Criteria
Domain experts, Chief Programmers and the Chief
Architect have been selected.

Exit Criteria
● Class diagrams focusing on model shape. That
is, what classes are in the domain, how are they
connected to one another and under what
constraints.
● Methods and attributes identified are placed in
the classes.
● Sequence Diagram(s), if any.
● Model notes to capture why a particular model
shape was chosen and/or what alternatives were
considered
 Processes

● A team consist of Chief Programmers from process 1

are formed to decompose the domain functionality.
● The team breaks the domain into a number of areas
(major feature Sets), based on the partitioning of the
domain by the Domain Experts in process 1
● Each area is further broken into a number of
activities (feature sets).
● Each step within an activity is identified as a feature.

Exit Criteria
● A list of subject areas
● For each subject area, a list of the
business activities within that subject
area
● For each business activity step, the
feature to satisfy the step
 Processes

The project Manager, Development Manager, and Chief Programmers plan the order that the features are to
be implemented, based on feature dependencies, load across the development team, and the complexity of
the features to be implemented.

Exit Criteria
● Business activities with
completion dates (month and
year)
● Chief programmers assigned
to business activities
● Subject areas with
completion dates (month and
year) derived from the last
completion date of their
respective business activities
● The list of classes and the
developers that own them
(the class owner list)
 Processes

Feature Team

Exit Criteria
● A covering memo, or paper, that integrates
and describes the design package such that
it stands on its own for reviewers.
● The referenced requirements (if any) in the
form of documents and all related
confirmation memos and supporting
documentation.
● The Sequence diagram(s).
● Design alternatives (if any)
● The object model with new/updated classes,
methods and attributes.
 Processes

Class owners implement the items necessary for their class

to support the design for the feature(s) in the work package,
based on the design package produced during the Design
by Feature process.
The developed code which is determined by the Chief
Programmer is tested and inspected.
After a successful code inspection, the code is permitted to
build.

Exit Criteria
● Class(es) and/or method(s) that have been
successfully code inspected.
● Class(es) that have been promoted to the build.
● The completion of a client-valued function (feature)
 Processes
Guidelines for time spent in each process

Process
 Progress

Reporting to Chief programmers and Project Manager

Major Feature Set – “Workshop Management Area”

Feature Set No of features No of No of No of %

Not started In progress Completed completed
 Progress

Reporting to Chief programmers and Project Manager

Every week, the rate of progress is shown by plotting a graph for the number of features completed each
week
 Progress

Reporting to Sponsors and Upper Management

Progress of the feature set “Scheduling a Service”

Work in progress

Attention (behind Schedule) Scheduling a Feature Set Name

Service
Completed No of Features in the
(19) Features Set
Not yet started

Completion Percentage 27%

Progress bar Feature set name
- Scheduling a service

Completion Status DEC 2012 Features are consist – 19

Completed
Currently complete – 27%

MY Targeted completion month Due date – Dec 2012

 Progress

Reporting to Sponsors and Upper Management

Feature Set No of features No of No of No of % completed

Not started In progress Completed

Progress of the feature sets

Scheduling Performing Billing a Booking in

a Service a Service Service a Repair

(19) (15) (6) (13)

27.7% 30.1% 16.6% 75%

DEC 2012 DEC 2012 DEC 2012 DEC 2012

 Progress

Reporting to Sponsors and Upper Management

Major feature set
 Major Usage of FDD

FDD can be implemented with

Up to 500 developers

More critical projects

Bigger projects

More novice developers

Environments that demand Waterfall

 Advantages and Disadvantages of FDD

Advantages

Supports multiple teams working in parallel

All aspects of a project tracked by a feature

Design by feature and build by a feature aspects are easy to understand and adopt

Scales to large teams or projects well

Better in teams where developers’ experiences varies

Offers well defined progress tracking and reporting capabilities

 Advantages and Disadvantages of FDD

Disadvantages

Promotes individual code ownership as opposed to shared/team ownership

Iterations are not well defined by the process as other agile methodologies

The model-centric aspects can have huge impacts when working on existing
systems that have no models.
 Summary and Conclusion

FDD is a process that begins with high level planning to define the scope of the project,
which then moves into incremental delivery.

FDD defines the overall scope of the project at the beginning, but does not define
the details.

FDD tries to combine good planning with the continuous improvement through
iteration.

There are five phases in an FDD process; the first three phases are planning phases
and the last two phases are iterative phases

Main Advantages: Easy to understand the feature based process, Scalability

Main Disadvantages: Promotes individualism, Undefined iterations, Potential Model-

Centric failures
 References & Links

Weinberg, G. Quality Software Management vols. NJ:Prentice Hall PTR, 2002.

Coad, Peter, et al. Java modeling in Color with UML.Upper Saddle River, NJ:Prentice Hall PTR, 1999.

Stephen R. Palmer, 2002. A Practical Guide to Feature-Driven Development. 1 Edition. Prentice Hall.

Sadhna Goyal. “Agile Techniques for Project Management and Software Engineering”, Major Seminar on
Feature Driven Development, Technical University-Munich, 2007-2008.

Internet links,
http://www.nebulon.com

http://www.petercoad.com

http://www.featuredrivendevelopment.com

http://www.featuredrivendevelopment.com/certification/list

http://en.wikipedia.org/wiki/Feature_Driven_Development
Q&A