Extending FDD for UI
Implementing Feature Driven Development on Presentation Layer Projects
by David J. Anderson

Feature Driven Development is a model-driven short-iteration process for managing the analysis, design and construction phases of a software project. Feature Driven Development was developed in 1998 by Jeff De Luca following on the back of work by Peter Coad on Feature Lists. I was fortunate to have worked on the team, together with Stephen Palmer, Phil Bradley and Paul Szego, as we developed the FDD method and used it to deliver a very large project.

So far the published material on FDD focuses on its use with the business layer piece of the system. Back in 1998 we also adapted the method to accommodate presentation and system interface layers. However, the early implementations for these other layers were never wholely satisfactory. Over the last 2 years I have continued to refine and develop FDD for use with presentation layers. This paper will set out my latest thinking on FDD for UI. This technique was used at ebeon.com (recently closed), Dublin, Ireland (aka Trinity Commerce, part of Eircom) in 1999 and the latest refinement is now in regular use at my current employer SprintPCS.com in Kansas City, MO.

The paper assumes no prior knowledge of FDD and hence those familiar with the existing work may choose to skip sections of this paper.

The era of the 2 to 5 year software project is almost dead. Increasingly we are asked to deliver more and more complex software for use over the internet, in shorter and shorter product cycles. These often have time driven release cycles. However, the way we run software projects hasn't changed much. The reality in the web world is that we are late, over-budget and lacking in desired functionality more and more often. Web speed tends to mean, fail often, fail early!

Rapid Application Development - The Silver Bullet

The answer to web speed projects with fixed time based delivery schedules, is often held up to be "Rapid Application Development". There has been much written about RAD, for example, Steve McConnell's 1996 book "Rapid Development" [McConnell 96] together with many examples on the web such as this one from project management website Gantthead.

The basis of most RAD methods is a list of functionality which the system might perform. The functionality is ranked by the business in order of its importance or desirability. The effort involved in developing each piece of function is sized. A line is then drawn across the list. Everything above the line can be developed for the next release date. Everything below the line has to wait.

This bears remarkable similarity to a method I learned from Peter Coad in 1997 - Feature Lists. The business function of a system is itemized as a list of features. A Feature is defined as "a small piece of client valued functionality". Or put another way, a Feature is something that a business can describe, talk about, teach the public and charge for. Features mean business to marketing people.

Each feature is scored by two criteria: 1 to 10 how pleased is the client to have this feature included?; 1 to 10, how upset will the client be, if this feature is excluded?. These two criteria can be aggregated and a score out of 20 is obtained. This score is used to rank the features on the list. Each Feature is then sized. Coordinating with the available resources it is then possible to draw a line across the Feature List. Everything above the list is included in the next release. Everything below the line has to wait for a future release.

Feature Driven Development is a logical extension of Peter Coad's Feature List method. Feature Driven Development is a model-driven rapid application development process which delivers measured quality.

Measurement

"You cannot control what you cannot measure!", Tom De Marco

The problem statement for a web speed development method requires more than just short time based delivery schedules. There is still the issue of delivering on budget with agreed function. The features above the cut-off line are the agreed function, so how do you ensure whether you can deliver them or not? The answer to this is accurate estimating. In order to calculate the resources budget for the project, you need to be able to estimate. However, you cannot estimate until you have learned how to measure.

For example, let us assume that you tasked with completing a journey in a car to a given location, perhaps several hundred miles off. You are asked to complete the task before a given time of day and you are asked not to spend more than a given aount on fuel. You calculate that you can complete the task, on time, within budget, if you achieve the correct fuel efficiency. In order to do this, you must travel at precisely 57 miles per hour.

Now imagine you are offered two vehicles. The first has a speedometer which is market off in 20 mile per hour increments, with a sub-mark at the odd 10 mile per hour intervals. The guage is of poor manufacture and is at best accurate to +/- 15%.

The second vehicle has a digital dial with a precision of 0.1 miles per hour. The sensors are expensive and the manufacturer claims that it the guage is accurate to +/- 3%.

