1. 传统开发流程的问题


传统的
软件开发流程是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每一个阶段都必需完毕所有规定的任务（文档）后才可以进入下一个阶段。
如必须完毕所有的系统需求规格说明书之后才可以进入概要设计阶段，编码必需在系统设计完毕之后才可以进行。这就意味着仅仅有当所有的系统模块所有开发完毕之
后，我们才进行系统集成，对于一个由上百个模块组的复杂系统来说，这是一个很艰巨而漫长的工作。

随着我们所开发的软件项目越来越复杂，传统的瀑布型开发流程不断地暴露出下面问题：

• 需求或设计中的错误往往仅仅有到了项目后期才可以被发现比如：系统交付客户之后才发现原先对于需求的理解是错误的，系统设计中的问题要到測试阶段才干被发现。
• 对于项目风险的控制能力较弱项目风险在项目开发较晚的时候才可以真正减少，往往是经过系统測试之后，才干确定该设计是否可以真正满足系统需求。
• 软件项目经常延期完毕或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱，须要进行返工或其它一些额外的开发周期，造成项目延期或费用超支。
• 项目管理人员专注于文档的完毕和审核来预计项目的进展情况所以项目经理对于项目状态的预计往往是不准确的，当他回答系统已完毕了80%的开发任务时，剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。

在传统的瀑布模型中，需求和设计中的问题是无法在项目开发的前期被检測出来的，仅仅有当第一次系统集成时，这些设计缺陷才会在測试中暴露出来，从而导致一系列的返工：又一次设计、编码、測试，进而导致项目的延期和开发成本的上升。

2. 採用迭代化开发控制项目风险


为
了解决传统软件开发流程中的问题，我们建议採用迭代化的开发方法来代替瀑布模型。在瀑布模型中，我们要完毕的是整个软件系统开发这个大目标。在迭代化的方
法中，我们将整个项目的开发目标划分成为一些更易于完毕和达到的阶段性小目标，这些小目标都有一个定义明白的阶段性评估标准。迭代就是为了完毕一定的阶段
性目标而所从事的一系列开发活动，在每一个迭代開始前都要依据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包括了需求、设计、实施（编
码）、部署、測试等各种类型的开发活动，迭代完毕之后须要对迭代完毕的结果进行评估，并以此为根据来制定下一次迭代的目标。

与传统的瀑布式开发模型相比較，迭代化开发具有下面特点：

• 同意变更需求
  需求总是会变化，这是事实。给项目带来麻烦的经常主要是需求变化和需求”蠕变”，它们会导致延期交付、工期延误、客户不满
  意、开发者受挫。通过向用户演示迭代所产生的部分系统功能，我们能够尽早地收集用户对于系统的反馈，及时改正对于用户需求的理解偏差，从而保证开发出来
  的系统真正地解决客户的问题。
• 逐步集成元素
  在传统的项目开发中，因为要求一下子集成系统中全部的模块，集成阶段往往要占到整个项目非常大比例的工作量（最
  高可达40%），这一阶段的工作常常是不确定而且很棘手。在迭代式方法中，集成能够说是连续不断的，每一次迭代都会增量式集成一些新的系统功能，要集成
  的元素都比过去少得多，所以工作量和难度都是比較低的。
• 尽早减少风险
  迭代化开发的主要指导原则就是以架构为中心，在早期的迭代中所要解决的主要问题就是尽快确定系统架构，通过几
  次迭代来尽快地设计出可以满足核心需求的系统架构，这样可以迅速减少整个项目的风险。等到系统架构稳定之后，项目的风险就比較低了，这个时候再去实现系统
  中尚未完毕的功能，进而完毕整个项目。
• 有助于提高团队的士气
  开发者通过每次迭代都能够在短期内看到自己的工作成果，从而有助于他们增强信心，更好地完毕开发任务。而在非迭代式开发中，开发者仅仅有在项目接近尾声时才干看到开发的结果，在此之前的相当长时间，大家还是在不确定性中摸索前近。
• 生成更高质量的产品
  每次迭代都会产生一个可执行的系统，通过对这个可执行系统进行測试，我们在早期的迭代中就能够及时发现缺陷并改正，性能上的瓶颈也能够尽早发现并处理。由于在每次迭代中总是不断地纠正错误，我们能够得到更高质量的产品。
• 保证项目开发进度
  每次迭代结束时都会进行评估，来推断该次迭代有没有达到预定的目标。项目经理能够非常清楚地知道有哪些需求已经实现了，而且比較准确地预计项目的状态，对项目的开发进度进行必要的调整，保证项目按时完毕。
• 容许产品进行战术改变
  迭代化的开发具有更大的灵活性，在迭代过程中能够随时依据业务情况或市场环境来对产品的开发进行调整。比如为了同现有的同类产品竞争，能够决定採用抢先竞争对手一步的方法，提前公布一个功能简化的产品。
• 迭代流程自身可在进行过程中得到改进和精炼
  一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，并且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完毕任务。

迭代化方法解决的主要是对于风险的控制问题，从下图可以看出，传统的开发流程中系统的风险要到项目开发的后期（主要是測试阶段）才可以被真正减少。
而迭代化开发中的风险，能够在项目开发的早期通过几次迭代来尽快地解决掉。在早期的迭代中一旦遇到问题，如某一个迭代没有完毕预定的目标，我们还能够及时
调整开发进度以保证项目按时完毕。一般到了项目开发的后期（风险受控阶段），因为大部分高风险的因素（如需求、架构、性能等）都已经解决，这时候仅仅须要投
入很多其它的资源去实现剩余的需求就可以。这个阶段的项目开发具有非常强的可控性，从而保证我们按时交付一个高质量的软件系统。

迭代化开发不是一种高深的软件project理论，它提供了一种控制项目风险的很有效的机制。在日常的工作我们也常常地应用到这一基本思想，如对于一个很
大型的project项目，我们常常会把它分为几期来分步实施，从而把复杂的问题分解为相对easy解决的小问题，而且可以在较短周期内看到部分系统实现的效果，通过尽
早暴露问题来帮助我们及早调整我们的开发资源，加强项目进度的可控程度，保证项目的按时完毕。

3. 管理迭代化的软件项目


当我
们在实际工作中实践迭代化思想时，Rational统一开发流程RUP(Rational Unified
Process)能够给予我们实践的指导。RUP是一个通用的软件流程框架，它是一个以架构为中心、用例驱动的迭代化软件开发流程。RUP是从几千个软件
项目的实践经验中总结出来的，对于实际的项目具有非常强的指导意义，是软件开发行业其实的行业标准。

3.1 软件开发的四个阶段


在RUP中，我们把软件开发生命周期划分为四个阶段，每一个阶段的结束标志就是一个基本的里程碑（例如以下图所看到的）。

这四个阶段主要是为了达到下面阶段性的目标里程碑：

• 先启(Inception)：确定项目开发的目标和范围
• 精化(Elaboration)：确定系统架构和明白需求
• 构建(Construction)：实现剩余的系统功能
• 产品化(Transition)：完毕软件的产品化工作，将系统移交给客户

每个目标里程碑都是一个商业上的决策点，如先启阶段结束之后，我们就要决定这个项目是否可行、是否要继续做这个项目。每个阶段都是由里程碑来决定的，推断一个阶段是否结束的标志就是看项目当前的状态是否满足里碑中所规定的条件。

从这样的阶段划分模式中能够看出，项目的主要风险集中在前两个阶段。在精化阶段中经过几次迭代后，我们要为系统建立一个稳定的架构，在此之后再实现更
多的系统需求时，不再须要对该架构进行改动。同一时候，在精化阶段中，我们通过迭代来不断地收集用户的需求反馈，便得系统的需求逐步地明白和完整。

3.2 关于开发资源的分配


基于
RUP风险驱动的迭代化开发模式，我们仅仅须要在项目的先启阶段投入少量的资源，对项目的开发前景和商业可行性进行一些探索性的研究。在精化阶段再投入多一
些的研发力量来实现一些与架构相关的核心需求，逐步地把系统架构搭建起来。等到这两个阶段结束之后，项目的一些主要风险和问题也得到了解决，这时候再投入
整个团队进行全面的系统开发。等到产品化阶段，基本的开发任务已经所有完毕，项目不再须要维持一个大规模的开发团队，开发资源也能够随之而降低。在项目开
发周期中，开发资源的分配能够例如以下图所看到的。

这样安排能够最充分有效地利用公司的开发资源，缓解软件公司对于人力资源不断增长的需求，从而减少成本。另外一方面，因为前两个阶段（先启和精化）
的风险较高，我们仅仅是投入部分的资源，一旦发生返工或是项目目标的改变，我们也能够将资源浪费降到最低点。在传统的软件开发流程中，对于开发资源的分配基
本上是贯穿整个项目周期而不变的，资源往往没有得到充分有效地利用。

基于这样的资源分配模式，一个典型的项目在项目进度和所完毕的工作量之间的关系可能例如以下表中的数据所看到的。

3.3 迭代策略


关于迭代计划的安排，通常有下面四种典型的策略模式：

