Extending FDD

Mon, 04/18/2005 - 15:20 — nbplopes

Following the topic around Projects Aspect, my interest in FDD extensions and adaptations has grown. I've been doing it for a couple years, but in the last few weeks I've been looking for a more normalized approach to the issue that encompasses needs beyond the traditional PD, DM, UI and SI aspects (for instance to include Documentation).

Probably people have tried to do this before hence raising this issue on this forum. To jump start let me introduce what I've been thinking, so invite you to clarify and challenge these ideas so we can come to a conclusion that is satisfactory.

The problem that I have with FDD is that the method for tracking artifacts in use is "limited" the development phase (DBF/BBF iteration) has the process is defined. In other words, just because all features are marked 100% may not mean that the project is finished and the "product" is delivered. This because features are taken and defined over an overall domain model designed (Object Model) on the 1st phase, and the description of this (ETVX Template) phase does not take into account issues such as UI, Documentation, Installation etc, just to name a few things. Only the concepts that need to be developed in the PD layer are taken into account. Although we can argue that these are not issues from developer's point of view or that this layer is the most important (etc, etc) and I tend to agree, it means that FDD does not cover the SDL as whole. So this "tool" may not be adequate at first to some projects from the start. In spite of this, the underling concepts of the tracking strategy have the potential to be used not only to track de development of features but also other "things".

I started to create a model that is based on the principles of FDD and that would also suffice other "deliverables". IMHO the feature list and the way it is defined have the potential to be used as the basis for all things, including documentation, installation, testing, etc etc. This is a good practice and the reason FDD fascinated me in the first place.

The extensible FDD process:

So I started thinking that a feature list may actually be the base line inventory of deliverables considering that a feature can be seen as a deliverable (of course it all depends how use the list but as the name implies we are talking about deliverables, so a database connection or connection pooling might not be seen as a deliverable but an architecture requirement). Around this base line we have aspects of this list, including PD, UI, DM, Documentation, Acceptance tests. One of them is mandatory; the PD. Overall domain modeling is the first phase of problem analysis (it is practice that I've found to be very useful). But this phase could be extended in order not only to include the buildup of the object model, but the base line UI model, the documentation structure, whatever. The mandatory aspect of this phase still would be the build up of the object model, and others optional.

So we might have a base line list of deliverables and the first and the second phase of the process is the same as in FDD. In the third phase we could now define a definite list of aspects of the project that we want to track - the PD, of course and any other, such as UI, User Manual, Installation, SI, etc. For each aspect we could establish a level of effort estimated for completion. For instance the PD be estimated to take 30%, the UI 60% and documentation 10%. The sum of estimated efforts for each aspect should be 100%.

We could now plan each aspect, For that matter from the base line inventory of deliverables we would select the features that are important for that particular aspect. For instance, features regarding installation would probably no be handled by the PD aspect, whether all other could be. Some features could span across multiple aspects of the project, documentation one of them, but also UI and SI.

For DBF/BBF we could have different milestones for each aspect. For PD, of course the same as described by FDD. But for others, for instance UI, most probably not, and most definably not for Documentation or Acceptance Testing.

As for reporting we now have another level. A level that focus on each aspect of the project and that takes into account the estimated effort per aspect as described above.

In conclusion, this approach is compliant with the standard FDD process, and we can now see progress reports that take into account different aspects of the project concerning a particular feature/base line deliverable, activity or subject to be implemented. So if a feature is 100%, is 100% across the multiple aspects of the project, so completely complete.

what you're talking about has been described by Jeff in many, many places on this site in the past. It's standard - i.e. what we do all the time.

Here's just a few examples: here, here and here, but there are several more if you do a quick search.

In fact Jim Highsmith picked up the parking lot as a standard reporting technique for his more general project management approach, which is possible precisely because it is already used in the way you mention.

WIthin the "standard" architectural layers we talk about (which are not part of the FDD specification) this is exactly what's done for the UI - see the various links. The milestones for UI development are different from standard PD and SI work, and their names and effort (as well as how many there are) are specific to the type of UI work being undertaken (e.g. JSP, Swing, HTML, whatever).

FDD itself isn't specific to any particular architectural approach - you can break down the "stuff that needs to be done" into whatever aspects you choose, so long as the same kind of work is done within each aspect (so that the same set of milestones for all work in that aspect is meaningful).

I've personally seen this done on many large projects going back to 1997 sometime.

I guessed I've been missing some things. Sorry to reiterate the issue.

FDD is involving fast since last year, well at least more information is been puting available by the original practioners.

If we look at the software tools being put forward, they don't deal with Project Aspects, so maybe this info as not yeat been preceived as extremely important.

Thanks for the links. If all, this post helped me to structure my ideas.

"In fact Jim Highsmith picked up the parking lot as a standard reporting technique for his more general project management approach, which is possible precisely because it is already used in the way you mention."

Were can I find info about this?

Best regards,

Nuno Lopes
PS: you have to understand when it comes to FDD and Agile you guys live in the "Guru" world, were most of us don't. We can hardly find time to think about these things and absorbe it all.

I appologise Jeff, if my PS sounded like a criticism. What I mean my Guru World, is of living in a community where people are experts on this subject amongst others and knowledge flows fluintely, wish is not the case of most of us (at least in Portugal). So it is something positive that I wish I could be part of, but I don't due to geographical location. In fact everything that I learned from you guys on this site I've been using it in practice with great success.

Back to the topic,

The business problem is stated on my first post:

"Currently if a feature is 100% complete does not that within the scope of the project deliverables that work on it is finished"

I know, that we can use traditional practices to overcome this, and I've been doing this. But I'm trying to apply an artifact that might solve this problem in a way that can be reused in other FDD projects if the need arises.

So what do you think about what I've writtent (appart from the awfull English misspellings). More precisely:

* Relaxing the constraint a "allocating" a feature to one and only one Aspect. So that, we can allocate the same feature to multiple Aspect (UI, SI, Documentation), meaning a feature to be complete we need to work on its UI aspect, SI aspect, PD aspect and so on.

* The above results in a traceability matrix, were we can track per feature the work that needs to be done within the scope of each aspect.

* Build a cross aspect parking lot report that shows project status not only per business activity on one aspect but also on its multiple aspects if we choose.

The premiss here is that features are well decribed and within the scope of FDD specification (it's a client valuable function that he can read and userstand immediatly). This alone, by experience would sustein its meaning across aspects.

For instance:

"Register new Customer on the Customer List"

As the feature is described we can easily see that we need an UI and it makes sense to be in the user manual. Other features might not.

Becouse I'm thinking about using this technique on my next project, and "upgrade" my excell spreadsheets to cope with it. Also I used the term deliverable rather then feature in my first post becouse it easier to explain in Portugal (I use the term deliverable and feature interchangebly).

But before I would like to know what the reader of this site/community think about it.

This thread has several branches, so you must read my replies to your other questions in another branch here and here BEFORE we get into this discussion in this branch.

I appologise Jeff, if my PS sounded like a criticism. What I mean my Guru World, is of living in a community where people are experts on this subject amongst others and knowledge flows fluintely, wish is not the case of most of us (at least in Portugal). So it is something positive that I wish I could be part of, but I don't due to geographical location. In fact everything that I learned from you guys on this site I've been using it in practice with great success.

No need for any apology. What you said was not taken as a criticism.

* Relaxing the constraint a "allocating" a feature to one and only one Aspect. So that, we can allocate the same feature to multiple Aspect (UI, SI, Documentation), meaning a feature to be complete we need to work on its UI aspect, SI aspect, PD aspect and so on.

* The above results in a traceability matrix, were we can track per feature the work that needs to be done within the scope of each aspect.

* Build a cross aspect parking lot report that shows project status not only per business activity on one aspect but also on its multiple aspects if we choose.

I think this is unnecessarily complex. But I am making an assumption about all of what's important to you.

It seems like what you are really looking for is an end-to-end trackable item that cuts across UI, PD, SI, Documentation and whatever other work needs to complete that trackable item from an end-to-end standpoint.

This is a lot like what most use case people want (and do). A single use case, spans UI, PD and SI (usually) but in your case Documentaiton would also be added.

Now, this could be done with the NunoFeature class discussed elsewhere in this thread. But I have to ask, if that's the thing that matters the most (i.e. the end-to-end or cross-aspect trackable item), then what does it matter tracking PD or UI or SI as discrete Aspects? If this end-to-end trackable item is the thing that matters, then what I think you should do is simply have one Aspect that contains these end-to-end Features (note: now they can be called Features because they now are an FDD Feature).

For example, you have one Aspect, and a Feature within it is "Register Customer on the Customer List" (using your example) and this Feature is not complete until it's UI, PD, SI and Doc is complete. What is the value to you, given such a cross-aspect focus, of tracking Aspects such as PD and UI discretely?

Now, if you go this way you will run smack into the problem of how to define sequential milestones for such an end-to-end Feature for the tracking to work.

This leads into the discussion of why it's better to decouple UI, PD and SI development than to tightly couple them by orienting around end-to-end Features such as use cases.

I never do this. But if someone wanted to, I think a single Aspect is worth consideration.

"Now, this could be done with the NunoFeature class discussed elsewhere in this thread. But I have to ask, if that's the thing that matters the most (i.e. the end-to-end or cross-aspect trackable item), then what does it matter tracking PD or UI or SI as discrete Aspects?"

I still would like to track PD, UI , Doc aspects in particular, and also have a global view (cross aspect) of each business activity and features identified.

So the single Aspect would not suffice this need. So I guess, no one as tried this before.

Nuno Lopes
PS: The most important are of course the core aspects leading to a full functioning solution. A cross aspect view its also important as it allows one to assess if a feaure is fully delivered or simply implemented on its PD or UI aspect.

A cross aspect view its also important as it allows one to assess if a feature is fully delivered or simply implemented on its PD or UI aspect.

No! You're applying two different concepts of Feature again. We can discuss and work on approaches for what you want, but only once we get clear on the terminology. This was the point of the model fragments I posted in this thread.

An FDD Feature is only within an Aspect. You can't talk about a within-Aspect Feature and a cross-Aspect Feature. Give the thing that you want to link Features together across Aspects another name. Then, we can continue this discussion and be clear about what we mean.

Let's call it Deliverable. I have not yet thought of a proper naming to this. Maybe someone can sugest a better name for it (Nuno Feature?).

Within this, I'm thinking that a Deliverable can "behave" (OO language) like a feature within an Aspect (this would suffice I believe the requirement that I stated). That it is, within the PD Aspect it would use exactely the same milestones of Feature. It could signed to workpackages and then developers. On other Aspects it whatever milestones one would think necessary. Maybe I'm overloading the term Aspect as I did to Feature. So let's call it Deliverable Aspect. A Deliverable would comply to the same naming template as a Feature does in FDD.

The baseline inventory of deliveravles is the collection of Deliverable Subjects containing Deliverable Business Activities, that in turn contains Deliverables (funcionality).

So the process would be on the (Build a Feature List) we would have (Build a Deliverable List), on the (Planning Phase) we would need to map Features to Deliverable Aspects (PD, UI, SI, etc). Once a feature is mapped to each Deliverable Aspect, the CP would treat a Deliverable exactely as he does to a feature in FDD. I believe that this is possible.

So all types of reports defined in FDD within the scope of an Aspect could be used.

Cross aspect view of Deliverables could be putten available throught parking lots focused on this concept of deliverables. But for that to work we would need to estimate a-priori effor/weights to Deliverable Aspects, much the same way as we do to milestones.

What do you think, Jeff.

Thanks for your time,

Nuno Lopes

PS: I wish most people would think about the importance of names as you do Jeff. I used to think that it was important, I guess I learned some bad habits.

Considering that there is nothing new, and all this is standard, can you say what you think about giving weights to the different aspects of a project as I stated?

For instance let's say that we start a web project. The project is around developing a corporate site. Obviously things such as usability and UI design are more demanding here then for instance in developing an POS Machine for a supermarket. In this case we could establish something like the following:

Since, the feature list forms the base line of all aspects (which is different then considering each layer a different FDD project), the same feature can have multiple aspects. Say feature F1 (register new customer on the corpotaye site) needs a UI, has some business rules (PD) and needs to be put on the user manual (DOC).

While it is being developed complete we can fore instance have that with respect to all aspects of the project:

We could now have parking lot reports where each Business Activity could be repesented with a square with four smaller pregress bars, each for each aspect of we wanted (and one for the overall).

We could actually build some graphs similar o to CFDs (Cummulative Flow Diagrams) where instead of milestones we have aspects. In projects such as Sites usually the UI aspects is ahead of PD, while in a PO for instance the PD could be ahead of UI etc.

Considering that this been used and fully thought of can you provide me more matured thoughts about this top layer weighting strategy? I been thinking about this issues and I read the information you mentioned, but I have not seen yet this strategy in particular discussed as helpful or not in generic terms.

what's standard is having different aspects (with different sets of milestones). For example on the Singapore project we tracked all kinds of things in different aspects like help authoring, and at a much coarser grain even outsourced development.

As for weighting aspects, I've never seen that done, but what you're talking about now (reporting across multiple aspects) is something that Jeff is better to answer. I know that weighting within aspects doesn't work - despite it looking attractive.

With respect to "feature" - I think we have a definition problem. In FDD terms "feature" is just an "trackable item" in the decomposed list of "trackable items" that we need to build in an aspect - we usually talk about the PD layer. It's not a slice across various aspects that combined provide you some externally visible capability (more like a "marketing" feature). You can use tradiational requirements tracability techniques to map from one thing to the other, but they are different animals. That's what I think you're talking about, if not maybe you could clarify for me?

"what's standard is having different aspects (with different sets of milestones). For example on the Singapore project we tracked all kinds of things in different aspects like help authoring, and at a much coarser grain even outsourced development."

Yes, I know. In fact its was with that info that I started this analysis. In fact I asked Jeff to clarify the definition of Project Aspects as it was not fully clear process wise.

"With respect to "feature" - I think we have a definition problem. In FDD terms "feature" is just an "trackable item" in the decomposed list of "trackable items" that we need to build in an aspect"

"With respect to "feature" - I think we have a definition problem. In FDD terms "feature" is just an "trackable item" in the decomposed list of "trackable items" that we need to build in an aspect - we usually talk about the PD layer. It's not a slice across various aspects that combined provide you some externally visible capability (more like a "marketing" feature)."

Thanks for the clarification. I've been using this definition of "feature" in my projects (the implementation scope of a feature is the aspect). What I'm trying to do to establish a coherent way to extend FDD to encompass the tracebility of feature across multiple aspects (I know that this is not how FDD does things by the book), but there is nothing stating that it shouldn't be done.

As I've stated, one the problems that I have with FDD is that just becouse a feature is 100% (in the PD, so in Reports) does not mean may not delivery of the feature is 100% garanteed (for instance, it is not on the user manual). So I need to define a tracebility matrix on the side.

"You can use tradiational requirements tracability techniques to map from one thing to the other, but they are different animals"

Yes they are different manuals. What I thought is that since each aspect can use a different set of milestones for each feature, this by itself is the process way to deal with the differences.

Considering this, and in other words, what I'm defining in part is a traceability matrix of a feature with respect to all aspects, and use that information to aggregate feature completion values into a single report.

This very simple traceability matrix (across aspects) could be defined in the end of the second phase, or constructed durring DBF/BBF interations.

"As for weighting aspects, I've never seen that done, but what you're talking about now (reporting across multiple aspects) is something that Jeff is better to answer. I know that weighting within aspects doesn't work - despite it looking attractive."

Within the context of my explanation, why it does not work? Remember that I'm defining a traceability matrix, and this weighting is just an estimation of effort for each stream (an average). There might be deviations from the norm, but it does not affect aspect centered reports in particular but eventually the cross aspects reports.

So we can still just track the PD layer only, as FDD does traditionally (simply ignore any other aspects and report only the PD) or include any other Aspect in the reports that you may want.

Apart from the concept of Project Aspects and other FDD things, what I cooked is not standard after all in FDD (but that was not intent). I should have explained it better. I'm actually adding some artifacts. What I want to know is someone tried this before and what do people think about it.

Notice, there is nothing in this model violates the mandatory rules of FDD apart form relaxing the constraint (1 feature, 1 aspect).

I'm sure there are a lot of things that I'm missing.

What do you think?

Best regards,

Nuno Lopes

PS: Just to visually clarify the tracebility matrix, we have business subjects/activities/features on the rows, and aspects in the columns. For each feature we define the "impact" on each Aspect.

well there's a lot of issues raised in this thread to discuss and explain. I'm going to start with a feature as defined by FDD and feature as also used in your example.

First, let me make it absolutely clear. There is nothing wrong at all with anyone extending or adapting FDD in any way they like. I teach a whole topic on how to do this and on some of the more common and obvious adaptations in the FDD workshop. Also, as stated in the readme for this site, at the end of the day I am for whatever it is that works for people - whether that be FDD or an adapted FDD or something completely different.

So, you adding the concept of a project level trackable item that comprises one or more FDD features is fine if that works for you. What's not ok though is also calling this project-level trackable item a feature - because that is confusing. A feature is well defined in FDD. It's the functional deliverable that is contained by a Business Activity (and a Subject Area and an Aspect) and it has a number of milestones.

Since you also talked about modeling this, here's a model fragment of what that looks like.

In FDD as mostly described here and elsewhere, we talk about three common Aspects: PD, UI and SI. But you could create an Aspect for visibility and tracking of any other classification of functional deliverable or work item. e.g. testing or documentation. (Note: these other two aspects plus more were used in Singapore in 1997).

In plain english, the word feature can be problematic because it is easily overloaded. The most common case is similar to what you're suggesting. i.e. some higher level "marketing feature" that may even be thought of before any of the FDD processes have occurred. Note: this is just an example of overloading the word feature. I don't mean that this is necessarily what you ahve in mind regarding timing.

Now, here is a model fragment along the lines of what you're talking about with your project level feature - which I've called a NunoFeature in this model to avoid confusion with a Feature.

The models really make it clear that these two classes are really very different things.

A Feature has milestones, is directly contained by a BusinessActivity (and a SubjectArea and an Aspect).

A NunoFeature is at the level of a Project. It comprises one or more Features from one or more Aspects.

Think about the behaviours in these two classes. What they know. Who they know.

They're just not the same thing.

So, by all means, use your cross-aspect item for the additional tracking and traceability you seek. But calling that item also a feature is not "relaxing a constraint" as you put it. It is to confuse two different things.

one the problems that I have with FDD is that just becouse a feature is 100% (in the PD, so in Reports) does not mean may not delivery of the feature is 100% garanteed (for instance, it is not on the user manual).

To paraphrase: just because a PD feature is 100% complete does not mean a feature is 100% complete because the Doc feature is not 100% complete.

This confusion only exists because of the overloading of feature you have applied.

The PD Feature from the PD Aspect is complete. The Doc Feature from the Doc Aspect is not complete. Thus, the NunoFeature (from the model above) that comprises this PD Feature and this Doc Feature is not complete.

Cool - just find a name for NunoFeature.

It's because you've added this other concept of feature that you've got this problem with FDD of an FDD feature being complete not meaning complete for you.

So we can still just track the PD layer only, as FDD does traditionally (simply ignore any other aspects and report only the PD) or include any other Aspect in the reports that you may want.

This is incorrect. FDD traditionally tracks multiple Aspects - not just PD.

You could argue that it traditionally tracks only three Aspects - PD, UI and SI (as that's what most of the literature would lead any reasonable person to conclude). But, even the so-called poster-child FDD project in Singapore tracked more Aspects than just those three.

Here's a screengrab of part of project homepage for the Signapore Lending project. Five Aspects are being tracked.

Here's an old image referenced in a few threads here that shows how I report status to steering committees or top management. This shows the three Aspects being reported - not just PD (Business Logic).

What Jeff is describing in terms of aspects, we at PE look at it a little differently.

In brief, FDD is a process that focuses on producing a deliverable and tracking the progress of building that deliverable. If you simplify the FDD model, you can look at it as what we call the five finger meta-model proces - Model, List, Plan, Design, Build. The focus or aspect, then becomes the specific type of deliverable your are producing, be it PD layer code, UI layer "code", or documentation layer "code". This maps very easily to the examples that Jeff used. It also extends to other non-code type things, but we can discuss that later. The point is, that the aspect can be based off of the "target" result that you need to deliver, (e.g. code, ui screens, db layout, documentation, etc.) and the milestones defined to what is appropriate for the type of deliverable. Milestone definition is critical to the measurability and consistancy (FDD flavor) of the process.

The units of work (% based on the effort assign to the milestone) can then be calculated accurately, and rolled up to the entire effort of all the deliverables that your are tracking against.

Semantics aside, I hope I have not confused the issue. As always, if this is helpful, use it, if not, ignore it.

Jeff,
I may have worded it incorrectly. Bottom line is that I am in aggreement with what you were explaining, I just tried to explain it differently. I was trying to approach it from a more abstract perspective.

To me, it is easier to grasp the concept if you
1) Understand the focus of the 5 step process on delivering and managing a result ( some type of artifact ).
2) Realize that different artifacts (deliverables) may have different milestones
3) By weighting the milestones appropriately you can achieve the same level of reporting accuracy we have for the PD (traditional FDD milestones)
4) The aggregation mechanism iterates over the completed milestones for each traceable item (feature) providing a consistant way to calculate how much work has been accomplished.

I would like to talk with you more about the meta-process and discuss the areas you disagree with. I will post that on a separate thread and we can discuss away. :)