统一过程是面向对象基于构件软件开发过程的惟一过程和标准过程吗？本书是这四本系列丛书的最后一本，它对统一过程提出了批评意见。作者介绍了其他可选择的软件过程，并且将统一过程与其他软件过程综合形成了一个处理真实世界开发和产品需要的更完整的、更健壮的统一过程。在详细阐述一个更完整的统一过程之后，每一卷书介绍了当前实现统一过程各个阶段（初始、细化、构造、移交和产品化）最佳实践的大师的经验智慧集合。
　　汇集业界杰出人物的集体智慧。来自于Ellen Gottesdiener、Larry O, Brien、Steve McConnell、Larry Runge、Karl Wiegers等的文章为读者提供对如下论题的观点：
　　● 如何开发和维护大规模、关键任务软件。
　　● 程序设计如何适合整体开发生命周期。
　　● 提高你的角色（职业）的技巧和技术。
　　并且在需求、管理项目风险、测试和度量投入以及选择和配置正确的工具等方面采用最佳实践来处理实施软件过程的若干细节。

　　一个增强生命周期来实现企业级统一过程。本书提供了正确部署、操作和支持新系统所需要的信息。在移交阶段将一个新系统交付给用户团体的过程中，你将：
　　● 测试和验证完整的系统。
　　● 并行地操作所开发的系统和遗留系统。
　　● 转换遗留的数据库和系统，使之支持新发布的版本。
　　● 培训用户、操作人员、支持人员和维护开发人员。
　　为了确保产品化阶段中系统的连续运行，你将：
　　● 监控系统，采取恰当的操作来确保系统连续运行。
　　● 操作和维护相关的工作、日志记录和支持系统。
　　● 对帮助请求、错误报告和特性请求做出响应。
　　● 管理变更控制过程。
　　本书的内容由美国《Software Development》杂志提供。

无

在《软件开发》杂志（Software Development）和它的前身《计算机语言》（Computer Language）中曾经刊登了大量关于如何成功开发软件的文章。为这一杂志撰稿的人包括许多业界最著名的专家，比如：Karl Wiegers、Ellen Gottesdiener、James Bach、Jim Highsmith、Warren Keuffel和Martin Fowler。简而言之，信息产业的大师们在这些年里一直在这本值得尊敬的杂志中与我们分享他们的智慧成果。
　　近来，几乎所有的组织对软件过程改进的关注越来越多了。从20世纪90年代中期开始，Rational公司控股和合并了其他一些软件工具公司；随着公司的发展，这些工具所支持的各种过程也被合并成一种开发方法，称为“统一过程”（Unified Process）。是否有可能让整个软件过程自动化？如果有可能，那么Rational公司是否拥有一套完整的工具集？对上述问题我们并不确定。但幸运的是，其他人也在定义软件过程，所以我们还可以从多个角度来看事物应怎样运作。这些过程包括：OPEN联盟的OPEN过程、面向对象软件过程（OOSP）的过程模式、极限编程（XP）和敏捷建模（AM）。这些不同的视角可以用来推动统一过程观点，使其更加健壮，结果就产生了一个更能准确反映你所在组织现实需要的增强的统一过程生命周期。因为我们相信《软件开发》中包含的多年积累下来的智慧能够用来充实统一过程—真正将我们产业的最佳实践统一起来，所以我们编写了本系列丛书。
　　为什么软件过程如此重要呢？让我们先设想一下：假如你想请人给你建造一间房子，让两位承包商来竞标。第一位承包商告诉你，通过使用一项最新的建筑技术给你盖房，如果从明天就开始的话，他能在两个星期内就把房子建好，造价只有10万美元。这个承包商手下有一流的木匠和水管工，他们以前用这项新技术建造过一个花园凉棚，他们愿意日夜加班以按期交付你的新屋。而第二位承包商告诉你，她需要先和你讨论你想要建一间什么类型的房子。然后，一旦她确定明白你的需要，她将在一个星期内提供一整套设计蓝图供你审阅和反馈。这个初始阶段只会花你1万美元，当你决定了最终方案，对于其余的工作她将给出详细计划和成本进度。
　　你会觉得选哪个承包商更让人放心呢？是想马上开始建房的那个，还是先搞清楚要建什么样的房子，再建模型，再详细计划，最后动工修建的那个？显然，后者更有可能理解你的需要—这是成功地交付给你一间符合你实际需要的房子的第一步。现在，设想你要构建的是软件—这通常是复杂好几个级别而且远比房子更昂贵的项目，再设想你还是面对两个与前面采取相同方法的承包商。选择哪个你会更放心呢？希望你的回答仍是第二个；她有一个更明智的过程。但遗憾的是，实践显示：在大多数时间里，组织似乎喜欢选择第一个承包商的方法；任意删改过程。当然，实践也显示：在我们的产业里，建造大型的、具有关键任务的系统的失败率在85%以上。也许这两种现象有一定的关联。
　　现实世界中，形势甚至更糟。你可能尝试要建造一间房子，而所能用的所有承包商却都只有建造花园凉棚的经验。甚至他们仅仅在热带地区工作过，并且从来没有处理过霜冻地区的情况，但是你却生活在加拿大偏僻的森林地区。而且，不同级别的加拿大政府颁布不同的经常变化的法规，承包商根本就不熟悉这些法规。再次强调，第一个承包商的杂乱无章的方法有可能使人陷入麻烦之中。

