FEATURE DRIVEN DEVELOPMENT (FDD)
FDD encourages status reporting at all levels hereby providing accurate and meaningful progress for the developers.
Get Support NowFDD is an Agile framework that is lightweight, short, customer-centric, iterative and focuses on delivering of tangible software development frequently and efficiently. FDD encourages status reporting at all levels hereby providing accurate and meaningful progress for the developers. FDD also allows teams to always update whatever project they might be working on and also fixing any error immediately. FDD was built around the practices of software engineering while blending a number of recognized industries.
FDD was devised initially by Jeff Du Luca who was the then project manager to meet the needs of a bank in Singapore for a very large scale, critical project. The original project took about 15 months with 50 people. 2000 functions features were delivered within the space of 15 months resulting in the set of five processes that covered the development; overall model, listing, planning, design and building of features.
It was then decided that FDD is going to be an approach that would be ideal for long-term and complex projects looking for simpler methodologies.
FDD’s two core principles;
- Software development as a human activity.
- Client-valued functionality.
Software development as a human activity implies that software development cannot be dealt with as a mechanical activity, rather it is essentially a human activity, which makes people and processes more important than plans and tools.
Secondly, the entire project is broken down into smaller user-centric portions which are developed through repetitive cycles in which modifications and new functional features are integrated into the project model in each subsequent iteration.
BASIC ACTIVITIES OF FDD
These five basic activities are typically used in large-scale development projects:
- Develop an overall model
- Building a feature list
- Planning by feature
- Designing by feature
- Building by feature
-
Develop an overall model
During this stage, the first process involves creating the base object model and establishing the shape of the system. This is done under the guidance of the Chief Architect who is an experienced object modeler. The Chief Architect, Chief Programmers and Domain Experts perform a high-level walkthrough of system’s scope and context. Team members get familiarized with the scope and context of the entire project or system and they do this under the guidance of a “chief architect”. Now, detailed domain models would be created for team members after which they will then get divided into smaller groups where every system area will be modelled and presented for peer review. One or more of these models are then selected by consensus to become the model for each domain area. Domain area models are then merged to form an overall model. -
Building a feature list
Every knowledge gathered during the first stage is used to identify and create a list of features. This would lead to the decomposing and splitting of the domain into subject areas according to the functionality of the area(s). Subject areas contain steps within a business activity that forms a categorized feature list. Features in this list are client-valued output. Bear in mind that you should make list of features and these features shouldn’t take longer than two weeks to complete if not, they would be broken into smaller goals. -
Planning by feature
All members of the team should take part in the planning, evaluation and implementation of each feature. This assessment gives the order in which a feature will get implemented as well as team members that will be assigned to each set of feature. Once a feature is being set in motion, development will then start its planning phase. Every member should have the development plan in mind. Class owners (developers who are assigned to class) should be identified as well because every developer will be assigned to every class. -
Design by feature
Every feature comes with each special design package during development. A chief programmer is always usually in charge. A chief programmer selects and determines every feature to be designed and built within two weeks. He/she together with the class owners works out some detailed sequence diagrams for every feature and then refines the object model based on the content for the sequenced diagram. After this is done, a class and method prologue is written after which a design inspection is held. -
Build by feature
Once a design inspection for each activity to produce a feature is ready, the class owners then move into actual programming. This means developing codes for their classes. The code developed passes through unit testing and inspection after which approval takes place to ensure a feature is complete which is determined by the chief programmer. Once a feature is completed it can then be incorporated into a system.