Feature Driven Development

Hi Matt,

Wow! 2500 classes? I'm sorry to hear that. Is that for an entire system, including business logic, user interface, system interfaces, persistence etc? We typically don't see that many classes. We build large systems, but they're usually line-of-business type apps for corporate and commercials these days, whereas you seem to do embedded systems so I'm not so sure if there be a correlation anyway.

We always layer our app into a Problem Domain (PD) that is the business logic, as well as UI, system interface (SI) and persistence layers (DM). The PD might be something like a couple hundred classes for a 12-month construct 50 person project. When you add in user interface this number can obviously baloon, as can things like "implementation" classes (I hate that word though) and interfaces for packaging etc.

The short answer to the Overall Model question is that we do what we call "shape modelling". By that we mean the focus of the model is the key classes and their associations only. We may capture a few key attributes (or even methods) for some classes, but this is not what we're concerned with primarily. What we are concerned with is that we get good coverage of the problem domain, as described by the domain walkthroughs described in process 1. Some people like to call this the "breadth" of the model, rather than then "depth" (but I have some problems with that terminology).

So our model would contain classes to capture all of the concepts presented during the domain walkthrough's, perhaps with a few key attributes, and all of the associations between the classes along with the correct cardinalities for the associations. Sometimes in the course of process one we run a sequence to validate some model shape, and might want to capture a few key methods that result from this.

We dont try to capture every attribute and method we can possibly think of! And we certainly don't try to include every possible class we can remotely justify. At this stage we go out of our way to get the simplest model possible that captures all of the problem domain as presented in the walkthroughs. We are looking for shape here, not content.

As far as embedded systems are concerned, FDD is really agnostic at this level. From my experience most of the differences with embedded are to do with the architecture and design constraints, and perhaps more of your requirements coming form standards documents rather than end users. At a lower level things like the development environment might be redically different, and an edit/build/test cycle may be significantly more complex if you dont have emulation available. The things you mention are all issues, but feel more like typical project management issues and really are outside the scope of what FDD addresses.

I think most difference would appear in the modelling - especially since we use Colour Modelling and the Archetypal Domain Shape. Note though that FDD doesn't mandate this - use whatever modelling approach you like (however the model in groups, present and then merge process is fundamental and necessary!). You tend to see more of a focus on the green party/place/thing classes with embedded than with the pink moment-intervals that are the key in business apps.

A fundamental shift here though is the language we use - maybe some "mental mapping" is necessary. So when we talk about "the customer" or the "domain expert" this might equate to some electrical and timing specifications for a bus in a PABX or the protocol spec for a layer in a comms stack.

So FDD still applies - it realy doesn't manadate technique down at the level where most differences are to be found when doing embedded systems development.

Hope this helps!