3. Rational 过程的各个阶段
3.1. 起始阶段
这个阶段产生一个预测产品的最初设想，并将其转换为一个实际的项目。本阶段的目的是建立一个新产品或一次大的更新的业务案例，并且指定项目的范围。
对于一个新产品的开发，本阶段的主要结果是得到一个"做还是不做"的决定以进入下一阶段，并投入一定的时间和资金来详细分析构建什么、能否构建，以及如何构建。
对于一个现有产品的演进，这会是一个简短的阶段， 主要看用户或客户的要求、问题报告，或是新的技术动态。
对于一个契约性的开发，是否进行项目的决定取决于在特定领域的经验、以及组织在此领域的竞争力和市场情况。这里起始阶段可以归结为一个参加投标的决定，或投标活动本身。该决定可能是基于一个现有的研究原型，其结构对最终软件可能合适，也可能不合适。
入口准则:
对于一项需要的描述，可以采用以下形式：
. 一份最初的设想
. 一个遗留系统
. 一份建议请求（An RFP --request for proposal)
. 先前一代的产品和一个增强要求清单
. 一些资产(软件, 专门技能, 财务资产)
. 一个概念原型或实物模型
出口准则：
. 一个初始的业务案例至少要包含以下内容:
对产品设想的明确表达即核心需求，表述为功能、范围、性能、容量和技术等。
成功标准 (如收入的数目)
最初的风险评估
完成细化阶段所需的资源估算
通常在初试阶段结束时，我们将得到：
. 一个最初的域分析模型(完成大约10%-20%), 确定最关键的用例, 并且足以进行进构架工作。
. 一个最初的构架原型，在这个阶段可以是一个一次性原型
3.2. 细化阶段
本阶段的主要目的是更彻底地分析问题域，定义构架并使之稳定，确定项目的最大风险。这样在本阶段结束时，我们可以得到一个关于下2个阶段如何工作的综合计划：
. 一个基于分析模型的基线产品设想（即最初的需求集合）。
. 至少对第一次构建迭代的评价准则。
. 一个基线软件构架。
. 开发和部署产品的必需资源，尤其是人员和工具。
. 一份日程安排。
. 足以对构建阶段的成本、日程安排和质量做出"精确"的评估的一份风险决议。
在这个阶段，建立了一个可执行的构架原型；它至少实现了初始阶段识别出的最关键的用例 ，解决了项目的最大技术风险；根据范围、规模、风险和项目新颖程度的不同构架原型需要一次或多次迭代。这是一个生成高质量代码（这些代码成为架构基线）的演进原型，但是也不排除开发出一个或几个试探性的、一次性原型，以降低开发的风险：对需求、可行性、人机界面研究、向投资者演示等的精化。在本阶段的结束时，仍然会产生一个"做还是不做"的决定， 以确定是否要真正投资构建这个产品（或参与合同项目的竞标）。
此时产生的计划一定要足够详细，风险也必须充分降低，可以对开发工作的完成进行精确的成本和日程估算。
入口准则：
前一阶段出口准则所描述的产品和工件
被项目管理者和投资者认可的计划，和细化阶段所需的资源
出口准则：
. 一份详细的软件开发计划，包含：
更新后的风险评估
一份管理计划
一份人员配置计划
一份显示迭代内容和次数的阶段计划
一份迭代计划，详细计划下次迭代
开发环境和所需的其他工具
一份测试计划
. 一个基线设想，以对最终产品的一个评估准则的集合的形式
. 用于评估构建阶段最初的迭代结果的客观、可测量的演进标准
. 一个域分析模型（80%完成），相应的构架可以称之为是"完整的"
. 一个软件构架描述（说明约束和限制）
. 一个可执行的构架基线
3.3. 构建阶段
本阶段可以划分为数次迭代，不断充实构架基线，向最终产品逐步演进或增量演进。在每次迭代过程中，上个阶段（细化阶段）的工件得到扩充和修正， 但它们最终将随着系统向正确和完整的方向的演进而稳定下来。在这个阶段，除了软件本身，还生成一些新的工件：文档（既有内部使用的文档，也有面向最终用户的文档）、测试床及测试套件、部署附件，以及用于支持下一阶段的部署辅助（例如销售辅助）。
对每次迭代，都具有：
入口准则：
. 上次迭代的产品和工件。 迭代计划必须阐明迭代的特定目标：
将要开发的新增功能，覆盖了哪些用例或场景
本次迭代过程中减少的风险
本次迭代过程中修改的缺陷
出口准则：
更新后的产品和工件，另外还有:
. 一个版本描述文档，记录了迭代的结果
. 测试用例和根据产品得出的测试结果
. 一个详细描述下一次迭代的计划
. 对下一次迭代的客观度量标准
到构建阶段的后期，必须完成以下工件，及本阶段最后一次迭代额外的出口准则：
. 一个部署计划，指定必需的事项：
打包
定价
演示
支持
培训
移交策略 (例如一个现有系统的更新计划)
产品 (软盘和手册)
用户文档
