统一过程本身足够来终结所有基于构件的面向对象软件开发标准吗？Scott Ambler 不这么认为。这本书是对统一过程的批判性评论的4卷系列其中的一本―――被设计用来提出更加健壮的软件过程来指导你的开发和产品化需求。为了很好地描述统一过程的4个阶段而组织编排了这个系列书籍，即初始阶段，细化阶段，构造阶段，和转移阶段。它将：
● 提供给你一个平衡的可用的另一种设计方法的视角。
● 提出一个综合的软件过程来定位你的真实世界范围需求。
● 展现了Software Development杂志的大量资料来充实统一过程的各个阶段。

　　你将获得来自于业界引路人的智慧成果的集合。由Peter Coad，Larry Constantine，Martin Fowler，David Linthicum，Mary Loomis，Steve Maguire，Steve McConnell，Clemens Szyperski， 以及Karl Wiegers，和其他人写作的文章对很多宏观的问题的解决视角，诸如：
● 大规模的关键任务的软件怎么开发和维护。
● 每个工作流怎么适合于整个开发生命周期。
● 很多技巧和技术来增强你的角色（和职业生涯）。
　　并且他们用诸如代码审查、配置管理、变更控制和软件组织架构建模等最佳实践说明了实现软件过程的细节。
　　使用一个包含了具体细节的计划填补了理论和实践的空白。细化阶段―――统一过程的4个阶段里的第二个―――集中于定义，确认和建立系统架构基准。一系列经过精心挑选的文章说明了这个阶段的关键要素。主题包括开发框架，构件架构，接口设计，大系统的构建，有效的使用统一建模语言（UML），遗留系统的重用，业务规则建模，工具选择，开发小组的构建，用户接口的原形化，需求测试，以及有效的度量管理。

　　R&D书籍是一个CMP国际媒体公司的印记
　　这本书的内容由Software Development提供。

无

Software Development（www.sdmagazine.com）以及它的前身Computer Language曾经发表过大量关于如何成功开发软件的文章。曾经以及还在为该杂志写作的很多作者都是令人印象深刻的：Steve McConnell, Ed Yourdon, Larry Constantine, Steve McCarthy, Clements Szyperski, Peter Coad, 以及Karl Wiegers 等等。这些信息产业的引路人已经通过这本令人尊敬的杂志同我们分享了他们的智慧成果。

　　后来，更多的组织开始逐步将更多的精力投入到提高软件过程上。这部分是因为千年虫（Y2K）的灾难，大约80－90％的大规模软件项目的失败，与日俱增的对于遵循成熟软件过程是决定一个软件项目的成功与否的关键的认识。从上世纪90年代中期以来，Rational公司就开始收购和合并别的软件公司，随之的结果是，他们将别的工具合并到单个开发过程，即所谓的统一过程。是不是有可能将整个软件过程自动化呢？即使可以将其完整自动化，Rational有一个完整的工具集吗？我不太确认。幸运的是，还有别的人们也在致力于定义软件过程－OPEN社团的OPEN过程就是其一，我自己的面向对象软件过程（OOSP）的过程模式也是一个－所以我们对于怎么去做这样的工作还是有些别的视角的。这些其它的选择视角能够被用于驱动一个更加健壮的统一过程，并且为精确反映你的组织的真实世界的需求的统一过程产生一个增强的生命周期。我相信在Software Development中多年积累起来的智慧成果能够用来充实统一过程，并且能够综合我们这个产业里的最佳实践。也因此有了我们这一套书。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
遵循一个经过证实的成熟的过程是你作为软件专家成功的关键。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

　　为什么软件过程这么重要？我们后面就会讨论这个问题。假如你想建造一墥房子，并且你让两个建筑商来竞标。第一个告诉你通过使用新的建造技术，他能在两周内为你建造一所房子如果他第二天就开始建造的话，这所房子将仅仅花费你100，000美金。这个建筑商有一些顶级的木匠和泥水匠，并且在过去已经使用这种技术建造过一个花园洋房，并且他们也愿意为你日夜加班工作保证按时完成。第二个建筑商告诉你她需要跟你讨论你希望建成什么样的房子，然后当她一旦清楚你的需求后，她将在一周内将你的需求做出一个草图，然后你可以审查并且做出反馈给她。这个初始阶段将耗费你10，000美元，并且一旦你决定了你想要建造的样式后，她会把一切细节和剩余工作的日程表综合起来。你对哪个建筑商更加放心呢？想立刻开始建造的那个还是想先了解你对建造样式需求，做出模型，做出计划然后再建造的那个呢？非常明显，第二个建筑商有更大的机会做出满足你实际需求的房子。现在设想你正在构建软件－这是一项比建房子复杂程度高出几个数量级，并且常常是更加昂贵的工作－并且再一次假设你有两个承包商，而且他们使用上面两种方式。你对哪个更加放心呢？我希望答案仍然是第二个；一个明智的过程。不幸的是，实践证明绝大多数的时间内，组织往往会选择第一个承包商所使用的方法；就是这么一回事。当然，实践也显示我们有大约85％的失败率，你认为两种现象有关联吗？我想是。

