Feature Driven Development

This may be a bit off-topic for this group, but here goes anyway...

As I mentioned here before, I am in the process of starting a new business based around turning a hobby project of the last few years into a commercial venture. I'm going through the whole process of developing a business plan for three to five years with projections for sales, revenue, routes to market, staff levels, expenses, R&D investment, etc.

This is presented by advisors as a necessary step. How can you be confident the business will succeed, they ask, without a clear picture of the end goal and a good idea of how you are going to get there.

Can't do it. Times out er sumptin.
Does anyone have them that they could forward to me?

Regards.

There has been on-going discussion privately between Jeff, Paul (and others) and I over the issue of how small does FDD scale. In fact, Jim Highsmith in his book quoted Paul questioning this?

In my experience most FDD steps and processes work just fine on smaller projects with smaller numbers of people but a few are problematic. I would like to start this thread to discuss them.

I want to make clear that Paul and Jeff may have solved these problems (or they may not) but that the real problem is that solutions are not written down or communicated in a public way. With the books on FDD there is ambiguity about what to do in smaller projects and that is what causes the problems I have observed.

I have a long history in developing business systems of various sorts. I have worked in organizations and on projects with "heavy" process and some with no process. I have gone through the Yourdon SDLC, the RAD methodologies, and on and on. The Agile methods, particularly FDD, seem to support the work of software development in the real world, the way it has always happened regardless of (and often in spite of) the process we have tried to wrap around it over the years. I have found FDD to be a good match for me, the way I think, and the projects I typically work on. Wonderful! I have found the books and material on the topic to be informative and useful, and generally tailored to busines systems. But....

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.