| Part of a series on |
| Software development |
|---|
Paradigms and models |
Standards and bodies of knowledge |
Feature-driven development (FDD) is aniterative and incrementalsoftware development process. It is alightweight oragile method for developingsoftware. FDD blends severalbest practices into a cohesive whole. These practices are driven from the perspective of delivering functionality (features) valued by the client.[1] Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind theagile manifesto.[2]
FDD was initially devised byJeff De Luca to meet the specific needs of a 15-month, 50-person software development project at a largeSingapore 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 byPeter Coad's approach toobject modeling. 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.
The description of FDD was first introduced to the world in Chapter 6 of the bookJava modelling in Color with UML[1] by Peter Coad,Eric Lefebvre, and Jeff De Luca in 1999. Later, in Stephen Palmer andMac Felsing's bookA Practical Guide to Feature-Driven Development[2] (published in 2002), a more general description of FDD was given decoupled from Java modelling.
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. This section gives a high-level overview of the activities. In the figure on the right, themeta-process model for these activities is displayed. During the first two sequential activities, anoverall model shape is established. The final three activities areiterated for each feature.
The FDD project starts with a high-levelwalkthrough of the scope of the system and its context. Next, detailed domain models are created for each modelling area by small groups and presented forpeer review. One or more of the proposed models are selected to become the model for each domain area. Domain area models are progressively merged into an overall model.
Knowledge gathered during the initial modeling is used to identify a list of features by functionally decomposing the domain into subject areas. Subject areas each contain business activities, and the steps within each business activity form the basis for a categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form "<action> <result> <object>", for example: 'Calculate the total of a sale' or 'Validate the password of a user'. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.
After the feature list is completed, the next step is to produce the development plan and assign ownership of features (or feature sets) asclasses toprogrammers.
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 detailedsequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written, and finally adesign inspection is held.
After a successful design inspection for each activity to produce a feature is planned, the class owners develop code for their classes. Afterunit testing and successfulcode inspection, the completed feature is promoted to the main build.
Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project, it is important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during theDesign By Feature activity, and the last three are completed during theBuild By Feature activity. To track progress, a percentage complete is assigned to each milestone. In the table below the milestones and their completion percentage are shown. At the point that coding begins, a feature is already 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%).
| Domain Walkthrough | Design | Design Inspection | Code | Code Inspection | Promote To Build |
|---|---|---|---|---|---|
| 1% | 40% | 3% | 45% | 10% | 1% |
Feature-driven development is built on a core set ofsoftware engineeringbest practices aimed at a client-valued feature perspective.
Metamodelling helps visualize both the processes and the data of amethod. This allows methods to be compared, and method fragments in themethod engineering process can easily be reused. The usage of this technique is consistent withUML standards.
The left side of the metadata model shows the five basic activities involved in a software development project using FDD. The activities all contain sub-activities that corresponding to sub-activities in the FDD process description. The right side of the model shows the concepts involved. These concepts originate from the activities depicted in the left side of the diagram.
