PROCESS 1 – DEVELOP AND OVERALL MODEL

A initial project-wide activity with domain and development members under the guidance of an experienced object modeller in the role of Chief Architect.  

Process 1 involves the project team creating an object model of the business domain that is more shape than content. The model is not fully defined with all attributes and methods, it is more about getting the shape of the business domain captured correctly in an object model, not capturing every detail.

The process is highly collaborative process where everyone has to work together to create the overall model. It takes an iterative approach where the domain expert explains a part of the business domain. The project team is broken up into groups (preferably 3 per group) to model that part of the domain. The groups then present their models and consensus is reached on which to use. This is then repeated for each part of the domain until everything has been covered. The end result is an overall model of the entire domain.

PROCESS 2 – BUILD A FEATURES LIST

An initial project-wide activity to identify all the features to support the requirements.

Creating the feature list is the task of the Chief Programmers involved in the modelling process. The Client and Stakeholders don’t need to be a part of this process as they have made their contribution in Process 1 and now it is a matter of capturing the project in a list of features. This does not require collaboration, getting a group of people involved at this stage would not be productive or constructive. The key to this process is defining the project using the language of the business domain. This means that the Client will be able to understand and value each feature. It also enforces a common language across the project team and reduces the risk of miscommunication or assumptions.

Poor communication is the basis of most problems in software development. The language we choose has a significant impact on how effectively we communicate. There are many techniques in FDD that help to provide meaningful communication, the most powerful one is in Process 2, defining the entire project in features using the language of the domain, i.e. using the Client’s language. This might sound simple and obvious but should not be underestimated. The focus that this brings is incredible and affects the project in many ways.

In FDD, everything is described as a feature which is defined as

action the result  by/for/to an object

For example

calculate the total for a sale

calculate the total sales for a cashier

A feature is also defined in terms of size, ie. more than 2 hours work but less than 2 weeks work. If it more than 2 weeks work, then it should be broken down in separate features.

Having everything defined as a feature avoids the problems that occur all the time when the Client refers to something in one way and the programmer refers to it in another and the Project Manager has to continually interpret. If the Project Manager doesn’t get it exactly right, mistakes happen, the programmer thinks they are building one thing, the Client thinks another. Using the same language doesn’t mean the problem disappears, but it reduces the risk considerably.

PROCESS 3 – PLANNING

An initial project-wide activity to produce the development plan.

This process extends the benefits provided by Process 2. It provides the Project Manager with a way of planning the development phase in a meaningful way for both the client and the programmers. It is done in conjunction with the Development Manager and Chief Programmers. They look in particular at the order in which features will be built, balancing load within the team and strategies delivering early results to keep the client happy.

 

PROCESS 4 – DESIGN BY FEATURE

A per-feature activity to produce the feature design package.

Process 4 is broken down into three steps, walkthrough, design and inspection.

In the walkthrough, programmer familiarises themselves with what they are about to build before starting on a detailed design which is then inspected before they can start building. The inspection of the design means defects can be found and removed before a single line of code is written for that feature.

It might seem like commonsense to design and inspect before building but it is often ignored. In many other industries, the idea of building something before it has been fully defined, designed and planned would be considered negligent, yet it happens all the time in software development. The first reaction of many programmers, especially in web development is to open their favourite editor and start coding. The amount of risk that this approach exposes to any project to is enormous. However the converse can also happen where there is an attempt to design everything upfront and can often result in “analysis paralysis”.
Exactly how much design should occur upfront is a hotly debated topic amongst advocates of agile methodologies. The approach taken in FDD is seen in the difference between Process 1 and Process4. As we have seen, Process 1 includes design early in the lifecycle, but it is not a detailed design. The detail is left to Process 4. Putting the detailed design in Process 4 ensures that it is considered at the right time – before the code is written. It also breaks the design down into meaningful chunks, feature by feature. This means programmers don’t feel like they are spending all of their time designing and no time coding; immediately after the design has been completed and inspected, the programmer can start coding.

 

PROCESS 5 - BUILD BY FEATURE

A per-feature activity to produce a completed client-valued function (feature).

Process 5 is also broken down into three steps: code, code inspection, and promote to build. As with Process 4, the idea of collaboration and benefits inspections is enforced. What makes Process 5 unique is the final step “promote to build”.

For code to be “promoted to build” it must be finished. The key to this is the definition of “finished”. A feature is not finished until there is nothing else to be done. The way a Project Manager can test if a feature is truly finished is simply by asking, if the programmer answers “yes”, the Project Manager then asks “so there’s nothing else to be done?”. This often gets a different answer. It’s not that the programmer is being difficult or misleading it’s just that given the chance, many programmers will continue to work on code, tweaking, optimising or trying to improve it. If there’s time to do this then it’s not a problem, but if there’s a tight deadline, the Project Manager needs to focus programmers on getting the project completed and this is a great way to ensure that focus.
 
The other benefit of this Process is that helps the Project Manager see clearly how much of the project has been completed and how productive each programmer is. According to Gerald Weinberg (Quality Software Management Vol.1), the productivity difference between programmers can as much as 20 to 1. The issue is how to assess the productivity. Even though features might range in size from 2 hours to 2 weeks of work, it doesn’t take long for the Project Manager to assess how much work each programmer is actually producing once the variances in feature size are taken into account.