Feature Driven Development

The attached document is a Guide for Chief programmers. The document was written for "Software Architecture and Engineering" course at Harvard University. This year the course is applying FDD to implement the course project. The document describes the typical activities that Chief Programmers perform during FDD iteration.

For the first time our company is developing with FDD. The software should be tested by the internal software test team, because there is no real customer. The test team is used to system testing in the classical way. The plan is to develop the software in iterations, but we are not sure how we should plan the system tests.
Does somebody has a suggestion on how we should plan the system tests?

Cutting content seems to be the prevalent way of meeting deadlines in projects that are running late. But why waste effort and time on things that most likely, will go at the first sign of trouble? Why don’t make the decisions about what is important and what is not up-front, and only start work on the latter if we have the necessary time to do it?

By combining critical chain and incremental development, we can create a plan and execute projects, which guaranties, with a set probability, the delivery of an agreed subset of the total functionality by a stipulated date.

You are the project manager of a large project, testing is uncovering faults, trouble reports (TRs) are starting to pileup, the release date is coming soon. Are they going to be fixed on time? What could you do to help? Are there any bottlenecks? Where should you assign more resources?
Sounds familiar? Have you been there? This article will explain how could you answer these questions by using an old method called Line of Balance in a new way.

This is a recently updated set of slides I use for 60-90 minute FDD overview presentations. These replace the older set at nebulon.com and elsewhere on the web.

Hi

I'm working with an organization at the moment that is trying to apply agile software development principles across large programmes of projects. They are mainly using Scrum with a few ideas borrowed from XP and, on the whole, it is working well for them when applied to individual teams working on a particular application.

The big business win for this organization is not the development of individual applications but the ability to integrate these applications to deliver new products to the market place quickly. Service-oriented architecture and web services are seen as the technical solution to this, and where each application that needs to participates in the solution already exposes suitable services, this works reasonably well.

The latest draft FDDI spec for public review.

Context:
- Software requirements/elements (features/classes) are tipically modeled either as a hierarchical set of components (FDD: Major feature set, Feature set, Feature) or as UML diagrams. None of these models can directly expose the relation/difference between functional and non functional requirements/elements. (Note: I do not know any methodology where "technical"/"business" would be base terms, eg. first class citizens.)
- Meanwhile many software projects are dealing with key/innovative and/or complex technologies. Thus I would say that non functional- or technical requirements may be good candidates for being managed components...

Hey Guys,

I've managed to find myself in charge of a product development team. We really need to have a bit of structure to the development process, especially around Progress reporting.

I've worked with Jeff and Paul on FDD at a large bank, so I like the process, but the milestones and granularity we used there, won't really apply to our product. For instance, we're spread all over the world so sit down code and design reviews are hard. But also, unlike the bank, we shuffle priorities around quite a bit, based on user feedback.

What I could probably do is break each release (quarterly or monthly depending on the situation) into a series of 'features'. These would probably a bit more granular than traditional features, but still able to group into work packets of a week or so's work.

My company is looking at a potential project that involves converting a fairly large Oracle Forms application to J2EE. Given the size of the application what we have suggested is that we spend a week to learn their application. This will be followed by three weeks of HLD which will involve the following
- Develop an overall Feature Breakdown Structure
- Develop a high level object model of the overall application

This will be followed by a detail design phase of two weeks for the features that will be tackled in Phase-1. Phase-1 will comprise 3 iterations, each about 3 weeks long.

Does the group have any advice on how to approach the HLD phase such that we can get a high-level overall object model without trying to get into details ?