Delivering Real Business Value using FDD - Page 2

By Grant Cause, IT Project Services Pty. Ltd.

A Brief introduction to FDD

So what is this FDD thing all about anyway? I hear you ask.

Well, the following is a very brief introduction to FDD in layman's terms.

Firstly I must state that FDD is no silver bullet (The Silver Bullet was first described in the book The Mythical Man month by Fred Brooks). In fact there are no silver bullets to delivering software development projects on-time, to-budget with agreed functionality. That takes hard work, patience, commitment and skill. FDD is a methodology, a good one, but just a methodology none the less. It is not designed to be followed rigidly or to replace good common-sense. FDD does however require street-smarts to be able to decide where, how and to what extent to adopt and adapt FDD to your particular business.

What is FDD?

FDD stands for Feature Driven Development.

Feature Driven Development is a process designed and proven to deliver frequent, tangible, working results repeatedly. FDD is a straight-forward, no-nonsense, common-sense, industry proven approach to software development built around a well recognised core of industry best practices.

Where did FDD come from?

FDD was developed in the field; it first came to prominence in 1997 in Singapore on a banking project known as PowerLender where Jeff De Luca was the Project Manager. Jeff had a bunch of processes and practices he'd been using for years. Peter Coad, who was brought on to do an initial up-front modeling exercise on the project, introduced Jeff to the concept of a fine-grained feature. Jeff then took that concept and implemented it throughout his process framework.

Over time a lot of other people have contributed in some way or another to what is now known as FDD. However the main drivers behind FDD have been Jeff De Luca and Peter Coad, with Jeff being the original inventor and owner of the methodology.

So why use FDD?

To quote Jeff De Luca "To enable and enforce the reliable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project."

FDD is a simple easy to understand and easy to implement methodology that:

• was developed in the field on real projects. It comes from practice and has been proven in practice; it was not a theory or a book first like so many other methodologies
• delivers frequent, tangible, working results repeatedly
• is highly iterative
• is built around a core set of industry best practices
• builds in quality rather than adding it as an afterthought
• provides highly accurate and meaningful progress and status information with minimal impact on the software developers
• is well liked by all project stakeholders, from the technical people through to the business people there is something in it for them all.

FDD makes use of a core set of industry best practices which include but is not limited to:

• Domain Object Modeling
• Developing by Feature
• Individual Class Ownership
• Feature Teams
• Inspections
• Regular Builds
• Configuration management
• High visibility/reporting of results

Domain Object Modeling is used extensively in FDD. The first process of FDD is in fact the development of an object model representing the problem domain for the project. Initially this model is just a straw man representing more shape than content but the details quickly start to be filled in as the project progresses. As each new feature is addressed, a small design phase ensures the details fall into place quickly so the build can proceed.

An example of this modeling technique is shown in Figure 1. Note the use of sticky post-it notes which get put on a wall to show the model. That way the model is dynamic it can be easily changed as new ideas and requirements come to mind. By keeping the modeling rules simple the business people can participate in the modeling exercise without having to know all the technical details.

For those who want to know the technical details, FDD makes use of some innovative modeling techniques. The most notable are the use of Colour and the use of Stereo Archetypes. Colour is used to differentiate between such things a Role (Yellow), a Party / Place / Thing (Green), a Description (Blue) and a MomentInterval (Pink) as shown here in Figure 1:

Figure 1 - Colour Modeling example / Copyright © 1997-2004 Jeff De Luca

Each of these is describing a Stereo Archetype. Stereo Archetypes are similar to the concept of Design Patterns but in an object modeling sense, they represent solutions to common problems that keep occurring in the real world. Jeff has put these together with a set of rules that govern them into what he calls the ADS or Archetypal Domain Shape. Almost any problem can be modeled by the use of the stereo archetypes contained in the ADS. Each one of these interacts with the other in a set way typically in the order of Blue->Green->Yellow->Pink. I wont go into all the details of what each of these is as that can get quite complex and is best left as the topic of a separate article.

FDD places emphasis on customer participation, by including the customer in the initial up-front and subsequent design sessions. The customer starts to buy into and take ownership for the project and the final project deliverables. For the developers this allows them the opportunity to see how and why things are done within the customers business and who and what interact with the feature in question. It is also a great way of building a rapport between the customer and the development team. It also gives both the customer and the development team a new perspective on the issues faced by each of them during the project.

Page 1    Page 3   Back to the archive list