Feature Driven Development
Jonathan Grommes
Software Engineering
University of Wisconsin-Platteville
[email protected]
Abstract
Feature driven development is an agile software process that is highly iterative, calls great
attention to quality, delivers repeated working products to the customer, and is liked by all main
participants in the process (i.e. customer, programmers, managers). Feature driven development
has strong ties to high visible reporting, which allows developers to see lots of project related
information quickly such as progress reporting. Feature driven development has five
collaborating framework activities that are driven by the customer-valued features. The first
three processes in feature driven development are done once and are intended for setting up the
majority of the entire project. The last two remaining processes are iterated over and over again,
building up the project feature by feature until the project is completed.
What is Feature Driven Development?
Feature Driven Development is an incremental and iterative software process that was created to
deliver frequent, working deployable code repeatedly to the customer. Feature Driven
Development can be considered a simple, straight forward approach to developing software
systems. With Feature Driven Development, programmers are provided correct information
from domain experts and communicate with team leaders. Since the team leaders have an
accurate status on their team they can follow their teams better and keep an accurate track on the
team that will help reduce risk. The user/customer will be satisfied that they will be receiving
the correct system that they ordered, because if a feature is incorrect the customer can give
feedback quickly to fix the error [1].
How Feature Driven Development was created
Feature Driven Development was created and first used by Jeff De Luca who was in need of 50
people for a 15 month project in 1997. Then Luca used the process again for another 18 month,
250 person project. After the completion of both projects Luca had created a five step process
that encapsulated the model that he used [3].
2
The first two steps in Feature Driven Development are heavily influenced by Peter Coad and his
idea of using a feature list to mange requirements and create an outline for development tasks.
Even though feature driven development was first used back in 1997 by Luca, it wasn’t fully
described or documented until 1999 when Luca, Coad and Eric Lefebvre wrote a book which
was entitled “Java Modeling in Color with UML.” They created it for a practical approach to
model object-oriented software. Stephen Palmer and John Felsing have extended Coad’s work
by writing the book “A Practical Guide to Feature Driven Development” where they explain the
feature driven development process and how it is capable of being applied to large sized software
projects [3].
Defining a Feature
A feature is a “customer-valued function that can be implemented in two weeks or less,”
according to COA99(Peter Coad and his colleagues). The features should be small, typically
taking one to three days to develop. Five days is acceptable, but a feature should never take more
than ten days to create. If a feature takes more than ten days to create, it should be broken down
into smaller features.
Benefits of Features
Since features are small the customer can describe in detail exactly what is desired, therefore the
user in turn gets the correct system they we requesting. Since the features are small, the design
and code are easier to inspect. Project planning and tracking are done by each feature, rather
than being tracked by a task set. Since feature driven development is incremental and new
features should be implemented every two weeks, the team quickly building up a system with
new features added to the system bi-weekly. Once all of the features are gathered, the team can
group them into related features lists, and begin working on the related features together [2].
Constructing a Feature
COA99 also created a template for defining a feature. The template is stated as <action> the
<result> <by | for | of | to> a(n) <object>. Action means that something will be done or
performed. Result is the item on which that the action will be performed. Finally object is a
person, place or thing. An example of using this template would be: add the student to the class
list. After gathering all of the requirements it is useful to group similar requirements together,
for ease of tracking and developing. Since the requirements are created with the template,
grouping them into categories is simple by using the <action><-ing> a(n) <object>. Adding
students to the class list would be covered in the category of creating a class list. Finally to
group major feature sets, COA99 uses the template <object> management, and example of this
grouping would be class list management [2].
Feature Driven Development Roles
3
As in all software processes, the system cannot be created unless people are there to develop it.
There are many roles that can be introduced into Feature driven development, but there are six
critical roles that are required by any feature driven development project. Without these roles the
project could be in jeopardy of failing. When filling these six main roles, one must ensure that
the employee being assigned to each role is the correct fit for that role to ensure maximum
efficiency from the team.
Project Manager:
This role is the main lead for the project. The Project Manager is responsible for progress
reports, budget management, and maintaining resources. The Project Manager’s job is to
construct and upkeep an environment that allows the team to work proficiently [1].
Chief Architect:
This role is responsible for the creation of the overall design of the system. The chief architect is
a technical role that can resolve disputes over any design issues. This role is also responsible for
setting up design sessions were the team can collaborate on the design of the system [1].
Chief Programmers:
This role consists of experienced developers that have been through the software lifecycle
several times. Chief programmers participate in high level analysis and design of creating the
whole system. Chief programmers are also usually in charge of teams of 6 down to 3 in size [1].
Development Manager:
This role is for running the day-to-day activities. Development managers resolve day-to-day
conflicts that the Chief Programmers cannot do themselves [1].
Class Owners:
This role is for developing, testing, and writing documents that make up a software system.
There are groups of three to six people in a single class owner group that works under a chief
programmer [1].
Domain Experts:
This role is filled by the customer, the sponsor of the project. Domain experts use their
knowledge expertise to help the class owners develop the correct system that the customer is
looking for [1].
Feature Driven Development Reporting
High visible reporting is also another powerful concept of feature driven development. It allows
for project stakeholders to view information without having to look through lots of data. Some
default reporting charts for feature driven development are the Milestone charts and parking lot
reports listed below. It gives a percentage on how close the feature is to being completed based
on the number of milestones it has passed. An example would be if a feature is at the coding
stage, then you would find that the feature is 44% complete by (Domain Walkthrough 1%,
Design 40%, Design Inspection 3 %.) [6]
4
Domain
Walkthrough
1%
Design
40%
Table 1:
Design
Code
Inspection
3%
45%
Code
Inspection
10%
Promote to
Build
1%
Another reporting tool that is used in feature driven development is a Parking Lot Report. This
type of chart quickly shows all of the feature activity in one place. For each activity, there would
be something similar to Figure 1 below. It would display all of the project’s feature activities in
one spot showing the progress of each. As an example, Figure 1 is an activity that deals with
Comply with credit policy features. Since it is still in progress the main area is light blue with a
progress bar toward the bottom of the parking spot. The benefit of a parking lot report is the
ability of having a spot for each feature area all in one place. This is extremely helpful for people
to see where the project is very quickly. Example: If a lot of the spots are red then the project is
behind, but if most of the spots are full green that means most of the activities have been
completed and the project is coming to a close. Finally, if the tile is light blue it means it is
under construction and the progress bar beneath shows how far the area is from being completed
[6].
Figure 1: Example of a Parking Lot Report
The Process
For feature driven development there are five major processes for every project. The five
processes can be split up into two different phases: upfront design phase, and the construction
phase. The upfront design phase consists of the first three processes of feature driven
development and is only done once and is where the outline of the project is established. Then
the construction phase is where the software is actually being designed and implemented.
Figure 2 (below) shows the whole process in a nut shell, where the down arrows coming out of
each process represent what is produced from that particular process. As described before, only
the last two processes in feature driven development are iterated repeatedly until the project is
complete.
5
Figure 2: Demonstrates the Feature Driven Development process
Time Estimation
When planning a feature driven development Jeff Luca’s approximate rule for the time taken to
model compared to the rest of the process is about 10% [4]. For example if it takes two weeks to
develop the overall model, then the project will be expected to take around 20 weeks to
complete.
Develop an Overall Model: Process #1
The first step in any Feature Driven Development project is to create an overall object model.
The object model for the project is a class diagram that covers the whole project and all of its
classes. The object model provides an overall framework which adds functionality to the project,
feature by feature.
The first step to do in the first process of feature driven development is to create a feature
modeling team and start the domain walk-through. The domain walk-through is finding out what
the domain experts know about the subject and what the customer is looking for in the system
that is going to be created. It is also important to manage scope and expectation of the project in
this step. It is not uncommon for the customer to have a misunderstanding of what the length
and cost of the project will be and they may not understand that a simple feature to add can be
extremely time consuming to implement. [5]
Building the object model should include both domain experts and class owners under the
guidance of the chief architect. By having both the domain and development members designing
the system allows for a firm, shared understanding of the problem. In doing so, the team will
learn to communicate better by starting to establish a shared vocabulary. The goal for this step is
to generate high level documents, where the details of the documents will be filled in overtime as
the project continues. [4]
The model that is generated should only have the major classes and only the classes most
important responsibilities. The model should also state the relationships of the major classes to
6
one another. Another document that is generated from this step is a high-level sequence diagram
demonstrating the models ability to support some complex functional requirements. A final
document that is generated from this process is a list of notes explaining and supporting the
object model as well as all of the alternative designs that were rejected. [1]
Build a Feature List: Process #2
The goal here is to identify all the features needed to cover all the requirements. Feature Driven
Development breaks up the features into a three level hierarchy called a feature list. Generally
the chief programmers from the first process decompose the project functionality.
Based on the categorizing from the domain experts in the first process, the team continues to
break up the requirements into hierarchies. The first hierarchy level is composed of areas or
major feature sets. Once broken down into areas, the second step is to break the feature list
down one last time into activities. Finally, the team creates a list of features for each activity,
leaving the smallest item as the features. It has been found in larger projects, the more
organization in the feature list, the better the project does [1].
After creating the entire feature list the team inspects the list for any errors. This helps by
increasing the quality and reducing the number of errors that are found in the feature list. As it is
needed, the feature list can also be reviewed by the Domain Experts or the customer for
clarification of issues that have been found in the features list.
Plan by Feature: Process #3
The third and last process that will be executed just once will create the initial schedule and
assign responsibilities. The project manager, development manager, and chief programmers
from the feature planning team will start to plan the sequence in which the feature sets will be
implemented. They look at feature based dependencies, load across the development team, and
the complexity of the feature being implemented to determine the schedule [3].
After looking at the data described above, the planning team has to break up and distribute all of
the work. They have to start to create a development sequence which states which feature will
be implemented by a certain date. The planning team also has to assign certain areas (feature
sets) to the chief programmers. After chief programmers get their classes, they have to distribute
the classes to the developers. Once everyone has been given their assignments, the planning
team makes a self assessment to ensure the plan’s validity [3].
Class Owners
Class owners are also assigned in this step. This assigns individuals or small teams to develop
and support particular classes. Although feature driven development is similar to most agile
methods, class ownership is a place where the two differ. With class ownership there are several
benefits that happen; First, the class owner has pride in something that he or she has done,
7
therefore making the class less prone to errors. A second benefit of class ownership is that there
is an expert on the class familiar with how it works, therefore they can answer any questions
about the class and implement changes faster that someone that is not familiar to the class. Since
there is a single owner to the class, the class owner will verify that the class integrity and design
are not compromised when there are changes to a project.
Design by Feature: Process #4
Now after doing the first three steps is where feature driven development gets iterative. The chief
programmer now has a small development team of three to six people called a feature team. The
chief programmer selects the features that were assigned to him and creates a feature team area.
The feature team area is a place for the feature team to work in and share progress. The feature
area can be on a server or a directory in a configuration management system. Also, the feature
team area is only for the feature team to share information and not the rest of the project.[3]
Forming Feature teams
Feature teams are created and destroyed with every iteration in the process. To form the feature
teams the chief programmers look at the feature they have responsibility for and then look at
what classes they will probably need, then form feature teams based on the owners of the classes
that the feature needs. Sometimes class owners will find that they will be in multiple feature
teams at the same time. If class owners are in multiple feature teams, they have to coordinate
with multiple chief programmers and most of the time the developers can cope with belonging to
two features for a single iteration or two.[3]
Once created, the feature team has a few things to do in this process. The feature team has to
update the initial sequence diagrams that were created in the first process by adding details to the
diagrams. The team also keeps detailed notes of the decisions, assumptions, alternate designs,
and finally any clarifications that occurred during this process.
With the feature team area in place, the chief programmer inspects the original model created in
the first process and adds or updates the model as needed. For instance, the chief programmer
may modify the model by adding classes, updating attributes and operations that are based on the
detailed sequence diagram. The feature teams also have to update the object model by having
each class owner create method prototypes that are defined in the sequence diagram. The class
model is also updated with parameter types, return types, expectations and messages.[3]
Finally, once everything is completed, the feature team performs a design inspection. Other
chief programmers from the project are also involved so they are aware and given input on the
updated design. Once everything is approved a to-do list is created for every affected class and
each feature member adds the appropriate tasks to his or her own to-do list.
8
Build by Feature: Process #5
The final process in Feature Driven Development is where the features are actually implemented.
Working from the plan in the design feature process, the class owners implement the code that is
necessary to create the features that are assigned. After the code has been developed, the class
owner creates unit tests for the class they own and do a code inspection throughout all of the
code in the feature. The order of unit testing and code inspections does not matter, but both need
to be done before the code is added to the project code. Now since the feature code has been
added to the project, the feature team can disband and reform into new teams to start the next
iteration of the project. [1]
9
Overview of the Whole Process
Figure 3: Shows a brief synopsis of the entire
Feature Driven Development process
10
Feature Driven Development Quality
Unit Testing
Feature Driven Development does not particularly care how units test are completed. The level
and complexity of testing is up to the feature team to design and execute. In feature driven
development is also does not matter if the test area is created before or after the code is
implemented.
Code Inspections
Based on the complexity of the feature, the feature team looks at the documents that reference
the feature to ensure that it is implemented correctly. When the inspection passes, the code is
added to the build.
Conclusion
Feature driven development can be a very efficient way for software to be created. Feature
driven development’s five steps are an elegant way to solve the solution of a large team
development strategy that needs executable code quickly. With its frequent inspections on the
documents being created it greatly increases the quality of any software project. With its high
quality aspects and its quick releases to the customer, I think it is possible for feature driven
development to become popular in the future of software engineering.
References
[1]
Stephen Palmer, John Felsing. (2002). A Practical Guide to Feature Driven
Development. Upper Saddle River: Prentice Hall.
[2]
Pressman, R. (2005). Software Engineering A Practitioner's Approach. Crawfordsville:
McGraw-Hill.
[3]
Unkown. (2007, 6 17). Feature Driven Development. Retrieved 3 25, 2011, from
SCMWise: http://www.scmwise.com/feature-driven-development.html
[4]
Palmer, S. (2009, 11 20). An Introduction to Feature-Driven Development. Retrieved 3
25, 2011, from AgileZone: http://agile.dzone.com/articles/introduction-feature-driven
[5]
Bauer, M. (2004, 5 27). FDD and Project Managment. Retrieved 3 27, 2011, from
martinbauer: http://www.martinbauer.com/Articles/FDD-and-Project-Management
[6]
Cause, G. (n.d.). Delivering Real Business Value using FDD. Retrieved 3 26, 2011, from
methodsandtools: http://www.methodsandtools.com/archive/archive.php?id=19p3