Database Reference
In-Depth Information
Feature-Driven Development
Feature-Driven Development (FDD) is a software development process for producing
frequent, tangible, working results (Coad, Lefebvre & DeLuca, 1999; Palmer & Felsing,
2002). FDD was used for the fi rst time in the development work of a large and complex
banking application project in the late 90's. FDD consists of fi ve sequential processes during
which the design and building of the system is carried out:
Develop an overall model
,
Build
a Feature list
,
Plan by Feature
,
Design by Feature
, and
Build by Feature
. While the fi rst
three processes are sequential, the next two (Design and Build) are the iterative part of the
FDD. FDD concentrates on the concept of feature. A feature is a small, client-valued function
expressed in the form <action><result><object>. As there may be a lot of features, FDD
recommends that features are organized into a hierarchical list: major feature set, feature set,
and feature steps. Features are determined from the formal requirements specifi cation. FDD
suggests that each feature should take no more than two weeks to design and develop.
FDD defi nes the six key human roles and nine supporting roles. The main role is that
of Chief Programmer(s), who is responsible for planning the schedule of features, allocat-
ing the ownership of classes, delivering a feature set, ensuring quality of all products, and
leading the feature teams. The FDD development approach has been applied to projects of
various sizes (from 50 people up to 250), claming to contain just enough process to ensure
scalability. Unlike some other agile methodologies, FDD claims to be suitable for the de-
velopment of critical systems.
As following the classical object-oriented paradigm, all diagrams and notation in FDD
are based on the UML with supporting textual documents for representing, e.g., the feature
list. For domain object model, a class diagram is used, specifying operations and attributes
of the classes and associations between them. For the list of features a textual notation is
used. The features can be derived from use cases of the system. In designing the system a
sequence diagram can be used for associating features to particular objects/classes. FDD does
not suggest using any specifi c tool support, but it can be assumed that for object modeling
and sequence diagrams a UML-based tool can be used. The domain object model through
different levels of detail serves as an architecture blueprint of the system. When the features
are later listed it is natural to map them onto the existing domain classes. That is a data-
centric view of the domain and may not be the best structure for the solution.
Agile Modeling
Agile Modeling (AM) has been proposed as an attempt to apply AD and XP principles
to modeling and design activities (Ambler, 2002). As in the case of XP, Agile Modeling is
a collection of values, principles and practices for modeling software that can be applied
in an effective and lightweight manner. The agility and effectiveness of the modeling are
achieved by the fact that the models are as simple as possible, easily understandable, suf-
fi ciently detailed, accurate and consistent. AM is not a prescriptive process, i.e., it does not
defi ne detailed procedure to create a given type of model; instead it provides advice on how
to effectively model and produce a quality product that matches business needs. The focus
of AM is on effective modeling and documentation. It does not include programming and
testing activities, project management, and system deployment and maintenance. Therefore
AM should be used with another complete method such as XP, DSDM or RUP, where it can
provide a way of effective and agile modeling and design (Figure 1).
