FDD（Feature-Driven Development）是由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发的一套针对中小型软件开发项目的开发模式。

FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。简单地说，FDD“是一个以Architecture为中心的，采用短迭代期，目期驱动的开发过程。它首先对整个项目建立起一个整体的模型，然后通过两周一次‘设计功能-实现功能’的迭代完成项目开发”。此处的“功能”是指“用户眼中最小的有用的功能”，它是可理解的、可度量的，并且可以在有限的时间内（两周）实现。在开发过程中，开发计划的制定、报告的生成、开发进度的跟踪均是以上述“功能”为单位进行的。在FDD中，它认为：只有良好定义的并且简单的过程才能被很好地执行。另外，由于在FDD中采用了短周期的迭代，最小化的功能划分法，所以可以对项目的开发进程进行精确及时地监控。

FDD的使用需要有相应工具的支持，Peter Coad等人开发出了一套扩展的UML（FDD UML Extensions），并在Together中实现有关的功能，详细内容可参见后文。

在FDD中，存在“主要功能集”、“功能集”、“功能”等概念，它们之间的关系及示例如下所示：

主要功能集 = 功能集1 + 功能集2 + …

功能集 = 功能1 + 功能2 + …

其中，主要功能集是在初始阶段根据用户的需求所制定出来的比较粗的，有待于细化的对开发项目所需要功能的描述；功能是在开发过程细化的结果，在每个迭代期中需要实现若一干个功能，这些功能的集合被称之为功能集。

在FDD中，它将开发过程划分为如下五个阶段：

l         制定整体的模型

l         根据优先级列出功能的详细列表

l         依据功能制定计划

l         依据功能进行设计

l         实现功能

每个阶段的定义又是通过被称之为：ETVX的方法从下面四个方面加以描述的：

l         Entry：Specify clear and well defined entry criteria for the process；

l         Task：列出所有要实现的任务列表，名称，是否需要实现，任务描述；

l         Verification：；制定对过程结果的评批标准；

l         eXit：过程结束时所需的结果；

FDD过程示意图

在FDD中主要存在三类人员：主要开发人员、类的所有者、功能团队，它们各自的含义如下：

l         主要开发人员：用于领导其它开发人员进行DBF/BBF的开发，对开发工作进行监督（例如对设计及代码进行审查）。主要开发人员的数量由项目整体的大小所决定，如果需要加快开发进度则可以再培养新的主要开发人员。与其它开发人员相比，主要开发人员具有更高的开发效率。Fred Brooks在几十年前就提出了：增加开发人员数量只会降低开发效率。但对于小型的，以用户功能驱动的轻量及的开发过程此原则并不适用。在此过程中采用增加人员的方法可以提高开发的并行效率。

l         类的所有者：一个类有且只有一个所有者，即一个类只能由一名开发人员进行设计及编码。采用这种方式是十分有效的，因为开发人员会感觉他拥有了部分属于自已的代码，他会以此为荣；此外，它还可以保证相关代码的一致性。如果此类中包含有复杂的算法，那么可以再增加一名专门负责算法的开发人员。虽然FDD是面向用户功能的，而不是面向类的，但用户最终关心的是那些他们需的功能，而并不关心在开发时采用何种框架模式，所以在此以类为单位进行人员分配与开发的宗旨并不矛盾。

l         功能团队：开发时功能会被分配给主要开发人员，再由主要开发人员根据实现此功能所需类的所有关系找到有关的开发人员从而构成一个临时的（最多两周）的团队。一名开发人员可以同时负责多个类的开发工作，即他可以在同一时刻处于多个功能团队中。因此在每个DBF/BBF中功能团队的人员均可能发生变化。在此团队中主要开发人员处于核心地位，团队内部的交流也是经及为中心的。采用这种方法可以加速开发进度，并且主要开发人员还可以对过程进行必要的监控，保证设计与实现的一致性。从更高的角度来看，主要的系统设计师又负责监控各功能团队中的主要开发人员。

采用FDD方式进行开发时，各阶段时间的分配关系大致如下所示：

l         Develop an overall model                     10% initial, 4% on-going

l         Build a features list                             4% initial, 1% on-going

l         Plan by feature                                          2% initial, 2% on-going

l         Design by feature, build by feature              77%（两周一个迭代期）

DBF/BBF中各阶段时间分配关系：

l         DBF

²        Walk through the domain              1%

²        Design                                40%

²        Inspect the design                3%

l         BBF

²        Code/test                             45%

²        Inspect the code                   10%

²        Promote to build                   1%

需要注意的是：上述Coding的过程中还包含有单元测试的内容。此外单从DBF/BBF的过程来看，设计所有的时间要比编码的时间长（40% : 45%），但考虑到FDD的整个实施过程（包括前期的建模过程），设计的时间还是比编码的时间要长的（45% : 35%）。