Which of these two speedometers would you rather carry on your trip?

The reality of any rapid application development technique is that, in order to know how fast you are going, you need to be able to make accurate fine grained measurements. Going at web speed requires the counter-intuitive notion that you must have a fine grained plan and you must measure progress often and with precision.

Feature Driven Development delivers a fine grain of control and offers opportunities for precise and frequent measurement of progress. This provides the ability to report progress with astounding accuracy e.g. 43% complete, and speed with equal accuracy e.g. work is progressing at 2.7% per week.

Estimates vs Agreed Function

However, simply being able to measure how fast you are going is not enough guarantee delivery of agreed function. Afterall your estimate could have been wrong!

This is a reality of life. Until you have been through several iterations and have accurate historic data, estimating will never be accurate. The advantage of having a fine grain of control, is that you will know early, whether you are going to be late. This gives you the opportunity to negotiate over the functionality. In other words, negotiate to raise the cut-off point - drop features from the requirement, with the client agreement.

In web speed projects, you must deliver for the appointed date. It is rare that you can increase resources so you must trade out features. Being able to do this early rather than later is much better. In order to have this early warning, you need a system which facilitates accurate measurement at frequent sampling points.

The solution to delivering frequent, tangible, working results at web speed, is achieved through Feature Driven Develop. Existing writing on FDD has focused on Business Layer modeling and development. How could FDD be extended to cover Presentation Layer modeling and development?

A Feature

The essential element of FDD is the feature. A feature is a small piece of client valued functionality - a tangible result - which can be delivered in 2 weeks or less - a frequent result - with some measure of quality - a working result.

A business feature is written using this structure:-

<action> the <result> <by|of|to|from|for> a(n) <object>

total the value of the sale
calculate the interest for the bank account
total the hours worked for the pilot

So the first question to be answered was, "What is a UI Feature?". In 1998, I had no really good answer for this. The problem was solved by making each view from the storyboard a feature, and that was that. The storyboard was known as the "high level design". It was elaborated into a class diagram of JFC/Swing classes and that was known as the "low level design". This was highly unsatisfactory. It wasn't until I discovered Ian Horrocks work with Statecharts [Horrocks 98] that I had a better answer - each State which relates to a distinct View is a feature and each Event is also a feature. (see below)

Feature Sets

In FDD, features are grouped into Feature Sets. A Feature Set is intended as a potentially client deliverable piece of work. It goes beyond simply client valued - a feature - but is a coherent set of client valued function which might be deliverable as a component. It is a grouping of related business features. Feature sets are named after business processes

A Feature Set is written using the following structure:-

<action>-ing <business deliverable> <by|of|to|from|for> a(n) <object>

creating an account for a customer
making a bank loan to a customer
assessing the inventory levels for a warehouse

A feature set might typically be 15 features. The idea is the the feature team develop a bundle of features together, perhaps 5. Therefore, with 3 iterations, the feature team develop the whole feature set. This feature set could then be delivered as an interim deliverable to the test team or client. It has real business value.

Again the question was, "What does a UI Feature Set look like?"

There were several possible strategies for developing feature sets. At this time, I haven't settled on the best one and I will continue to experiment.

Strategy 1. A Feature Set for each View

This is my current favourite choice. It is a View-centric approach to bundled delivery. Views have real tangible value to clients. Everyone can get their head around the idea of a screen, and the functionality that it requires.

A Feature Set for a View would consist of the View itself, any sub-views, or aggregated components. A Feature for each Event. Events have real client value. Everyone can understand that pressing a button causes "stuff" to happen. Making that "stuff" happen is rightfully the job of an Event. Finally we need a Feature for each Transient Business Feature, of which more later.

Strategy 2. A Feature Set for each Use Case

A slightly larger grained alternative, might be to group UI features by use case. Hence, you would aggregate all the features from Strategy 1, for each View required in order to complete a use case.

Strategy 3. A Feature Set for each business layer Feature Set

