【UML视频总结】——RUP

1. 软件面临的危机

a. 宏观

i. 软件开发周期大大超过规定日期
ii. 软件开发成本严重超标
iii. 软件质量难以保证

b. 微观

i. 不能满足用户或商业的要求
ii. 不能很好的定位需求
iii. 模块难于集成
iv. 到最后才发现错误
v. 对于终端用户来说质量较差
vi. 负载时性能差
vii. 没有协调团队的努力
viii. 不断地修改-发布问题

2. RUP介绍

a. Rational  统一过程（RUP）

b. RUP所处理的问题

i. 有缺陷的、无法预见结果的、高度依赖于个别“英雄”程序员的、不可重复的开发过程
ii. 开发的软件难以适应用户的要求
iii. 在应对需求的变更方面无能为力
iv. 需要单调乏味和昂贵的测试流程
v. 项目中出现的严重缺陷发现得太迟
vi. 开发的软件难以维护和扩充

c. RUP使得开发团队成员将共享

i. 同一个知识库
ii. 同一个开发过程
iii. 同一个开发视图
iv. 同一种建模语言

3. RUP的思路：implementing best practices

a. RUP得到最佳实践的集中措施

i. 迭代式开发
1) 瀑布模型的缺陷
a) 延迟关键风险解决
b) 延迟和集中系统的集成和测试
c) 派出了早起部署
d) 经常导致较大的无法计划反复
2) 迭代式开发的优点
a) 降低风险
b) 得到早起用户反馈
c) 持续的测试和集成
d) 适应更高
e) 提高复用性
3) 迭代开发示意图
4) 迭代式开发详述
a) 迭代式一种技术，用来把系统功能传递到一系列连续的增量的完整版本
b) 每个版本都在一个特定固定的时间段被开发，该时间段称之为迭代
c) 迭代的成果是一个可执行产品的一个版本，是最终系统产生的一个子集
d) 通过多次迭代连续增加和精化系统，在每个迭代过程中逐步增加信息、进行细化。
e) 每次迭代都选择目前对风险影响最大的使用实例进行，以分解和降低风险
5) 特征
a) 在进行大规模的投资之前就解决了关键的风险问题
b) 使得早期的用户反馈在初始迭代中就能出现
c) 连续进行测试和集成
d) 各个目标里程碑提供了短期的焦点（阶段性的中心）
e) 对过程的测量是通过对实现的评定（而不仅仅是文档）来进行的。
f) 可以对局部的实现进行部署
6) 风险分析
ii. 需求管理
1) 需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。
2) 确保能够：解决正确的问题，建立正确的系统
3) 包括
a) 提取、组织系统的功能和约束，并将它们写成文档
b) 估计需求的变化并评估它们会产生的影响
c) 跟踪需求的实现。
iii. 使用构件架构
1) 优势
a) 对体系结构进行自下而上的设计、实现和测试
b) 用一种系统化的做法来定义好的体系结构
c) 采用定义明确的接口来使得变更有弹性
d) 采用现成的和通过逆向工程得到的构件
e) 由高级别的用例来驱动
f) 易于直观上的理解
iv. 可视化建模
1) 描述体系结构特点和结构
2) 描述系统里的各个元素如何组合在一起
3) 保证设计和实现上的一致性
4) 保证没有歧义的沟通
v. 检验质量
1) 可用性
用户界面是否友好
2) 可靠性
3) 性能
4) 可扩充性
5) 功能
6) RUP的思路
a) 为每个关键模块创建测试用例并去测试，从而保证所有的需求被正确的实现
b) 不可接受的应用性能和不能接受的可靠性对一个软件系统的影响同等重要
c) 验证软件可靠性，例如：内存泄露、性能瓶颈。
d) 对每一次迭代进行测试
vi. 控制变更
1) 管理哪些变更
a) 控制、追踪和监控项目的所有变更，从而启动每次迭代
b) 为每个开发者建立安全的工作空间
c) 对不同工作空间的改动提供隔离机制
d) 控制所有的软件制品：模型、代码、文档等。

4. RUP的基本特征

a. 迭代式增量开发