移交阶段
　　在企业级统一过程（EUP）的增强生命周期中，移交阶段是5个阶段（初始、细化、构造、移交和产品化）中的第4阶段，每个软件的发布版本在其生命周期内都将遍历这些阶段。移交阶段的主要目标是把系统交给用户群体。要完成这步，需要做以下工作：
* 测试和验证完整的系统。
* 如果是可应用的系统，让它与其他要替换的遗留系统一起并行运行。
* 转换遗留的数据库和系统，使之支持新发布的版本。
* 培训用户、操作人员、支持人员和维护开发人员。
* 部署系统进入产品化阶段。
　　移交阶段要完成的最重要的事情是保证系统在产品化阶段能够运行。这不仅仅意味着系统是可操作的，还表明了系统能够实现用户的真实操作需要。你要保证你的系统不会损害其他系统，保证用户明白怎样使用系统并且在遇到麻烦时知道怎样寻求帮助，保证系统在用户需要时可以使用。

产品化阶段
　　系统移交到用户手中了，但是系统的生命周期并没有结束。事实上，大多数用户可能会说系统才刚刚开始它的生命周期。产品化阶段是EUP的5个阶段的最后一个阶段。产品化阶段的主要目标是操作系统并且支持使用该系统的用户。要完成这步，需要做以下工作：
* 监控系统，采取恰当的操作来确保系统连续运行。
* 操作和维护相关的工作、日志记录和支持系统。
* 对用户的帮助请求、错误报告和特性请求做出响应。
* 管理变更控制过程，使得缺陷和新的特性可以被划分优先级并分配到将来的发布版本中。
　　你要认识到仅仅交付一个系统使之进入产品化是不够的，你还要让它保持下去，这一点非常重要。EUP跟Rational统一过程（RUP）一样，是统一过程的一个实例，它包括产品化阶段，这是因为曾经交付给用户的操作和支持系统对于真实世界的组织来说太冷漠、太难以理解。最好的开发人员在构建一个系统时会考虑维护问题，同理，最好的组织在管理一组计算机系统时会考虑产品化问题。
　　本书向读者呈现了业界专家所撰写的描述软件领域最佳实践的文章。本书乃至本系列丛书的一个目标是提供已证实的统一过程所包含技术的可替代方案。另一个目标是弥补统一过程中的一些缺陷。因为统一过程是一个开发过程，而不是软件过程，它不可避免地遗漏或缺少了一些对软件专业人员来说非常重要的概念。幸运的是，《软件开发》杂志的作者们已经对过程范围有了更广泛的了解，并已经为我们弥补了许多缺陷。

