Feature Driven Development methodology, a practical guide
Feature Driven Development: this article explains the Feature Driven Development in a practical way. Next to what Feature Driven Development is, the article aslo highlights it’s origin, how it works in practice, the activities, the core principles and advantages / disadvantages. After reading it, you’ll understand the basics of this powerful software development methodology. Enjoy reading!
What is the Feature Driven Development methodology?
Feature Driven Development (FDD) is a framework and agile approachfor iterative and incremental software development. The Agile method is used to develop software, aiming to frequently and efficiently produce results.
FDD stimulates reports on all levels, which helps to keep track of progress and results. Unlike other software development methods, teams can regularly and quickly identify and fix errors and bugs. In addition, there is a focus on providing the customer with updates and interim results at any time.
FDD is one of the favourite approaches to software development because it targets two aspects which are usually struggled with: confusion and revision.
FDD is an incremental tool for development, which means it builds on an already existing feature set of software. Instead of implementing a large and all-encompassing update, FDD is used to release new functions step by step. This way, the client’s requests can be prioritised at all times, maintaining their satisfaction.
FDD combines a few of the project sector’s recognised best practices into a coherent whole. All practices are driven from the customer’s perspective. The most important goal is to, following the rules of the Agile Manifesto, deliver fast working and tangible software.
Where did Feature Driven Development (FDD) originate?
Feature Driven Development (FDD) was thought up by Jeff De Luca in 1997 when he was working as a chief programmer on a software development project for 15 months, and with more than fifty employees.
This experience lead to the creation of a series of five processes which entailed the development of a general model. This description was first introduced to the world in 1999 in the book ‘Java Modelling in Color with UML’. This book was written by Peter Coad, Eric Lefebvre, and Jeff De Luca.
Later, in 2002, Stephen Palmer and Mac Fesling’s book gave a more general description of FDD, outside of Java.
How does the Feature Driven Development (FDD) process work?
FDD is a model-driven iteration process consisting of five basic activities. These activities are displayed in the figure below. During the first two activities, a general form for the model is established. The last three activities are repeated for every function.
The first main activity consists of developing a general model. The result of this first activity is a high level object model, together with notes about the development, functions and demands. The second step is the compiling of a function list by grouping the different functions into related functionalities and fields.
The biggest part of the process consists of step four and five. These two activities entail tasks such as modelling, programming, testing and preparing.
What are the different activities from the FDD process?
As with all Agile methods, the first step in the Feature Driven Development process is to obtain a good overview of the content and context of the project.
Also, a clear and shared understanding of the target group and their needs must be established. During this preparation phase, teams need to strive for learning everything about the project and the motives. This phase of preparation can be considered as phase 0.
Although not part of the official model, this phase can not be skipped.
Activity 1: general model development
During the first real phase of FDD, results from the previous research phase are worked on. The first real sketch is created. Using the thesis (guideline), the team will develop a detailed domain model, which will be merged into a new general model which will function as a blueprint for the system. During the development, and whilst the team learns and develops, details are added.
Activity 2: developing function lists
The second phase of Feature Driven Development (FDD) consists of the identification of features that the user or client demands and appreciates. It is important to remember that a function is an output which is appreciated by the client.
Make a list of functions which can be completed within two weeks, and realise that these functions are goals instead of tasks.
Activity 3: plean by feature
The third phase consists of the managing of all functions, and the way they are implemented. The team’s workload is taken into account, as are the various risks, and other important aspects which prevent problems from arising.
The team now mainly focuses on the analysis of the complexity of every function, and the planning of tasks which are related to their execution.
During the planning phase, all members of the project should participate in the various evaluation moments which will be held in order to align the functions of the model or system with the demands and wishes of the client.
Also, class owners will be established. These are individual developers who are assigned to certain class functions. Because every class of the function belongs to a specific developer, there is always someone responsible for all classes. If changes are necessary, it is key that the owners of the classes work together.
Activity 4: design by feature
The head programmer selects, using previously obtained knowledge, all the functions that a team needs to develop. He or she also identifies the domain classes.
After the team has started to work, the domain expert focuses on the analysing and development of the solutions for every function.
Activity 5: build by feature
The last activity of Feature Driven Development (FDD) consists of the implementation of all necessary elements that support the design. During this phase, for instance, a user interface can be built, or components of the system which were established during the technical design.
Afterwards, a prototype of the function will be made. This will be tested, inspected and approved. After the approval, the function can be added to the main version of the system. Every function that requires more than two weeks, will be further divided into elements so that they adhere to the rule of a maximum of two weeks per function.
Core principles of Feature Driven Development (FDD)?
FDD is based on a few core principles, or best practices. Seven of them are explained below.
FDD teams regularly inspect to ensure quality. The emphasis is on the design and the code of the system. It is important that during this inspection defects are identified, which otherwise would have surfaced much later.
A feature-team is a dynamic and small team that develops a small feature. They make sure every moment of decision-making is looked at from multiple angles, and that several design options are evaluated.
Even though a single person is responsible for the presentations and the quality of a function, everybody contributes to the design and implementation decisions.
Configuration management involves identifying the source code for all functions that have been completed up to a point in time. In addition, configuration management is about keeping a history of changes to the system in different classes, as the project progresses.
Individual ownership means that different pieces of work, or a piece of code, are assigned to an owner. He or she is responsible for the execution, and needs to guarantee the quality and the performances.
Domain object modelling consists of resolving problems. Teams develop different diagrams to describe objects in a domain and the relationship between objects. This process ensures time is saved during the execution of later activities.
A function or tool that is so complex that it takes more than two weeks to develop, is broken down into smaller functions until each sub-problem is small enough to be solved within two weeks. This makes it easier to deliver the right functionalities and to adjust the system.
Managers lead a project using regular progress reports from all levels inside and outside the project.
Members of the Feature Driven Development team
A modelling team that uses FDD at least encompasses the following roles:
The project manager oversees, as in all projects, the entire project. The project manager is also the link between the sponsor and owner of the team. FDD is known for its stimulation of close contact with the client. This is an important responsibility for the project manager.
The head architect is responsible for the overall design and modelling of the new system. During the development phase the head architect works closely with the other developers.
The development manager leads and guides the entire development team. He or she also oversees the daily programming activities, and is the point of contact for team members.
The head programmer assists with design and analysis, and is sometimes also appointed to supervise and manage smaller development teams.
The class owner is a member of a smaller development team which is led by the head programmer. The responsibilities of the class owner entail design, codes, testing, and documenting of functions.
The domain expert is part of a team that solves the problem through analysis and client contact. The developers rely on the domain expert’s knowledge and skills, and ensure that functions work and deliver what the customer expects.
Advantages and disadvantages of Feature Driven Development (FDD)?
The use of FDD entails both pros and cons. Below is an overview of the most important aspects of both categories.
- Structured use of FDD provides the team with a solid understanding of the scope and context of the project and its goals
- FDD demands less lengthy meetings than alternatives based on Scrum. FDD stimulates the use of documentation in order to communicate
- FDD is a user friendly approach to software/system development
- FDD is compatible with big, small, short and long projects
- The five activities make it easier for new team members to quickly learn the project’s goals
- FDD breaks large quantities of work up into smaller sets which makes it easier to find and repair mistakes.
- Therefore the risk of delay is smaller, and a faster lead time can be guaranteed
- Feature Driven Development (FDD) is less suitable for very small projects, and does not work for projects with a single developer
- FDD creates a strong dependency on the head programmer
- FDD offers little written documentation to the consumer themselves, despite the quantity of documentation between group members
- Stimulates individualism instead of collectivism
Feature Driven Development (FDD) vs. Scrum
FDD has many similarities with Scrum, but instead of being delivery-oriented, FDD is function-oriented. Functions are an important component in FDD. For FDD, functions are what user stories are to Scrum developers. User stories are also small functions that are appreciated by the client.
During the FDD proces, a function should be delivered every two to ten days. In Scrum, the sprints are usually a few weeks. The FDD approach also places more value on documentation for internal use than other methods such as Extreme Programming (XP) and Scrum.
This creates differences in usefulness and roles in meetings. With Scrum, teams meet every day. With FDD, teams rely on the internal documentation which is exchanged as part of the project strategy. There are not as many meetings necessary when using Feature Driven Development (FDD).
Another important difference between the two methods, is that with FDD the person who will eventually use the system is considered the end user. With Scrum, the product owner is considered the end user.
Now it is your turn
What do you think? Are you familiar with the explanation of Feature Driven Development (FDD)? What are your personal success factors for successfully implementing software solutions or other functions? Is FDD used in projects around you? Do you prefer Scrum or other Agile methods? Do you have any tips or comments?
Share your experience and knowledge in the comments box below.
- Arbain, A. F., Ghani, I., & Jeong, S. R. (2014). A systematic literature review on secure software development using feature driven development (FDD) agile model. Journal of Internet Computing and services, 15(1), 13-27.
- Chowdhury, A. F., & Huda, M. N. (2011, December). Comparison between adaptive software development and feature driven development. In Proceedings of 2011 International Conference on Computer Science and Network Technology (Vol. 1, pp. 363-367). IEEE.
- Firdaus, A., Ghani, I., & Jeong, S. R. (2014). Secure feature driven development (SFDD) model for secure software development. Procedia-Social and Behavioral Sciences, 129, 546-553.
- Firdaus, A., Ghani, I., & Yasin, N. I. M. (2013). Developing secure websites using feature driven development (FDD): a case study. Journal of Clean Energy Technologies, 1(4), 322-326.
How to cite this article:
Janse, B. (2020). Feature Driven Development methodology, a Practical Guide . Retrieved [insert date] from Toolshero: https://www.toolshero.com/information-technology/feature-driven-development/
Published on: 09/23/2020 | Last update: 11/17/2022
Add a link to this page on your website:
<a href=”https://www.toolshero.com/information-technology/feature-driven-development/”>Toolshero: Feature Driven Development methodology, a Practical Guide </a>
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?