Feature Driven Development

Hi All,

I have just taken on a new position at a company and have been tasked with putting a development process methodology in place. After spending some time looking at the various options I belive that FDD is the right direction for us.

I have done as much reading as I can and I am pretty confident on most parts of the process and where I need to make minor tweaks to fit in with our enviroment.

The main question I am a little stumped on is during the Planning by Feature stage it mentions devloping a "Development Sequence" what actually is this ? Also how/who decide what features are built in each iteration and is this done in the Planning by Feature stage or is this done at the beginning of each iteration ?

There's another long thread running that's spawned some interesting side discussions. I'd like to promote one of these out of there, since it's getting rather confusing and since I think there's a lot of valuable discussion going on I'd hate for it to get lost.

So this post follow on from the comment
Need to clarify the semantics of "the model" by Rudy.

Hi all, I'm looking for a tool that supports FDD.
Some of my customers are interested to evaluate/buy such a product.

Any references would be greatly appreciated.
Thanks, Rudy

Does class ownership really work? Suppose implementing a feature affects classes A, B, and C which are all owned by different class owners - different people in this case. Each class owner makes the modifications necessary to his class, adding methods and attributes, changing signatures, etc... Each developer promotes his work to the shared workspace.

• Who assures that this workspace compiles?
• Even when doing extensive design in the DBF process, how assure that these 3 classes will cooperate as needed?
• And most importantly, who is responsible for testing this feature?

Does anyone know where I can download the first chapter of the book? Its no longer on the Together site.

Regards

I'm currently looking at a major J2EE project, over a period of 3 years, with 6 analysts and a dozen programmers. The analysts are responsible for creating business models/specifications and application requirements. During this period, parts of the system will go into production and be extended along the way. So there will be some release while analysis and development continues (1.0, 1.1, 2.0,...)

The analysts will develop an overall domain model, and describe use cases and features.
A list of features will be specified to be implemented in version 1.0 of the application.

Suppose there is only one model which is equal to the implementation at all times (TogetherJ approach). Also suppose version 1.0 is currently under development, while the analysts already start analyzing features for version 1.1. Of course these new features can not be added to the same model, for some reasons:

Principles of the Business Rule Approach author: Ronald G. Ross asin: 0201788934

Computerworld has an article of interest to DNC/ADS modelers by Ronald G. Ross called "Business Rules Connect First". It is an extract from his new book Principles of the Business Rules Approach in which he describes Business-driven Development as the notion that the business owners set the agenda for development and stear (control) it through the definition of 'business rules' (from the title). He claims definition of rules is a process business people can understand and perform without involvement of IT people.

The start of a new project is when the most fundamental decisions are made. These decisions will impact dramatically on the project from that point onwards setting it on a sound and low risk path or pointing it towards a path of difficulty, frustration, spiralling costs and even collapse.

These fundamental decisions cover things such as the project objective (assuming there is one), the business expectations, how much the company is willing to invest and most importantly, who is involved in making these decisions. Having the right people working on the project and making these decisions will give you the greatest chance of success, the wrong people will guarantee trouble.

Streamlined Object Modeling: Patterns, Rules, and Implementation author: Jill Nicola,Mark Mayfield,Mike Abney asin: 0130668397

All the discussion here over the last few days on the Domain Neutral Component (DNC), modeling with Archetypes, and the Archetype Domain Shape (ADS), has reminded me about the book Streamlined Object Modeling by Jill Nicola, Mark Mayfield and Mike Abney.

I was recommended this book by Stephen Palmer so he will undoubtedly say something about it too.

In it, Nicola et al extend the work of Coad and Mayfield from the Object Models book, but in a slightly different direction from Archetypes and the DNC. It's another way of looking at a similar thing. They define "Pattern Players" which are like Archetypes and then they go on to deliver 12 patterns - each of which is like a mini-DNC.

I am working on a project at the moment that is approaching the idea of executable UML. A runtime library reads a representation of a UML statechart and uses it to control the execution paths.

This has the effect of elevating the design effort to the runtime. Where previously the design was a tool that informed the coding effort and only the code was deployed to the runtime (witness design-by-feature and build-by-feature as seperate tasks) now the design can replace some of the coding effort and the design is included in the runtime deployment.

To put it another way: the design stops being a necessary or useful step towards the goal and starts being part of the goal.