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

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

字串8

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

字串8

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

主要功能集 = 功能集1 + 功能集2 + … 字串5

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

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

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

l 制定整体的模型

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

l 依据功能制定计划

l 依据功能进行设计 字串4

l 实现功能 字串5

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

字串1

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

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

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

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

FDD过程示意图 字串8

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

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

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

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

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

字串2

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

字串7

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

字串3

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

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

字串2

字串1

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

字串9

l DBF 字串2

? Walk through the domain 1%

? Design 40% 字串3

? Inspect the design 3%

字串6

l BBF

字串8

? Code/test 45% 字串5

? Inspect the code 10% 字串6

? Promote to build 1%

字串4

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

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

字串2

字串7

字串9

字串2

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

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

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

字串4

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

字串6

l 主要功能集

l 功能集 字串7

l 文档引用信息 字串2

l 活动事件 字串1

l 主要开发人员

字串2

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

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

字串6

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

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

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

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

字串9

l 备注

字串5

字串8

项目计划表

字串7

字串9

功能详细列表 字串8

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

字串9

项目已完成功能统计表 字串7

字串5

FDD中扩展的UML

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

Entry Criteria:

字串1

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

Tasks: 字串1

组建建模团队 字串8	项目管理 字串6	必须 字串9
建模团队是由来自于领域以及开发方面的永久性人员组成。在建模的过程中也可以从其它项目中人员以便有更多的人可以参与并对模型进行评估。 字串6
领域分析 字串4	建模团队 字串7	必须 字串4
领域专家对问题域进行介绍，此过程可能是20分钟也可能是几个小时，需根据具体的问题域情况决定。在介绍时所涉及的内容应比问题域稍大一些。 字串1
学习资料 字串6	建模团队 字串6	可选 字串8
学习各种资料，包括：组件模型、传统的或者是采用use-case方式描述的功能需求书、数据模型以及用记手册。 字串6
生成非正式的功能列表 字串8	系统设计师 主要程序员 字串1	必须 字串1
建模团队生成非正式的功能列表，至于具体的细化和完善留到下一阶段进行。如果需要的话，应将有关的参考资料一并注明。 字串9
开发子模型 字串3	划分为小组形式的建模团队 字串8	必须 字串6
系统设计师提出最初的组件或者是入手点。根据对问题域的理解，小组使用原型及组件创建出类图。创建过程如下：首要关心的是类以及它们之间的关系，然后是类所包含的函数，最后才是类所具有的属性。在寻找类的函数的过程中可以参考对问题域的理解，最初的功能列表，以及原型中所建议的函数等方法。同时还需要生成一个或多个非正式的序列图。 字串9
开发模型 字串6	系统设计师 建模团队 字串1	必须 字串1
记录候选模型 字串5	系统设计师 主要程序员 字串1	必须 字串2
记录员（可以由团队人员分别担任）记录下来工作中所评估过的比较重要的但未被采用的模型，以便于将来在项目中参考。 字串4

Verification: 字串2

内部及外部的评审 字串3	建模团队 字串2	必须 字串5
参与此项目的领域专家进行内部自评，外部评审是必须的，以便判断对问题域的理解是否正确，功能是否是必须的，范围是否合理。 字串8

Exit:

字串2

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

字串3

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

- 非正式的功能列表。

字串1

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

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

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

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

Entry Criteria: 字串3

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

Tasks:

组建功能列表团队 字串3	项目经理 开发经理 字串2	必须 字串9
功能列表团队是由来自于领域专家以及开发方面的固定人员构成的。 字串2
标识功能 创建功能集 字串5	功能列表团队 字串2	必须 字串9
团队首先从上一阶段得到的非正式的功能列表入手，接着： 字串6 - 将模型中的函数转换为功能 字串7 - 将模型中的moment-intervals转换为功能集（并将功能集再组织成主功能集），头脑风暴，选择，添加功能以便实现用户所要的以及所想的。 字串4 在此采用下述格式进行描述： 字串6 - 针对功能： thea(n)object> 字串6 - 针对功能集：<_-ing />a(n)
为功能集以及功能设置优先级 字串4	功能列表团队 字串9	必须 字串3
通过“Feature Board”为功能集以及功能设置优先级。优先级的划分：A（必须实现），B（最好能实现），C（如果可能则实现），D（以后再实现）。设置时是依据用户的满意程序所定的。 字串1
分解复杂功能 字串4	功能列表团队 字串4	必须 字串1
在系统设计师的带领下开发人员对功能进行查开，以便找到那些无法在两周之内完成的功能，对此类功能应将其细分为更小的功能或步骤。 字串1

Verification:

内部及外部的评审 字串5	功能列表团队 字串9	必须 字串6
参与此项目的领域专家进行内部自评，外部评审是必须的，以便判断对问题域的理解是否正确，功能是否是必须的，范围是否合理。 字串9

Exit Criteria:

字串8

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

字串7

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

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

Entry Criteria:

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

Tasks:

计划制定团队 字串5	项目经理 字串6	必须 字串8
计划制定团队由项目经理、开发经理以及主要开发人员给成。 字串6
制定功能以及功能集的开发顺序 字串9	计划制定团队 字串2	必须 字串8
计划制定团队设置开发的先后顺序，并制定出最初的针对功能集或者主要功能集的完成日期。 字串9
为类指定实现人 字串9	计划制定团队 字串7	必须 字串5
根据开发顺序以及功能的重要性为每个类指定特定的实现人。 字串5
为主要功能集以及功能集指定相应负责的主要设计人员 字串1	计划制定团队 字串7	必须 字串5
根据开发顺序以及功能的重要性为每个主要功能集或者是功能集指定相应负责的主要开发人员。 字串7

Verification:

内部及外部的评审 字串4	计划制定团队 字串4	必须 字串2
参与此项目的计划制定人员进行内部自评，外部评审是必须的，并且是由更高一级的管理人员进行。采用“由顶向下”的方式让所有的开发人员均对此计划进行评估。通常一些开发人员由于过分保守会希望延长开发时间。但另一方面，项目经理或者是开发组长又会觉得“每个人都具有与我相同的能力”从而认为可以提前完成开发。在此应进行相应的平衡。 字串1

Exit Criteria:

字串4

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

字串6

- 一个整体的开发日期

字串2

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

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

注意： 字串2

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

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

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

Entry Criteria: 字串5

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

Tasks:

组建DBF团队 字串5	主要程序员 字串4	必须 字串9
主要开发人员从已有的类中找与可能与特点功能有关的类，然后找到负责实现这些类的开发人员并将他们组建成功能实现团队。开始进行功能的设计，如果需要的话，还可以请领域专家加入。 字串9
问题域学习 字串4	功能实现团队 领域专家 字串9	可选 字串4
（本步骤是可选的，主要依赖于功能的复杂性而定）领域专家将对问题域进行一个一般性的介绍，他只介绍与功能有关的内容，但这并不是为理解与功能有关的上下文所必须的工作。 字串1
学习有关参考资料 字串7	功能实现团队 字串5	可选 字串7
（本步骤是可选的，主要依赖于功能的复杂性而定）根据功能列表中所列的参考书目以及其它的可拿到的资料，功能实现团队的成员进行学习，以便获得与功能相关的详细的信息。 字串3
创建序列图 字串4	功能实现团队 字串2	必须 字串4
根据对功能的理解以及原有的非正式的序列图和组件，功能实现团队创建一正式的，详细的序列图。同时应记录下可选择的其它方案、决定以及注释。主要的开发人员将序列图添加至项目模型中（同时也要更新相应的类图）。 字串1
实现类及其方法的原型 字串2	功能实现团队 字串8	必须 字串2
每位类的实现人员根据序列图更新有关类及类中的方法，这包括：方法的参数、返回值、错误处理以及消息的发送。 字串9
设计复查 字串4	功能实现团队 字串4	必须 字串7
功能实现团队完成对设计的复查。如果主要开发人员认为有关功能的设计比较复杂并对其有所担心的话，他可以从别的地方请若干人员一起进行复查。 字串3
记录设计复查活动 字串8	文档人员 字串4	必须 字串3
团队中的文档人员针对类的实现人按顺序将有关设计复查的活动记录下来。 字串6

Verification: 字串2

设计复查 字串8	功能实现团队 字串7	必须 字串8
功能设计团队通过对序列图的“走查“实现内部的复查。外部评审是必须的，以确保存有关功能均以实现。 字串9

Exit Criteria: 字串2

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

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

- 详细的序列图 字串6

- 更新后的类图

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

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

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

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

Entry Criteria:

字串7

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

Tasks: 字串3

实现类及其方法 字串6	功能实现团队 字串4	必须 字串9
根据DBF中的详细的序列图类的实现人员完成类的方法的实现。此外他也要为测试实现有关的测试方法。主要开发人员则需添加针对功能的测试方法。 字串6
代码检查 字串8	功能实现团队 字串3	必须 字串5
主要开发人员负责安排一次针对BBF的代码检查，检查可以在单元测试之前也可以在其后。一般检查是由功能实现团队成员加以完成的，如果主要开发人员认为需要的话，也可以请团队以外的人进行检查。 字串6
代码检查记录 字串8	文档人员 字串5	必须 字串1
团队中的文档人员针对每个类的实现人将有关的代码检查活动记录下来。 字串8
单元测试 字串6	功能实现团队 字串8	必须 字串4
每个类的实现人员均需测试相应的类的代码以及此类所支持的功能。作为所有功能的集成者，主要开发人员对整个功能进行测试。 字串8
Check-In代码并对其进行构造 字串2	功能实现团队 字串4	必须 字串3
代码一旦编写完成并经过检查和测试，类的实现人就可以将其放入配置管理系统中。当所有的类均已完成Check-In并且可以正常工作时，主要开发人员将提升代码以便进行构造，同时更新在功能列表中的有关功能的状态信息。 字串5

Verification: 字串6

代码检查及单元测试 字串4	功能实现团队 字串7	必须 字串6
功能实现团队必须进行代码检查。文档人员应记录有关活动。 字串8

Exit Criteria: 字串2

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

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

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

字串9

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