在FDD中另一个重要的，并且也是十分有特色的部分就是它的报告功能。每周Release经理要召开一次会议，会议一般限定于30分钟以内，在会上每个主要的开发人员全面地介绍其所做的工作，并标识出相应的项目状态图。通过这种口头上的交流，可以确保各主要开发人员能对项目的其它部分有一个充分的了解。会后，Release经理还要根据有关内容更新数据库中的信息并生成相应的报告，这个报告将发送给项目团队、用户以及主要的管理人员。

为跟踪项目开发状态需要使用数据库对有关内容加以保存，在数据库中应保存如下信息：

l         类型（问题域、人的交互活动、系统交互活动）

l         标识（功能集前缀+序列号）

l         状态（正在处理、不再需要、正常）

l         主要功能集

l         功能集

l         文档引用信息

l         活动事件

l         主要开发人员

l         问题域分析时的计划日期，实际日期

l         设计时的计划日期，实际日期

l         设计复查时的计划日期，实际日期

l         编码时的计划日期，实际日期

l         编码复查时的计划日期，实际日期

l         提交构造时的计划日期，实际日期

l         备注

项目计划表

功能详细列表

另外，有关类及类的所有者的信息保存在其它的表中。根据数据库可自动生成有关报告。

项目已完成功能统计表

FDD中扩展的UML

FDD 过程 #1: 开发总体模型

Entry Criteria:

客户已准备好建立一个系统。他已经有采用某种形式保存的需求列表。此时用户可能还不能完全分清楚什么是他“必面要的”，什么是他“想要的，最好有的”，但这没有关系。

Tasks:

Verification:

Exit:

结束过程时，团队必须提交如下内容，并且这些内容已经过开发经理以及系统设计师的审阅及批准：

-          类图，包括：类、类间关系、类的函数以及属性。类及类间关系建立起了模型的大致轮廓。根据最初的功能有列表以及非正式的序列图而来的函数展现出系统的功能，并且是后续开发过程中建立详细功能列表的前提。此外还应有非正式的序列图。

-          非正式的功能列表。

-          其它可供选择的模型信息。

FDD 过程 #2: 创建功能列表

在此阶段，团队标识出所有的功能，对其加以分组，为其设定优先级，并设置相应的权重。

在下面的活动中，小组工作的重点在于功能，因此领域专家可以不再需要。

Entry Criteria:

建模团队已成功地完成了FDD第一阶段的工作，开发出了系统的整体模型。

Tasks:

Verification:

Exit Criteria:

    本阶段结束时，详细的功能列表必需已经产生了，并且将功能进行分组形成主功能集以及功能集，此外这些内容已经过开发经理以及系统设计师的审阅及批准。

FDD 过程 #3: 根据功能制定计划

根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。

Entry Criteria:

功能列表团队已成功地完成了FDD第二阶段的工作，并已形成详细的功能列表。

Tasks:

Verification:

Exit Criteria:

本阶段结束时，开发计划已经产生了，并且这些内容已经过开发经理以及主要设计师的审阅及批准。计划中应包括以下内容：

-          一个整体的开发日期

-          针对每个主要功能集、功能集、功能指定有关负责人（CP）以及完成时间

-          针对每个类，指定负责其完成的开发人

注意：

    为便于为功能设置优先级，可以创建一个称之为FFB（待实现功能板）。

FDD 过程 #4: 根据功能进行设计（DBF）

根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。

Entry Criteria:

计划制定团队已成功地完成了FDD第三阶段的工作。

Tasks:

Verification:

Exit Criteria:

本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：

-          功能及其相关参考资料（如果有的话）

-          详细的序列图

-          更新后的类图

-          更新后的类及其方法原型

-          开发团队认为有价值的其它实现方案

FDD 过程 #5: 根据功能进行设计（BBF）

在DBF工作的基础上，每个类的实现者完成类的各个方法。此外他还需完善基于类的测试方案并实现类一级的单元测试。根据主要开发人员的意见，功能实现团队可能还需在进行单元测试之前先进行源代码检查。当代码编写并检查后开发人员就将其放入配置管理系统中。在所有的类均已完成并Check-In之后，主要开发人员将代码提升以便进行构造。

Entry Criteria:

功能实现团队已成功地完成了FDD第四阶段的工作。

Tasks:

Verification:

Exit Criteria:

本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：

-          实现了类的方法并对代码进行了检查和单元测试

-          按顺序针对每个类的方法的单元测试记录

-          类已被开发人员Check-In，主要开发人员已提升代码进行构造并同步更新功能状态。