A variation on strategy 2, this one makes a lot of sense but may be difficult to implement in practice. After the business layer feature sets have been devised, identify each view required for, "assessing the inventory levels of a warehouse", then aggregate features from Strategy 1 for each View required for that feature set.

The problem with this strategy is that it might lead to rather large feature sets for the UI, getting away from the fine granularity which we are seeking.

Strategy 4. A Feature Set for each Container in the UI Model

This is really a larger grained version of Strategy 1. It relies on the development of a complete model for the UI. Next you identify the major containers within the design. Containers usually bound the persistent transactions or the save points. Build a feature set from all the finer grained views aggregated by the container, following strategy 1.

I currently have no best choice for this. I am using Strategy 1 at the current time though I do not believe it to be optimal. A single view is not in itself a good client deliverable or interim deliverable.

Subject Areas (aka Major Feature Sets)

A Subject Area in FDD is a major component or sub-system. In many organisations a Subject Area represents a single project. Several projects together make a business program.

In some cases, the same business logic may be reused for several different applications i.e. a banking application may have web client version for account holders, a retail version for branch clerks and a customer care version for call center operators. Together they might be known as the Retail Banking Manager Program and individually they were run as three separate projects. Naming is always tricky in the IT business, so you may know a Subject Area by some other name.

In FDD Subject Areas are named with the following convention:

<object> management

customer management
account management
product management
resource management

Again, the question arose, "What is a Subject Area for UI?"

Subject Areas are large grained sets of function which often result in standalone applications or distinct sub-sites with a website. A Subject Area for a UI purposes is all the features associated with all the Views which are required to deliver the business layer Subject Area (or Major Feature Set).

For example, all the screens for Customer Relationship Management, or all the screens for inventory management.

There are other possibilities for this such as "all the screens for a given user role" but I haven't tried it.

As stated earlier, FDD is a model-driven process. It is also a 5 stage process.

Stage 1 - Develop an Overall Model

This model should be wide rather than deep. In other words, the objective is to build an analysis model of the business function for the whole of the requirement without going too deep. No need to develop sequence diagrams or long lists of attributes. By far the fastest way to achieve this initial object model is through the use of the Domain Neutral Component and the 4 business model Archetypes [Coad99], [Palmer 00-2]

Stage 2 - Develop a Feature List

The second stage is to develop the feature list from a combination of the requirements documents, the object model and the project glossary. The object model and the glossary act as source for naming and help to resolve naming conflicts. It is common in a requirements document for similar or identical things to be called by different names. Using the object model as reference, it is easier to develop the structured language for the feature list.

If the feature list is developed correctly, each feature will lead to a single Sequence Diagram with the <action> as the name of the method, the <result> as the return value and the <object> as the class on which the method is placed. A properly written feature list is a very powerful tool.

Stage 3 - Develop a Detailed Plan

The "Plan by Feature" stage involves grouping the features into the appropriate feature sets and subject areas / majopr feature sets. Also at this stage a weighting and sizing of each feature can be conducted. The total resources, in both time and staff can then be assessed for the construction phases. A properly developed Feature Plan can lead to incredibly accurate estimates for construction.

Stage 4 - Design by Feature

Features are bundled into manageable sets through agreement between the project manager and the chief programmer. A small set of features will be designed and built as a unit by a feature team. A feature team is typically 2 or 3 programmers.

Each feature leads to the development of a Sequence Diagram in UML. This is the design deliverable. This will be peer reviewed by the feature team against the requirements, the guidelines for architecture and development, and the design review checklist. A successful review will see the feature enter development.

Stage 5 - Build by Feature

The code for each feature is then written by the appropriate members of the feature team who own the business classes affected by the feature's functionality. Once complete, the code is delivered for peer review. When unit tests are complete and the code passes review, it will be labeled for inclusion in the system build.

The feature is complete!

A piece of client valued function has been completed in two weeks or less by a small team of developers. We have delivered a frequent, tangible working result!

