FDDi - Revisited

Vernon's picture

I wanted to try to get the FDDi discussion started again. The lack of follow-up comment on the part of the FDD Tools team wasn't intended to indicate any lack of interest on our part. Actually were were quite happy with where the FDDi was going. The last release brought us to a point where it was actually pretty consistent with what we were already doing with some good enhancements, such as a standardized date format and extensibility built in. I personally felt we were well on the way to interchange, at least at a basic level. I also think this would support a good subset of reporting, and that the extensibility built into the format that additional enhancements, such as the Resource information (Chief Programmer for example), could be developed to address any additional areas to further enhance interchange and allow a broader range of reporting capabilities.

Standards present many advantages, and I would look forward to FDDi bringing some of these advantages to the FDD community. One specific benefit that I would like to promote would be an area to share FDD project templates. I'm confident that many organizations have used FDD to define feature sets for ecommerce systems, shopping carts, etc. A common interchange format would allow these projects to be used as project starters potentially reducing the time required to generate initial feature lists as well as an opportunity to create 'best practice' feature lists, which may be more comprehensive than a feature list produced by a single organization. Allowing end-users of FDD to be able to try different tools to select the one most appropriate to their own needs without them having to worry about wasted effort if they later move to a different system is another advantage.

I hope we can continue to develop FDDi, based on the strong foundation already in place, and look forward to expanding upon the previous conversation to achieve these goals.

Comment viewing options

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

Re: FDDi - Revisited

Vernon,

I am glad you started the discussion again. I am working on supporting FDDI in FDDPMA application, so I got some hands-on experience with FDDI.

I found that the current FDDI is quite flexible and supports extensions. FDDPMA has much more than what is described in FDDI. When exporting into XML, all of FDDPMA extensions fit nicely. There is one area though where it becomes a little clumsy. It is project templates.

FDDPMA supports project templates. At this time, our project template consists of name and the list of aspect types. Each aspect type is defined by the name, effort and a reference to the milestone template. The milestone template has a name and a list of milestones. Each milestone is exactly what FDDI describes: name and effort. When starting a new project, user may simply pick an existing template. Here is an example of a template:

Project template: “FDD (PD, SI, Swing UI)”
   Aspect type: Modeling
   Aspect type: PD development with “FDD Standard” set of milestones
   Aspect type: SI development with “FDD Standard” set of milestones
   Aspect type: UI development with “UI Swing” set of milestones
Milestone template: “FDD Standard”
   Walkthrough (1%), Design (40%), Design Inspection (3%), Coding (45%), Code Review (10%), Promote to build (1%)
Milestone template: “UI Swing”
   High Level Design (10%), Low Level Design (15%), View (12%), Controller (28%,) PD Hookup (30%), Code Inspection and Promote (5%).

While we can export and import template information using our extensions to FDDI, it is somewhat clumsy. FDDI describes milestones in aspect/info elements. Each aspect has its own definition, even if they share exactly the same milestones. Take it one level higher: there may be several projects in FDDI XML; all of them may have the same aspect structure. Yet, there is no way to externalize this information. It would be more convenient if FDDI allowed describing project template separately, then each project would simply refer to the template.

This is just a proposal. While I think FDDI should include project template description, I’d like to wait until more applications support FDDI. Then we will probably see more potential areas for extending FDDI.

Just for information: next version of FDDPMA will support export and import according to FDDI. The release is scheduled in September.

Thanks,
Serguei

Jeff De Luca's picture

FDDI

Hi Serguei,

FDDI can be many things and so we need to establish which of those things it should be. Some real usages would help with this.

When we first published FDDI the intention was not as a full interchange from one FDD tool to another. It was to allow some interchange, of course, but it was slanted towards enough data to be able to produce the FDD management reports. Hence some of the early feedback about summary or repeating data in the schema.

To move towards full interchange is ok as a goal but it can never truly get there as that would require mandating one and only one schema that all FDD tools themselves work on. i.e. no opportunity for a tool to add its own value (that would require a schema change). As an example, to look at full interchange means you would have to bring across the workpackages also. When this is done is it at the point in time of the export only or does it bring the history across as well? Then, to bring across workpackages also drags in resources. And so on it goes.

Now, don't get me wrong. I'm not saying some of these thigs shouldn't be considered and even added to FDDI - but we need to be careful where the line is drawn. Too much in FDDI sets the bar too high for a different kind of FDD tool (one that doesn't need workpackages or resource information or whatever).

Your example of a project template is a fine idea. We've modeled that before. It's an obvious thing to do in a broad-based tool. Now, your tool with its templates, can easily generate a FDDI file which is instances of a template. Nothng needs to change for that.

I think what you're asking for though is for FDDI to natively support interchange of a project template itself. In that case I feel that is best left to the FDDI extension mechanisms. Adding project templates to FDDI is putting too much into FDDI. It's mandating that any FDD tool must support project templates. And beyond that, who's to say your version of project templates is the right one. What about teams and roles - every project has them too...

But that's just my first-cut reaction to the idea of adding this to FDDI. I am very happy to continue to discuss this and hear other opinions on it.

Jeff