• 增量式(Incremental)
  这样的模式的特点是项目架构的风险较小（往往是开发一些反复性的项目），所以精化阶段仅仅须要一个迭代。但项目的开发工作量较大，构建阶段须要有多次迭代来实现，每次迭代都在上一次迭代的基础上添加实现一部分的系统功能，通过迭代的进行而逐步实现整个系统的功能。
• 演进式(Evolutionary)
  当项目架构的风险较大时（从未开发过相似项目），须要在精化阶段通过多次迭代来建立系统的架构，架构是通过多次迭代的探索，逐步演化而来的。当架构建立时，往往系统的功能也已经基本实现，所以构建阶段仅仅须要一次迭代。
• 增量提交(Incremental Delivery)
  这样的模式的特点产品化阶段的迭代较多，比較常见的样例是项目的难度并不
  大，但业务需求在不断地发生变化，所以须要通过迭代来不断地部署完毕的系统；但同一时候又要不断地收集用户的反馈来完好系统需求，并通过兴许的迭代来补充实现
  这些需求。应用这样的策略时要求系统架构很稳定，可以适应满足兴许需求变化的要求。
• 单次迭代(Grand Design)
  传统的瀑布模型能够看作是迭代化开发的一个特例，整个开发流程仅仅有一次迭代。但这样的模式有一个固有的弱点，因为它对风险的控制能力较差，往往会在产品化阶段产生一些额外的迭代，造成项目的延误。

这几种迭代策略仅仅是一些典型模式的代表，实际应用中应依据实际情况灵活应用，最常见的迭代计划往往是这几种模式的组合。

3.4 制定项目开发计划


在迭代
化的开发模式中，项目开发计划也是随着项目的进展而不断细化、调整并完好的。传统的项目开发计划是在项目早期制定的，项目经理总是试图在项目的一開始就制
定一个很具体完好的开发计划。与之相反，迭代开发模式觉得在项目早期仅仅须要制定一个比較粗略的开发计划，由于随着项目的进展，项目的状态在不断地发生变
化，项目经理须要随时依据迭代的结果来对项目计划进行调整，并制定下一次迭代的具体计划。

在RUP中，我们把项目开发计划分为下面三部分：

• 项目计划
  确定整个项目的开发目标和进度安排，包含每个阶段的起止时间段。
• 阶段计划
  当前阶段中包括有几个迭代，每一次迭代要达到的目标以及进度安排。
• 迭代计划
  针对当前迭代的具体开发计划，包含开发活动以及相关资源的分配。

项目开发计划也是全然体现迭代化的思想，每次迭代中项目经理都会依据项目情况来不断地调整和细化项目开发计划。迭代计划是在对上一次迭代结果进行评
估的基础上制定的，假设上一次迭代达到了预定的目标，那么当前迭代仅仅须要解决剩下的问题；假设上一次迭代中留有一些问题还没有解决，则当前迭代还须要继续
去解决这些问题。所以必须注意，迭代是不能重叠的，即你还没有完毕当前迭代时，你决不能进入下一迭代，由于下一次迭代的计划是依据当前迭代的结果而制定
的。

1. 引言


本文对 Rational 软件开发过程（Rational Software Development Process）的原理和结构给出了高度的描写叙述，它是：

• 迭代的、增量的开发过程
• 面向对象的开发过程
• 管理和控制的开发过程

它具有足够的普遍性，能够在规模与应用领域方面，为各个软件产品和项目量身订做。

2.整体软件生命周期

2.1 两种视角


Rational 过程能够从两种不同而又密不可分的视角来观察：

• 从管理的视角来看，涉及財务、战略、商业和人文方面
• 从技术的视角来看，涉及质量、project和设计方法方面

2.2 周期和阶段

从管理的角度，即从业务和经济的角度来看，相应项目的进展，软件的生命周期包括四个主要阶段:

• 起始阶段（Inception）– 有一个好的想法：具体构想出终于产品的设想和它的业务案例，确定项目的范围 。
• 细化阶段（Elaboration）–计划必要的活动和所需资源，具体确定功能并设计构架 。
• 构建阶段（Construction）– 构建产品， 发展最初的设想、构架和计划，直到一个能够交付给用户的产品（完毕后的设想）完毕。
• 移交阶段（Transition）– 将产品移交用户使用，包含：制造、交付、培训、支持、维护，直到用户惬意。

完毕这4个阶段称为一个开发周期, 它产生的软件称作第一代（generation）。 除非产品的生命结束，
一个现有产品能够通过反复下一个同样的起始、细化、构建和移交四阶段，各个阶段的側重点与第一次不同，从而演进为下一代产品。
这个时期我们称之为演进(evolution)。最后伴随着产品经过几个周期的演进，新一代产品也不断被制造出来。

比如，演进周期的启动可能由下面这几项触发：用户建议增强功能、用户环境的改变、重要技术的变更，以及应对竞争的须要。

实际中，周期之间会有轻微重叠：起始阶段和细化阶段可能会在上一个周期的移交阶段未结束时就開始了。

2.3. 迭代


从技术的角度来
看，软件开发能够视为一连串的迭代过程，通过这些迭代被开发的软件得以增量演进。 每次迭代都以一个可运行的产品的公布而结束，
该产品可能是完整版本号的一个子集，但从project的或用户的角度来看是实用的。 每次公布都伴随一些支持性工件：版本号描写叙述、用户文档和计划等。

一次迭代包含下面活动： 计划、分析、设计、实施和測试。 依据迭代在开发周期中所处位置的不同，这些活动分别占不同的比例。

管理角度和技术角度之间是协调的， 并且各个阶段的结束还和各次迭代的结束保持同步。

换句话说，每一个阶段能够分为一次或多次迭代过程。

(注意：本图中每阶段的迭代数目仅为示意)

可是，这两个角度（管理角度和技术角度），不只不过保持同步，它们还具有一些全然同样的里程碑，它们共同贡献出一些随时间演进的产品和工件。 一些工件很多其它地处于技术方面控制之下，还有一些工件很多其它地处于管理方面的控制之下。见第五节。

这些工件的可用性、工件是否满足所建立的评估标准，是构成里程碑的主要详细元素，比日历牌上的日期提供了多得多的内容。

像周期一样，迭代之间也会有轻微重叠。即第N次迭代的计划和构架在第N-1次迭代还未结束时就開始了。有时候，迭代也会平行进行：一个工作于系统某一部分的小组，可能在某个迭代内没有可交付的工件。

2.4.差别


对于不同的项目而言，每一个阶段的側重点，入口和出口准则，一个开发周期的各个工件，以及各次迭代的数目和长度都会不同。这主要取决于作为过程判别式的的四个主要项目特征。依照影响程度降序排列，它们是：

• 业务环境
  • 契约性工作，开发人员基于给定的客户规格说明仅仅为该客户开发软件。
  • 猜測性开发或商业开发，开发人员开发软件以推向市场。
  • 内部项目， 开发人员和客户在同一个机构中。
• 软件开发工作量的规模:
  依照一些度量标准来确定，比方 Delivered Source Instructions，或功能点、人-月数，或者仅仅依照成本。
• 新颖程度：
  对于软件开发组织，这个软件新颖程度怎样有多新，尤其是该软件是否为第二次或更后面的周期。这项差别包含了组织和过程的成熟度、资产、技术水平，当前的技状况，以及诸如组建并培训团队、获取工具及其它资源这种问题。
• 应用类型，目标领域：
  MIS，命令和控制系统, 嵌入式实时系统, 软件开发环境工具等等, 尤其时详细的应用领域会给开发提出特殊的约束条件：安全性、性能、国际化、内存限制等。
  本文首先描写叙述适用全部类型软件开发的通用过程，然后描写叙述了一些有差别价值的特定过程实例，并列举了几个样例。

2.5工作量和日程安排


各阶段在工作量和时间安排上是不同的。虽然因为不同项目类型之间相差会非常大，一个典型的中等规模项目的最初开发周期能够估计为以下的比率：

能够用下图表示：

可是对于一个演进周期来说，起始阶段和细化阶段可能大大缩减。使用特定工具和技术（如应用程序构建器），构建阶段能够远远小于起始阶段和细化阶段的总和。

3. Rational 过程的各个阶段

3.1. 起始阶段


这个阶段产生一个预測产品的最初设想，并将其转换为一个实际的项目。本阶段的目的是建立一个新产品或一次大的更新的业务案例，而且指定项目的范围。

对于一个新产品的开发，本阶段的主要结果是得到一个”做还是不做”的决定以进入下一阶段，并投入一定的时间和资金来具体分析构建什么、是否能构建，以及怎样构建。

对于一个现有产品的演进，这会是一个简短的阶段， 主要看用户或客户的要求、问题报告，或是新的技术动态。

对于一个契约性的开发，是否进行项目的决定取决于在特定领域的经验、以及组织在此领域的竞争力和市场情况。这里起始阶段能够归结为一个參加投标的决定，或投标活动本身。该决定可能是基于一个现有的研究原型，其结构对终于软件可能合适，也可能不合适。

入口准则:

对于一项须要的描写叙述，能够採用下面形式：

• 一份最初的设想
• 一个遗留系统
• 一份建议请求（An RFP –request for proposal)
• 先前一代的产品和一个增强要求清单
• 一些资产(软件, 专门技能, 財务资产)
• 一个概念原型或实物模型

出口准则：