Having thought through what a feature might look like, the next job was to consider what the model of a UI might look like. In 1998, I felt that this was probably based on a storyboard of the screens. A Navigation diagram. At the time this was known as a "high level design". I now consider this totally unsatisfactory. Navigation modeling is a the process of mapping a storyboard for a UI in an engineering notation. There is currently no standard for this but the leading work in the area belongs to Dave Roberts of IBM's Ease of Use group, OVID [Roberts98]. Constantine and Lockwood have also done considerable work in the area of model driven interaction and interface design. [Constantine99]. However, at this time tool support is sparse. When you are running at web speed, you must reject any method which cannot be automated in tools. I have therefore ignored the Navigation model (the high level design) and focused on the Implementation model (the low level design), for the model which will drive FDD for user interface.

Directly following earlier work by Ian Horrocks [Horrocks 98], I am proposing that the implementation model for a user interface design is delivered using David Harel's Statechart notation which is already adopted into the UML. This provides ready availability of modeling tools and the support of an open standard. FDD for UI is therefore a Statechart model-driven method for presentation layer project management.

Stage 1. Develop a Statechart Model

From the user interface prototype, storyboard or navigation model, develop a Statechart Model. This model should be wide. It should cover, at least, the whole of a Subject Area from the business features list.

Modeling a UI with Statecharts has been explained in detail by Ian Horrocks [Horrocks 98] and in the Web MVC articles here at uidesign.net [Anderson 99]

Identify the Views from the Navigation model, storyboard or prototype which are associated with appropriate states.

Stage 2. Develop a Feature List

For each State which has a View associated with it, list a feature in the format,

<purpose of screen> View
e.g. subscriber search dialog View

For each Event coming from each View, list a feature in the format,

<action> Event
e.g. search Event

The <action> should be named from the button or control which was affected in order to create the event e.g. a button labeled "Search" would create a 'Search Event'.

Note that several transitions from the same state can actually be using the same event. Do not create a feature for each transition, only 1 for each event.

Transient Business Features

There is a third type of feature created from the UI. I am calling these Transient Business Features. These are additional to the existing features from the Business Layer which I am now proposing are known as Persistent Business Features.

Transient Business Features are created by the requirement in the UI to display information which does not affect the persistent state of the business objects. These features are often associated with transient collections. For example,

List the Subscribers for a given Search Criteria

This feature is still being written in the agreed format for business features, <action> <result> <for|to|of|from> <object> but the object is a transient e.g. a search criteria and the result is a transient e.g. a collection of Subscriber objects. It would normally be implemented as a class method, or directly onto the persistent data store.

This first class of Transient Business Features usually manifest themselves in the guard conditions or the actions on the transition arrows on the Statechart.

There is a second type of Transient Business Feature. These are generated by implementation dependencies. For example, in a distributed environment such as the J2EE platform, it may be necessary to build fine grained data objects to facilitate "pass by value" from the business layer implemented as EJBs in the application server, to the presentation layer, implemeted as JSPs or Servlets, in the web server. Code needs to be written for these "pass by value" structures. This code is tightly coupled to the display object and is most definitely transient.

An example of a "pass by value" Transient Business Feature might be

Get the data for the account summary table

These "pass by value" features are hard to spot because they require detailed design. However, they will impact your planning. If you decide not to list such features then be sure to size View classes appropriately as to include time to develop any "pass by value" code which might be necessary.

Stage 3. Develop a Detailed Plan

Number each feature for tracking purposes. Insure that each feature is traceable to a requirement, a use case, an element of your navigation model or your storyboard, or all of these.

Group features into sets using Strategy 1 from above. Each set should contain a View, any sub-views, all the Events from the View, and any Transient Business Features which resulted from the Event transitions for the View.

Develop subject areas of feature sets by identifying all the UI features required to deliver the interface onto a subject area from the business layer.

Now weight and size each feature.

The 5 point scale

