A per-feature activity to produce the feature(s) design package.

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.

Entry Criteria

  • The planning team has successfully completed FDD process 3: Plan by Feature

Tasks

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 documents.

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 package.

 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 project.

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.

Verification

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.

Exit Criteria

To exit the process, the feature team must produce a successfully inspected design package. The design package comprises:

  • 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.
Follow me on Twitter...