特征驱动开发（FDD）方法是新兴的敏捷软件开发过程家族的一员，其特点是可以不断提交、切实可行的结果。本书是第一本详细介绍在实际项目中使用FDD的书，提供了许多深层次资料，针对不同角色的应用进行提示和指导，并且告诉读者如何将FDD方法加以改造，然后运用到自己的工作环境和开发项目中去。
对于学习软件工程课程的专科生、本科生和研究生，本书可以作为教材或教学参考书。对于从事软件项目开发的管理人员和技术人员，本书是一本实践性很强的有较高价值的参考书。
本书作者在书中展示了如何应用FDD解决传统软件开发过程和现代软件开发过程所不能解决
的问题。他们帮助你确定最适台应用FDD的项目，然后引导你一步步地了解FDD的整个开发过程。
主要内容:
FDD的角色、制品、目标和时间表
创建整体模型，为有效的开发建立牢固的基础和结构
构造特征表：对特征进行完善、分级、分组、分配优先级
根据特征制定计划：建立类所有者、特征集所有者和初步的开发计划
根据特征进行设计：领域走查、设计和审查
根据特征进行构造：编码、审查、测试和提交
跟踪进度并向技术领导、项目经理、业主和高级管理层报告
将FDD应用到用户界面和外部系统接口
将FDD应用到你的项目一一业务和技术环境
Stephen R．Palmer是利用TogetherSoft公司彩色建模技术和FDD过程进行领域对象建模的专家。他具有长
达12年的在世界各地不同领域进行软件项目开发的经验。他用C和Fortran语言在英国电力行业的主要项目中设计和实现实时软件。最近，他从事政府机构和新加坡银行的主要项目。stephen是TogetherSoft公司聘用的首位全职顾问和技术电子月刊《The Coad Letter》(http：／／www．togethercommunity．com／coad—letter) 的编辑。
John M．Felsing具有长达22年的开发不同应用领域大型软件项目的经验。他作为TogetherSoft公司的顾问，支持产品线的运作，指导开发小组在项目中应用面向对象程序设计和FDD技术。
FDD是什么
特征驱动开发（FDD）是一种软件的过程，其特点是可以不断提交、切实可行的结果。这是第一部详细描写在实际项目中使用FDD日常情况的书，为开发小组负责人提供了在他们自己的工作环境中成功应用FDD的所有必要信息。
FDD是构造系统的一种直接途径，运用简单的、易于理解、易于实现的方法，以及解决问题的技巧和报表指南，为项目的每个相关人员及时做出正确决策提供必要的信息。
通过FDD，程序员将获取建立应用程序必需的支持基础结构和信息，开发小组负责人和经理将得到关于小组和项目的最新信息，这有助于他们降低项目的风险。项目经理和投资人会清楚项目当前状况和问题所在，以便能够以可控的、有计划的方式做出及时、明智的决定。生成报告将变得容易、相对轻松、及时和精确。
随着项目的进展，用户（客户、业主、最终用户）将看到其业务逐步实现，在系统正在开发时及早地提出建设性的反馈意见。同时开发小组有所需的工具和信息，可以有效控制“范围蔓延”！
FDD不是什么
FDD不是那种只占用资源、时间和资金而不产生所需结果的过程，也不是管理者、官员和以过程为中心的入迷者能够集中每个人的时间和精力来产生大量的打印报表和签字，但却不能展示任何成果的过程。FDD也不是那种过程文卷，只搁置在架子上落灰，给上级、合作者和其他重要人物留下这样的印象，你拥有的知识对于构造系统毫无用处。
为什么要读这本书（里面有我需要的什么）
如果下列任何一个问题适用于你，你将在以后的章节中找到答案：
你是否负责一个小组，要用有限的资源在很短的期限内交付一个关键的系统，并且在项目组织方面需要帮助？
你是否疲于填写太多的过程表格和检查太多的文档，以至于没有时间做你真正该做的工作？
你是否对于无法实现过程方法所提出的不断地提交高质量成果的要求而感到沮丧？
你是否正在寻找一种更加有效的办法来组织你的开发小组，提高生产率、减少不必要的干扰以及提高项目报告的准确性？
你当前是否正在做一个项目，因为不能建成系统而陷于困境？
你是否想在你的项目管理或小组领导人的工具箱中加入FDD技术和工具？
阅读准备
虽然FDD已经在《Java Modeling in Color with UML》[Coad 1999]中做了初步介绍，但我们对FDD给出了更为透彻的阐述，包括对于取得成功非常关键的提示，以及泛泛阅览时不大容易注意到的缺陷。内容包括：
谁应该使用FDD。
角色、制品、目标和时间表。
为什么FDD包含这些实践和技巧。
FDD开发背后的动力。
使FDD适用于不同风格的项目。
FDD综合了许多业界认可的最佳实践，这些实践都受对客户有价值的特征观点的驱动，并曾为Peter Coad、Jeff De Luca以及其他人所成功运用。正是这些技术和实践的有力结合，才使得FDD如此引人入胜。
John M.Felsing（mfelsi01@sprintspectrum.com）
Stephen R.Palmer（sp@togethersoft.com）
2001年12月
为了构造成任何具有持久价值的东西，比如软件、系统和公司，构造者必须全面掌握一切工作的核心和灵魂。“过程”（process）就是用来改进人们如何共同工作的。过程是人类工作改进的灵丹妙药、祖传秘方和竞争优势。
每个人都有自己的一些过程，每个开发小组也是如此。无论过程好坏，使之明确清晰是理解发生了什么事情，明白什么能行、什么行不通的第一步，也是以智慧的眼光看待各种情况的第一步。考虑一个过程，也就是你与他人一起工作的方式，将使你尽力思考、上升一个层次。如果感到了压力，就站到一个更高的层次上观察审视，事情马上就开始平静下来，你开始看得更清楚。如果对什么时间做什么、什么是最重要的心里没底，请上升一个层次。如果与一个同事发生问题而又不知道该怎么办，请上升一个层次。如果遇到了如何与其他人一起开发更好软件的问题，请上升一个层次。
“过程”使你能够上升一个层次，使你能够得到新的见识，使你能够邀请其他人与你一起上升一个层次，从而使得日复一日的工作变得更有效、更惬意、更有趣、更有回报、更令人满意。
过程让人们明白自己在干什么，别人在干什么，互相之间有哪些问题和变化，哪些是瓶颈和加速器，整体的语境是什么，扩展后的语境是什么以及如何去做。
如果发生了问题，请上升一个层次，找出该做的事情。如果事业成功，请上升一个层次，去发现让你能取得更大成功的方式。
愿我们都有勇气提升一个层次，与他人更好地建立联系、建立有意义的关系、塑造人、构造持久价值以及真正的成功。
以上这些将我们带到本书的主题，即特征驱动开发（Feature-Driven Development，FDD）的主题。FDD是在一个完整过程之中的一组最佳实践，它使至关重要的软件开发项目中的业务人员和开发人员从每天都可能面对的紧急情况有时甚至是恐慌的状况中超脱出来，提升一个层次。
本书介绍了TogetherSoft公司及其客户生产世界级软件的过程及其秘诀。两年前，我和Jeff De Luca首次在《Java Modeling in Color with UML》中用一小节描述了这种方法。本书中斯蒂夫和马克（模拟项目的开发人员）的工作远远超出了那些最初的描述，他们两人极大地发展了FDD方法，我欣赏他们所做的工作以及书中所表达的许多见解。
FDD方法本身已上升了一个层次。
请阅读这本书，把书中描述的方法与你自己的实际情况相结合，以达到最佳效果。
Peter Coad
TogetherSoft公司首席执行官和总裁
peter. coad@togethersoft.com
（英）Stephen R.Palmer,John M.Felsing：暂无简介
熊焕宇 王峰 彭设强 等：暂无简介
随着中国加入WTO，我国IT企业面临着激烈的竞争和挑战。好的IT企业应该能够发现、吸引并且留住优秀人才，最大限度地发挥他们的潜能，调动他们的工作热情，使他们积极地投入到项目中去；应该能够随时得到关于项目状况的准确信息，包括质量、进度、成本等；应该能够及时发现潜在的风险，并采取措施予以化解；应该能够在项目预算范围内按时地交付高质量的软件产品等等……要实现这一切目标，IT企业应该将各种软件工程的思想、方法和技术运用到每一个项目中。
软件工程主要是从技术和管理的角度研究如何开发符合用户需求的软件产品，其目标是提高软件的生产率，改善软件质量。经过30多年的发展，在众多技术人员、管理人员和开发人员的共同努力下，在软件工程中出现了很多开发方法。在应用实践中，开发人员应该根据自己所在单位的情况以及项目的特点加以选择，并不断地总结和改进，逐步形成自己的方法，提升企业组织实施项目的能力。特征驱动开发（FDD）方法就是在实践中产生的新方法，是TogetherSoft公司（现已成为Borland公司的一部分）开发大型软件项目的总结。作为敏捷开发方法的一种，FDD是构造系统的一个直接途径，其过程可以高度迭代，每一步都强调质量，不断交付完成的、切实可行的结果。它易于理解，行之有效，受到了客户、经理和开发人员的普遍欢迎。本书提供了许多深层次资料，针对不同角色的应用进行提示和指导，并且告诉读者如何将FDD方法加以改造，然后运用到自己的工作环境和开发项目中去。本书是软件开发技巧和实践的有力结合，其中穿插了扮演角色讨论问题的有趣描写，引人入胜。
本书第1、2、3、4、5、6章及前言等由熊焕宇、胡喜飞、姚惠丽翻译，第7、8、9章由彭设强、卓佳、余文芳翻译，第10、11、12、13、14章由王峰、廖非凡、吴勃、佟金荣、喻琳翻译，第15章由李晓青、李海燕翻译。翻译不妥之处恳请广大读者批评指正！
武汉大学软件工程国家重点实验室的应时教授审阅了本书的译稿。贲可荣教授为本书的翻译出版做了大量协调工作，并提出了许多建设性意见，在此表示感谢。
对于学习软件工程课程的专科生、本科生和研究生，本书可以作为教材或教学参考书。对于从事软件项目开发的管理人员和技术人员，本书是一本实践性很强的有较高价值的参考书。
译 者
2002年12月
第一部分 特征驱动开发—概念
第1章 惟过程是尊：痛苦与解脱 3
1.1 惟过程是尊 3
1.1.1 重装旅 3
1.1.2 轻装旅 4
1.2 探索 6
1.3 沟通、沟通、沟通 7
1.4 复杂性 10
1.5 质量 11
1.5.1 质量谱 11
1.5.2 保质构造 12
1.6 过程的痛苦与解脱 14
1.7 小结 14
第2章 特征驱动开发—项目与人 15
2.1 三大要素 16
2.2 过程和人 18
2.2.1 个人生产率 18
2.2.2 吸引、发现与留住优秀人才 19
2.3 FDD中的角色 21
2.3.1 六种关键项目角色 21
2.3.2 支持角色 23
2.3.3 其他角色 23
2.3.4 项目模式 24
2.4 小结 24
第3章 特征驱动开发—实践 27
3.1 集成最佳实践 27
3.2 小结 40
第4章 特征驱动开发—过程 41
4.1 特征驱动开发的范围 41
4.2 对FDD的简要表述 42
4.3 FDD的核心 42
4.4 FDD过程概要 44
4.4.1 FDD过程模板 45
4.4.2 FDD过程 46
4.5 小结 55
第5章 特征驱动开发—进度 57
5.1 时间：不足的资源 57
5.2 估计进度 58
5.3 根据特征进行跟踪 58
5.4 向开发小组报告 59
5.5 向主程序员和项目经理报告 60
5.6 向业主和高层管理层报告 63
5.7 主程序员计划 66
5.8 特征消除 69
5.9 小结 69
第6章 特征驱动开发—包 71
6.1 主程序员工作包 71
6.2 当你不得不生成纸山时 76
6.3 小结 77
第二部分 特征驱动开发—实践
中的五个过程
第7章 特征驱动开发—开发一个整体
对象模型 81
7.1 促成对象建模会议 82
7.2 成立建模小组 86
7.2.1 预期结果 86
7.2.2 参与 86
7.2.3 给项目经理/主设计师的提示 86
7.3 进行领域走查 87
7.3.1 预期结果 87
7.3.2 参与 87
7.3.3 给协调员／主设计师的提示 88
7.3.4 给领域专家的提示 88
7.3.5 给建模小组的提示 89
7.4 研究文档 89
7.4.1 预期结果 90
7.4.2 参与 90
7.4.3 给主设计师／领域专家的提示 90
7.5 开发工作小组模型 91
7.5.1 预期结果 91
7.5.2 参与 91
7.5.3 给主设计师／协调员的提示 91
7.5.4 给建模小组的提示 91
7.6 开发一个小组模型 94
7.6.1 预期结果 95
7.6.2 参与 95
7.6.3 给建模小组的提示 95
7.6.4 给协调员／主设计师的提示 95
7.7 精化整体对象模型 97
7.7.1 预期结果 97
7.7.2 参与 97
7.7.3 给建模小组的提示 97
7.7.4 给Together产品用户的提示 97
7.7.5 给不是Together产品用户或
替代品用户的提示 98
7.8 编写模型注释 98
7.8.1 预期结果 98
7.8.2 参与 98
7.8.3 给协调员／主设计师的提示 100
7.9 验证 101
7.9.1 参与 101
7.9.2 给项目经理／主设计师的提示 101
7.10 退出准则 101
7.10.1 预期结果 101
7.10.2 给主设计师／协调员和项目经理
的提示 101
第8章 特征驱动开发—构造特征表 103
8.1 成立特征表小组 105
8.1.1 预期结果 105
8.1.2 参与 105
8.1.3 给项目经理的提示 105
8.2 构造特征表 106
8.2.1 预期结果 106
8.2.2 参与 106
8.2.3 给特征表小组的提示 106
8.3 验证 108
8.3.1 参与 108
8.3.2 给特征表小组的提示 108
8.4 退出准则 108
8.4.1 预期结果 109
8.4.2 给特征表小组的提示 109
第9章 特征驱动开发—计划特征
开发 111
9.1 成立计划小组 112
9.1.1 预期结果 112
9.1.2 参与 112
9.2 确定开发顺序 112
9.2.1 预期结果 113
9.2.2 参与 113
9.2.3 给计划小组的提示 113
9.3 为主程序员分配特征集 115
9.3.1 预期结果 115
9.3.2 参与 115
9.3.3 给计划小组的提示 115
9.4 为开发人员分配类 116
9.4.1 预期结果 116
9.4.2 参与 116
9.4.3 给计划小组的提示 116
9.5 验证 117
9.5.1 参与 118
9.5.2 给项目经理的提示 118
9.6 退出准则 118
9.6.1 预期结果 118
9.6.2 给计划小组的提示 118
第10章 特征驱动开发—根据特征
进行设计 121
10.1 成立特征小组 122
10.1.1 预期结果 122
10.1.2 参与 122
10.1.3 给主程序员的提示 123
10.2 进行领域走查 124
10.2.1 预期结果 125
10.2.2 参与 125
10.2.3 给主程序员的提示 125
10.2.4 给领域专家的提示 125
10.2.5 给特征小组的提示 125
10.3 研究参考文档 126
10.3.1 预期结果 126
10.3.2 参与 126
10.3.3 给特征小组的提示 127
10.4 开发顺序图 128
10.4.1 预期结果 128
10.4.2 参与 128
10.4.3 给主程序员的提示 128
10.5 精化对象模型 129
10.5.1 预期结果 130
10.5.2 参与 131
10.5.3 给主程序员的提示 131
10.6 编写类和方法的序言 131
10.6.1 预期结果 131
10.6.2 参与 131
10.6.3 给主程序员的提示 132
10.7 验证：设计审查 133
10.7.1 预期结果 133
10.7.2 参与 133
10.7.3 给主程序员的提示 133
10.7.4 给审查人员的提示 134
10.8 退出准则 134
第11章 特征驱动开发—根据特征
进行构造 137
11.1 实现类和方法 138
11.1.1 预期结果 138
11.1.2 参与 138
11.1.3 给特征小组的提示 138
11.2 进行代码审查 139
11.2.1 预期结果 140
11.2.2 参与 140
11.2.3 给特征小组的提示 140
11.3 单元测试 142
11.3.1 预期结果 142
11.3.2 参与 142
11.3.3 给特征小组的提示 142
11.4 提交构造 143
11.4.1 预期结果 143
11.4.2 参与 144
11.4.3 给主程序员的提示 144
11.4.4 主程序员工作区域 144
11.5 验证 144
11.6 退出准则 145
第三部分 特征驱动开发—其他主题
第12章 特征驱动开发—技术体系
结构 151
12.1 技术体系结构 151
12.2 FDD项目中的技术体系结构 154
12.2.1 四个逻辑层 155
12.2.2 小组、层和特征表 156
12.3 PD层 157
12.4 SI层 157
12.4.1 给系统交互小组的提示 158
12.4.2 给问题领域小组的提示 159
12.4.3 给项目经理的提示 159
12.5 UI层 159
12.5.1 导航、外观和感觉 159
12.5.2 给项目经理的提示 159
12.5.3 表示逻辑 160
12.5.4 给用户界面小组的提示 160
12.5.5 给问题领域小组的提示 161
12.5.6 给项目经理的提示 161
12.6 DM层 161
12.7 层和构造 162
12.8 减少组件之间的依赖性 163
第13章 特征驱动开发—测试：失效、
故障和修复 165
13.1 测试的种类 165
13.2 失效、故障和修复 166
13.3 FDD和单元测试 167
13.4 FDD和集成测试 169
13.5 FDD和系统测试 170
13.5.1 从哪里开始 171
13.5.2 尽早开始系统测试 171
13.5.3 测试哪些构造 171
13.6 客户/用户验收测试 171
13.7 发现失效 172
13.7.1 组织测试用例 173
13.7.2 测试用例特征和属性 174
13.8 报告失效 174
13.9 诊断缺陷 175
13.10 修复缺陷 175
13.11 缺陷委员会 175
13.12 小结 176
第14章 特征驱动开发—其他的
相关问题 177
14.1 需求变更管理 177
14.1.1 需求的澄清 177
14.1.2 需求中的缺陷 177
14.1.3 需求中的变更 178
14.2 用户文档 180
14.3 数据加载与转换 185
14.4 部署 187
14.5 小结 187
第15章 特征驱动开发—“万物皆
变化” 189
15.1 人与变化 189
15.2 技术与变化 192
15.2.1 考虑技术变化 192
15.2.2 避免“摆设品” 195
15.2.3 面向单用户的工具 195
15.3 过程与变化 196
15.4 结束语 197
参考文献 199
