Feature-Driven Development: An Agile Alternative to Extreme Programming

• design/code is "promoted" to the next level of development readiness.

• The use of both change-tracking & version-control tools are mandated for carrying out the CM-related activities of FDD.

The above is a sufficient overview of CM-related activities of FDD. Notice how FDD embraces (rather than eschews) documentation and traceability while still taking great strides to keep it as light and simple as possible. The feature-lists and the detailed domain model are the enabling mechanisms for traceability and status-reporting and make substantial use of tools and technologies to automatically track and report status/progress of features.

In some ways, FDD attempts to use feature-sets and features as configuration-items not merely for the functional (requirements) baselined, but for the development and product baselines and configurations. Organizing and aligning the work and work-packages along feature-boundaries vastly simplifies and facilitates traceability and status accounting/reporting.

FDD and Color Modeling

The Four Color Archetypes and their "Grammar"

Coad's Color Modeling method describes four basic archetypes for the kinds of objects that participate in an object-oriented domain model:

The moment-interval archetype

These are events (an important "moment" in time) and transactions (an important "interval" in time) that are the context or backdrop for important system operations and user-interactions. Examples might be: a sale, a purchase order, opening/closing an account or withdrawing/depositing to or from an account. They are similar to the states, transitions, and activities in a traditional state-model diagram. Moment-interval classes and objects are depicted in UML color modeling diagrams using the color pink.

The role archetype

A role is a particular way in which an actor or an agent (a party, place or thing) participates in an interaction with the system. Role objects are depicted in UML color models with the color yellow.

The catalog-entry description archetype

A description is quite simply a catalog-like entry that classifies or labels an object. Such objects typically represent some abstract collection of values that "catalog" or classify all objects of their type. Descriptions provide behavior to access information about their characteristics, but they do not, by themselves, change the way the system behaves. They provide structured information but no real overall functionality to the system. They don't do much of anything, they just "exist" and have attributes and characteristics that need to be used by the system. Description objects are blue in a UML color model.

The party, place or thing archetype

These are objects that are uniquely identifiable entities that may play different roles in initiating, influencing, or realizing the results of system behavior/functionality. These are made green in UML color models.

These different archetypes from the basic grammatical elements of a sentence that describe a feature or requirement of the system: a subject comprised of a noun (or pronoun) and any descriptive adjectives; and a predicate that consist of a verb (action), an object (or complement) that receives the action of the sentence, along with any descriptive modifiers or qualifiers.

There are some other basic color modeling rules that are pretty much the visual equivalent of grammatical rules for the valid and invalid ways of connecting these archetypes together in a domain model. The colors used in the model help make it very easy to see when correct grammatical structure and semantics are and are not present in each part of the model.

The Domain-Neutral Component (DNC) Pattern When the different archetypes are plugged together according to these basic grammatical rules, a resulting structure is a Domain-Neutral Component . The domain-neutral component is a particular structural pattern of interactions between archetypes in a "sentence" that recur over and over again throughout all systems. It has a mostly