Feature Driven Development

Bugs Bunny vs the Tasmanian Devil.

Each development project is the road that our characters run down in those Warner Bros
cartoons.

Bugs is much like FDD.
He runs down that road in the most optimal manner possible (domain modelling, upfront design/test reviews etc) .

Taz is much like XP.
He moves very fast indeed, but never apparently in a straight line.
He spins all over the place, but never always in a forward direction.

All that XP continuous changing/discarding of code and tests, is that what the
spinning is ??

And he spins so fast we cannot see what he is doing. Is that what XP means by

This was working for some authenticated users but not others. That problem has now been fixed and this capability should now be available to all authenticated users.

Comment moderation has been switched on. You can "mod" a comment up or down from a list of votes with scores. You cannot mod your own comments. When viewing a discussion thread, you can mod (vote) multiple comments and then at the end of the page click the Moderate button to register all your votes.

Hi,

I wonder if anyone in the community has a formulaic method for componentizing a color domain model (DNC/ADS model) for use in EJBs?

I've been working on this problem recently and don't want to re-invent the wheel.

First my assumptions - Entity Beans are out! The persistence solution should be something like JDO or Toplink or Hybernate running against the domain classes from the color model.

What I would like to do is partition the domain model into Java packages resolving any two-way dependencies using <<interface>>s and class methods (such as _find()). How I see this happening is that a <<Moment-Interval>> holds the key theme for a package. Everything below it, i.e. its <<MI-Details>> and all the <<Thing>>s hanging from that go into the package along with the <<Role>>s for the <<Place>>s and <<Person>>s on the other legs of the DNC. So far this has produced some nice packaging which seems to be working without side-effects.

This is going to sound like a terribly simplistic question but I'd like the community's opinion on the use of Together Control Center running in synchronous code and diagram mode and the Step 4 milestones of Design and Design Review.

The problem as I perceive it is that classes are "owned" by their owners but in order to draw a sequence diagram, a single developer has to check-out all of those classes in order to create the methods on the classes and complete the diagram. This breaks the class ownership constraint. In an ideal world, all the developers involved in the classes of a single sequence diagram would all be involved in the same CPWP at the same time and hence all working on the same sequence diagrams for the same batch of Features. However, in reality I find this problematic on a day-to-day basis - for example, a class owner may be involved in bug fixing whilst also participating in a new Feature Team.

Unless I misunderstand what a Feature would be, Steve Palmer's book indicates that a Feature can only belong to one FeatureSet and yet we are finding that Features could be resused in several FeatureSets. An example would be in a FeatureSet of ing a we would reuse the Feature of the for the which would use the same objects that were used within the Management Major FeatureSet.

The Era of Software Engineering is over. It has been proved a failure methodology and practice by the high failure rate of software projects in the last 20 years.

The FDD, XP and other Agile methodoloies, which we also call 'lightweight methodologies', are good tries in creating the Post Software Engineering Era. But they are still not the right solutions because they are making the same mistakes as of the Software Engineering. This mistake, in my own words, is that the software development has been managed and controlled by software professionals. For example, the setting of Chief Programmer in the team is a typical such mistake.

Phil Armour made this post against an old thread and seeing as it talks about cognitive factors in software - topic that interests me - I thought I'd start a new thread in reply to it.

I have a suspicion this (i.e. studies showing that inspections are more effecive than testing) may be both highly situational and a somewhat invalid conclusion, even based on the original data.

I'm a psychologist by background and I know that clear and pronounced results in any kind of behavioural study are quite unusual. There have been enough studies with clear results to show that inspections are both a very effective way of removing defects from software and much more effective than testing. Also I have never seen a study that shows testing to be more effective than inspections. Also I know from personal experience that inspections are very effective. So unless you can present new evidence your opinion is not significant.

I want to start with FDD right away. But an FDD implementation like Nebulon's Project Tracking System (PTS) still is not public available. Or is it free available and I don't know about it?

Giving my manager a clear view to FDD's benefit through such a tracking and report system, would make it much easier for me to convince him of the FDD approach.

Any hint from you except for writing my own PTS are very welcome.

This is in response to a request for a list of features. Would it be worthwhile for the community to apply FDD to the PetStore project which is rather well known in the java and .Net Community. This could then serve as a instructive application of FDD beginning to end ( the source code is already on the Net as well as a complete running example).

Others have done this using variants of the Unified Process.

Jeff states
"
Your request for an FBS from a real project is understandable but problematic - for several reasons. Features are very granular and therefore are very project and domain specific. This means that a small number features from a real project FBS are unlikely to make sense to someone outside that domain

This one has bugged me for some time and I heard a reference to it again the other day which has prompted to me ask about it here.

At last years Agile Development Conference in Salt Lake City, I was on a park bench panel with several others on Adopting Agile. The panel had been running for maybe half an hour and I happened to have one of the four "speaker chairs" at the time and I'd just finished speaking quite a bit myself. Alistair Cockburn came in and took one of the speaker chairs. He said that he'd just come from a presentation by Roy Singham, CEO of Thoughtworks, and Roy had said that to do Agile required 50% of the people to be experienced in Agile. Someone in our session asked Alistair if that meant 50% of the people had to be trained (e.g. had to have done an XP course - for example) and Alistair answered no. Not just do 50% had to have done an XP course, they had to also have done an XP project.