软件工程系列。

本书描述了一个完整的软件开发项目，从最初与客户接触直到软件交付。通过案例分析，它描述了一个小型的分布式团队如何设计并应用一个成功的开发过程。但这并不是对一个完美案例的分析，案例中包含了有效的和无效的做法，说明了团队在下一个项目中可能需要做出哪些改变。作者鼓励你评估他们的结果，并在你的下一个项目中使用从本书中汲取的经验教训。

目 录 译者序 序 言 前 言 第1章 写在开始 1.1 组成团队 1.2 后续内容 第2章 在小型项目中使用开发过程 2.1 什么是小型项目？ 2.2 对小型项目运用的开发过程如何？ 2.3 从使用RUP开始 2.4 让团队成员参与的技巧 2.5 照规矩办事 2.6 参考信息 2.7 小结 第3章 人员. 过程与工具 3.1 人员 3.2 过程 3.3 工具 3.4 什么会出错？ 3.5 小结 第4章 项目启动：项目成员形成团队 4.1 结合成一个团队 4.2 编写开发案例 4.3 关于我们进度的报告 4.4 为初始阶段建立迭代计划 4.5 小结 第5章 初始阶段：我们开始取得进展 5.1 项目前景：设定目标 5.2 处理和管理需求 5.3 定义初始用例 5.4 项目管理 5.5 建立开发环境 5.6 迭代评估 5.7 这听起来确实像瀑布式 5.8 小结 第6章 细化阶段：建立框架 6.1 细化阶段的目标 6.2 生成测试和测试计划 6.3 建立PSP Tools的架构 6.4 对工具环境的改变 6.5 推迟建立数据库 6.6 范围管理：尽早并经常进行剪裁 6.7 不能安装该产品是什么意思？ 6.8 对细化阶段进行评估 6.9 小结 第7章 细化阶段详情 7.1 开始细化阶段 7.2 PSP Tools用户界面 7.3 PSP Tools数据库 7.4 单元测试 7.5 小结 第8章 构造阶段：构建PSP Tools 8.1 再次调整开发环境 8.2 构造阶段的目标 8.3 构造阶段计划：项目的心跳 8.4 实现过程加速 8.5 在构造阶段中前进 8.6 为什么开发会加速？ 8.7 其余的构造阶段迭代 8.8 每个人都会在某个时候需要朋友：结对编程 8.9 在构造阶段进行测试 8.10 预见团队成员的变化 8.11 小结 第9章 构造阶段详情 9.1 精细调节用户界面 9.2 完成数据库 9.3 测试 9.4 小结 第10章 移交阶段：交付PSP Tools 10.1 什么是移交阶段？ 10.2 向移交阶段过渡 10.3 移交阶段的目标 10.4 需求怎么样了？ 10.5 移交阶段的代码变更 10.6 独立测试人员的重要性 10.7 产品打包 10.8 用户培训 10.9 我们完成了吗？ 10.10 小结 第11章 事后分析：如何改进下一版？ 11.1 进行事后回顾的益处 11.2 引导事后分析回顾 11.3 我们的事后分析回顾 11.4 为下一个项目团队进行清理 11.5 变化的地形 11.6 PSP Tools的将来 11.7 小结 附录A Rational统一过程介绍 A.1 通向RUP之门 A.2 RUP的关键概念 A.3 RUP里程碑 A.4 小结 附录B 个体软件开发过程概述 B.1 个体软件开发过程 B.2 目标与关注的重点 B.3 结论 附录C 极限编程介绍 C.1 主要的价值 C.2 极限编程实践方法 推荐读物

本书不是一本关于RUP、敏捷开发过程或者项目管理的教材，而是一份来源于实际工作的“战地”报告。它记录了一个小型的分布式团队，经历许多变化最终成功地完成任务，向用户交付一个有价值的、可用的软件产品的过程。在本书中，这些“战士们”以直述的方式讲述了他们的故事，没有试图去“执导”有关的内容。

