Feature Driven Development

Feature Driven Development (FDD) is a client centric, architecture centric and pragmatic software process. The term “client” in FDD is used to represent what agile Modeling refers as stakeholders or extreme Programming (XP) calls customers. FDD was first introduced to  the world in 1999 via the book Java Modelling In Colour with UML, a combination of the software processes followed by Jeff DeLuca’s company and Peter Coad’s concept of features. Scrum orgnizes its catalog of features that the scrum owner prioretize for development team know as the scrum team. As the name implies, features are an important aspect of FDD.  A feature is a small, client-valued function expressed in the form <action><result><object>. The FDD life cycle is as follows

FDD

An FDD project starts by performing the first three steps in the equivalent of the RUP’s Inception phase or XP’s “iteration 0”, the goal being to identify the scope of the effort, the initial architecture, and the initial high-level plan.  Construction efforts occur in two-week (or less) iterations, similar to XP although a little extreme for most RUP teams, with the team iteratively working through all five steps as needed.  As with other agile software development processes, systems are delivered incrementally by FDD teams.

Develop an Overall Model: The project starts with a high-level walkthrough of the scope of the system and its context. Next, detailed domain walkthroughs are held for each modeling area. In support of each domain, walkthrough models are then composed by small groups which are presented for peer review and discussion. One of the proposed models or a merge of them is selected which becomes the model for that particular domain area. Domain area models are merged into an overall model, the overall model shape being adjusted along the way.

Build Feature List: The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form <action> <result> <object>.

Plan by Feature: After the feature list is complete the next step is to produce the development plan. Class ownership is done by ordering and assigning features as classes to chief programmers

Design by Feature: A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held.

Build by Feature: After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build. more.

More on FDD

FDD( Feature Driven Development) development consists of the two main stages : discovering a list of
features to implement and feature by feature implementation. Discovering a list of features is a critical
process. The outcome of this step is the UML diagram of problem domain. The list of features is
derived from the UML diagrams. The features are expressed in a language that is clear to both
development community and customers. The implementation starts from grouping the related features
into work package. A work package should be complete in one iteration. Gathering user requirements
is critical for the success of FDD project. It is so important that the process has a proud name of
“Process One”. The outcome of the process is a UML diagram and a list of features. UML diagram(s)
define the problem domain of the software system. If implemented well, it covers all the relevant areas
of business and allows to easily adding features for subsequent releases. The process involves
developers familiar with UML and customer representatives, including problem domain experts. The
good problem domain covers customer’s business. It supposed to be stable:

user requirements for the application may change, while business usually stays the same. In addition to creating object-oriented model of business, Process One indirectly indicates the duration of development phase. FDD rule of thumb says: the development team will spend approximately 6 months of development for each 2 weeks of modeling. FDD does not require create design documentation . At the end of process one the developers usually create a description of UML diagrams, documenting the alternative ways that where rejected and reasons behind the decisions. The document becomes useful later: in a long project people may forget details of initial decision, so the document serves as a reminder. If customer requests the formal user requirements may also be written on the basis of this document.

FDD requires a number of chief programmers (CPs) to be selected. CPs are most experienced programmers in the team that play the role of technical leaders. They also take some additional responsibilities. In the team hierarchy CPs stand in between the developers and a project manager. CP prepares iteration planning meeting by grouping the right amount of relevant features into a work package. Normally the team has a number of CPs, each of them conducts iterations independently. Each iteration does not have to include the whole development team. Instead, the new iteration team is formed for each iteration. CP selects iteration team members based on availability. Each developer receives a subset of features; strong class ownership is encouraged. The iteration team goes through the list of features, which should be familiar from Process One. If needed, the team contacts the customer to clarify any obscure features. In the complex cases the team may create sequence diagrams. The planning meeting also sets time line for iteration milestones.