• 一个初始的业务案例至少要包括下面内容:
  • 对产品设想的明白表达即核心需求，表述为功能、范围、性能、容量和技术等。
  • 成功标准 (如收入的数目)
  • 最初的风险评估
  • 完毕细化阶段所需的资源估算

通常在初试阶段结束时，我们将得到：

• 一个最初的域分析模型(完毕大约10%-20%), 确定最关键的用例, 而且足以进行进构架工作。
• 一个最初的构架原型，在这个阶段能够是一个一次性原型

3.2. 细化阶段


本阶段的主要目的是更彻底地分析问题域，定义构架并使之稳定，确定项目的最大风险。这样在本阶段结束时，我们能够得到一个关于下2个阶段怎样工作的综合计划：

• 一个基于分析模型的基线产品设想（即最初的需求集合）。
• 至少对第一次构建迭代的评价准则。
• 一个基线软件构架。
• 开发和部署产品的必需资源，尤其是人员和工具。
• 一份日程安排。
• 足以对构建阶段的成本、日程安排和质量做出”精确”的评估的一份风险决议。

在这个阶段，建立了一个可运行的构架原型；它至少实现了初始阶段识别出的最关键的用例
，攻克了项目的最大技术风险；依据范围、规模、风险和项目新颖程度的不同构架原型须要一次或多次迭代。这是一个生成高质量代码（这些代码成为架构基线）的
演进原型，可是也不排除开发出一个或几个试探性的、一次性原型，以减少开发的风险：对需求、可行性、人机界面研究、向投资者演示等的精化。在本阶段的结束
时，仍然会产生一个”做还是不做”的决定， 以确定是否要真正投资构建这个产品（或參与合同项目的竞标）。

此时产生的计划一定要足够具体，风险也必须充分减少，能够对开发工作的完毕进行精确的成本和日程估算。

入口准则：

• 前一阶段出口准则所描写叙述的产品和工件
• 被项目管理者和投资者认可的计划，和细化阶段所需的资源

出口准则：

• 一份具体的软件开发计划，包括：
  • 更新后的风险评估
  • 一份管理计划
  • 一份人员配置计划
  • 一份显示迭代内容和次数的阶段计划
  • 一份迭代计划，具体计划下次迭代
  • 开发环境和所需的其它工具
  • 一份測试计划
• 一个基线设想，以对终于产品的一个评估准则的集合的形式
• 用于评估构建阶段最初的迭代结果的客观、可測量的演进标准
• 一个域分析模型（80%完毕），对应的构架能够称之为是”完整的”
• 一个软件构架描写叙述（说明约束和限制）
• 一个可运行的构架基线

3.3. 构建阶段


本阶段能够划
分为数次迭代，不断充实构架基线，向终于产品逐步演进或增量演进。在每次迭代过程中，上个阶段（细化阶段）的工件得到扩充和修正，
但它们终于将随着系统向正确和完整的方向的演进而稳定下来。在这个阶段，除了软件本身，还生成一些新的工件：文档（既有内部使用的文档，也有面向终于用户
的文档）、測试床及測试套件、部署附件，以及用于支持下一阶段的部署辅助（比如销售辅助）。

对每次迭代，都具有：

入口准则：

• 上次迭代的产品和工件。 迭代计划必须阐明迭代的特定目标：
  • 将要开发的新增功能，覆盖了哪些用例或场景
  • 本次迭代过程中降低的风险
  • 本次迭代过程中改动的缺陷

出口准则：

更新后的产品和工件，另外还有:

• 一个版本号描写叙述文档，记录了迭代的结果
• 測试用例和依据产品得出的測试结果
• 一个具体描写叙述下一次迭代的计划
• 对下一次迭代的客观度量标准

到构建阶段的后期，必须完毕下面工件，及本阶段最后一次迭代额外的出口准则：

• 一个部署计划，指定必需的事项：
  • 打包
  • 定价
  • 演示
  • 支持
  • 培训
  • 移交策略 (比如一个现有系统的更新计划)
  • 产品 (软盘和手冊)
• 用户文档

3.4. 移交阶段


移交阶段是将产品交付给终于用户的阶段。 它涉及销售、打包、安装、配置、支持用户社区和做出修正等.