细化阶段

　　细化阶段是5个阶段的第二个－初始阶段，细化阶段，构造阶段，移交阶段以及产品化阶段－在这个阶段中软件的发布贯穿了它的整个生命周期。这个阶段有几个目标：

●为你的系统产生一个经过证实的，架构的基准
●让你的需求模型发展到80％的完成点
●为构造阶段开发一个粗粒度的项目计划
●确保关键的工具，过程，标准和指南已经为构造阶段准备好
●理解和消除你的项目的高优先级的风险

　　这本书描述了一组由产业里知识渊博的人写作的文章的集合，这些文章描述了业内最佳实践的前沿。本书的一个目标，并且也是这套书的总的目标，是为统一过程指导技术提供可选的，经过证实的方法。本书的另一个目标则是填补统一过程的漏洞－－－坦白说，没有任何过程是可以真正称为“完整”的。统一过程是开发过程而不是软件过程；因此，也正因为它所选择的范围，必然将会略过一些软件专业方面的重要概念。但幸运的是，Software Development中的作者们都使用了更为广阔的视角来看待过程。

关于这一系列丛书
　　本系列丛书由四卷组成：分别对应于初始阶段，细化阶段，构造阶段，以及移交阶段和产品化阶段。每本书都是独立的体系，但你需要整个系列才能够完整了解软件过程。由于在每卷的文章都不重复，你会发现每一卷书都很有价值。有时候，可能其中一本书中讲述比较薄弱的过程工作流在其它几本书中讲述的更为详尽。例如，初始阶段卷包括了大量关于项目计划和评估的内容－－－这也是开始一个项目时最关键的内容－－－而在其它几卷中这方面的讨论就比较少。

　　另外，在我着手编著这套系列丛书时，我发现要比我最初相象的难许多。我所碰到的问题在于，我面对大量的好的资料，但本系列丛书却只有有限的容量。如果允许我尽情选择，那么本系列的每一本书都将是上千页而不是现在大家所看到的304页左右。所以大家可以发现本系列书中的文章都是精华中的精华。

关于我本人
　　我最喜欢的话题！作为Computer Language以及后来的Software Development杂志多年来忠实的读者，我从1995年开始为它撰写文章，并在1997年成为对象专栏作家。我在上世纪80年代初期开始软件开发的工作，曾经使用Fortran以及Basic语言来编写代码，在80年代中期使用过Turing，C, Prolog以及Lisp。在80年代后期，我意识到有比编程生命周期更为长久的工作，所以我开始重新学习用户接口设计，数据建模，过程建模以及测试的技术。当我从结构/过程技术中醒悟过来后，在1990年我发现了对象并很快的一头扎入Smalltalk开发，接着使用C++开发，最后又重新回到Smalltalk。经过在几个机构中担任过指导者以及架构师的工作后，我决定将这些经历以及我所获取的技术结合，并在多伦多大学获得了一份助教的工作，在90年代中期开始职业培训。不久之后，我就意识到下面两件事情，首先，尽管我很喜欢教授培训课程（我到今天仍不曾间断），我并不希望作一个全职授课者。其次，更重要的是，我学习到如何使用简单易懂的方式来交流复杂的概念，例如怎样开发面向对象软件。基于这样的经验，我最初的两本书诞生了－－－The Object Primer(Cambridge University Press,1995)以及Building Object Applications That Work(Cambridge University Press, 1997/1998)---这两本书从开发者的角度讲述了对象技术的基础知识。紧接着，我在Process Patterns(Cambridge University Press, 1998)一书中继续讲述了面向对象软件过程（OOSP），并在另一本书More Process Patterns(Cambridge University Press, 1999)中提供给读者我在加拿大某个一流的对象技术咨询公司所获得的宝贵经验。从那时开始，我帮助过多个机构，无论大小，成立时间长短，所属行业，来提高他们的内部软件过程。我近期的著作包括本系列丛书以及另一本书：The Elements of Java Style (Cambridge University Press, 2000)。我想，我已经发现了属于我自己的体系结构。

信息技术行业最不可告人的事就是那些大型的，关键性的项目有80%~90%最终都遭遇失败。作为一个曾经从事软件开发工作超过15年并在最近的3年前刚刚成为编者的我来说，这些都是我亲身体会所得。当我刚刚开始成为Software Development杂志的技术编者时，Scott Ambler开始在“Thinking Objectively”专栏中发表文章。他使用日常的语言来写作，这使得普通的开发者都能够阅读。在例如过程模式，有效使用UML，以及将对象规划入关系型数据库中这些领域里，Scott可谓是专家。现在Scott开始将他的热情和兴趣投入到如何将大多数软件项目从高失败率的深渊中解救出来。

