Hi,
we have a large non-OO, non-java (yes these still exist!!) project to run. I am just wondering whether or not and how FDD can be applied to such a non-oo, primarily PL/SQL and forms based project.
I can see despite the design and implementation technology/technique, both are still solving a business problem (i.e., implementing features). I can see definining and tracking features can remain the same and the processe requiring tweeks in terms of defining classes and packages and assigning class ownerships etc..
So is there anyone with any experience using FDD in the similar scenario? Appreciate your insights.
btw, is there any good book on FDD?
thanks
sri
It Works Well
Hi Sri,
it will work very well as most of the practices I had in use before the switch to OO. I've done PL/SQL O*Forms projects too!
Basically, it's about abstracting what the FDD processes are about. The first process - develop an overall model - is written for OO as the modeling technique as described in that process is the best I've seen for the requirements and requirements analysis.
However, abstracting it, the first process is really the informational/analytical activity to get enough knowledge to do the features list (FBS) and the planning with accuracy. So, if you think about it this way it is simply do whatever informational/analytical activity works for you (OO or not) that will result in enough knowledge transfer for you to be able to construct the FBS and have a high degree of confidence about the accuracy of its coverage.
Then you can run the rest of the FDD processes pretty much as-is.
When it comes to the tracking and milestones, again, simple abstraction here will let you do whatever works for you. In FDD the things being tracked are called features, and for PD, DM and SI features I state the number of milestones (6) and their names (domain walkthrough, design, design inspeciton, etc.) and for PD features I suggest the percentages for each milestone (1%, 40%, 3%, 45%, etc.).
So, let's abstract this. There are things we want to track. In FDD they are called features. Let's now use a generic name and call them TrackableItems. You can then customise this name to something specific meaningful to you. For each TrackableItem you establish the milestones that make sense for you in terms of specific measurable events. You establish how many milestones and what their names are. Then, you set the percentages. If you have no idea what they should be, you simply measure for the first few weeks and then plug in the actuals for your team for this project (which is what you do for FDD anyway).
Now you can track anything, and I do mean anything, using the same FDD style reports and visualizations.
The other place some OO specific things are mentioned is in design by feature. Again, this process is simply about formalising the design activity prior to coding. So, drop the sequence diagram and use whatever design artifact works for you. Before the Design By Feature process, I used a form of the IBM Rochester Software Development Process' I0 (inspection level 0) documents. They worked very well for me on projects (appropriately scaled back from the rigors of system development).
Hope that helps. It really will adapt very easily as the thinking and approaches long predate my switch to OO.
There's some other discussion about this in this thread
Jeff