RUP 学习二：阶段 跨`�(薥K�
害鷉�
阶段一：先启
目标
先启阶段的基本目标是实现项目的生命周期目标中所有涉众之间的并行。 先启阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。对于重点是扩展现有系统的项目来说，先启阶段较短，但重点仍然是确保项目值得进行而且可以进行。
先启阶段的主要目标包括：
- 建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望产品中包括和不包括的内容。
- 识别系统的关键用例（也就是将造成重要设计折衷操作的主要场景）。
- 对比一些主要场景，展示（也可能是演示）至少一个备选构架
- 评估整个项目的总体成本和进度（以及对即将进行的精化阶段进行更详细的评估）
- 评估潜在风险（不可预测性的来源）
- 准备项目的支持环境。
核心活动
- 明确地说明项目规模。这涉及了解环境以及最重要的需求和约束，以便于可以得出最终产品的验收标准。
- 计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备选方案。
- 综合考虑备选构架，评估设计和自制/外购/复用方面的折衷，从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。先启阶段的原型设计工作应该限制在确信解决方案可行就可以了 - 该解决方案在精化和构建阶段实现。
- 准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。
阶段二：精化
目标
精化阶段的目标是建立系统构架的基线，以便为构建阶段的主要设计和实施工作提供一个稳定的基础。构架是基于对大多数重要需求（对系统构架有很大影响的需求）的考虑和风险评估发展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。
精化阶段的主要目标包括：
- 确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。对大多数项目来说，通过此里程碑也就相当于从简单快速的低风险运作转移到高成本、高风险的运作，并且在组织结构方面面临许多不利因素。
- 处理在构架方面具有重要意义的所有项目风险
- 建立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常可以显示项目的最大技术风险。
- 制作产品质量构件的演进式原型，也可能同时制作一个或多个可放弃的探索性原型，以减小特定风险，例如：
- 设计/需求折衷
- 构件复用
- 产品可行性或向投资者、客户和最终用户进行演示。
- 证明已建立基线的构架将在适当时间、以合理的成本支持系统需求。
- 建立支持环境。
为了实现这个主要目标，建立项目的支持环境也同等重要。这包括创建开发案例、创建模板和指南、安装工具。
核心活动
- 快速确定构架、确认构架并为构架建立基线。
- 根据此阶段获得的新信息改进前景，对推动构架和计划决策的最关键用例建立可靠的了解。
- 为构建阶段创建详细的迭代计划并为其建立基线。
- 改进开发案例，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。
- 改进构架并选择构件。 评估潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。
阶段三：构建
目标
构建阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。构建阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。从这种意义上说，从先启和精化阶段到构建和产品化阶段，管理上的思维定势经历了从知识产权开发到可部署产品开发的转变。
构建阶段的主要目标包括：
- 通过优化资源和避免不必要的报废和返工，使开发成本降到最低。
- 快速达到足够好的质量
- 快速完成有用的版本（Alpha 版、Beta 版和其他测试发布版）
- 完成所有所需功能的分析、开发和测试。
- 迭代式、递增式地开发随时可以发布到用户群的完整产品。这意味着描述剩余的用例和其他需求，充实设计，完成实施，并测试软件。
- 确定软件、场地和用户是否已经为部署应用程序作好准备。
- 开发团队的工作实现某种程度的并行。 即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现自然的并行（资源允许）。这种并行性可较大幅度地加速开发活动；但同时也增加了资源管理和工作流程同步的复杂程度。如果要实现任何重要的并行，强壮的构架至关重要。
核心活动
- 资源管理，控制和流程优化
- 完成构件开发并根据已定义的评估标准进行测试
- 根据前景的验收标准对产品发布版进行评估。
阶段四：产品化
目标
产品化阶段的重点是确保最终用户可以使用软件。产品化阶段可跨越几个迭代，包括测试处于发布准备中的产品和基于用户反馈进行较小的调整。在生命周期中的该点处，用户反馈应主要侧重于调整产品、配置、安装和可用性问题，所有较大的结构上的问题应该在项目生命周期的早期阶段就已得到解决。
在产品化阶段生命周期结束时，目标应该已经实现，项目应处于将结束的状态。某些情况下，当前生命周期的结束可能是同一产品另一生命周期的开始，从而导致产生产品的下一代或下一版本。对于其他项目，产品化阶段结束时可能就将工件完全交付给第三方，第三方负责已交付系统的操作、维护和扩展。
根据产品的种类，产品化阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。
产品化阶段的迭代期间所进行的活动取决于目标。例如，在进行调试时，实施和测试通常就足够了。 但是，如果要添加新功能，迭代类似于构建阶段中的迭代，需要进行分析设计。
当基线已经足够完善，可以部署到最终用户领域中时，则进入产品化阶段。通常，这要求系统的某个可用部分已经达到了可接受的质量级别并完成用户文档，从而向用户的转移可以为所有方面都带来积极的结果。
产品化阶段的主要目标是：
- 进行 Beta 测试，按用户的期望确认新系统
- Beta 测试和相对于正在替换的遗留系统的并行操作
- 转换操作数据库
- 培训用户和维护人员
- 市场营销、进行分发和向销售人员进行新产品介绍
- 与部署相关的工程，例如接入、商业包装和生产、销售介绍、现场人员培训
- 调整活动，如进行调试、性能或可用性的增强
- 根据产品的完整前景和验收标准，对部署基线进行的评估
- 实现用户的自我支持能力
- 在涉众之间达成共识，即部署基线已完成
- 在涉众之间达成共识，即部署基线与前景的评估标准一致
核心活动
- 执行部署计划
- 对最终用户支持材料定稿
- 在开发现场测试可交付产品
- 制作产品发布版
- 获得用户反馈
- 基于反馈调整产品
- 使最终用户可以使用产品
|
