Feature Driven Development

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).

!

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.

Jeff

Hi,

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.

Jeff