Old discussions

admin's picture

These posts were collected from the previous forum, and have been archived here.

New discussions should start a new topic in the forum (but feel free to contribute to the threads of discussion below).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

FDD and safety critical systems


Anyone got any experiences or stories about applying FDD (or other agile methods) to the development of safety critical systems ?

Would be interesting to see how the rigourous requirements of safety critical systems interact with agility of FDD.

Jeff De Luca's picture

Classes of Software System and Project Phases

Hi Mark,

first I would need your definition of safety critical - but here's some general thoughts.

If we use the simple waterfall-ish phases of requirements analysis, design, code, and test to describe the major project activity areas, we can then plot different classes of software systems against these phases.

For example, for the classes of software systems we could start with freeware at one end of the scale. Then shareware, shrinkwrap, application system, operating system, and so on all the way up to man-rated where man-rated means if there's a defect someone's life is at risk (could be a space shuttle on-board computer,or medical equipment, etc.). (obviously there could be quite a classification of software system types here - this list is not meant to be exhaustive).

As we move along this scale of classes of software system, what changes are there in terms of the time and effort spent in the project phases: requirements analysis, design, code and test?

Well, as we move along the scale from freeware towards man-rated, more time and effort is spent in requirements analysis, design and test. As we move along the scale, the coding portion as a percentage of the total becomes less and less. Also, as we move along the scale the verifications mechanisms each phase become more and more important and rigorous.

I've visited NASA in Houston when IBM FSD (Federal Systems Divsion) did major work there and I've seen the rigours at that extreme. I've also worked in IBM Programming Laboratories in the USA at the operating system level for midrange and mainframe class systems.

At NASA, and less so at IBM, coding becomes almost a data entry operation. That is, so much analysis and design is done before coding that coding becomes almost as simple as "key these statements in".

At IBM Rochester in the 80's their first two inspection levels (I0 and I1 as they were called) resulted in an enormous amount of analysis and design work being performed. The I1 is at the level of psuedo code.

The point of all this background is to say that as we move along the scale of classes of software system towards safety critical and man-rated there is more emphasis on requirements analysis, design and testing and the verification of each phase.

Feature Driven Development can play well here. Process #1 in FDD - Develop an Overall Model is also a Requirement and Requirements Analysis step. Process #1 can also be described as the informational and analytical activity that must take place in order to establish a reasonably accurate project baseline.

Then, in Feature Driven Development we again have the emphasis on design at the feature level in Process #4 - Design by Feature plus we have the best-practice (and measured as such ) use of formal design inspections and code inspections for verification - again at the feature level.

Thus, we can see the Feature Driven Development has the framework and already has the right points in its framework to be able to extend to cater for the demands of safety critical and beyond.

Whereas in a more typical Feature Driven Development project we are only spending roughly 2 weeks in Process #1 for every 6 months or project time, and the level of individual feature design and inspection is left to the discretion of the Chief Programmer; we can easily extend towards the additional needs of safety critcal software systems.

That is, the informational and analytical activites associated with Process #1 will be much more and run for much longer. The features List in Process #2 and the Planning in Process #3 are essentially the same.

For Processes #4 and #5, there would be a detailed design for every feature and formal design and code inspections - rather than this being at the discretion of the CP in a typical project.

FDD has the framework to scale up in this way. That's because, in part, it came from my experiences in the labs where I saw such rigours but wanted a way to scale them down and make them not only practical, but effective in the kinds of projects most of us do. Line of business systems - for example. (only a fraction of the programmer population writes for safety critical).

I'm not saying you should use FDD as-is for man-rated systems.What I am saying though, is that FDD can be easily extended towards that as its framework has the right points for such extension. What you'd end up with would be far more rigorous and with many more artifacts than regular FDD, but what you end up with could easily have a Features List at its core plus the Feature and Workpackage workflows in FDD and its tracking mechanisms.

The granularity of the feature in FDD is a part of what makes it so agile. The granularity of the feaure, for example, makes implementing known best practices such as inspections so much easier than before (e.g. here's a 500 page COBOL program - there'll be an inspection next week).


Actors in the FDD process


Reading through the latest FDD processes, a number of actors are mentioned to be involved in a FDD project; e.g. project manager, development manager, chief architect, chief programmer, developer, business, and domain expert.

Where can I find a description of these actors, with their responsibilities and activities in each phase?


Rudy D'hauwe
UsToBe Software Foundation

-- Better Software Faster
-- Download Scottit for Resin monitoring and administration

Jeff De Luca's picture

Roles (Actors) are problematic

Hi Rudy,

