(第七章)统一软件开发过程（RUP）
Rational就是公司名，不用翻译，直接保留。
- RUP = Rational Unified Process
- 中文标准叫法：统一软件开发过程
考试只写中文：统一软件开发过程就行，不用带 Rational。
简单记：
Rational = 瑞理（公司名，不译）
Unified = 统一
Process = 过程
在 RUP 里，9 个核心工作流是贯穿项目始终的，不仅仅是初始阶段，从细化到构造，再到移交阶段的每一次迭代，都会完整执行这 9 个工作流。
为什么这么执行？（考试逻辑）RUP 的核心是 “迭代开发”。每一个迭代（Iteration），无论处于哪个阶段，都是一个完整的生产循环。你不能只写代码不测试，也不能只建模不实施。
9个核心工作流
RUP的9个核心工作流分为6个核心过程工作流和3个核心支持工作流，在迭代中反复执行：
业务建模：理解用户业务需求，建立业务用例模型。
需求：提取、分析并规约系统需求，定义用例模型。
分析与设计：构建系统架构与设计模型（类图、交互图等）。
实现：编码、单元测试，构建可执行组件。
测试：验证系统功能与质量，发现缺陷。
部署：打包、发布系统到用户环境。
配置与变更管理：控制版本与变更请求，维护一致性。
项目管理：规划、监控迭代过程与风险。
环境：搭建开发、测试与部署所需的工具和流程环境。
它们以迭代方式执行，每次迭代都覆盖所有工作流，只是侧重点不同，确保系统增量式演进。
4个阶段
RUP 的 4 个阶段，是项目从启动到交付的完整迭代过程，也是软考高频考点，我帮你整理成了“名称+核心目标+关键产出”的记忆版：
1. 初始阶段（Inception）
- 核心目标：明确项目的业务价值、范围边界和可行性。
- 关键产出：项目愿景文档、初步业务案例、风险评估、迭代计划大纲。
2. 细化阶段（Elaboration）
- 核心目标：完成系统架构设计，解决高风险问题，确定大部分需求。
- 关键产出：完整的用例模型、架构原型、详细的项目计划和风险应对方案。
3. 构造阶段（Construction）
- 核心目标：迭代实现系统功能，完成编码与测试，构建可交付的系统版本。
- 关键产出：可运行的软件增量、测试报告、用户文档草稿。
4. 移交阶段（Transition）
- 核心目标：将系统部署到用户环境，完成验收、培训和上线支持。
- 关键产出：最终交付的软件产品、用户手册、运维文档、项目总结报告。
💡 记忆小技巧：
- 初始定方向，细化搭架构，构造写代码，移交给用户。
- 每个阶段都包含一次或多次迭代，且都有明确的里程碑评审。
在 RUP（统一软件开发过程）中，4个阶段是宏观的时间线与里程碑，9个核心工作流是贯穿始终的活动集合，二者的关系可以这样理解：
总体关系（核心逻辑）
RUP 是一个迭代式的过程：
- 4个阶段（Inception → Elaboration → Construction → Transition）：是项目从启动到交付的4个“大里程碑”，定义了项目的生命周期和演进方向。
- 9个核心工作流（6个过程 + 3个支持）：是在每个阶段的每次迭代中，都需要执行的活动集合。
也就是说，每个阶段都会经历多次迭代，而每一次迭代，都需要覆盖所有9个工作流，只是它们的侧重点和投入强度不同。
分阶段解析（重点变化）
| 阶段 | 名称 | 核心目标 | 重点工作流 |
|---|---|---|---|
| 1 | 初始（Inception） | 明确项目可行性、愿景和业务价值 | 业务建模、需求 |
| 2 | 细化（Elaboration） | 搭建稳定的架构，解决高风险问题 | 分析与设计、需求 |
| 3 | 构造（Construction） | 实现系统功能，完成编码和测试 | 实现、测试、部署 |
| 4 | 移交（Transition） | 交付系统并部署到用户环境 | 部署、测试、配置管理 |
同时，配置与变更管理、项目管理、环境这3个支持工作流，是贯穿所有阶段的“后台保障”，在整个项目中持续进行。
- 4个阶段是“骨架”：规定了项目从开始到结束的节奏和方向。
- 9个工作流是“血肉”：是每个迭代中都在执行的具体活动。
- 它们的关系就是：在4个阶段的每次迭代中，循环执行9个工作流，只是随着项目推进，各工作流的重点不断变化。
RUP vs 敏捷（Scrum为代表） 核心对比表（软考考点版）
| 对比维度 | RUP（统一软件开发过程） | 敏捷（Agile/Scrum） |
|---|---|---|
| 核心定位 | 重量级、规范化、架构驱动的过程框架 | 轻量级、迭代式、用户价值驱动的开发理念 |
| 核心原则 | 用例驱动、以架构为中心、迭代式增量开发 | 个体和互动高于流程工具、可工作软件高于详尽文档、客户协作高于合同谈判、响应变化高于遵循计划 |
| 开发节奏 | 4大阶段（初始→细化→构造→移交），长周期迭代（数周/数月） | 短周期冲刺（Sprint，通常2-4周），持续快速交付 |
| 需求管理 | 前期尽可能锁定需求，变更需严格走变更控制流程 | 拥抱变化，需求可在迭代中动态调整，用户持续参与 |
| 文档要求 | 重文档，强调完整、规范、可追溯的交付物 | 轻文档，只保留必要文档，优先交付可运行软件 |
| 架构设计 | 架构先行，细化阶段完成核心架构设计，风险前置 | 架构随迭代演进，边开发边优化，不追求前期完美 |
| 适用场景 | 大型、复杂、高风险、强合规项目（金融、政务、航天、医疗） | 中小团队、需求变化快、互联网/ToC产品、创业项目 |
| 团队角色 | 角色分工明确（架构师、分析师、项目经理等），层级清晰 | 自组织、跨职能团队，角色扁平，强调协作 |
| 计划方式 | 前期做详细整体计划，阶段里程碑严格管控 | 只做短期冲刺计划，拥抱变化，滚动式规划 |
| 核心产出 | 完整的系统模型、架构文档、可交付软件、运维手册 | 可工作的软件增量、用户反馈、持续优化的产品 |
补充记忆要点（考试直接背）
1. 核心差异一句话
RUP 是“先搭骨架再填肉，稳字当头”，敏捷是“边做边调边优化，快字当头”。
2. 高频考点区分
- 题目出现大型项目、架构先行、重文档、强合规、风险控制→ 选RUP
- 题目出现快速迭代、拥抱变化、轻文档、用户参与、自组织团队→ 选敏捷
3. 补充：两者不是完全对立
现在很多企业会用混合模式：用 RUP 的架构设计、风险管理、阶段管控做顶层框架，用敏捷的短迭代、用户协作做落地开发，兼顾稳定性和灵活性。