关于本套丛书
　　本套丛书由四卷组成：第1卷介绍初始阶段，第2卷介绍细化阶段，第3卷介绍构造阶段，第4卷介绍移交和产品化阶段。每卷都已经独立成书，但是如果想对整个软件过程有一个完整的认识，你需要通读全套丛书。本套丛书的文章覆盖了整个过程，在每卷之间没有重复。我们在为本书选择材料时确实费了一番心思，有大量可以选择的材料，但是篇幅有限，缩小选择范围并不总是那么容易。如果时间和篇幅没有限制，那么每一本书都可能会有现在的两倍那么厚。通过缩小选择范围，我们相信留下来的文章一定都是精华中的精华。此外，为了增加每本书的重点内容，我们限制了每本书覆盖的工作流的数量。没错，大部分工作流对于每个阶段都是相关的，但正如表1中所指出的，为了提供范围更广的资料，每本书覆盖了工作流的一个子集。
表1　 本套书的整体结构
工作流/主题 初始阶段 细化阶段 构造阶段 移交和产品化阶段
（第1卷） （第2卷） （第3卷） （第4卷）
业务建模 X X
需求 X X
分析和设计 X X
实现 X
测试 X X X X
部署 X
操作和支持 X
配置和变更管理 X
项目管理 X X X X
环境 X
基础设施管理 X X X

关于编者
　　Scott W. Ambler
　　作为《计算机语言》和后来的《软件开发》杂志的热心读者，我于1995年开始为杂志写稿，并在1997年终于成为对象专栏的作家。我从20世纪80年代早期开始从事软件开发，用Fortran和Basic等语言编写代码；到20世纪80年代中期，我开始使用Turing、C、Prolog和Lisp语言编码。在20世纪80年代末期，我发现生活中除了编程之外还有更多的东西，于是在用COBOL和几种第四代语言为IBM大型机编程的同时，我又开始学习用户界面设计、数据建模、过程建模以及测试等多方面的技巧。到了20世纪90年代，在我对结构化/过程化技术大失所望之后，我发现了对象技术，并跳跃到Smalltalk开发，然后转为C++开发，最后又转回Smalltalk。
　　我曾先后在多个组织中担任顾问和架构师，之后我决定结合这些经验，并运用我在多伦多大学当助教时所获得的技巧，并且在20世纪90年代中期开始做职业培训。我很快学到了几件事情。第一，尽管我喜欢教培训课程（直到现在我还在做这项工作），但是我自己并不想全职做这件事。第二，也是更重要的，我学会了如何用简单易懂的方式交流复杂的概念，比如如何开发面向对象软件。这就促使我写下了我最初的两本书：《The Object Primer》（Cambridge University Press，1995/2000）和《Building Object Applications That Work》（Cambridge University Press，1997/1998）（获得Jolt生产效率奖），这两本书以开发人员的观点描述了对象技术的基本原理。然后我决定再写两本书来描述面向对象的软件过程（OOSP），这两本书是《Process Patterns》（Cambridge University Press，1998）和《More Process Patterns》（Cambridge University Press，1999），其中讲述了我在加拿大一家顶尖的对象技术咨询公司工作时所获得的来之不易的经验。从那时起，我帮助过业界的几个组织机构（大的和小的，新成立的和历史悠久的），帮助它们改善其内部的软件过程。我最新的作品包括本系列丛书以及与别人合著的《The Elements of Java Style 》（Cambridge University Press，2000）。我现在是Ronin International公司（www.ronin-intl.com）的总裁，这是一家提供软件过程和软件构架指导和咨询的公司，总部设在丹佛；同时我还是我自己的网站（www.ambysoft.com）的自由作家，在这个网站上我张贴了许多白皮书。我还是敏捷建模（AM）方法学（详见www.agilemodeling.com）的思想领袖。我想，我终于找到适合自己的小天地了。