your question is about Roles (actors as you call them) and there are several issues with Roles.

  • There is a problem with role names in general (there are no crisp consensus definitions for them) and it is industry-wide and the fdd processes therefore suffer from this as well.
  • Some of the role names in the FDD processes are plain wrong - meaning very poorly named (e.g. chief architect in process 1).
  • There are role-to-task mappings that are not crisply defined in FDD (e.g. the project manager versus the dev manager).
  • It is possible that some roles will be added to the current FDD processes (e.g. the process 1 facilitator). I've been revisiting this aspect lately as some of the newsletters I've been writing raise the issue. However, this has to do with what you include and what you don't include in the fdd processes - and this (their being "well bounded") is one of their major value propositions.
  • Finally, there are some points in the processes where input and inluence can come from multiple sources. It is possible that roles may be the way to deal with making this explicit in the processes (by abstracting the people that can play the role away from the role itself). Another way may be to simply make it explicit in the processes narratives and relevant task descriptions. Or, it may be that these things should not be included in the fdd processes (e.g. customer-driven vs technical-driven scheduling).

Now, in case that makes thing sound really bad let me say that things are actually pretty good. The role names used in the current FDD processes (with the exception of chief architect) are from the mainstream and suffer less from the lack of industry-wide consensus definitions. Also, it is trvial to construct the role to process and task matrix from the current processes (your actors to responsibilities and activities in each phase). The Role name column above each task in each of the processes makes it explicit which Roles are involved in that task - and therefore the process that contains the task.

Furthermore, it is also easy to extract the responsibilities for each Role from the task descriptions (and process narratives).

This is all, of course, bounded by the 5 FDD processes.

Having done these steps, you would have FDD Role names (actors) and their Tasks (activities and responsbilities) in each Process (phase).

If you then considered these realy as Role names and the Roles being defined by their Tasks, then you could map the Roles onto people in your organisation - whatever their title may happen to be.

FWIW - I'm heavily leaning towards a process update that addresses the Role issues mentioned in the bulleted list above, as well as adding other entry criteria and elaborating some of the processes - in particular process 1 Develop an Overall Model.


FDD and web desing

Is there any studies where web desing is applied into FDD process???

Jeff De Luca's picture

Do you mean applying FDD for webpage projects?


I'm not sure what you mean. If you mean applying FDD to the building of simple websites (brochureware or simple backend scripting only) then yes there are several companies I know of that have done that. Sausage Interactive (which at the time was Australia's most famous Internet company) applied FDD and I believe (could be wrong though) that SMS (the company that now owns them) still does so.

Also Martin Bauer - who was the dev manager at Sausage - applies FDD at his website company - designit.com.au.


i know my english is not good

What I tried to say is if there is any documents, web site, tutorial, books, etc. about FDD and Web developments.

I'm trying to apply FDD in the company I work, and It could be good if I have any guidelines of how can I introduce another roles like web designer, UI behaviour especialist and so on.

Regards, Enrique.

Jeff De Luca's picture

The FDD processes do not address User Interface explicitly

Hi Enrique,

you could try some of the work by David Anderson at uidesign.net. I know he was, at one point, working on an FDD for UI (User Interface) and there are several papers on that site.

I don't have a system for UI. I solve it each time by hiring the right person, bounding and then delegating to them. That's hardly a system though! Eye-wink


web development & fdd

Hi Enrique,

I tried to apply FDD to the web development firm that I worked for back in 2000. I got lead developers, designers & project managers involved so that we took a whole company approach. Basically, we found FDD was great for dealing with project management issues and capturing the business logic but did not cover interface design.

The simple answer is that interface design has to be seen as another part of the project. We tried to create interface features and capture them in the same way - not very effective. We tried to map screen design to features and that didn't work very well either. In the end, you have to look at interface design as a separate stream (how to actually do this is something I'm still working on!)

Below is the outcome of a workshop that we held about using FDD which might help.

What did we like about FDD as a software development process?

  • Excellent reporting & planning
  • Risk Reduction via
    • iteration of design & build in small chunks
    • clarity of requirements
    • better understanding of system to be built
    • no wiggle room - less assumptions
    • more accuracy in requirement gathering
  • Provides a starting point for modeling using existing models
  • Disciplined & Clear
  • Customer Focused

What did we dislike about FDD?

  • High reliance on Tech Leads
  • Doesn't deal with User Interface design & build
  • Not as powerful on smaller projects (ie, one developer, only one person modelling)
  • Doesn't cover testing & deployment
  • Not a Silver Bullet!

What can we successfully use from FDD in our work?

  • State requirements as features (customer focused)
  • Reporting
  • Team Structure
  • Plan development based on features
  • Code & Design review process
  • Weekly project status meetings

How ?

  • Implement weekly project status report meetings
  • Build an FDD reporting system
  • Educate Account Management, Business Development and Management on how it works
  • Get colour modeling training
  • Define new projects in features
  • Use FDD on intranet as a pilot project
  • Trial colour modeling on some projects
  • Monitor progress of FDD integration
szego's picture

What is a "Feature Set"?

I've seen feature set mentioned in a few posts, and some mapping to work packages and worksheets that I don't understand.

From the feature list we have the breakdown of subject areas to business activities to features.

Then for design and build we have work packages. A worksheet is just the "paper trail" of artifacts produced for a work package - it doesn't define any other structuring of feaures.