I have developed a 5 point scale for this purpose. Following on from lessons learned from Fred Brooks [Brooks 95], the scale is non-linear. The scale is used later for tracking actual against plan and adjusting estimates as project progress is reported.

A planning team which typical consists of the project manager / project office staff, some of the modeling team or analysts, plus the chief programmers will make the estimates. Each feature will be briefly discussed and a weight assigned. For a project with 500 features, this weighting can be performed in a typical afternoon planning session. It is well worth the effort.

If a 3 person feature team were given 3 features to design and build, all of weight 3, then it ought to take them 2 working days to develop the design material, review it amongst themselves, write the code, perform some unit tests and and review the delivered code. Typical, work bundles will be 5 to 10 features per chief programmer.

In recent studies, where the emphasis was on web development of presentation layer, the average complexity of features, modeled using the methods described in this paper have delivered an average complexity weighting of around 1.6.

In other words a typical web page can be build as a JSP by a single programmer in 1 day, and a typical event controller, can be build by as a Servlet by a single programmer in half a day.

So far this scale has proved reliable, needing only minor adjustment during the development lifecycle. At the very least it provides a good basis for evaluating plan vs actual performance.

Business Features and the 5 point scale

I have also used the same scale for business features. One rule of thumb which I have adopted is to assign points on the scale against the number of affected classes for the feature. During the planning, we are only guessing at the complexity of the sequence diagramming but a good guess is good enough. Normally, there are enough features that guessing will average out over the whole project.

This scale worked well at ebeon.com, in 1999, where it was used to predict the resources needed for the business layer development on a medium sized project with 153 business features, to an accuracy of -10%. In other words, development actually took 10% longer than predicted but the bug count of only 5 reported errors against 153 features meant that the slight time overrun was broadly acceptable, as the time could be made up during system test. Feature Driven Development run properly with design and code reviews leads to a high quality of delivered code.

More experiments and more data points are required to see whether the 5 point scale is of true value.

Stage 4. Design by Feature

At this stage the deliverables become implementation specific. The project office will assign features to a chief programmer who will work with the feature team to design and build them. Developers on the feature team will be assigned Views or Controllers to build. They may also be assigned to work with the business layer developers to provide the transient business features.

The design output in a JFC/Swing project might include a class diagram detailing the JFC components being used and how, as well as detail of the Event classes being used, the Listener inner classes acting as controllers, and the JFC classes acting as Views. A Sequence Diagram showing the interaction amongst the presentation layer components and how they interact with the business layer classes may also be needed.

In a web environment, a design detailing how the Controller or View is being implemented together with a Sequence Diagram of interaction with the business layer, may be needed. If an infrastructure similar to that decsribed elsewhere at uidesign.net [Anderson 99] were being used then the developer would detail the logical names of events, the parameters being passed and the transient or persistent business methods being called to implement the guard conditions and the actions.

The feature team would review the design documentation against the requirements, the Statechart model, the architecture and design guidelines for the project, and the design review checklist.

Stage 5. Build by Feature

Each developer builds their assigned classes or adds appropriate methods to existing classes. Unit tests are run and results collated. Code is brought back to the feature team for review. It is reviewed against the design documentation from stage 4, together with coding guidelines for the project and the code review checklist.

If the chief programmer is satisfied that the work is complete to the agreed standard then the feature is marked as complete and the code is promoted to the system build for handover to the system testing team.

Modeling with Statecharts - a review

Modeling the user interface with Statecharts has been discussed at uidesign.net before. However, it would be appropriate to review how it is done and how it helps to develop the UI Feature List and facilitate the development of the presentation layer code.

Practical experience using Statecharts for user interface design have shown that it is not completely up to the task in its current form. There are three key areas where Statechart notation is not currently sufficient for the purpose of user interface modeling. The first is the notational scoping of transactions or units of work. The second is the ability to cope with processing exceptions where the normal flow of states is interrupted. The third is derived out of the hierarchical nature of user interface design problems. This leads to a large depth count in the hierarchy of states which diagrammatically problematic. Drawing user interface implementation models with current Statechart notation is difficult. Suggestions to change the notation were made in the TUPIS 2000 Position Paper [Anderson 00]

