本文对 Rational 软件开发过程（Rational Software Development Process）的原理和结构给出了高度的描述, 它具有足够的普遍性，可以在规模与应用领域方面，为各个软件产品和项目量身订做。

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

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

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

2.总体软件生命周期

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

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

2.2 周期和阶段

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

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

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

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

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

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

　

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

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

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

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

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

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

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

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

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

2.5工作量和日程安排
各阶段在工作量和时间安排上是不同的。尽管由于不同项目类型之间相差会很大，一个典型的中等规模项目的最初开发周期可以预计为下面的比率：

	起始阶段	细化阶段	构建阶段	移交阶段
工作量	5%	20%	65%	10%
日程安排	10%	30%	50%	10%

可以用下图表示：

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

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

　

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

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

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

尽管具体的项目有具体的区别，但对于一个中等规模、初次开发的典型项目来说，其开发周期中各种活动的比例如下：

计划与管理	15%
分析/需求	10%
设计/集成	15%
实施/功能测试	30%
度量/评估/验收测试	15%
工具/环境/变更管理	10%
维护（开发过程中的修补）	5%

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

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

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

5.2技术工件
它们或者是交付的产品，可执行的软件及手册，或者是一些用于制造产品的蓝图，这些产品包括软件模型、源代码和其他有助于理解和演进产品的工程信息。

• 用户手册, 在生命周期早期开发。
• 软件文档, 最好以源代码自建文档和模型的形式，其中模型是用合适的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）进行更新。
• 必要的用户手册

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

7. 结束语
Rational 过程强调通过快速开发出一个定义了构架的系统的初始版本，从而尽早处理风险问题。它并没有假设您在项目的初试阶段就有一个固定不变的需求集合，而是允许随着项目的演进不断精化需求。它认可并支持需求的变化。 过程不过分倚重文档或"仪式"， 它自身就解决了与软件开发相关的那些繁杂任务的自动化。重点主要放在软件产品本身及产品质量上，即最终用户对它的满意程度，以及它要满足的投资回报目标。

一个从本文描述的Rational过程所派生的软件开发过程完全能够符合ISO 9000标准的要求。

更进一步的读物
B. W. Boehm, "A Spiral Model of Software Development and Enhancement," IEEE Comp., 21 (5), May 1988, pp. 61-72.
G. Booch, Object Solutions: Managing the Object-Oriented Project, Addison-Wesley , Redwood City, California, 1996.
M. T. Devlin, and W. E. Royce, Improving Software Economics in the Aerospace and Defense Industry, Technical paper TP-46, Rational Software Corp., Santa Clara, CA, 1995.
T. Gilb, Principles of Software Engineering Management, Addison-Wesley, Wokingham, UK, 1988.
W. Humphrey, Managing the Software Process, Addison-Wesley, Reading MA, 1989.
Ph. Kruchten, "Un processus de dévelopment de logiciel itératif et centré sur l'architecture," Proceedings of the 4th International Conference on Software Engineering, Toulouse, France, December 1991, EC2.
D. L. Parnas, & P. C. Clements, "A Rational Design Process: How and Why to Fake It," IEEE Trans. on Soft. Eng., SE-12 (2), February 1986, pp. 251-257

术语表
工件（Artifact）：软件产品本身之外的任何文档或者软件。
基线（Baseline ）：从属于变更管理和配置控制的版本发布。
构建（Construction）： 过程的第三个阶段，在该阶段软件从可执行的架构基线进入准备交付给用户的状态。
周期（Cycle）：包含四个阶段的完整的过程，这四个阶段是起始阶段，细化阶段，构建阶段和移交阶段。时间跨度为从起始阶段的开始到移交阶段的结束。
细化（Elaboration ）：过程的第二个阶段，在这个阶段定义产品远景及其构架。
演进（Evolution）：初次开发周期之后的一个软件生命阶段；产品进行演进的任何一个后续周期。
代（Generation） 一次软件开发周期的成果。
起试（Inception）： 过程的第一个阶段，在该阶段，构思、RFP、前一代作为进入细化阶段的开始。
迭代（Iteration） ：使用基线规划和评估标准的一个清晰的活动序列。
里程碑（Milestone）：采取一个事件来正式初始化并总结一次迭代过程。
阶段（Phase ）：在一个过程的两个主要的里程碑之间的时间，在此期间，定义的目标集合与预期相吻合，工件也完成了，并且要做出决定是否进入下一个阶段。
产品（Product）：包括作为开发结果的软件，和一些与之相关的工件（文档，发布媒体，培训）
原型（Prototype）：不必从属于变更管理和配置控制的一次发布。
发布（Release）：最终产品的子集，它是一个主要里程碑的评估目标。（参见：原型，基线）
风险（Risk）：正在发生的或者将要发生的一些利害关系，在很大程度上可能阻碍成功地达到主要里程碑。
移交（Transition ） ：过程的第四个阶段，在该阶段软件将交付到用户手中。
远景(Vision )：从用户的角度来看，将要开发的产品。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  

　

关于作者 Philippe Kruchten,Philippe Kruchten,Vancouver，BC,pbk@rational.com