Feature Driven Development

Balancing Agility and Discipline: A Guide for the Perplexed author: Barry Boehm,Richard Turner asin: 0321186125

FDD gets a good mention along with XP, Scrum, RUP and some others in the new book by Barry Boehm and Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed.

The book is aimed at big company IT managers who have to decide whether agile processes are worthwhile and whether to adopt them rather than traditional methods. It also introduces the idea that risk management can be used as a method to allow an organization to successfully mix the best of both worlds.

The main section on FDD is in pages 183 - 185. It's a pity that some of the conclusions drawn are wrong and I wonder if the authors had anyone from the FDD community review their work.

Hi,

this post is steamed from my own Pet project concerning the development of an integrated suit of tools for managing projects following FDD.

I've been trying to create a static model using the DNC and is rules, but I'm finding it hard if not impossible to follow them. In my tools I want PM, CPs and Customers to be able to assess the ammount of work that has been done, including the level of completeness (Percentage Complete) and what has been completed.

Do this I've defined eatch stage of FDD as classes respecting the moment interval archytype. Plus I have another one called Project. As I see them all they are "moment intervals", in the sense that each of them as a Start Date, Completion Date, Status (planned and actual).

"Writing models and then writing the code never works," says Dr Booch. Instead, the code and the model are two ways of looking at the same thing. Models can be used as scaffolding to help programmers "climb" existing code, or to guide the construction of new code. Rather than advocating top-down construction, from model to code, Dr Booch advocates an incremental, iterative process: start with a model, make a working program, and then add features to the program progressively, in small steps, keeping the model updated along the way.

http://www.economist.com/science/tq/PrinterFriendly.cfm?Sto

One problem with tracking progress and status through use cases is the invisible scope creep they allow.

Adding a single phrase to the textual description of a use case can add more functional requirements that need to be implemented. However, from a manager's perspective there are still the same number of use cases. It is only when a developer starts complaining that use cases are growing that the managers starts to see the problem and by then it could be too much of a task to quantify the scope creep.

In a features list adding new features is immediately visible to managers and Jeff's

Here's a pretty interesting (old) article. They Write the Right Stuff [fastcompany.com].

Hi All,

There is plenty of material on developing software with FDD from scratch, but what about maintenance ? How does FDD work in the maintenance phase, after product delivery ?

mark

Hi,

I've recently learned about FDD and particularly liked the idea of using features for planning and controlling a project at a detailed level. We are currently starting a project and have produced a use case model (no detailed use case documentation), a high-level domain object model and a non-functional requirements document.

The idea I wanted to explore is to use the use case model as basis for the feature sets. Each use case could be a feature set and instead of defining the use case in detail we just identify features associated to each use case. We also identify feature sets from the non-functional requirements list (e.g. interface to accounting system, etc.).

FDD :: The Hydra Experience

[Introduction]

The project was an industry based final year Software Engineering project for Melbourne University Engineering students. The team was made up of 16 students working full time for the university year (approximately 8 months), and aptly named "Hydra". Our client was the CRC for Hydrology, run by CSIRO Land and Water.

The purpose of this discussion was to identify where FDD worked and what we learnt from the project. I've left the project specifics out, but the system we built was an distributed environmental simulation framework (not a typical Line of Business application).

A recent article on Slashdot asks the question "Why do computers still crash?". And a fair question it is, too, which got me thinking...

Some interesting discussion follows. Many comments suggest that reliability is simply too costly for some markets to bear. Many conclude that the PC consumer marketplace is not prepared to pay for quality. They also point out that vendors frequently favour new features at the expense of quality, and that users have come to expect this.