Larry L. Constantine
　　我与《软件开发》及其前身《计算机语言》的合作是长久而富有成果的，但比起我与软件开发以及计算机语言打交道的时间，又是小巫见大巫了。从我在计算机的摸索时代所写的第一个FORTRAN程序开始，我就一直热衷于寻找能把事情做得更好并能帮助其他人做得更好的方法—正是这种兴趣让我不久就超越了技术领域而进入了管理和过程，以及设计和构建软件的可用性的本质问题。我在将近40年间在这一领域内摸爬滚打，一直在与经常把人与技术相分离的这种论调抗争。在我看来，软件开发的成功取决于对这两方面的理解和掌握，这一点也同样反映在我为杂志和其他刊物所写的文章中。我已经写了150多篇文章和论文以及14本书，其中包括现在这本与Scott Ambler合作编辑出版的书。经过Scott的同意，我自己在杂志中的一些文章也被收录到这套书中。其他的文章收录在《The Peopleware Paper》（Prentice Hall，2001）和《Managing Chaos: The Expert Edge in Software Development》（Addison-Wesley，2000）中。前者重印了我的长期专栏“人件”中的内容；后者集中了广受欢迎的“软件开发管理论坛”每期印在最后的精华。
　　在最近几年里，我的专业兴趣集中在增加软件的可用性上，这导致了我在以使用为中心的设计上的发展，也促使我与Lucy Lockwood合著的《面向使用的软件设计》（Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design）（Addison-Wesley，1999）一书的诞生。《软件开发》杂志评选该书为1999年最佳书籍，授予我们Jolt大奖。最近，我好像穿越大洋比穿越河流还要频繁，因为虽然我住在美国，但是我同时还要到澳大利亚悉尼理工大学授课，我是这所大学计算机科学系的兼职教授。尽管题目是计算机科学，我讲授的都是管理和设计问题相结合的主题。我还是一位勤奋的职业培训师、设计师以及咨询顾问，帮助世界各地的客户建造更易使用的软件。我与Lucy Lockwood一起创立了Constantine & Lockwood有限公司（www.forUse.com），由我担任研发主管。现在除了原有的工作，我们正致力于将以使用为中心的设计与统一过程和统一建模语言（UML）结合起来。

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

兰雨晴 雷雷 高静　等：暂无简介

软件产业的不断发展，使人们越来越认识到优化的过程在软件开发和生产过程中的重要作用，遵循良好的过程是高效率、高质量和低成本地开发和生产软件的必由之路。
　　近年来，我国软件业发展迅猛，在众多的软件项目和软件产品的开发过程中，人们越来越意识到优化的软件过程对于保证这些软件项目和产品质量的重要性，围绕软件过程改进进行的专题培训、企业内部培训等越来越多，业界的一些专家、学者围绕这一领域编著、翻译的书籍也很多。然而略感遗憾的是，人们在认识到软件过程重要性的时候，对如何有效且高效地实践这些过程却还未找到最佳方法，这方面的专著目前也比较匮乏。
　　在笔者翻译的本书及本套丛书的其他书中，详细介绍了作者在他们大量的软件过程经验和收集的来自于10余位业界杰出人物以及10多年的《软件开发》和《计算机语言》杂志的更广泛经验的基础上提出的软件过程最佳实践方法，并将这些方法和统一过程的各阶段对应起来。
　　在本系列书中，作者综合Rational 统一过程（RUP）、OPEN联盟的OPEN过程 、面向对象软件过程（OOSP）、极限编程（XP）等软件过程形成了一个处理真实世界开发和产品需要的更完整、更健壮的统一过程。在详细阐述一个具有更完整的增强生命周期的统一过程之后，每一卷书介绍了当前实现统一过程各个阶段（初始、细化、构造、移交和产品化）最佳实践的大师们的经验智慧集合。通过本书作者提供的资源链接，读者可获得更广泛的“在线知识库”。
　　本书介绍的最佳实践方法与统一软件过程的移交和产品化阶段相对应，介绍了需求工作流、分析和设计工作流、实现工作流、测试工作流、部署工作流、操作和支持工作流、配置和变更管理工作流、项目管理工作流和基础设施管理工作流的最佳实践。在移交阶段向用户群发布新系统时，项目组的焦点在于测试和确认完成的系统，与遗留系统并行运行系统，转换遗留数据库和系统以适应新系统，培训用户、操作人员、支持人员和维护开发人员，将系统部署成产品。在产品化阶段，项目组会关注运行系统并给使用它的用户提供支持，监控系统并进行适当操作以保证系统的连续运转，运行和维护相关的工作、日志和支持系统，处理帮助请求，提供错误报告和用户的特征需求，管理变更控制过程。本书提供了恰当的部署、操作和支持新系统所必需的信息。
　　翻译本书的目的是为实践这一过程提供最佳实践参考。本书可作为软件项目管理人员、软件开发工程师、过程工程师、质量工程师、系统工程师、系统分析员等的软件过程实践指导用书，也可作为大专院校计算机及相关专业学生的软件工程实践参考书。
　　参加本书翻译工作的有兰雨晴、雷雷、高静、韩芳，全书由高静统稿，兰雨晴进行了审订。由于水平和时间有限，本书翻译中的缺点和错误在所难免，个别用词还有待商榷，真诚欢迎读者批评指正。
　　联系：Lanyuqing@buaa.edu.cn、LL@buaa.edu.cn、Gaojing@cse.buaa.edu.cn