And we don't use "feature sets" anywhere.

What do others mean when they use this term? I expect there might be some confusion out there, perhaps since there's been nothing written to date about the workflow side of FDD.

Definition of Feature Set - JMCU Chapter 6 Section 3


I believe that the term Feature Set refers specifically to the definition given in "Java Modeling in Color" Chapter 6 Section 3 <action>ing a[n] <object>

FWIW I find Feature Sets problematic. I find Subject Areas very useful and easy for the domain owners to understand. I find Feature Sets difficult to define and arguably not useful in their groupings. IMO all the features in a CPW (work package) should come from the same grouping. I don't always find this to be the case with the current advice on Feature Set.

I also hate the name "Feature Set", so I would like to see more published in this area and the concepts explored better.


David J. Anderson
The Webzine for Interaction Designers

Jeff De Luca's picture

That's a selective reference though

Feature Set does come from JMCU chapter 6 (which I wrote). But if that is your point of reference then you can't use Subject Areas as they should be Major Feature Sets.

Jeff De Luca's picture

More Information

I really should have a little more about this.

The drafts for chapter 6 of JMCU attempted to use more meaningful names for the categories of the features list. Business Areas and Business Activities where the terms used for several revisions. Near the end, we couldn't agree on a "great" set of names and so, to avoid the issue entirely, a generic or abstract set of names was used That is, simply collective names for the noun involved. Thus Major Feature Set and Feature Set.

Here is the actual text from an earlier JMCU chap6 draft.

First, from the overview.

"We first do Shape Modelling where we are focused on understanding the domain to then identify the classes and their connections. When then build a features list where a feature is something tangible to the business (client) and we categorize features by business areas and business processes."

And then from the detail.

"A feature is a very small but tangible piece of the domain that means something to the business. Partition the domain into major business areas. For each area, list the major business activities. For each activity, list the steps. This sounds harder than it is. You will find it very easy to categorize the domain in this way and in doing so, you are identifying features and categorizing them at the same time."

This captures the essence of what the Features List processs is all about. It is simple functional decomposition of the domain. For each Subject Area (Business Are using the above text) what are the Business Activities? For each Business Activity, what are the steps? The steps become features by being expressed using the feature naming template and by using the two week rule (to break them down further if necessary).

The point of saying all this is to remind and make explicit what is happening in the Features List process. This makes it clear why Major Feature Set and Feature Set are such poor names. They move far too far away from what it is we are actually doing.

As I've told Palmer before, if I hear of a better name than Business Activity I'll use it. Feature Set however, sucks toxic waste.

Also remember, that a Business Activity becomes a parking lot. It's very important these are meaningful to clients. They naturally are when decomposition of the domain is used as described above.


szego's picture

Sets of Features

The latest FDD processes use Subject Area's and Business Activities as the two levels of decomposition. Take a look at http://www.nebulon.com/ for the latest definitions.

We don't use the name "feature set" anywhere in the current descriptions of the processes. The term "set of features" is used in only two places:

  • When building the feature list, we identify the entire set of features as part of this task. See FDD Process #2 - Build a Features List for more information. This is simply "the features list".

  • In FDD Process #4 - Design By Feature we define a Work Package as a set of features that are scheduled for development.

So the only groupings we have are the entire features list, business activities, subject areas, and work packages. Problem solved - we don't use that term anywhere!

As far as grouping of features into work pacakges, there is no such constraint. We often find it useful to group features from different business activities or even subject areas into one work package. There are a number of reasons, but it all comes back to workflow: the CP decides what to do next based on all the factors they need to balance.

Often a series of business activities within a subject area will involve similar classes, and it's not unusual that a work package might span more than one of these. Especially in the case where we have a large number of low complexity features - we often bundle quite a few of these together into one work package if they are focuessed on a few core classes. If there's little or no dependancy on other classes then this is quite easy to schedule and an efficient way to crunch through these features. For the same reasons we might elect to include features from across different subject areas.

Remember that the features list is a functional decomposition of the domain. We usually have the first level of decomposition provided by the way the domain experts have chosen to break down the domain walkthroughs into pieces. This is completely different to the object model. The model is not broken down in this way. We model the domain, not subject areas. We might sneak up on an overall model by doing component models one at a time, maybe one subject area after another, but the overall model emerges no matter which way we attack it.

By placing these constraints on work package feature selection we are implying an artificial relationship that simply doesn't exist. Given this, why force ourselves into this situation? I can't see what is to be gained.

Jeff De Luca's picture


Correct. The processes were on this site as well actually. They are (were) in the Files section. They will be back as soon as the Files section is working again after the site upgrade.

We're looking at adding the glossary module to this site also and then I'll use that to enhance the standaad by defining terms and acronyms. For example, we also have CPW being used in posts here instead of CPWP (chief programmer work package). It will be helpful for all to get consistent on one set of standard acronyms and definitions. I think that's another useful role this site can play.