RUP随想
[摘要] 本文主要阐述一下我对RUP软件工程思想的看法以及一些感想。我认为软件工程既然是工程，那么纯粹的空谈理论是没有意义的，软件工程需要实干。我认为软件工程的思想实际上和兵法理论是一样的，兵法只是提供一个指导作用，打仗毕竟还是要真枪实弹的打赢了才是硬道理。那么对软件工程来说，毕竟软件做好了，用户满意能才是硬道理。本文没有涉及 RUP的方方面面，只谈及我感悟最深的一些东西。实际上RUP只是提供了一些做软件指导方针，真正要做好软件毕竟还是要发挥人的作用。
一，主要内容
- RUP简介
- RUP的灵魂
- RUP通常的误解
- 四个阶段
- 六个最佳实践
- 九个核心工作流
- RUP可以借鉴那些实践或思想？
二，RUP(Rational Unified Process)简介?
简单来说，就是Rational 统一软件开发过程,软件开发流程框架或定义平台。RUP是可配制的、风险驱动、架构为中心的、基于用例驱动的软件开发过程。是无数软件工程实践经验的总结。
我们应该如何看待RUP? 我想用兵法来说个道理。孙子兵法，为什么敌我双方都读兵法，却有胜有败？在《康熙大帝》这本书中著名兵法家周培公这么说“知变者胜，守常者败”，岳飞说“运用之妙，存乎一心”。所以道理就是，兵法其实只是提供指导思想，关键还是要因地制宜的灵活运用，例如成吉思汗就没有学过汉人的孙子兵法，但是打仗却战无不胜，这是因为他在实践中掌握了打仗的要领，并加以灵活运用。所以关键是兵法的思想，而不是形式。思想是灵魂、流程是外在表现。同样对于RUP我们应该注意和加以运用的也是他的核心思想和灵魂而不是形式。例如对待 RUP很多文档的态度，我想其实更应该注意的是文档的目的是交流，如果这个目的达到了，那么其它任何形式都是一样的。所以我的观点就是：对于RUP，最重要是RUP灵魂和核心思想。采用RUP的团队也有很多失败的例子，RUP也没有魔术。但是RUP是无数项目的经验结晶，使用得当对项目成功很有益。盲目遵循过程是不可取的。其实当我们了解了RUP之后，就会知道其实RUP制定的很灵活，很多时候是需要我们灵活处理和运用的。
我们是否要完成RUP的所有的文档？答案是只有觉得该文档能起到重大交流作用的时候，才决定去写。否则就是浪费时间。
我们要完成RUP所规定的所有的活动？答案就是除非该活动对产出可工作的的软件有很大的帮助，否则不执行。
RUP是王者，我们不需要其它东西了？我觉得RUP可以借鉴很多敏捷开发诸如XP或Scrum的东西，诸如小规模重构，测试开发，代码审查等等
为什么说它是可配置？风险驱动？架构为中心？
为什么说RUP是可配置可剪裁的？根据实际做出一定的取舍，合理输出最有价值的文档，执行最有价值的核心工作流。
为什么说RUP是风险驱动的？四个阶段是为了化解不同的风险，持续的化解风险是RUP的灵魂。后面会介绍不同阶段化解什么样的不同风险。
为什么说是架构为中心的？RUP提倡要有稳定架构，架构风险是一个重大风险，在细化阶段要产生稳定的架构，达到项目的架构里程碑。
为什么说RUP是用例驱动的？项目实现的过程就是用例一个个用例实现的过程，目标就是实现用例。
二，RUP的灵魂
RUP的灵魂是什么？或者说他的核心思想是什么？
尽早的持续的化解重大风险；确保满足客户的需求；把注意力放在可执行的软件上；尽早在项目中适应变化；在早期确定一个可执行的架构；使用构件构造系统；建立高效团结的开发团队；始终重视质量。
尽早的持续的化解重大风险：四个阶段是为了化解不同的风险。
确保满足用户需求：进化式需求，跌代开发确保满足用户需求。
把注意力放在可执行的软件上：文档本身不是目的，最终目的是交流已从产生更好的 可执行的软件。
尽早在项目中适应变化：早期只分析和实现最核心的用例，细化阶段跌代产生稳定的架构已适应变化。
始终重视质量：每个阶段都有测试，尽早的，持续的测试。
三，四个阶段
1，四个阶段介绍
· 初始阶段：大体的构想、范围和模糊评估、用例，只详细编写最重要的部分用例。
· 细化阶段：核心架构的迭代实现，高风险用例的实现、确定大多数需求、范围以及更为准确的评估。
· 构造阶段：对遗留下来的风险较低的比较简单的元素迭代实现，准备部署。
· 移交阶段：进行beta测试和部署。
2，四个阶段－和瀑布模型的区别
· 瀑布模型是线性的管道式开发，按照需求分析、设计，编码、测试等开发活动划分的阶段。这种顺序开发模式难以抵挡需求变化的影响，难以满足客户的需求。
· 而RUP的四个阶段是为了化解不同风险。需求风险、架构风险、发布风险是软件开发中重大风险。四个阶段是为了化解这些不同的风险。迭代是最重要的区别。每个阶段都迭代进行。迭代贯穿于四个阶段。
RUP的四个阶段和瀑布模型的四个阶段区别在哪里？初始：需求阶段？细化：设计阶段？构建：编码阶段？移交：测试改错阶段？下面会详细阐述。
初始阶段－体现了风险驱动，满足用户需求
· 并不试图获取全部需求、以及详细的计划，而只是详细识别出最重要的用例并加以详细描述。制定一个项目计划和第一次迭代计划。也会考虑初步的可行性方案。达到生命周期的目标里程碑。化解可行性风险。进化式需求，体现了持续化解需求变更带来的风险，确保满足用户的需求。
· 初始阶段不是需求阶段，在这个阶段并不获取所有的需求，也并不就冻结需求文档，只分析最核心的用例。达到项目的目标里程碑。
细化阶段－体现了风险驱动,架构为中心
· 并不只是做设计，会实现最重要的部分用例，形成可执行的架构，并可以测试，活动包括了分析、设计、编码、测试。迭代实现最重要的用例。迭代的开发，进化式需求，化解需求变更对架构的影响的风险，体现了持续化解风险的思想，并确保满足用户的需求。产生一个可执行的架构，体现了把注意力放在可执行的软件上的思想，体现了在早期确定一个可执行的架构的思想，可测试架构、测试体现了持续验证软件质量的思想。达到软件架构里程碑。迭代实现核心架构及高风险的用例。
· 细化阶段不是设计阶段，它包含了众多的活动，主要是为了化解架构风险。要达到项目的架构里程碑。
构建、移交阶段－体现了风险驱动
构建阶段
o 除了编码也会有建模、分析、设计，也会有测试。迭代构建。保证满足用户需求。测试持续验证软件质量。达到完全可执行能力里程碑。
o 构建阶段不是编码阶段，除了编码还有设计分析、测试。
发布阶段
o 有用户测试。化解发布风险。
o 发布阶段不是系统测试阶段，是为了化解发布风险。
3，四个阶段总结
四个阶段体现了 RUP是可配置的，风险驱动的，架构为中心的、用例驱动的。体现了RUP的灵魂：满足用户需求、持续的化解风险、持续的验证软件质量。
四个阶段体现了可配置：文档工作流都是可剪裁可配置的。
四个阶段体现了风险驱动，无疑RUP 把需求变更和变更给架构产生的影响作为项目最重达的风险，四个阶段通过迭代不断的持续的化解风险，只有化解了特定的重大的风险，才算是达到一定的里程碑，才可以继续下去，所以说是风险驱动的。
四个阶段体现了架构为中心，必须有个稳定的架构，细化阶段就是为了得到一个可执行的，稳定的，可测试的架构。
四个阶段体现了用例驱动，四个阶段都在实现不同的用例，随着用例的实现，可执行的软件产生。
四个阶段体现了满足用户需求，RUP通过迭代开发，进化式需求分析来满足用户的需求。初始阶段只分析一部分最重要的用例，并在细化阶段实现架构及用例，可执行的软件可以给用户演示测试，可以快速的得到用户的反馈，以达到满足用户需求之目的。很多其实是在使用瀑布化的RUP，忽视了迭代开发，管道式作业方式。
四个阶段体现了持续的验证软件质量，尽早的、持续的测试，每个阶段都有测试。
四，六个最佳实践
· 迭代的开发软件：在迭代中执行你的项目，化解需求变化风险
· 需求管理：用例，从用户的角度描述需求，进化式需求
· 使用基于构件的体系结构：利用组件与服务进行构架
· 可视化软件建模：对主要观点建模
· 验证软件质量：测试你的代码，单元测试，持续集成测试
· 控制软件变更：拥抱并管理变更
迭代是最核心关键的实践
· 结合早期时间定量的迭代开发，进行迭代和进化式需求分析，且引入频繁的涉众参与、评估和对局部结果的反馈。
· 迭代并不是匆忙上阵编码，只是分析一点、设计一点、实现一点、测试一点、得到一点反馈。
· 每次迭代以前一次的迭代为基础产生一个可执行的更接近最终系统的产品。
· 迭代的返工是在精心控制之下的。
· 定周期迭代。
五，九个核心工作流
1． 商业建模(Business Modeling)
商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2． 需求(Requirements)
需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。最重要的是理解系统所解决问题的定义和范围。用用例捕获需求。
3． 分析和设计(Analysis & Design)
分析和设计工作流将需求转化成未来系统的设计。分析设计的结果是一个设计模型和一个可选的分析模型。
4． 实现(Implementation)
实现工作流的目的编码实现、集成、单元测试，使其成为可执行的系统。
5． 测试(Test)
测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。
6． 部署(Deployment)
部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
7． 配置和变更管理(Configuration & Change Management)
配置和变更管理工作流描绘了如何制品的版本控制管理，同时也阐述了对制品修改原因、时间、人员保持审计记录。
8． 项目管理(Project Management)
软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9． 环境(Environment)
环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
核心工作流是可选可配置的
六，RUP需要借鉴什么
- 完整团队的思想：开发、测试、业务人员、客户一起紧密地工作
- 客户作为团队成员
- 构建过程中借鉴一些最佳实践：TDD，重构，持续集成、Code Review、简单设计、小版本发布
- 面对面交流的作用，适当弱化文档的地位，选择性的输出最有价值的文档
- RUP过于专注于过程，软件开发毕竟是人的活动，要考虑人的能动性，人和过程结合才能产生好的效果。以人为本的思想。
七，问题
- RUP和瀑布模型的本质区别在哪里？
- RUP在初始阶段完成所有的需求分析？在细化阶段完成所有的设计及设计文档？在构建阶段就是编码？
- RUP如何持续的保证质量？RUP到后期才可以测试？编码构建完成才可以测试？
- RUP初始阶段就制定一个详细的准确的计划？
- 设计需要花很长时间么？在细化阶段要花一个多月来设计才能保证质量？
- 初始阶段要花很长时间来调研需求？
- 一次迭代时间越长越好？
- 采用RUP必须遵循大量的步骤和正规繁琐的过程？
- 迭代开发意味着匆忙编码，不需要设计？
- 在编写代码前要彻底的和细致的设计？画出所有的UML图？所有方法的序列图？
- 细化阶段只有一次迭代就够了？
- 构造阶段只是机械的编码？
- 迭代是敏捷方法才有的，RUP不需要迭代？
- 每次迭代都需要完整的执行所有的工作流？
- 每次迭代都要输出每个工作流要求的所有制品？
- RUP可以和敏捷方法Scrum,XP结合？如何和Scrum, XP等有效结合？
- RUP中人员不同角色如何协作？
- 如何做计划？如何将一个use case的实现分配到人？他们如何协作？
- 在我们公司这种情况下，如何有效的应用RUP?