3.4. 移交阶段

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

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

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

    入口准则：

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

    出口准则：

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

    3.5. 演进周期

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

    较小的演进可以通过延长移交阶段或增加一两次迭代来完成。

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

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

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

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

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

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