　　软件过程是关于如何标准化开发团队并促进实践，例如代码走查，配置管理，变更控制以及架构建模。对于拥有过程模式背景的Scott来说，正是处于一个可以提供对当前的面向对象软件过程（例如Rational 统一过程即RUP，OPEN联盟所提供的OPEN过程，以及面向对象软件过程即OOSP）的可调和的和聚焦的评价最佳的位置。尽管OOSP（详见Scott的Process Patterns 和More Process Patterns ）为过程模式提供了更好的内在支持，它是Scott的真实世界产业敏锐的标志，无论好坏，他认识到：尽管面临挑战，统一过程是市场领导者，而且还将继续扮演下去。正如Scott所说的（“增强统一过程”，Software Development，1999十月），“统一过程不是完美的－－－没有任何软件过程是完美的－－－但是，如果我们想要组织在软件领域成功的话，它是我们需要投入工作的一个领域。”这个系列书籍从OPEN过程和OOSP里抽取了资料来充实目前还单薄的统一过程。在我看来，一个充实的统一过程是处理这一尴尬问题的最好的方式之一，同时Scott就是分析解决这种问题的优秀教师。

Roger Smith
技术编辑
Software Development杂志

Scott W.Ambler：Scott W.Ambler: Scott W. Ambler是软件开发方法年轻一代的领军人物之一，在理论和实践上的造诣都很深厚。作为一位高级咨询师，他一直积极参与全球各种大型软件开发和过程改进项目。同时，他还是一位视野广阔的方法学者，是《Software Development》杂志的专栏作家，撰写了多部颇受推崇的著作，其中包括《The Object Primer》、《Agile Modeling》、《The Elements of UML Style》、《More Process Patterns》等。

兰雨晴 高静：暂无简介

第一章　概述 7
1.1 统一过程 8
1.2 超越统一过程 10
1.2.1 能力成熟度模型（ＣＭＭ） 10
1.2.2 OPEN过程 11
1.2.3 过程模式 12
1.3 增强的统一过程生命周期 13
1.4 细化阶段的目标 16
1.5 细化阶段通常如何进行 16
1.5.1 项目管理工作流 16
1.5.2 业务建模工作流 17
1.5.3 需求工作流 18
1.5.4 基础管理工作流 19
1.5.5 分析设计工作流程 19
1.5.6 实现工作流 20
1.5.7 部署工作流程 20
1.5.8 测试工作流程 21
1.5.9 配置和变更管理工作流程 21
1.5.10环境工作流 21
1.6 本书的组织 22
第二章 项目管理工作流最佳实践 22
2.1 多团队开发管理 23
2.2 人力管理 24
2.3 招募新人和团队定义过程管理 24
2.4 培训和教育工作管理 25
2.5 文章 26
2.5.1“全球团队管理” 26
2.5.2 协作管理 32
2.5.3 实现特征团队 35
2.5.4 技术面试的技巧 39
2.5.5“持续不停地进步” 45
2.5.6 面向对象的训练 54
第三章 业务建模工作流的最佳实践 58
3.1 从你的业务建模到业务流程重组 59
3.2 公共的建模标记 61
3.3 文章 62
3.3.1“本质言说” 62
3.3.2“业务规则的逻辑” 64
3.3.3“为什么要使用UML” 71
3.3.4“实用UML：将UML加入到你项目中的诀窍” 75
第四章 需求工作流的最佳实践 78
4.1 用例及其他 80
4.2 用户界面原型制作 81
4.3 需求的重要性何在？ 82
4.4 相关文章 82
4.4.1 工程化面向对象的需求 83
4.4.2 撰写高质量需求 86
4.4.3 用例的各种用途 90
4.4.4 从用户角度进行原型制作 93
4.4.5“打破屏障” 99
第五章 基础管理工作流的最佳实践 106
5.1 企业需求和架构建模 107
5.2 遗传应用的集成:EAI 110
5.3 相关文章 111
5.3.1 “面向对象架构建模：第一部分” 111
5.3.2 “面向对象架构建模：第二部分” 116
5.3.3 “混合方法” 119
5.3.4 “适应变更的架构” 125
5.3.5 “从头开始进行企业应用集成” 128
5.3.6 “掌握消息代理” 135
5.3.7 “构建企业架构” 141
第六章 分析和设计工作流最佳实践 147
6.1 以架构为中心的建模实践 149
6.2 分离关注的对象 149
6.3 分布式架构 151
6.4 构件和基于框架的架构 151
6.5 遗留软件的复用架构 151
6.6 接口设计与设计模式 152
6.7 文章 152
6.7.1 回复：架构 153
6.7.2“分布式对象设计” 155
6.7.3“构件和对象共同体” 163
6.7.4“构建遗留链接” 170
6.7.5 Java接口设计 177
6.7.6 模式简介 183
第七章 测试工作流的最佳实践 187
7．1 相关文章 190
7.1.1 对象测试模式 191
7.1.2“客户/服务器系统使用的基于场景的测试” 195
7.1.3“最高速的软件质量” 201
第八章 结束语 206
8.1 对构造的展望 207
附录A 参考以及推荐阅读 208
附录B 文章作者 208
索引 209