Feature Driven Development

"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

De Luca on FDD Newsletter Issue 5

Testing is one of the Least Effective Defect Removal Techniques

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.

I guess I'm one of the younger members of this community, but don't let that fool you!

I have applied more of a vanilla implementation of FDD last year in my final year project at uni (16 developers), and recently just some aspects of it to my last J2EE project, which i worked on by myself reporting to two managers.

I have many views and still many questions on agile development. It's funny to me how so many IT professionals are looking "the next big thing" to fly straight into their laps, specifically I'm talking about those that view agile as being Fred Brooks'(sp) silver bullet for development.

This should probably go into the forum, however I think front page exposure might be good for what I'm proposing.

Last year, myself and 15 others from the University of Melbourne (Australia) developed a framework for the distributed simulation of catchment (rivers, dams) models, that dealt with large data sets using JXTA and other Java technologies. We had an 8 month time span to do this and it was quite a challenge. We were introduced to FDD by quite an avid fan and contributor to this community, Gavin Baker and compared to XP, RUP dx etc. it offered quite a wide range of benefits (most of which I'll talk about in a different post regarding what I found from a project manager perspective. Hopefully the CA from our team will publish his story on FDD as a CA).