开发流程 - RUP
Summary
RUP的基本组成元素：
通过工作流的方式体现软件工程过程，以各种指导原则方式组织，并明确各个角色及其职责、活动、工件等
整个软件工程过程的步骤划分如下：
关键特征：迭代（Iterative）、以架构为中心（Architecture-Centric）、用例驱动（Use-Case Driven）
横轴表示时间维度，纵轴表示RUP中的9个工作流。工作流在纵轴上的高度，表示某时刻该工作流的工作量比重
Phases
在时间维度上，RUP将项目分成4个阶段（Phases）：初始阶段Inception、细化阶段Elaboration、构造阶段Construction、交付阶段Transition。阶段只是一种较粗的划分方式，强调该时间段内的工作重心、主要目标。比如说交付阶段，并不仅仅是将项目交付给用户使用，同时也包括了需求、设计、实现、测试等活动，只是说这个阶段从项目整体来看，他的重点在于给客户交付，比如参考下面的增量交付模式
每个阶段包含一个或者多个迭代过程，每个迭代都是一个完整的开发流程，至少包括需求、分析设计、实现、测试这几个活动，可以看作一个小的瀑布模型过程，每个迭代的产出都是稳定的、可执行的产品（产品子集）
每个工作流都定义了相关的产出，在项目的四个阶段中，各工作流产出的完成情况可以用下图大致描述
项目完成时，所有产出都是完整的
每个阶段结束都是一个主要milestone，需要进行评估检验是否实现了该阶段的目标
对比较典型的中型项目，各阶段的进度、工作量分布大致如下
初始阶段 Inception
对新项目，初始阶段主要与利益相关者就项目目标进行交流，确定业务和需求风险等，对已有系统改进升级的项目，也需要确定项目值得做并且可以做
工作流：
主要目标：
1. 确定项目范围、边界条件，包括运作场景、验收标准，以及哪些可能会做哪些可能不会做
2. 确定关键用例、主要业务场景，用于开展主设计工作
3. 针对主要业务场景，陈述或者是演示至少一种备选架构方案
4. 评估项目的总体成本和进度计划
5. 评估潜在的风险
6. 项目环境准备
细化阶段 Elaboration
确定系统架构，为后续构造阶段的设计和实现工作提供一个稳定的基础
工作流：
主要目标：
1. 确定架构的各种风险
2. 构建基准架构
3. 使用原型降低风险
4. 基于成本、时间等方面评估验证架构的可行性，确保架构、需求和进度计划足够稳定，以及风险被很好的控制，不影响项目成本和进度
5. 下阶段环境准备
构建阶段 Construction
明确项目需求，基于架构进行开发，重点是成本、进度、质量的控制
交付阶段 Transition
包括发布前的测试、根据用户反馈进行调整。用户反馈应该集中于产品的优化、配置、安装、用户使用性等问题
还有安装准备工作、用户培训、上线运行、实现客户自行维护、按照验收标准进行评估、利益相关者确定交付完成等
Iteration
每个迭代确定一个主要的milestone，需要release出可执行的产品。迭代划分的粒度不会太细，一般小项目中一个迭代也在一周以上。因为迭代的主要目的是降低类似瀑布模型方式下的风险，避免在最后时刻所有风险才显现出来，因此一个迭代结束，需要有验证评估等管理手段，迭代周期划分的太细反而会失去这种管理方式的初衷。但迭代周期也不能划分的太长，否则仍然会减弱对风险的控制能力
迭代模式：Incremental Lifecycle（增量模式）
确定用户要求，定义系统需求，然后通过多个构建阶段实现产品，第一个阶段实现一部分功能，以后每个阶段添加一部分功能
典型过程：
1. 一个较短的初始期迭代，建立项目范围和目标，建立业务用例
2. 一个细化期迭代，确定需求，创建架构
3. 多个构造期迭代，实现架构和用例
4. 多个交付期迭代，整合产品，交付给用户
适用场景：a). 对问题域很熟悉；b). 较好的理解项目风险；c). 项目团队经验丰富
迭代模式：Evolutionary Lifecycle（演化模式）
不同于增量模式的地方是用户的要求无法确定，没法在最开始将用户需求完全定义出来，而是通过一个个迭代过程来明确、确定用户需求，构建项目、产品
典型过程：
1. 一个较短的初始期迭代，建立项目范围和目标，建立业务用例
2. 多个细化期迭代，每个阶段用户需求进一步细化、明确
3. 一个构造期迭代，实现架构和用例
4. 多个交付期迭代，整合产品，交付给用户
适用场景：a). 针对新的或不熟悉的问题域；b). 团队经验不足
迭代模式：Incremental Delivery Lifecycle（增量交付模式）
可以说是增量模式的一种，但其迭代的产出需要给客户部署实施起来。一般场景是市场压力比较大，尽早发布关键功能可以给客户带来巨大的商业效益。对客户而言关键在于尽早发布，这种模式要求一开始能创建一个稳定的架构
典型过程：
1. 一个较短的初始期迭代，建立项目范围和目标，建立业务用例
2. 一个细化期迭代，需要基本确定一个稳定的架构
3. 一个构造期迭代，实现架构和用例
4. 多个交付期迭代，整合产品，交付给用户
适用场景：a). 对问题域很熟悉，需求和架构能尽早在项目初期确定，针对项目团队和客户而言没有太多新的需要尝试的东西；b). 团队经验丰富；c). 增量的功能发布能给客户带来很高的价值
迭代模式：Grand Design Lifecycle（总设计模式）
即瀑布模型，他可以看作迭代模式的退化方式，只包含一个迭代周期。实际操作中可能会包含多个交付迭代周期。与增量交互模式等相比，他的构造期时间比较长，例如下图所示，其构造期相比于正常的迭代过程，所占比例比较大，并且是单一一个构造期
迭代模式：Hybrid Strategies（混合模式）
没有几个项目采用单一迭代模式，都是各种形式的混合
RUP的基本组成元素：
通过工作流的方式体现软件工程过程，以各种指导原则方式组织，并明确各个角色及其职责、活动、工件等
整个软件工程过程的步骤划分如下：
关键特征：迭代（Iterative）、以架构为中心（Architecture-Centric）、用例驱动（Use-Case Driven）
横轴表示时间维度，纵轴表示RUP中的9个工作流。工作流在纵轴上的高度，表示某时刻该工作流的工作量比重
Phases
在时间维度上，RUP将项目分成4个阶段（Phases）：初始阶段Inception、细化阶段Elaboration、构造阶段Construction、交付阶段Transition。阶段只是一种较粗的划分方式，强调该时间段内的工作重心、主要目标。比如说交付阶段，并不仅仅是将项目交付给用户使用，同时也包括了需求、设计、实现、测试等活动，只是说这个阶段从项目整体来看，他的重点在于给客户交付，比如参考下面的增量交付模式
每个阶段包含一个或者多个迭代过程，每个迭代都是一个完整的开发流程，至少包括需求、分析设计、实现、测试这几个活动，可以看作一个小的瀑布模型过程，每个迭代的产出都是稳定的、可执行的产品（产品子集）
每个工作流都定义了相关的产出，在项目的四个阶段中，各工作流产出的完成情况可以用下图大致描述
项目完成时，所有产出都是完整的
每个阶段结束都是一个主要milestone，需要进行评估检验是否实现了该阶段的目标
对比较典型的中型项目，各阶段的进度、工作量分布大致如下
初始阶段 Inception
对新项目，初始阶段主要与利益相关者就项目目标进行交流，确定业务和需求风险等，对已有系统改进升级的项目，也需要确定项目值得做并且可以做
工作流：
主要目标：
1. 确定项目范围、边界条件，包括运作场景、验收标准，以及哪些可能会做哪些可能不会做
2. 确定关键用例、主要业务场景，用于开展主设计工作
3. 针对主要业务场景，陈述或者是演示至少一种备选架构方案
4. 评估项目的总体成本和进度计划
5. 评估潜在的风险
6. 项目环境准备
细化阶段 Elaboration
确定系统架构，为后续构造阶段的设计和实现工作提供一个稳定的基础
工作流：
主要目标：
1. 确定架构的各种风险
2. 构建基准架构
3. 使用原型降低风险
4. 基于成本、时间等方面评估验证架构的可行性，确保架构、需求和进度计划足够稳定，以及风险被很好的控制，不影响项目成本和进度
5. 下阶段环境准备
构建阶段 Construction
明确项目需求，基于架构进行开发，重点是成本、进度、质量的控制
交付阶段 Transition
包括发布前的测试、根据用户反馈进行调整。用户反馈应该集中于产品的优化、配置、安装、用户使用性等问题
还有安装准备工作、用户培训、上线运行、实现客户自行维护、按照验收标准进行评估、利益相关者确定交付完成等
Iteration
每个迭代确定一个主要的milestone，需要release出可执行的产品。迭代划分的粒度不会太细，一般小项目中一个迭代也在一周以上。因为迭代的主要目的是降低类似瀑布模型方式下的风险，避免在最后时刻所有风险才显现出来，因此一个迭代结束，需要有验证评估等管理手段，迭代周期划分的太细反而会失去这种管理方式的初衷。但迭代周期也不能划分的太长，否则仍然会减弱对风险的控制能力
迭代模式：Incremental Lifecycle（增量模式）
确定用户要求，定义系统需求，然后通过多个构建阶段实现产品，第一个阶段实现一部分功能，以后每个阶段添加一部分功能
典型过程：
1. 一个较短的初始期迭代，建立项目范围和目标，建立业务用例
2. 一个细化期迭代，确定需求，创建架构
3. 多个构造期迭代，实现架构和用例
4. 多个交付期迭代，整合产品，交付给用户
适用场景：a). 对问题域很熟悉；b). 较好的理解项目风险；c). 项目团队经验丰富
迭代模式：Evolutionary Lifecycle（演化模式）
不同于增量模式的地方是用户的要求无法确定，没法在最开始将用户需求完全定义出来，而是通过一个个迭代过程来明确、确定用户需求，构建项目、产品
典型过程：
1. 一个较短的初始期迭代，建立项目范围和目标，建立业务用例
2. 多个细化期迭代，每个阶段用户需求进一步细化、明确
3. 一个构造期迭代，实现架构和用例
4. 多个交付期迭代，整合产品，交付给用户
适用场景：a). 针对新的或不熟悉的问题域；b). 团队经验不足
迭代模式：Incremental Delivery Lifecycle（增量交付模式）
可以说是增量模式的一种，但其迭代的产出需要给客户部署实施起来。一般场景是市场压力比较大，尽早发布关键功能可以给客户带来巨大的商业效益。对客户而言关键在于尽早发布，这种模式要求一开始能创建一个稳定的架构
典型过程：
1. 一个较短的初始期迭代，建立项目范围和目标，建立业务用例
2. 一个细化期迭代，需要基本确定一个稳定的架构
3. 一个构造期迭代，实现架构和用例
4. 多个交付期迭代，整合产品，交付给用户
适用场景：a). 对问题域很熟悉，需求和架构能尽早在项目初期确定，针对项目团队和客户而言没有太多新的需要尝试的东西；b). 团队经验丰富；c). 增量的功能发布能给客户带来很高的价值
迭代模式：Grand Design Lifecycle（总设计模式）
即瀑布模型，他可以看作迭代模式的退化方式，只包含一个迭代周期。实际操作中可能会包含多个交付迭代周期。与增量交互模式等相比，他的构造期时间比较长，例如下图所示，其构造期相比于正常的迭代过程，所占比例比较大，并且是单一一个构造期
迭代模式：Hybrid Strategies（混合模式）
没有几个项目采用单一迭代模式，都是各种形式的混合