i. 将软件开发分为一些列小的迭代过程，在每个迭代过程中逐步增加信息、进行细化
ii. 根据具体情况决定迭代的次数、每个迭代延续的时间以及迭代工作流
iii. 每次迭代都选择目前对风险影响最大的用例进行，以分解和降低风险。

b. 用例驱动

i. 采用用例来捕获对目标系统的功能需求
ii. 采用用例来驱动软件的整个开发过程，保证需求的可跟踪性，确保系统所有功能均被发现
iii. 将用户关心的软件系统的业务功能模型和开发人员关心的目标软件系统的功能实体模型结合起来，提供一种贯穿这个软件生存周期的开发方式，使得软件开发的各个生存阶段的工作自然、一致地协调起来。

c. 以软件体系结构为中心

i. 强调开发过程的早期，识别出与软件体系结构紧密相关的用例，并通过对这些用例的分析、设计、实现和测试，形成体系结构框架
ii. 在后续阶段中心对已形成的体系结构框架进行不断细化，最终实现整个系统
iii. 在开发过程的早起形成良好的软件体系结构，有利于对系统的理解、支持重用和有效的组织软件开发。

5. RUP软件开发生命周期

a. 时间

i. 周期：一个RUP可以分为若干个周期
1) 阶段：起始、演化、构造、提交
a) 迭代：每个阶段进行若干次

b. 核心工作流

i. 工作流：对应于特定的迭代的连续活动
1) 活动：需求定义、分析、设计、实现和测试
a) 中间制品：活动的结果

c. RUP将一个周期的开发过程分为四个阶段

i. 起始阶段-为项目建立一个业务案例
1) 意图：
a) 建立业务模型用例
b) 明确项目的范围
2) 结果：
a) 项目的实际需求
i) 初始用例模型和领域模型（10-20%完成）
b) 初始的业务案例，包括
i) 成功准则
ii) 风险评估
iii) 所需资源评估
iv) 显示主要里程碑进度表的阶段计划
3) 在初始阶段的最后，检查项目的生命周期目标，决定是否继续进行全范围的开发
ii. 细化阶段-建立工程计划和合理的体系结构
1) 意图
a) 分析问题域
b) 建立一个健全的、合理的体系结构
c) 明确高项目中风险的元素
d) 制定一个合理的项目开发计划
2) 结果
a) 用例图和领域图（80%完成）
b) 一个可执行的体系结构和文档
c) 一个修订的用例图和风险评估
d) 一个针对整个项目的开发计划
3) 在这个阶段的最后，检查已经细化的系统目标和范围，体系结构的选择以及主要风险的解决办法，并决定是否需要进行构造。
iii. 构建阶段-建造系统
1) 意图
a) 迭代增量的开发一个完整的软件系统，该产品是准备提交给用户使用的。
2) 产品
a) 完整的用例图和设计模式
b) 用户手册
c) 可执行代码
d) 开发文档
e) 每次迭代的评测标准
f) 改进的开发计划
iv. 提交阶段-把系统提供给最终用户
1) 意图
a) 为用户安装部署软件
2) 产品
a) 可执行的程序
b) 改进的系统模型
c) 每次迭代的评测标准
d) 发出程序的描述和评测指标测试 
e) 改进的用户文档
f) 改进的开发文档

d. 迭代与阶段之间的关系

i. 每个阶段可以分解成多个迭代
ii. 一个迭代是一个完整的开发循环，他将产生一个可执行产品的发布版本，这个版本构成最终产品的一个子集，然后迭代得到最终的系统

6. RUP带来的观念变化

a. 更强的计划性：迭代开发意味着要有更强的预见性和计划性，阶段的划分、阶段内的迭代都需要仔细的规划
b. 坦然面对迭代过程中一部分中间制品带来的推倒重来：
c. 把软件放在首位：
d. 尽早进行困难的工作：
e. 坦然的面对中间制品的“不美观”：
f. 加强开发过程监控与量化管理：
g. 确定迭代的数量、持续时间和内容：
h. 即需要好的项目管理者，也需要好的体系结构设计师：