北京航空航天大学软件工程研究所
兰雨晴　 雷雷　 高静
2005年秋

第1章　 概述 1
1.1　 统一过程 1
1.2　 企业统一过程 (EUP) 4
1.3　 移交阶段的目标 6
1.4　 产品化阶段的目标 6
1.5　 在移交和产品化阶段通常工作如何进行 7
1.6　 需求工作流 7
1.7　　分析和设计工作流 8
1.8　 实现工作流 8
1.9　 部署工作流 8
1.10　 测试工作流 8
1.11　 操作和支持工作流 8
1.12　 配置和变更管理工作流 9
1.13　 项目管理工作流 9
1.14　 基础设施管理工作流 9
1.15　 本书的组织 10
第2章　 部署 11
2.1　 部署工作流的最佳实践 11
2.1.1　 部署准备 11
2.1.2　 部署系统 13
2.2　 文章 13
2.2.1　 有效的软件部署 14
2.2.2　 计划部署 17
2.2.3　 计划恰当的首次演示 19
2.2.4　 创建好的安装 23
2.2.5　 可管理的移植 25
2.2.6　 UML 部署建模和超越 29
2.2.7　 把标签A放在插槽B中 32
2.2.8　 垃圾管理 35
第3章　 测试 39
3.1　 测试工作流的最佳实践 39
3.1.1　 将测试人员放在首位 40
3.1.2　 有效的测试实践 41
3.1.3　 测试没有真正地结束 42
3.2　 文章 43
3.2.1　 招募软件测试人员 43
3.2.2　 培训测试人员 48
3.2.3　 运转一个持久的软件测试小组 52
3.2.4　 根据用户优先级选择测试用例 59
3.2.5　 J2EE测试入门 64
3.2.6　 真实世界的接受测试 68
3.2.7　 不要浪费你的bug 71
3.2.8　 生存能力消防演习 75
第4章　 项目管理 83
4.1　 项目管理工作流的最佳实践 83
4.1.1　 从经验中学习 83
4.1.2　 从灾难中恢复 84
4.2　 文章 86
4.2.1　 从柠檬中榨柠檬汁 86
4.2.2　 向后看 89
4.2.3　 迷失在混乱中：失败时间表 95
4.2.4　 挽救处于麻烦中的项目 101
4.2.5　 补救当前的工作 106
4.2.6　 无痛的解雇：说再见 108
第5章　 操作和支持 113
5.1　 操作和支持工作流的最佳实践 113
5.1.1　 操作 113
5.1.2　 支持 113
5.2　 文章 115
5.2.1　 系统操作的秘密生活 115
5.2.2　 忽视提供帮助请求将带来危险 118
5.2.3　 你的帮助有多大作用 121
5.2.4　 从帮助平台获得真正的帮助 127
5.2.5　 开发者的焦虑：产品支持 130
第6章　　基础设施管理 135
6.1　 基础设施管理工作流的最佳实践 135
6.1.1　 系统安全 136
6.1.2　 通过开放源码软件进行复用 136
6.1.3　 软件过程改进 137
6.2　 文章 140
6.2.1　 谁在我的应用中 140
6.2.2　 入侵检测：集中在电子开发和安全上 142
6.2.3　 通过内部的开放源码进行复用 146
6.2.4　 艺术和工艺软件 149
6.2.5　 免费软件的道德规范 151
6.2.6　 软件过程改进：10个要避免的陷阱 156
6.2.7　 运行中的过程改进 161
6.2.8　 超越优化 168
6.2.9　 开始行动 171
6.2.10　 统一霸权 173
第7章　 超越统一过程—敏捷软件过程 177
7.1　 迈向敏捷 177
7.2　 敏捷软件过程 180
7.3　 文章 182
7.3.1　 方法的敏捷性 183
7.3.2　 敏捷宣言 186
7.3.3　 给过程节食 191
7.3.4　 设计已死？ 197
7.3.5　 学到的极限经验教训 202
7.3.6　 极限编程 206
7.3.7　 精益编程（第一部分） 208
7.3.8　 精益编程（第二部分） 213
7.3.9　 极限建模 216
7.3.10　 近距离洞察极限建模 220
第8章　 结束语 225
附录A　 参考书目 227
附录B　 作者索引 231
附录C　 参考文献 235