Finally you should adopt a naming convention emerge for States within Statechart diagrams, so that is possible to identify a given State on a diagram and understand its position in relation to others in a hierarchy. Make this naming convention part of your standards and guidelines for your project. Encourage its use and discourage deviation from the naming convention. Deviation will only slow you down later.

The modeling tradeoff

Recently, I have had very good feedback from developers on the use of modeling with Statecharts. Comments like, "It has been really useful to do this, it really makes you think carefully about how the application should work." "Modeling with Statecharts has really helped me to understand what we are doing". Overall I have noticed a marked improvement in team confidence after completing the Statechart modeling exercise. I believe wholeheartedly that the effort pays back in improved team understanding, clarity of work to be carried out, and improved quality of deliverables. The only cost is that you must keep the Statechart model accurate during development. As UI design changes arrive from the user experience team, you must insure that the model as well as the code are kept in sync.

An example of statechart modeling for a UI Feature list

In Diagram 2, there are 4 Views called: First Page; Second Page; Good Exit; and Bad Exit. There are 2 Events: Submit Name and Address; Submit Credit Card Number. [Note these are not particularly good names for the events]. There are only two Events because the transitions coming from "Second Page" View have the same event. This event would be processed through a Controller which is described in the Mediator Pattern in the seminal text on the subject, Design Patterns [Gamma 95].

There is arguably one Transient Business Feature - "validate credit card number". The transaction start and commit or rollback requirements do not need to be considered as features, they are merely design detail for the Event features.

[The transaction boundary shown below is a manually added embellishment and is not supported by any Statechart modeling tools at this time]

Exception States

In Diagram 3, we are modeling the catching of exceptions and displaying appropriate error recovery screens. Modeling exceptions is currently not supported in Statecharts, so you will need to add these manually or improvise through the use of Start States labeled as exceptional starting points.

Arguably each exception catching point should be listed as an Event feature. It is merely an "unexpected" event - an exception. The screen displayed after the exception is just another View for the feature list.

Tracking Progress with Precision

Feature Driven Development is a model-driven process which uses a fine grained plan representing all of the tangible, business valued deliverables in the system. It is a process which focuses on output. Simply measuring the delivery of output would provide better project tracking than many other methods. However, FDD can be used to get an even finer grain on control. It is possible to measure each feature during the lifecycle.

Stages 1 through 3 are measured as follows:-

On completion of the initial Statechart model, the presentation is 10% complete. Once the feature list is completed, it is 13% complete. Once the plan has been constructed and all the features weight with the 5 point scale then we are 16% complete. A total of 7% is assigned to be amortized over the remaining lifecycle of the project for rework, revision and changes to the initial model and plan.

Stages 4 and 5 are broken down by each individual feature. In other words, we will track progress for design and build of each feature and aggregate the completeness of each feature to give an overall figure. In total stages 4 and 5 are worth 77% of the effort. When all the features are complete we will be at 100% and the system will be ready for system and user acceptance test phases.

Each feature is tracked as follows:-

The Design phase of each feature has 3 stages. The requirement should be explained to the feature team by an analyst or business stakeholder. The appropriate design materials should be developed e.g. class and sequence diagrams which can be mapped against the statechart model for the feature. Finally, the design is reviewed.

The Build phase is also divided into 3 stages. The code is developed. It is then reviewed against the design documents from the previous stage and against guidelines documents for the project. Finally when the chief programmer is happy, the feature will be promoted into the build for the whole system. By assigning a single percentage point to this stage, a feature cannot be complete until the work is truly complete and has been handed off for inclusion in the build and system testing.

The role of the project office or project manager is to gather reports from each chief programmer each week. [Weekly intervals have proved often enough] For each feature currently in development, determine which stage it has completed and assign the appropriate percentage complete score. Sum all the scores for all the features on the project and multiply by 77%. This will give the overall progress for the "Design by Feature - Build by Feature" stages of FDD. Add the number to the numbers for stages 1 through 3 and you will have an overall percentage complete score.