从技术角度来看，伴随本阶段迭代的是一次或多次公布：`beta\’ 版公布、正式版公布、修补bug , 或增强版公布。

当用户对产品惬意时，本阶段即告结束。 比如，契约性开发时正式验收， 或者产品有关的全部活动都已结束。 此时，某些积累的资产能够加以整理，以为下一个周期或其它项目重用。

入口准则：

• 上一次迭代的产品和工件， 尤其是足够成熟能够交付给用户的软件产品

出口准则：

• 前一阶段某些文档的更新，以及必要时依据原始及修订后的成功标准，进行”事后”项目性能分析，从而替换原有计划。
• 一个简短的清单，列出本次开发周期给组织带来的新的资产

3.5. 演进周期


对于重要的演进，我们应用整个过程递归，仍从起始阶段開始一个新的周期。由于我们已经有了一个产品，所以比起一个初次开发的产品，起始阶段可能大大缩短。细化阶段也可能缩小范围，而在计划方面的关注程度要大于分析或构架的演进方面。须要指出：周期之间能够略有重叠。

较小的演进能够通过延长移交阶段或添加一两次迭代来完毕。

移交阶段能够以一个终结过程而结束，即产品不再演进了，可是为了终结它，须要採取一些特定的动作。

4. Rational过程中的活动


Rational
过程中各个阶段的名称(如起始、细化、构建、移交)与描写叙述高级活动的术语（如分析、设计、測试等）相差甚远。
因此我们easy理解某种活动的进行并不局限于某个特定阶段，也与其它作者、标准及特定领域的所使用的术语无关。这些活动确实发生，但它们在每一个阶段和每次迭
代中的程度有所不同。下图表明了活动重点怎样随时间的推进而发生演进。

图中活动重点的变化也说明虽然每次迭代在形式上都是”类似”的，但它们的性质和内容却是随时间而改变的。

这还表明，一项活动的结束并不总意味着还有一项活动的開始，即并非分析完毕了才開始设计，而是这些活动相关的各种”工件”在随着开发人员对问题或需求的理解的加深也不断得到更新。

最后，在一个迭代过程中，计划、測试和集成这些活动不是集中堆积在开发活动的開始和结束阶段，而是增量地分布在整个开发周期的各个阶段、每次迭代之中。 它们并不表现为开发过程的某个独立的阶段或步骤。

虽然详细的项目有详细的差别，但对于一个中等规模、初次开发的典型项目来说，其开发周期中各种活动的比比例如以下：

5. 生命周期工件


开发过程不是文档驱动的：它的工件中必须一直包含软件产品自身。文档应该十分精简，数目不能太多，应仅仅保留那些确实从管理或技术的角度有真正价值的文档。 Rational 建议保留下面典型的文档集。

5.1管理工件


管理工件不是产品，而是用来驱动或监控项目进展、预计项目风险、调整项目资源，以及使客户或投资者对项目保持一定的”可见性” 的。

• 一份机构策略文档，是机构开发过程的明文规定。 它包括一个此类项目的实例。
• 一份远景文档, 描写叙述系统级需求，质量要求和优先级。
• 一份业务案例文档, 描写叙述財务环境、合同，以及项目的投资回报等等。
• 一份开发计划文档, 包含整体的迭代计划和当前及最近迭代的具体规划。
• 一份评估标准文档，包括需求、验收标准及其它特定的技术目标，它们由各个阶段演进的主要”里程碑”组成。包括迭代的目标和验收水平。
• 每次公布的版本号描写叙述文档。
• 部署文档, 包括对交付、培训、安装、销售、制造和交割相关的实用信息。
• 状态评估文档: 项目状态的阶段性”快照”， 具有进展、人力、开销、结果、关键风险、活动等的度量标准。

5.2技术工件


它们或者是交付的产品，可运行的软件及手冊，或者是一些用于制造产品的蓝图，这些产品包含软件模型、源码和其它有助于理解和演进产品的project信息。

• 用户手冊, 在生命周期早期开发。
• 软件文档, 最好以源码自建文档和模型的形式，当中模型是用合适的CASE工具捕获并维护的这些模型包含用例、类图和过程图等。
• 一个软件构架文档, 描写叙述软件的总体构架，及它的主要组成元素的分讲解明： 类的分组、类、过程、子系统、关键接口的定义和关键设计决策的根据。

本文第3部分中列举的入口准则和出口准则能够映射到这11类文档之中。

上面介绍的这套文档能够按照详细项目的类型进行扩充和删减，一些文档能够合并。 文档不必一定是纸张形式—也能够是电子表格、文本文件、数据库、源码的凝视、超文本文档等等—但对应的信息资源必须被清楚地识别，易于訪问，也要保存一些历史记录。

5.3需求


Rational 软件开发过程也不是需求驱动的。 在产品演进的周期中，需求表现为不同的形式：

• 业务案例给出了主要约束，多是些可用的资源。
• 远景文档从用户角度仅描写叙述了系统的关键需求，它在开发过程中将缓慢演进。
• 更具体的需求在第二阶段（细化阶段）以用例和场景的形式进行阐明，并在第三阶段（构建阶段）随着对产品和用户需求了解的加深进一步精化。这些更具体的需求记录在评估标准文档中，它们驱动了构建阶段和移交阶段迭代内容的定义， 并在迭代计划中引用。

6. Rational过程的样例


依照2.4节中所述的差别，Rational 过程採用不同的形式。 这里有两个极端的样例。

6.1大型契约性软件开发的Rational过程


对这个软件开发项目，Rational 过程分为3个阶段建立招标, 相应3个不同类型的合同。

• 一个研究与设计阶段, 包括了生命周期的起始阶段和细化阶段, 通常以风险分担方式投标，举例来说，成本加奖金合同（ cost plus award fee contract ，CPAF）。
• 一个生产阶段，包括了生命周期的构建和移交阶段, 通常作为一个公司、固定的价格合同（a firm, fixed price contract ,FFP）来投标。
• 一个维护阶段，相应生命周期的演进阶段，通常作来工作量水平合同（ a level of effort contract ，LOE）来投标。

由于用户须要更高的可视性来评估项目，还由于项目涉及大量人员和组织，开发过程应更加正规化，要比小型、内部的项目更加重视书面工件。第5部分列出的11类文档都以某种形式或名称存在。

6.2小型商业软件产品的Rational过程


在按规模分类的过程家族的还有一端，是小型的商业软件开发。它的流动性更强一些，仅仅有有限的正规性， 表现为一些基本的里程碑和有限的文档集：

• 一个产品远景 （A product vision）。
• 一份开发计划，显示资源和日程安排
• 版本号描写叙述文档，在每次迭代的開始指明本次迭代的目标，在迭代结束时 作为版本号说明（release notes）进行更新。
• 必要的用户手冊

软件结构、软件设计、开发过程能够通过代码本身或软件开发环境来进行文档化。

我们集中讨论怎样通过使用两个流行的方法得到过程的恰当级别：Rational Unified Process 或简称 RUP
以及极限编程（XP）。我们展示怎样在小型项目中使用 RUP 以及 RUP 怎样处理 XP
没有涉及到的领域。二者融合为项目团队提供了所需的指南–降低风险同一时候完毕交付软件产品的目标。

RUP 是由 IBM Rational 开发的过程框架。它是一种迭代的开发方法，基于六个经过行业验证的最佳实践（參见 RUP
附录）。随着时间的推进，一个基于 RUP
的项目将经历四个阶段：起始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）、交付阶段
（Transition）。每一个阶段都包含一次或者多次的迭代。在每次迭代中，您依据不同的要求或工作流（如需求、分析和设计等）投入不同的工作量。
RUP 的关键驱动因素就是减少风险。RUP 通过数千个项目中数千名 IBM Rational
客户和合作伙伴使用而得到精化。下图展示了一个典型迭代过程的工作流：

典型迭代流

作为风险怎样影响过程的一个样例，我们应该考虑是否须要为业务建模。假设因为对业务的理解中没有考虑到一些重大风险，将导致我们所构建的系统是错误
的，那么我们就应该运行一些业务建模工作。我们须要正式进行建模工作吗？这取决于我们的涉众–假设一个小团队将非正式地使用结果，那么我们或许仅仅进行非
正式的记录就能够。假设组织中的其它人也将使用结果或者查看结果，那么我们可能就要投入更大的努力，而且确保该结果的正确性和可理解性。

您能够定制 RUP
使其满足差点儿不论什么项目的须要。假设没有满足您特定须要的即装即用的过程或路线图，您能够轻松地创建您自己的路线图。路线图描写叙述了该项目怎样计划使用过程，
因此代表了该项目的特定过程实例。这就意味着，RUP 能够按须要变得简单或复杂，我们将在本文中详解。

XP 是一个用于小型项目中的以代码为中心的轻量级过程（參见 XP 附录）。它来自 Kent Beck 的创意，在大概 1997 年
Chrysler 公司的 C 3 工资单项目中得到软件界的关注。如同 RUP 一样，XP
也是基于迭代的，而且体现了诸如小规模公布、简单设计、測试以及持续迭代几项实践，。XP
为恰当的项目和环境引入了一些有效的技术；只是，当中也存在隐藏的如果、活动和角色。

RUP 和 XP 具有不同的基本原理。RUP 是过程组件、方法以及技术的框架，您能够将其应用于不论什么特定的软件项目，我们希望用户限定
RUP
的使用范围。XP，从还有一方面来说，是一个具有很多其它限制的过程，须要附加内容以使其适合完整的开发项目。这些不同点解释了软件开发界的一个观点：开发大型
系统的人员使用 RUP 解决这个问题，而开发小型系统的人员使用 XP
作为解决方式。我们的经验表明大部分的软件项目都处于两者之间–尽力找寻适用于各自情况的过程的恰当级别。单纯地使用两者之中的一个是不充分的。

当您在 RUP 中融合了 XP
技术时，您会得到过程的正确量，既满足了项目全部成员的须要，又攻克了全部基本的项目风险问题。对于一个工作于高信任环境中的小型项目团队，当中用户是团
队的一部分，那么 XP
全然能够胜任。对于团队越来越分散，代码量越来越大，或者构架没有非常好定义的情况，您须要做一些其它工作。在用户交互具有”契约”风格的项目中，仅有
XP 是不够的。RUP 是一个框架，您能够从 RUP 出发，在必要时以一组更健壮的技术来扩展 XP。

本文的下面部分描写叙述了一个基于 RUP 四个阶段的小型项目。在每一个阶段中，我们都确定了所产生的活动和工件 。尽管 RUP 和 XP 具有不同的角色和职责，可是我们在这里不会处理这些差异。对于不论什么组织或项目，实际项目成员必须在过程中与正确的角色关联起来。

项目启动－起始阶段


对于新的开发项目来说，起始阶段是非常重要的，在项目继续进行前，您必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比較短暂的，可是其目的仍是确定该项目的实施价值及可行性。

在起始阶段中，为了构建软件您能够创建业务案例。视图是起始过程中的关键工件。它是系统的高级描写叙述。它为每一个人解释该系统是什么、可能使用系统的用
户、使用系统的原因、必须具备的功能，以及存在的约束。视图可能非常短，或许仅仅有一两段。视图往往包含软件必须为客户提供的关键功能。

以下的样例展示了一个项目的非常短视图，该项目对 Rational 的外部站点进行了改造。

为使 Rational 的地位达到电子开发（包含工具、服务和最佳实践）的世界率先程度，能够通过动态的、个性化的站点加强客户关系，为訪问者提供自助服务、支持和目标内容。新的过程和技术启用能够使内容供应商通过一种简化的、自己主动的解决方式加速公布并提高内容的质量。

RUP 起始阶段中 4 个重要活动为：

制定项目的范围。假设我们打算构建一个系统，我们须要知道其内容以及它怎样满足涉众的须要。在这个活动中，我们捕获内容和最重要的需求的足够具体的信息，从而得出产品可接受的标准。

计划并准备业务案例。我们使用视图作为指导，定义风险缓和策略，开发起始的项目计划，并确定已知成本、日程计划，以及盈利率平衡。

综合得出备选构架。假设正在计划中的系统没什么新颖性，并且使用的框架广为人之，那么您能够跳过这一步。我们一旦知道客户的需求，就要開始分配时间
研究可行的备选构架。新技术可以带来解决软件问题的新的而且经过改进的解决方式。在过程的早期花些时间评估购买还是创建系统，并选择技术，也可以开发出一
个起始原型，这些都能够降低项目的一些主要风险。

准备项目环境。不论什么项目都须要项目环境。不论您使用 XP 技术（比如结对编程），还是较传统的技术，您都须要确定团队将要使用的物理资源、软件工具以及步骤。

进行小型项目开发时，并不须要太多的”过程时间”来运行起始过程。您往往能够在几天中或者更少的时间里完毕，以下的内容说明了本阶段除了视图之外的预期工件。

一个经批准的业务案例


涉众有机会
从业务的角度认定项目是值得进行的。RUP 和 XP
都承认最好在早期就得出项目是否值得进行的结论，以免在一个注定将要失败的项目中花费宝贵的资源。如同在”Planning Extreme
Programming” 一书描写叙述的那样，XP
对于项目是怎样形成的以及涉及哪些角色这两个问题的回答是比較模糊的（似乎在现有项目或系统的环境中是最清晰的），可是在研究阶段，XP 处理的工件与
RUP 起始过程中的是同样的。

不论您在 XP 中非正式地考虑业务问题，还是在 RUP
中将业务案例做成一流的项目工件，您都须要考虑这些问题。风险清单您应该在整个项目开发过程中都保持记录 Risk
List（风险清单）。使用有风险清单能够是一个具有经过计划的风险缓和策略的简单清单。为各个风险设定优先级。不论什么与项目有关的人员都能够随时看到风险
的内容以及怎样处理风险，可是没有提供解决风险的一般方式 。

初步项目计划


本计划包含资源估算、规模以及阶段计划。对于不论什么项目，这些估算都是不断变化的，您必须监控它们。

项目验收计划


您的计划正式与否依
赖于项目的类型。您必须推断客户会怎样才干觉得您的项目取得了成功。对于一个 XP
项目，客户会採取验收測试的形式。在更普遍的过程中，客户可能不会真正地进行測试，可是接受的标准必须直接由客户作出，或者由还有一个角色作出，比如与客户
直接接触的系统分析员。也可能存在其它的验收标准，比如创建终于用户文档和帮助，可是XP并不涉及此内容。

起始细化迭代计划


在基于 RUP 的项目中，在上次迭代的最后，您将具体计划下次迭代。在迭代的最后，您能够评估迭代開始时设立的标准。XP 提供了探监控与衡量迭代成功的一些优秀技巧。衡量标准是简单的，您能够轻松地将它们合并到迭代计划和评估标准中。

起始用例模型


尽管这听起来比較正
式而让人望之却步，可是它却相当简单。用例与客户在XP中编写的”故事”相相应。其间的差异就是一个用例就是一套完整的动作，由參与者或系统外部的人员或
事物发起，这正是用例的价值所在。用例可能包含若干个XP”故事”。RUP
为了定义项目的边界，推荐在起始过程中确定用户与角色。从用户的观点关注整套操作有助于将系统分为有价值的部分。这有助于判定恰当的实施特性，因此我们能
够在每次迭代的最后向客户交付一些成果（可能在起始迭代与细化迭代早期除外）。

RUP 与 XP 都能够帮助我们确保避免一种情况，即整个项目已完毕 80％，但都不是可交付的形式。我们一直希望公布的系统对用户都是有价值的。

在这一点上，用例模型在识别用例和參与者方面差点儿没有或仅仅有非常少提供支持的细节。它能够是手工或使用工具绘制的简单的文本或者
UML（统一建模语言）图。该模型帮助我们确保已经包括了涉众所关心的正确的功能，而且没用忘记不论什么功能，并同意我们轻松地查看整个系统。用例依据若干因
素设定优先级，这些因素包含风险、对客户的重要程度以及技术难点。起始阶段中不须要过于正式的或过大的工件。依照您的需求让它们保持简单或者正式就能够。
XP 包含对计划与系统验收的指南，可是 RUP
须要在项目的早期加入很多其它的一些内容。这些少量加入可能通过处理一套更完整的风险而为项目提供非常大的价值。

细化阶段


细化阶段的目标是为系统构架设立基线，为在构建阶段大量的设计与实施工作打下坚实的基础。构架通过考虑最重要的需求（那些对系统构架影响最大的需求）与评估风险演进而来。构架的稳定性是通过一个或多个构架原型进行评估的。

在 RUP 中，设计活动主要关注系统构架的概念，对于软件密集型的系统来说，就是软件构架的概念。使用组件构架是在 RUP 中体现的软件开发
6 项最佳实践当中之中的一个，该实践推荐在开发与所作所为构架上要投入一些时间。在这项工作花费的时间能够减缓与脆弱的、僵化日系统有关的风险。

XP 使用”隐喻”替换了构架的概念。隐喻仅仅捕获构架的一部分，而其余构架部分则随着代码开发的自然结果而演进。XP假定构架的形成是从生成简单的代码開始，然后进行持续的代码重构。

在 RUP
中，构架不仅仅是”隐喻”。在细化阶段中，您构建可运行的构架，从中可能减少与是否满足非功能性需求相关的很多风险，比如性能、可靠性以及健壮性。通过阅读
XP文献，非常可能判断出一些 RUP 为细化阶段所描写叙述的内容，尤其是过于 XP 所称的基础设施的过分关注，都是徒劳无功的。XP
觉得在没有必要的情况下创建基础设施所做的工作导致了解决方式过于复杂，而且所创建的结果对客户没有价值。在 RUP 中，构架与基础设施不是等同的。

在 RUP 与 XP 中创建构架的方法是截然不同。RUP
建议您关注构架，避免随时间变化而产生的范围蔓延、添加项目规模以及採用新技术带来的风险。XP
採用足够简单或是非常好理解的现有构架，该构架可以随着代码而演进。XP 建议您不要为明天而设计，而要为今天而实施。XP
相信假设您尽可能地保持设计简单，那么将来管理起来也轻而易举。RUP 希望您考虑该主张带来的风险。假设系统或者部分系统在未来不得不重写，那么
XP 觉得这样的举措比方今就计划这样的可能性更明智并且花费更少。对于一些系统，这是千真万确的，并且使用 RUP
时，在您细化阶段考虑风险也会得出同一结论。RUP
并不觉得对于全部系统这都是正确的，并且经验表明对于那些较大型、较复杂和没有先例的系统来说，这可能是灾难性的。

尽管为未来的可能性（可能永远不会生生）花费太多的精力可能是一种浪费可是对未来进行足够的关注不失为一件精明之举。多少公司能花得起代价不断重写或者甚至是重构代码呢？

对于不论什么项目，在细化阶段您应该至少完毕这三项活动：

定义、验证而且设定构架的基线。
使
用风险清单从起始阶段开发备选构架。我们关注是否可以保证构想中的软件具有可行性。假设选定技术对于系统没什么新颖性或者复杂性，这项任务不会花费太长时
间。假设您正在向现有系统中加入内容，那么假设现有构架不须要进行变更，这项任务就不是必要的。可是当真正出现构架风险时，您并不想让您的架构来”碰运
气”。

作为这项活动的一部分，您可能运行一些组件选择，而且做出决定进行购买/创建/重用组件。假设这须要大量工作，您能够将其分为单独的活动。

精化视图。
在起始
阶段，您开发了一个视图。由于你要确定项目的可行性，而且涉众有时间检查和评价系统，因此可能要对视图文档及需求作出一些变更。对视图与需求的改动一般在
细化阶段进行。在细化阶段的最后，您已经深刻理解了用来构建和计划的最关键的用例。涉众须要得到认可，在当前构架的环境中，仅仅要依照当前的计划开发整个系
统，就能实现当前的设想。在随后的迭代过程中，变更的数量应该有所降低，可是您可能会在每次迭代中花一些时间进行需求管理。

为构建阶段创建迭代计划而且设定基线
。
如今，能够为您的计划填充细节了。在每次构建迭代的最后，您能够按须要又一次考虑计划而且进行调整。调整过程常常是必需的，由于须要进行的工作往往被错误地
估算，业务环境也会经常变化，有时需求也会发生变更。为用例、场景以及技术工作设定优先级，然后将它们分配到迭代过程中。在每次迭代过程的最后，您计划产
生一个可以为涉众提供价值的工作产品。

您能够在细化阶段运行其它活动。我们推荐您建立測试环境而且開始开发測试。尽管具体的代码还没有完毕，可是您仍然能够设计測试，或许能够实施集成測
试。程序猿应该随时准备进行单元測试，而且了解怎样使用项目选定的測试工具。XP
推荐您在编写代码前先设计測试内容。这是个独到的见解，尤其是当您向现有代码主体中加入内容时。只是，不管您选择怎样进行測试，都应该在细化阶段建立常规
測试体制。

RUP 描写叙述的细化阶段包含 XP 中的研究阶段和投入阶段。XP
处理技术风险（比如新颖性和复杂性）的方式为使用”spike”解决方式，比如花费一些时间进行试验以对工作量进行估算。这样的技术在很多案例中都是有效
的，当较大风险没有体如今单个用例或”故事”中时，您就须要花些工夫确保系统的成功并且对工作量进行精确的估算。

在细化阶段，您会常常更新工件，比如起始阶段的需求与风险清单。在细化阶段可能出现的工件包含：

软件构架文档（SAD）。
SAD
是一个复合型的工件，它提供了整个项目的技术信息的单一来源。在细化阶段的最后，该文档可能会包括具体的介绍，描写叙述在结构上非常重要的用例，而且确定关键的
机制和设计元素。对于增强现有系统的项目，您能够使用曾经的
SAD，或者假设你认为不会带来什么风险，那么就决定不使用该文档。在全部的情况下，您都应该深思熟虑而且记录于文档中。

构建过程的迭代计划。
您
能够在细化阶段计划构建迭代的次数。每次迭代都有特定的用例、场景以及其它分配的工作项目。这些信息都在迭代计划中有所体现而且设定基线。评审与核准计划
能够作为细化阶段的出口标准的一部分。对于很小的短期项目来说，您能够将细化阶段的迭代与起始过程和构建过程合并。关键性的活动仍然能够进行，可是迭代
计划和评审所需的资源都会有所降低。

构建阶段


构建的目标是完毕系统开发。构建阶段从某种意义上来看是一个制造过程，当中重点工作就是管理资源、控制操作以优化成本、日程和质量。从这个意义上来讲，管理理念应该进行一个转换，从起始阶段和细化阶段的知识产权开发转换到构建和交付阶段的部署产品的开发。

XP 側重构建阶段。构建阶段是编写产品代码的阶段。XP全部阶段的目的都是为了进行计划，可是 XP 的关注焦点是构建代码。

构建阶段的每次迭代都具有三个关键活动：

管理资源与控制过程。
每一个人都须要了解自己的工作内容和时间。您必须保证工作负荷不会超过您的能力，并且工作能够按计划进行。

开发与測试组件。
您构建组件以满足迭代中用例、场景以及其它功能的须要。您对其进行单元測试和集成測试。

对迭代进行评估。
在迭代完毕时，您须要推断是否已经达到了迭代的目标。假设没有，您必须又一次划分优先级并管理范围以确保可以按时交付系统。

不同类型的系统须要使用不同的技术。RUP
为软件project师提供了不同的指导，以帮助他们创建恰当的组件。以用例和补充（非功能）需求的形式提出的需求是足够具体的，能够使project师开展工作。RUP
中的若干活动为设计、实施和測试不同种类的组件提供了指南。一名有经验的软件project师不须要具体查看这些活动。经验稍欠缺一些的project师能够通过最佳实践获得
非常大的帮助。每一个团队成员都能够按须要深入研究过程或者仅仅是略微了解一下。只是，他们都參照一个单独的过程知识基础。

在 XP 中，”故事”驱动实施过程。在 Extreme Programming Installed
一书中，Jeffries等人觉得”故事”是程序猿的”会话承诺”（promises for conversation）。
持续有效的交流大有裨益。尽管总是须要澄清一些细节，假设”故事”不够具体，而使程序猿不能完毕他们大部分工作，那么能够说”故事”还没有就绪。用例必须
足够具体以方便程序猿实施。在很多情况下，程序猿会帮助编写用例的技术细节。Jeffries
等人觉得，会话应该记录在文档中而且附加到”故事”中。RUP
也允许这个观点，除了以用例规格说明的形式，能够按须要使用非正式的形式。捕获并管理会话的结果是您必须管理的任务。

XP 的好处在于构建阶段。对于大多数团队来说，都存在适用于他们的”智慧与指南的结晶”。XP 中最显著的实践包含：

測试–程序猿不断地随着代码的开发编写測试。測试反映了”故事”。XP提倡您首先编写測试，这是一项优秀的实践，由于它能够迫使您深刻地理解”故
事”，而且在必要的地方提出很多其它的问题。不论在编写代码之前还是之后，一定要编写測试。将它们增加到您的測试包中，而且保证每次代码变更时都执行測试。

重构–不断重构系统的结构而不改变其行为，能够使其更加简单或灵活。您须要推断对您的团队来说是否存在一个较好的实践。简单与复杂的判别否因人而
异。有这样一个样例，一个项目中的两个非常聪明的project师每晚都要重写对方的代码，由于他们觉得对方的代码过于复杂。这产生了一个副作用，也就是他们总是干扰
第二天其它成员的工作。測试是有帮助的，可是假设他们之间不陷入代码之争的话，那么团队的处境就会更好一些。

结对编程–XP 觉得结对编程能够在更短的时间内创建出更好的代码。有证据表明这是正确的
。假设您遵照这项实践，就须要考虑很多人文与环境的因素。程序猿愿意对此进行尝试吗？您的物理环境能够满足这样的情况吗，即有足够的空间使两个程序猿在一个
单独工作站中有效地工作？您怎样对待远程工作或者在其它地点工作的程序猿？

持续集成–集成与构建工作须要持续进行，可能每天不止一次。这是一种确保代码结构完整的非常好的方式，它还同意在集成測试过程中进行持续的质量监控。

集体代码全部权–不论什么人都能够随时改动不论什么代码。XP 依赖这样一个事实，即一组好的单元測试将会降低这项实践的风险。让大家将每一件事都搞清楚的优点不能局限在一定的尺度上–是 1 万行代码、2 万行代码还是一定要少于 5 万行？

简单设计–随着重构过程的进行，须要不断地改动系统设计使其变更简单。再一次重申，您须要推断这项工作进行到何种程度才恰好合适。假设您在细化阶段中花费了必要霎时间来设计构架，我们相信简单的设计将会非常快完毕而且非常快变得稳定。

代码标准–这一直都是一项良好实践。标准是什么都没关系，仅仅要您使用它们并且每一个人都认可就能够。

RUP 与 XP
都觉得您必须管理（和控制）迭代过程。衡量标准能够提供较好的计划信息，由于它们能够帮助您选择对于您的团队来说什么是最适合的。须要衡量三件事：时间、
规模和缺陷。这样您就能够获得全部类型您所感兴趣的统计数字。XP
为您提供简单的衡量标准来推断进展而且预測成果。这些衡量标准环绕着完毕的”故事”数量、通过測试的数量以及统计中的趋势这些问题。XP
为使用最少量的衡量标准做出了一个优秀的表率，由于查看太多并不一定会添加项目成功的机会。RUP
为您提供了对于您能够衡量的内容以及怎样衡量的指导，而且举了有关衡量标准的样例。在全部的情况中，衡量标准必须简单、客观、易于搜集、易于表达，而且不
易产生误解。

在构建阶段的迭代过程中将会产生哪些工件呢？这取决于迭代是处于构建阶段的早期还是后期，您能够创建下面工件：

组件–组件代表了软件代码中的一部分（源码、二进制代码或者可运行程序），或者包括信息的文件，比如，一个启动文件或者一个 ReadMe 文件。组件还能够是其它组件的聚合，比如由几个可运行程序组成的应用程序。

培训资料–假设系统的用户界面比較复杂，那么请在用例的基础上尽早编写用户手冊和其它培训资料的初稿。

部署计划–客户须要一个系统。部署计划描写叙述了一组安装、測试而且有效地向用户交付产品所需的任务。对于 以Web 为中心的系统来说，我们已经发现，部署计划的重要性又提高了。

交付阶段迭代计划–临近交付时，您须要完毕而且评审交付阶段迭代计划。

代码完整吗？


觉得代码就是设计而且设计也就是代码。代码与自身总是一致的，这一点是千真万确的。我们觉得花费精力进行设计而且沟通设计是非常值得的，而不不过创建代码。以下的小故事会说明这一点。

RUP 与 XP 间的差异除了建立构架的方法以外，还包含其它方面的不同。当中一点就是关于设计概念的沟通方式。XP

一名project师曾有两次这种软件项目经历，设计体如今代码中，而且仅仅能在代码中找到设计信息。这两个项目都是关于编译器的：一个是改进与维护用于 Ada 编译器的优化程序，还有一个项目是将一个编译器的前端移植到一个新的平台上，而且连接一个第三方的代码生成器。

编译器技术是比較复杂的，但也是广为人知的。在这两个项目中，该project师想要概览编译器（或者优化程序）的设计和实施。在每一个案例中，他都接到一堆源
代码清单，大概有几英尺厚，并且被告知”查看这些信息”。他本应被提供一些带有支持性文字的构建非常好的图。优化程序的项目没有完毕。可是编译器项目确实取
得了成功，因为在代码开发过程中进行了广泛的測试，所以代码质量非常高。这位project师花费了数天时间研究调试器中的代码以弄明确其作用。个人的损失尚在其次，
团队的损失代价就更不值得。我们并没有按 XP 所看到的的那样在 40 小时后完毕开发，我们反而花费了大量个人努力来完毕工作。

仅仅开发代码带来的主要问题就是不管代码文档编写得多么好，它都没有告诉您它本身要解决的问题，它仅仅提供了问题的解决方式。一些需求文档在最初用户和
开发者继续工作非常长时间以后，仍然能够非常好地解释项目的原始目标。为了维护系统，您往往须要了解最初项目团队的设计目标。一些高级设计文档都是类似的
–代码常常没有经过高度的抽象，所以无法提供不论什么信息以表明总体的系统可以实现什么功能。在面向对象的系统中，这一点尤其是正确的，由于只查看里面的
类文件是非常难甚至无法得出运行线程。设计文档指导您在后期出现故障时该查看的内容–在后期常常会出现故障。

这个故事说明花费时间创建与维护设计文档确实会有所帮助。这能够减少误解的风险，而且加速开发过程。XP
的方式就是花费几分钟勾画出设计的大概内容或者使用 CRC 卡片。
可是团队不主张这样，而仅仅是进行代码开发。他们有一个隐含的如果，那就是任务非常easy，我们已经知道该怎样进行了。即使我们成功地完毕了任务，那么下一个新
来的人可能就不会如此幸运。RUP建议您多花费一些时间创建并维护这些设计工件。

交付阶段


交付阶段的焦点就是确保软件对于终于用户是可用的。交付阶段包含为公布进行产品的測试，在用户反馈的基础上做微小的调整等几方面内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。

较早公布、常常性公布都是非常好的办法。可是，我们通过公布要达到的目的是什么呢？XP
没有清楚地解释这个问题，也没有处理公布商业软件所必须制造问题。在内部项目中，您能够为解决这些问题找到捷径，可是即使这样，您仍然须要编辑文档、员工
培训等工作。那么技术支持与变更管理又怎样呢？希望现场客户控制这些内容，这是可行的吗？Bruce Conrad 在他的 XP 的
InfoWorld 评论 中指出用户并不希望得到的软件总是在持续变更。您必须对高速变更软件的利益和变更的劣势及可能带来的不稳定性进行权衡。

当您决定公布的时候，您必须为终于用户提供比代码多得多的东西。交付阶段的活动和工件会指导您完毕本部分软件开发过程。这些活动主要是为了向您的客户提供可用的产品。交付阶段的关键活动例如以下：

确定终于用户支持资料。该活动比較简单，您仅仅需提供一个清单就可以。可是务必要确保您的组织已准备好对客户进行技术支持。

在用户的环境中測试可交付的产品。假设您可以在公司内部模拟用户环境，那是最好只是的。否则，就到客户的公司去，安装软件而且保证其可以执行。您一定不想尴尬地回答客户：”可是在我们的系统上工作非常正常。”

基于用户反馈精确调整产品。假设可能的话，在您向有限数量客户交付软件时计划一次或者多次 Beta 測试周期。假设进行该測试，那么就须要对 Beta 測试周期进行管理，而且考虑您”收尾工作”中的客户反馈。

向终于用户交付终于产品。对于不同类型的软件产品和公布版本号，须要处理很多有关打包、制造和其它产品问题。您肯定不会只将软件拷贝到一个目录中，然后向客户发一封邮件告诉他们软件已经到位了。

与其它阶段一样，过程的格式与复杂度都有所不同。只是，假设您没有注意部署细节，那么可能导致数周或数月的良好开发工作前功尽弃，从而在进入目标市场时以失败告终。

在交付阶段中您能够生成若干工件。假设您的项目涉及到将来的公布（有多少项目没有涉及到呢？），那么您就应该開始为下次公布确定功能和缺陷。对于不论什么项目，下列工件都至关重要：

部署计划–完毕您始于构建阶段的部署计划而且将其作为交付的路线图。

版本号凝视–它是一个比較少见的软件产品，不包括对终于用户至关重要的指令。能够对其做出计划，对于凝视要有一个可用的、一致的格式。

交付阶段资料与文档–这类资料能够採取非常多形式。您能够在线提供全部内容吗？您会进行指导吗？您的产品帮助完整而且可用吗？不要觉得您所了解的，客户也相同了解。您的成功就在于帮助您的客户取得成功。

结束语


构建软件的工作远远多于编
写代码所工作。一个软件开发过程必须集中处理向用户公布高质量软件的全部必需活动。一个完整的过程不必是庞大的。我们通过集中论述项目中的主要活动和工
件，已经向您展示了怎样进行一个小型可是完整的过程。假设运行某项活动或者创建某个工件对于缓解项目中的风险是有帮助的，那么就请进行。您能够按须要为您
的项目团队和组织使用或多或少的过程和格式。

RUP 和 XP 并不必是互相排斥的。通过结合使用这两种方法，您全然能够得到一个过程，帮助您比方今更快地交付更高质量的软件。Robert
Martin 描写叙述了一个叫做 dX 的过程，他将其作为 RUP 的附属品 。它就是一个从 RUP 框架中构建的过程的实例。

一个优秀的软件过程能够使用经业界验证的最佳实践。最佳实践已经在真实的软件开发组织中使用，而且经历了时间的考验。XP 是眼下广为关注的方法。它以代码为中心，并提供了一项承诺：花费最少的过程开销得到最大的生产力。XP 中的很多技术值得在恰当的情况中考虑和採用。

XP 关注”故事”、測试和代码–它以一定的深度讨论了计划，但没有具体阐述怎样获取计划。XP
意味着您能够完毕其它一些工作，比如”使用一些卡片进行 CRC 设计或者草拟某种
UML……”或者”请不要生成并不使用的文档或者其它工件”，但仅仅是一带而过。RUP
希望您在定制和更新开发计划时，只考虑创建实用和必须的东西，而且指出了这些东西该是什么。

RUP 是一个能够处理整个软件开发周期的过程。它关注最佳实践，而且经过了数千个项目的洗礼。我们鼓舞研究和发明新的技术以产生最佳实践。随着新的最佳实践崭露头脚，我们希望将它们纳入 RUP 中。

附录：Rational Unified Process


Rational
Unified Process，或者简称 RUP，提供了软件开发的规律性方法。它是由IBM
Rational开发并维护的过程产品。它为来同类型的项目提供了几种即装即用的路线图。RUP 还提供了一些信息，帮助您在软件开发过程中使用其它
Rational 工具，可是它不要求将 Rational 工具有效地应用于整个组织，您也能够将 Rational
工具与其它供应商的产品进行集成。

RUP 为软件项目全部方面提供了指导。并不须要您运行不论什么特定的活动或者创建不论什么特定的工件。它仅仅为您提供信息和指南，您能够决定将哪些应用于您的组织。假设没有特定的路线图适合您的项目或者组织，RUP 还提供了一些指南来帮助您量身定做你的过程。

RUP 强调採用现代软件开发的一些最佳实践，作为一种减少开发新软件所带来的内在风险的方式。这些最佳实践包含：

1． 迭代开发
2． 管理需求
3． 使用基于组件的构架
4． 可视建模
5． 持续的质量验证
6． 控制变更

这些最佳经验融合到 Rational Unified Process 的下面定义中：

角色–运行的系列活动和拥有的工件。
学科–软件project中的关键领域，比如需求、分析与设计、实施与測试。
活动–工件生成与评估方式的定义。
工件–在运行活动中所使用的、生成的或改动的工作产品。

RUP
是一个迭代过程，确定了不论什么软件开发项目的四个阶段。随着时间的推进，每一个项目都要经历起始阶段、细化阶段、构建阶段和交付阶段。每一个阶段包含一次或多次
迭代，当中您能够生成可运行文件，可是系统可能不完整（可能起始阶段除外）。在每次迭代过程中，您以不同的细节级别运行几个学科中的活动。下文是
RUP 的概述图。

RUP 概览图

The Rational Unified Process, An Introduction, Second Edition 一书是
RUP 的好的概述。您能够在 Rational 的 Web 网站 www.rational.com 上找到更进一步的信息和对于 RUP 的评价。

附录：极限编程


极限编程（XP）
是由 Kent Beck 在 1996
年开发的一种软件开发学科。它基于四个价值：沟通、简单、反馈和勇气。它强调客户与开发团队成员的持续沟通，在开发进程中设立一名现场客户。该现场客户决
定创建的内容和顺序。通过持续重构代码并创建最小的非代码工件集合而体现简单。很多短期公布和持续单元測试建立了反馈机制。勇气意味着完毕正确的事情，即
使并非最流行的事情。它还意味着诚实面对您能做的和不能做的事情。

12 个 XP 实践为这四个价值提供支持。它们是：

有计划的开发：通过结合使用优先级”故事”和技术估算，确定下一版本号的功能。

小版本号：以小的增量版本号常常向客户公布软件。

隐喻：隐喻是一个简单、共享的”故事”或描写叙述，说明系统怎样工作。

简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点而且立马进行移除。

測试：用户编写測试内容以对”故事”进行測试。程序猿编写測试内容来发现代码中的不论什么问题。在编写代码前先编写測试内容。

重构：这是一项简化技术，用来移除代码中的反复内容和复杂之处。

结对编程：团队中的两个成员使用同一台计算机开发全部的代码。一个人编写代码或者驱动，还有一个人同一时候审查代码的正确性和可理解性。

集体代码全部权：不论什么人都拥有全部的代码。这就意味这每一个人都能够在不论什么时候变更不论什么代码。

持续集成：每天多次创建和集成系统，仅仅要不论什么实现任务完毕就要进行。

每周 40 个小时：程序猿在疲劳时无法保证最高效率。连续两周加班是绝对不同意的。

现场客户：一名真实的客户全时工作于开发环境中，帮助定义系统、编写測试内容并回答问题。

编码标准：程序猿採用一致的编码标准。

測试驱动开发(TDD)是极限编程的重要特点，它以不断的測试推动代码的开发，既简化了代码，又保证了软件质量。本文从开发者使用的角度，介绍了 TDD 优势、原理、过程、原则、測试技术、Tips 等方面。

背景


一个高效的软件开发过程
对软件开发者来说是至关重要的，决定着开发是痛苦的挣扎，还是不断进步的喜悦。国人对软件蓝领的不屑，对繁琐冗长的传统开发过程的不耐，使大多数开发人
员无所适从。近期兴起的一些软件开发过程相关的技术，提供一些比較高效、有用的软件过程开发方法。当中比較基础、关键的一个技术就是測试驱动开发
（Test-Driven
Development）。尽管TDD光大于极限编程，但測试驱动开发全然能够单独应用。以下就从开发者使用的角度进行介绍，使开发者用最少的代价尽
快理解、掌握、应用这样的技术。以下分优势，原理，过程，原则，測试技术，Tips等方面进行讨论。

1. 优势


TDD的基本思路就是通过測试来推动整个开发的进行。而測试驱动开发技术并不仅仅是单纯的測试工作。

需求向来就是软件开发过程中感觉最不好明白描写叙述、易变的东西。这里说的需求不仅仅是指用户的需求，还包含对代码的使用需求。非常多开发者最害怕的就是
后期还要改动某个类或者函数的接口进行改动或者扩展，为什么会发生这种事情就是由于这部分代码的使用需求没有非常好的描写叙述。測试驱动开发就是通过编写測试
用例，先考虑代码的使用需求（包含功能、过程、接口等），并且这个描写叙述是无二义的，可运行验证的。

通过编写这部分代码的測试用例，对其功能的分解、使用过程、接口都进行了设计。并且这样的从使用角度对代码的设计通常更符合后期开发的需求。可測试的要求，对代码的内聚性的提高和复用都很故意。因此測试驱动开发也是一种代码设计的过程。

开发者通常对编写文档很厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而測试驱动开发过程中产生的測试用例代码就是对代码的最好的解释。

快乐工作的基础就是对自己有信心，对自己的工作成果有信心。当前非常多开发者却常常在操心：“代码是否正确？”“辛苦编写的代码还有没有严重
bug？”“改动的新代码对其它部分有没有影响？”。这样的操心甚至导致某些代码应该改动却不敢改动的地步。測试驱动开发提供的測试集就能够作为你信心的来
源。

当然測试驱动开发最重要的功能还在于保障代码的正确性，可以迅速发现、定位bug。而迅速发现、定位bug是非常多开发者的梦想。针对关键代码的測试集，以及不断完好的測试用例，为迅速发现、定位bug提供了条件。

我的一段功能非常复杂的代码使用TDD开发完毕，真实环境应用中仅仅发现几个bug，并且非常快被定位解决。您在应用后，也一定会为那种自信的开发过程，功能不断添加、完好的感觉，迅速发现、定位bug的能力所感染，喜欢这个技术的。

那么是什么样的原理、方法提供上面说的这些优点哪？以下我们就看看TDD的原理。

2. 原理


測试驱动开发的基本思想就是在开发功能代码之前，先编写測试代码。也就是说在明白要开发某个功能后，首先思考怎样对这个功能进行測试，并完毕測试代码的编写，然后编写相关的代码满足这些測试用例。然后循环进行加入其它功能，直到完所有功能的开发。

我们这里把这个技术的应用领域从代码编写扩展到整个开发过程。应该对整个开发过程的各个阶段进行測试驱动，首先思考怎样对这个阶段进行測试、验证、考核，并编写相关的測试文档，然后開始下一步工作，最后再验证相关的工作。下图是一个比較流行的測试模型：V測试模型。

【图 V測试模型】

在开发的各个阶段，包含需求分析、概要设计、具体设计、编码过程中都应该考虑相相应的測试工作，完毕相关的測试用例的设计、測试方案、測试计划的编
写。这里提到的开发阶段仅仅是举例，依据实际的开发活动进行调整。相关的測试文档也不一定是很具体复杂的文档，或者什么形式，但应该养成測试驱动的习惯。

关于測试模型，还有X測试模型。这个測试模型，我觉得，是对具体阶段和编码阶段进行建模，应该说更具体的描写叙述了具体设计和编码阶段的开发行为。及针对某个功能进行相应的測试驱动开发。

【图 X測试模型】

基本原理应该说很easy，那么怎样进行实际操作哪，以下对开发过程进行具体的介绍。

3. 过程


软件开发其它阶段的測试驱动开发，依据測试驱动开发的思想完毕相应的測试文档就可以。以下针对具体设计和编码阶段进行介绍。

測试驱动开发的基本步骤例如以下：

1） 明白当前要完毕的功能。能够记录成一个 TODO 列表。

2） 高速完毕针对此功能的測试用例编写。

3） 測试代码编译不通过。

4） 编写相应的功能代码。

5） 測试通过。

6） 对代码进行重构，并保证測试通过。

7） 循环完毕全部功能的开发。

为了保证整个測试过程比較快捷、方便，通常能够使用測试框架组织全部的測试用例。一个免费的、优秀的測试框架是 Xunit 系列，差点儿全部的语言都有相应的測试框架。

开发过程中，通常把測试代码和功能代码分开存放，这里提供一个简单的測试框架使用样例，您能够通过它了解測试框架的使用。以下是文件列表。

	project/				项目主文件夹

	project/test			測试项目主文件夹

	project/test/testSeq.cpp		測试seq_t 的測试文件，对其它功能文件的測试文件复制后改动就可以

	project/test/testSeq.h

	project/test/Makefile			測试项目的 Makefile 

	project/test/main.cpp			測试项目的主文件，不须要改动

	project/main.cpp		           项目的主文件

	project/seq_t.h			功能代码，被測试文件

	project/Makefile		           项目的 Makefile

主要流程基本如此，但要让你的代码非常easy的进行測试，全面又不繁琐的进行測试，还是有非常多測试原则和技术须要考虑。

4. 原则


測试隔离。不同代码的測试应该相互隔离。对一块代码的測试仅仅考虑此代码的測试，不要考虑事实上现细节（比方它使用了其它类的边界条件）。

一顶帽子。开发者开发过程中要做不同的工作，比方：编写測试代码、开发功能代码、对代码重构等。做不同的事，承担不同的角色。开发者完毕相应的
工作时应该保持注意力集中在当前工作上，而不要过多的考虑其它方面的细节，保证头上仅仅有一顶帽子。避免考虑无关细节过多，无谓地添加复杂度。

測试列表。须要測试的功能点非常多。应该在不论什么阶段想加入功能需求问题时，把相关功能点加到測试列表中，然后继续手头工作。然后不断的完毕相应的測试用例、功能代码、重构。一是避免疏漏，也避免干扰当前进行的工作。

測试驱动。这个比較核心。完毕某个功能，某个类，首先编写測试代码，考虑其怎样使用、怎样測试。然后在对其进行设计、编码。

先写断言。測试代码编写时，应该首先编写对功能代码的推断用的断言语句，然后编写对应的辅助语句。

可測试性。功能代码设计、开发时应该具有较强的可測试性。事实上遵循比較好的设计原则的代码都具备较好的測试性。比方比較高的内聚性，尽量依赖于接口等。

及时重构。不管是功能代码还是測试代码，对结构不合理，反复的代码等情况，在測试通过后，及时进行重构。关于重构，我会另撰文具体分析。

小步前进。软件开发是个复杂性非常高的工作，开发过程中要考虑非常多东西，包含代码的正确性、可扩展性、性能等等，非常多问题都是由于复杂性太大导致
的。极限编程提出了一个很好的思路就是小步前进。把全部的规模大、复杂性高的工作，分解成小的任务来完毕。对于一个类来说，一个功能一个功能的完毕，如
果太困难就再分解。每一个功能的完毕就走測试代码－功能代码－測试－重构的循环。通过分解减少整个系统开发的复杂性。这种效果很明显。几个小的功能代码
完毕后，大的功能代码差点儿是不用调试就能够通过。一个个类方法的实现，非常快就看到整个类非常快就完毕啦。本来感觉非常多特性须要添加，非常快就会看到没有几个
啦。你甚至会为这个速度感到震惊。（我理解，是大幅度降低调试、出错的时间产生的这样的速度感）

5. 測试技术

5.1. 測试范围、粒度


对
哪些功能进行測试？会不会太繁琐？什么时候能够停止測试？这些问题比較常见。按大师 Kent Benk
的话，对那些你觉得应该測试的代码进行測试。就是说，要相信自己的感觉，自己的经验。那些重要的功能、核心的代码就应该重点測试。感到疲劳就应该停下来休
息一下。感觉没有必要更具体的測试，就停止本轮測试。

測试驱动开发强调測试并不应该是负担，而应该是帮助我们减轻工作量的方法。而对于何时停止编写測试用例，也是应该依据你的经验，功能复杂、核心功能的代码就应该编写更全面、仔细的測试用例，否则測试流程就可以。

測试范围没有静态的标准，同一时候也应该能够随着时间改变。对于開始没有编写足够的測试的功能代码，随着bug的出现，依据bug补齐相关的測试用例就可以。

小步前进的原则，要求我们对大的功能块測试时，应该先分拆成更小的功能块进行測试，比方一个类A使用了类B、C，就应该编写到A使用B、C功能的測
试代码前，完毕对B、C的測试和开发。那么是不是每一个小类或者小函数都应该測试哪？我觉得没有必要。你应该运用你的经验，对那些可能出问题的地方重点測
试，感觉不可能出问题的地方就等它真正出问题的时候再补測试吧。

5.2. 怎么编写測试用例


測试用例的编写就用上了传统的測试技术。

• 操作过程尽量模拟正常使用的过程。
• 全面的測试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖。
• 測试数据尽量包含：真实数据、边界数据。
• 測试语句和測试数据应该尽量简单，easy理解。
• 为了避免对其它代码过多的依赖，能够实现简单的桩函数或桩类（Mock Object）。
• 假设内部状态很复杂或者应该推断流程而不是状态，能够通过记录日志字符串的方式进行验证。

6. Tips


非常多朋友有疑
问，“測试代码的正确性怎样保障？是写測试代码还是写測试文档？”这样是不是会陷入“鸡生蛋，蛋生鸡”的循环。事实上是不会的。通常測试代码一般是很easy
的，通常环绕着某个情况的正确性推断的几个语句，假设太复杂，就应该继续分解啦。而传统的开发过程通常强调測试文档。但随着开发节奏的加快，用户需求的不
断变化，维护高层（需求、概要设计）的測试文档能够，更低层的測试文档的成本的确太大了。并且可实时验证功能正确性的測试代码就是对代码最好的文档。

软件开发过程中，除了遵守上面提到的測试驱动开发的几个原则外，一个须要注意的问题就是，谨防过度设计。编写功能代码时应该关注于完毕当前功能点，
通过測试，使用最简单、直接的方式来编码。过多的考虑后期的扩展，其它功能的加入，无疑添加了过多的复杂性，easy产生问题。应该等到要加入这些特性时在进
行具体的測试驱动开发。到时候，有整套測试用例做基础，通过不断重构非常easy加入相关特性。