A per-feature activity to produce the feature(s) design package.
A number of features are scheduled for development by assigning them to a Chief Programmer. The chief programmer selects features for development from his or her "inbox" of assigned features. Operationally, it is often the case that the Chief Programmer schedules small groups of features at a time for development. He or she may choose multiple features that happen to use the same classes (therefore, developers). Such a group of features forms a chief programmer work package.
The Chief Programmer then forms a feature team by identifying the owners of the classes (developers) likely to be involved in the development of the selected feature(s). This team produces the detailed sequence diagram(s) for the selected feature(s). The Chief Programmer then refines the object model, based on the content of the sequence diagram(s). The developers write class and method prologues. A design inspection is held.
- The planning team has successfully completed FDD process 3: Plan by Feature
|Form the Modeling Team||Chief Programmer||Required|
|The Chief Programmer identifies the
classes likely to be involved in the design of this group of
features. From the class ownership list, the Chief Programmer
identifies the developers needed to form the feature team. As part
of this step, the Chief Programmer starts a new design
package for the feature(s) as part of the work package.
|Conduct a Domain Walkthrough||Domain Expert||Optional|
At the request of the Chief Programmer, a domain expert walks the feature team through details of algorithms, rules, formulas, and data elements needed for the feature to be designed. This is an optional task, based on the complexity of the feature and/or its interactions.
|Study the Referenced Documents||Feature Team||Optional|
|The feature team studies the documents
referenced in the features list for the feature(s) to be designed
and any other pertinent documents, including any confirmation
memos, screen designs, and external system interface
specifications. This is an optional task, based on the complexity
of the feature and/or its interactions and the exis-tence of such
|Develop the Sequence Diagram(s)||Feature Team||Required|
|The feature team develops the detailed
sequence diagram(s) required for each feature being designed. The
team writes up and records any alternative designs, design
decisions, assumptions, requirements clarifications, and notes in
the design alternatives or notes section of the design
|Refine the Object Model||Chief Programmer||Required|
|The Chief Programmer creates a feature
team area for the feature(s). This area is either a directory on a
file server, a directory on his or her personal computer (backed up
by the chief programmer, as required), or utilizes work area
support in the project's version control system. The feature team
uses the feature team area to share work in progress and make it
visible among the feature team but not to the rest of the
The Chief Programmer refines the model to add additional classes, operations, and attributes and/or to make changes to existing classes, operations, or attributes, based on the sequence diagram(s) defined for the feature(s). The associated implementation language source files are updated (either manually or automatically by some tool) in the feature team area. The Chief Programmer creates model diagrams in a publishable format.
|Write Class and Method Prologue||Feature Team||Required|
|Using the updated implementation
language source files from the "Refine the Object Model" task in
the feature team area, each Class Owner writes the class and method
prologues for each item defined by the feature and sequence
diagram(s). This includes parameter types, return types,
exceptions, and messages.
|Design Inspection||Feature Team||Required|
|The feature team conducts a design
inspection. Other project members may participate; the Chief
Programmer makes the decision to inspect within the feature team or
with other project team members. On acceptance, a to-do list is
created per affected class, and each team member adds his or her
tasks to their to-do list.
|Internal and External Assessment||Modeling Team, Business||Required|
|A successful design inspection is the
verification of the output of this process. The design inspection
task is described above.
To exit the process, the feature team must produce a
successfully inspected design package. The design package
- A covering memo, or paper, that integrates and describes the design package so that it stands on its own for reviewers
- The referenced requirements (if any) in the form of documents and all related confirmation memos and supporting documentation
- The sequence diagram(s)
- Design alternatives (if any)
- The object model with new/updated classes, methods, and attributes
- The <your tool>-generated output for the class and method prologues created or modified by this de-sign
- The to-do task-list entries for action items on affected classes for each team member
This version of FDD Process #1 is taken from the book, Palmer, Felsing, 'A Practical Guide to Feature-Driven Development' , Prentice Hall, 2002.