Accuracy

The progress score for an FDD project is remarkably accurate. The error rate is often less than 1%. If you track progress week to week then you can get the derivative value for the speed of progress. This can be used to calculate the end date.

BEWARE: As Fred Brooks explained at great length in The Mythical Man Month [Brooks 95], the industry is non-linear. So the speed during the early weeks of the project will be slow. However, if you have not reached a sufficiently quick pace with 33% of the features completed then you are late! With 1/3rd of the project complete your team should be running at optimum speed.

Refactoring the plan

If you are late then use the completed features and the scores for actual delivery effort versus estimated effort to refactor the values on the 5 point scale. Recalculate the whole plan and derive a new delivery date. Take that date back to the client.

The client can do one of two things. He can look at all the incredibly accurate data you can give him and he can take the view that your revised date is very very accurate. He may decide to accept that new date. Or he can insist that you stick to the original date. This would be the norm on web projects. So you, as project manager, have to conduct some tricky negotiating with the client. Ask them to adjust the scope of the 1st deliverable and try to drop some functionality which was agreed earlier had a lower ranking.

Feature Driven Development is a relatively young method for project management of object technology projects. It has been developed over the last 3 years by developers who desired to have a process which facilitated the development of good quality code, whilst minimizing the overhead of project management paperwork.

FDD involves the use of artifacts which directly affect the code developed. The work on project planning and estimating is directly usable in the development cycle.

FDD measures output, not input!

FDD offers highly accurate planning and tracking of small, client valued deliverables.

FDD offers programmers the job satisfaction of knowing that they got to be "complete" at least once every two week, delivering a client valued piece of code.

FDD for UI utilizes readily available tools and through the use of statechart modeling, greatly enhances the quality of the deliverables through improved understanding of the application across the whole development team.

FDD is in use on internet projects across the world, and is helping those project to deliver "frequent, tangible, working results," "on time, on budget, with agreed function".

The original team from the Commercial Lending System project in Singapore has dispersed to new projects and new employers throughout the world. Those new employers are seeing the benefits that FDD can bring to internet time development.

Finally, FDD is still evolving. As each project goes by, each of us who was involved from the beginning learns something new about how to run small, medium or large scale internet projects using OO technologies. As more people use the technique, more tools become available which support it. Though in truth, all you really need is a UML compliant modeling tool, a web server to publish documentation on an intranet, and a spreadsheet which can output to HTML to report the progress.

References:

[Coad 99] Java Modeling in Color with UML, Coad, De Luca, Le Febvre, PTR-PH, 1999. Specifically, Chapter 6 available in PDF Format from Togethersoft.

[Palmer 00] Feature Driven Development and Extreme Programming, The Coad Letter #70, Stephen Palmer, 2000

[Palmer 00-2] The Domain Neutral Component, The Coad Letter #68, Stephen Palmer, 2000

[McConnell 96] Rapid Development, Steve McConnell, Microsoft Press, 1996

[Roberts 98] Designing for the User with OVID, MacMillan, Roberts, Berry, Isensee, Mulally, 1998

[Constantine 99] Software for Use, ACM Press, Larry Constantine & Lucy Lockwood, 1999

[Horrocks 98] Constructing the User Interface with Statecharts, Addison Wesley, Ian Horrocks, 1998

[Anderson 99] Server-side MVC Architecture, David Anderson, uidesign.net 2000

[Anderson 00] TUPIS Position Paper, David Anderson, uidesign.net 2000

[Brooks 95] The Mythical Man Month, Fred Brooks, [insert publisher here], 1995

[Gamma 95] Design Patterns : Elements of reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, Addison Wesley, 1995

The Class Diagrams and Statechart Diagrams used in this paper were produced using Together/J v3.x from Togethersoft. The Transaction Boundaries, Exception States and other proposed additions to the Statechart language were added to the standard notation using Photoshop.