我经常听到：“我们不需要采用一个开发过程，因为我们的项目又小又简单。”可能你也有类似的感觉。但是，实际上你总会采用某种开发过程，而且这一过程很可能是临时发明出来的。在我们的行业中有一种普遍存在的印象，就是一个预先描述好的开发过程只适合于大公司、用于大型项目、管理几百个开发人员；而对于小型项目来说，这种开发过程只会使开发人员过得更加痛苦。在本书中，你将会看到一个很小的团队在解决一个中等的项目时，如何按照他们的需要采用和剪裁RUP这样一个描述化的开发过程。他们并没有因为采用这一开发过程而增加过多的正规性。他们只选择了那些对自己有用的要素，甚至采用了类似PSP（Personal Software Process，个体软件开发过程）、极限编程（eXtreme Programming）以及其他一些敏捷开发方法。

我也经常听到：“让我看看你到底是如何做的。”成功项目的例子和某些不成功项目的反例常常是导致开始采用一个新开发过程的关键。仅仅埋头于书本中或者网站上，苦读一页页有关某种理想处理方法的描述，对于我们大多数人来说都太抽象了。包装好的、与理论严格匹配的完美示例没有太多的说服力。本书最大的价值在于，它带领读者接触到一个实际项目中的真实经历，包括了其中的失败、错误的开始以及各种限制；而作者以批判的眼光来分析他们所采取的做法，以及这些做法为什么会成功或者失败。我们从自己的经验以及与别人经验的对比中进行学习。“噢，是的，我知道这种模式；我也曾经处于这种境地。啊，你是这样解决的。”

本书讨论了在传统的开发过程（包括RUP）中都没有涉及到的问题。作者大胆地探索了关于开发人员、关于形成一个团队的力量、关于分布式环境中的通信联系、关于使用基于Internet的协作工具等方面的内容，而所有这些要素都是当前许多小型开源软件项目的组成部分。

最后，本书强调了一个常常在计划中标明了，而在赶着完成任务的过程中通常被遗忘的关键性的实践步骤：自省（self-reflection），有时也被称为事后分析（post-mortem）或者回顾（retrospective）。这一步骤就是暂时停下，回头看看我们做过的、我们是如何做的，看看哪些做法有效，哪些做法无效，以及导致这种结果的原因。而这整本书就是一个非常完整的事后分析的极好例子，坦白而谦虚。本书不能代替你没有做的那些事后分析和回顾，但是可以让你意识到可能错过了哪些东西。

那么，哪些人需要使用这本书以及何时需要这本书？可能性有很多：如果你刚接触现代的开发过程，如RUP、敏捷开发方法、PSP等等，那么本书可以让你了解它们的精髓，而不用深入到细节中去。如果你不确定该如何处理小型的分布式项目，你将可以学到极有价值的内容，这些内容的作者也曾经问过自己那些你可能会提出的问题。他们对这些问题曾经做出过选择，这些选择的对与错都通过最终的结果反映了出来。你很可能发现一些熟悉的模式，从书中的解答和解决方案中学会一些东西；这意味着在你自己的项目中犯的错误会更少。如果你是这些方法的专家，那么本书将为你打开新的途径——如何结合不同的方法或者缩减一个开发过程，并告诉你自省的价值。

我从这本书中学到了许多关于RUP的知识，并学会了从不同的角度来看待它。感谢Gary、Jas、Liz和Chris与我们分享他们的经验。

——Philippe Kruchten于加拿大温哥华

Gary Pollice拥有近35年的软件开发经验。他在开始写作本书时是Rational软件公司RUP方面的元老，后来转向教育行业，担任Worcester Polytechnic Institute计算机科学系的实践学教授。

Liz Augustine在软件行业工作了20多年，先是作为软件开发人员，现在是一位技术文档作者。在其职业生涯中，她在项目中的主要职责是帮助软件开发人员更有效地工作。

Chris Lowe为DEC公司、Funk软件公司、Rational软件公司和IBM公司开发过软件。在业余时间里，Chris是Toastmasters International的成员，也是所在社区教堂的键盘手和歌手，是波士顿科学博物馆的志愿者，还是一名业余木工。

Jas Madhur从1985年开始在加拿大温哥华的高技术园区工作。他是最早的RUP团队的一员，后来担任过顾问，建立了一家e-learning公司。他在不列颠哥伦比亚大学教授软件工程过程学，还是国际系统工程协会(International Council of Systems Engineering,INCOSE)的成员。