Submitted By: Hafiza Areeba Khalid

Submitted To: Sir Shahab Siddiqui

Submitted On: 30th Aug, 2019

Assignment: 01

Agile Method: Feature-driven development (FDD)

FDD was initially devised by Jeff De Luca to meet the specific needs of a 15-month, 50-person
software development project at a large Singapore bank in 1997. This resulted in a set of five
processes that covered the development of an overall model and the listing, planning, design, and
building of features. The first process is heavily influenced by Peter Coad's approach to object
modelling. The second process incorporates Coad's ideas of using a feature list to manage
functional requirements and development tasks. The other processes are a result of Jeff De
Luca's experience. There have been several implementations of FDD since its successful use on
the Singapore project.

Overview:
FDD is a model-driven short-iteration process that consists of five basic activities. For accurate
state reporting and keeping track of the software development project, milestones that mark the
progress made on each feature are defined.

Definition:
Feature-driven development (FDD) is an iterative and incremental software development
process. It is a lightweight or agile method for developing software. FDD blends a number of
industry-recognized best practices into a cohesive whole. These practices are driven from a
client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working
software repeatedly in a timely manner in accordance with the Principles behind the Agile
Manifesto.

FDD - Agile:
FDD is an agile methodology. Businesses these days don’t want to wait a long time for results.
The crux of this methodology depends on iteration cycle of two weeks. The features are built
within 1-12 days. Any feature that requires longer build time than this is further broken down till
it meets the two weeks rule.

FDD – An Inclusive Methodology

It is a simple but comprehensive methodology. It is very easy for organizations to adopt. All the
stake holders get involved from the beginning of the project right from the time the feature list is
made. There is no scope of any unpleasant surprises for anyone. All the way through the
software development lifecycle through FDD there are reporting mechanisms which keep
everyone in the loop. Iterative designs involve everyone. Everyone works towards the same set
of goals.

Methodologies Used by FDD:

FDD incorporates the best of different agile methodologies like Extreme Programming and
Scrum. It uses model-centric techniques including Domain-Driven Design by Eric Evan and
modelling in color by Peter Coad.
Domain Driven Design focuses on core domain and domain logic. Complex designs are based on
the model of the domain. One needs to constantly collaborate with the domain expert to improve
application model and resolve domain related issues.
There are UML color standards – a set of four colors associated with Unified Modelling
Language (UML) diagrams. The colors indicate the archetypes applied to the UML object. UML
reporting component captures feature progress during FDD. The use of color enables quick
understanding of the problem domain’s dynamics.

Processes of FDD:
1st Process: Developing an overall model
In this process, FDD pushes teams to build an object model of the domain problem. Differing
from others, FDD modelling is a cross-functional, iterative & collaborative activity. The team
members (development, domain experts & chief programmers) work together to compose a
model for the domain area and are guided by a Chief Architect. The idea is to have different
teams proposing different models and later on, after getting reviewed, choose an option, or mixes
them up. Finally, the domain area model will be merged into the overall model. It’s actually a
great way to start the project as it enables the team to get a strong understanding of the project as
well as a solid communication.

2nd Process: Building the feature list

Here, you could compare the features list to the product backlog in scrum, and the feature would
be some sort of user story. After having the overall model ready, based on the knowledge got
during that phase, we will have to identify the features which are valuable to the client and which
will basically guide the project. Features shouldn’t take longer than two weeks to be completed,
and if they do, then it should be put into more than one feature. They are usually expressed as an
action, result & object.
3rd Process: Planning by feature
In the third phase, as its name says it, it is more or less about planning in which order the features
will be implemented, it’s about organizing. Feature sets are then assigned to
programmers. Obviously while planning we take into consideration different aspects such as
risks, complexity dependencies, team workload, etc.

4th Process: Designing by feature

As during all the processes, we use the knowledge we got from the first modelling process. The
chief programmer takes responsibility to select a group of features that should be developed next.
He will also have to determine the domain classes that will be involved. After the feature team is
formed, they all start working together in order to get the job done, where the domain expert will
be in charge of analyzing & designing a solution to each feature.
5th Process: Building by feature
Once the domain expert is done and based on the work done in the design by feature process, the
class owners will have to implement all the items that are necessary to be able to support the
design. Therefore, we work on the code that has been developed and with unit test it and inspect
it to ensure that it is all correct and approved by the chief programmer that will then give the ok
to start building.

Features of FDD:
 FDD is excellent for big projects and is actually quite scalable and prone to get achieve
success.
 FDD is very effective in helping with complex projects that are in a critical situation.
 The 5 processes help when it comes to getting new members to join the team, especially in
short periods of time.
 Feature Driven Development is built around best practices that are recognized by the industry
and it considers the strengths and weaknesses of developers.
 The fact that with FDD you do regular builds ensures that the system is always up to date and
it can be shown to the client. You can easily identify errors in the source code of the features.

 All along the processes you have a high visibility of progress and results due to the fact that
there are frequent progress reporting that are made at all the levels of the project