移交阶段完成产品发布
当项目进入移交阶段时，系统已具备可初步运行能力。
此时，项目精力详细系统已能在用户环境中运转，尽管不是很完美。
本阶段的基本目标时：
- 要满足初始阶段所确立的需求，让项目相关人员满足
- 处理在用户环境中运转时遇到的所有问题。
验收测试是客户的职责，尽管一些客户把它委托给专门的验收测试组织。
移交阶段概述
本阶段的终点是要在运行环境中安置产品。根据产品与其十尝的关系的性质的不同，项目实现这一目标的具体途径会有所不同。
项目监控从运行站点反馈回来的信息，用来完成以下工作：
- 发现系统是否真正实现了业务及其用户的需求。
- 发现没有遇见的风你先
- 留意为解决的问题
- 寻找错误
- 修复用户文档中不清楚和有遗漏的内容
- 把终点放在用户现得无能为力和需要信息或培训的地方。
基于这些反馈信息，项目组修改系统或者相关的制品。
移交阶段随着产品的发布而结束。
移交阶段初期
软件是在大量的业务安排下进行生产的。可以把这些安排归为两种类型：
- 由软件供应商开发，在十尝中销售给多个客户。
- 软件开发机构于单个客户鉴定的开发合同。
- 软件组织为但站点上的单个客户开发程序。
- 软件组织为拥有许多下级单位和站点的客户开发程序。
- 任务外包的软件公司
- 在公司限定的擦无安排，为统一公司内的其他部门开发软件的内部软件开发组织。
移交阶段的组织和用户的关系在这些不同的模式下会有所不同。
制定移交阶段计划
项目处于构造阶段时，很难预先制定移交阶段计划的大量细节。另一方面，项目经理指导本阶段讲获得在构造阶段开发的beta版本，并发布给选定的用户进行测试。注意认识为移交阶段的早期规划提供了基础。
在制定移交阶段计划时，可能会出现什么才是“足够好”的软件这一问题。有三个答案：
- 首先，统一过程的阶段和迭代有意识地去识别风险，捕获正确的需求，并合理地制定项目计划。
- 其次，既然项目组和项目相关人员都不期望初步可运行版本没有一丝一毫的缺陷，他们都应该会允许为移交阶段安排实际和资源。
- 第三，既然项目组和相关想人员同理何做并达成以上共识，其结论时，可能会延迟移交阶段或这讲不希望做的工作延期奥下一个开发周期。
移交阶段人员安排
设立评价准则
对于移交阶段，只要评价这一阶段出现的问题。基本上存在以下五个方面的我呢提：
- β用户是否使用了所有的关键功能？
- 类似地，产品是否同理由客户进行的验收测试？
- 用户资料是否达到可验收质量？
- 是否移交准备好所需要的考察资料？
- 最后，客户和用户是否对产品表示满意？
核心工作流在本阶段中扮演了很小的角色
我们再次部分并行的开展四组活动。第一部分时五个核心工作流；第二部分时迭代计划；第三部分时业务案例，第四部分时评估。
本阶段活动水平处于很低状态，这并不是说在本阶段没有大量的工作可做，而是几乎没有与需求、分析和设计工作流相关的工作。
在移交阶段要干些什么
项目按如下顺序执行移交活动：
- 以构造阶段产生的版本为基础，准备实际β版本
- 在站点上安装该本本，并在该站点上做一些附件的工作
- 根据测试站点的反馈采取行动
- 让目前已改正过的额产品能适应用户环境。
- 完成项目制品。
- 决定项目合适结束。
发行beta版本
大多数β测试用户将是非常有经验的。
在移交阶段早期，项目组将早已准备好的β用户或验收测试人员所需要的文档放在一起，把特殊的β用法说补充到文档中。然后选择beta用户，并将beta版本及其相关文档分发给他们。
安装beta版本呢
响应测试结果
为了决定如何采取行动，项目组要手机并分析测试结果。结果可能会分为以下两种：
- 相对较小的代码故障，只要简单地浏览一下即可将其改正。导致故障的首要与i尿素可能来自构件缺陷，但是该缺陷可能会追杀到涉及、分析或更早模型中的缺陷。另外没项目组要考虑如下问题：
- 该缺陷是否与其他尚未发现的缺陷有联系？
- 步改动构件或涉及，缺陷是否可以得到纠正？
- 纠正是否没有带来新的问题？
- 非常重要的问题，其影响可能非常广泛，甚至可能涉及到系统构架的改变。
让产品适应不同的用户环境
软件组织按两种广义的关系面向十尝并提供产品：上市产品和单一客户关系。任何一种关系都可能有更进一步的任务：数据移植。
- 市场关系， 市场可能是高夫分化的目标几乎，开发组必须为不同的用户准备不同的可执行版本。
- 单一客户关系，按合同所安排的方式将系统移交给单个用户。
- 数据移植或转换
完成制品
指导项目完成了全部制品，移交阶段才结束。
项目什么适合结束
移交阶段的结束，不仅是在所有工作和制品都完成时，而是在客户满意时。那么什么适合用户才满意呢？这要取决于市场关系。
- 对于用于市场销售的产品，项目经理认为当项目组从β版本获得反馈并对这些反馈信息进行处理后，大多数的用户就会满意了。那是，在发布一个通用版本。移交阶段要在项目组把继续维护的任务交给一个支持组织的适合才结束。
- 对于特定用户签订合同的产品，项目经理认为要在系统通过验收测试后，客户才算满意。
业务案例的完成
详细描述阶段结束时，在业务标书中提到了移交阶段的花费和进度安排。到移交阶段结束时，移交获得了判断业务案例价值所需要的进一步信息。
控制进度
项目经理把实际进度与为阶段所规划的进度、人力和费用进行比较。
在移交阶段结束时，项目预算也技术了，项目经理会召集人员回顾：就整个工程而言，与计划的数字相关的实际时间进度、个人共识、费用、缺陷率以及公司可能采用的其他的一些度量，已达如下目的：
- 看一看项目是否达到了计划的目标。
- 确定为什么没有达到计划目标的原因。
- 把项目的度量数据添加到公司的度量数据库中，以备将来使用。
业务计划的审查
这个计划预示了项目是否会缺德经济上的成功。童颜的有两种模式：
- 基于合同的产品开发，黑瞳的定价是否大于项目实施的费用？
- 基于市场的产品开发，项目成功与否，以产品是否大奥公司基于在开发过程中所投入的资金而确定的最低收益率来衡量。
评估移交阶段
项目经理召集一个小组对移交阶段进行评估，并从整体上对开发周期进行事后分析。
对迭代和阶段的评估
如果项目开发组织有效地实施了前三个阶段，则移交阶段就能顺利进行，并按计划和预算圆满地完成任务。评估小组要找出一些对产品质或者下一个生命周期要处理的项目时很有价值的注意事项。
项目的事后分析
与评估想法，事后分析主要时致力于分析项目组织正确地做了哪些事情，错误地做了哪些事情。目的是为更有效地组织后续项目和更成各地执行开发过程提供记录。
制定下一版本或升级版开发计划
几十年来软件工业商城经验表明，几乎没有长期不变的如阿健。当上述因素改变时，几乎全部的软件系统理解进入一个新的生命周期。这个ixn的周期将重复初始、细化、构造和移交阶段。
关键的可交付内容
本阶段的可交付内容与构造阶段所陋劣的内容十分相似。但是此时他们移交被修正，而且完成了如下的交付内容：
- 可执行软件本身，包括安装软件
- 合同、许可证、弃权声明和波证书等法律文件。
- 完成和该横过的产品发布基线，包括系统的所有模型。
- 完成的和更新过的构件描述。
- 最终用户、操作人和系统管理人员使用的手册和培训材料
- 客户支持连接和WEB连接，从中可以招等多的信息。