瀑布模型的价值观和实践：
● 首先，确定大部分的需求，假设用户在看到其产品之前，就可以妥善的定义需求；
● 第二，进行详细的设计，假设对于一个定义糟糕的问题，可以为其找到一个精确定义的解决方案；
● 第三，在设计未经证实或者无法证实之前实现；
● 第四，集成、测试和部署。
瀑布模型的一些活动：
● 量完全地实现一些阶段产品，例如需求或者设计，然后再向前进行。尽量使这些阶段产品完备和稳定，并精益求精。
●随后发现，先前我们竭力确定下来的需求、模块或者设计必须要进行重要的变化，这是失败的迹象。为了使需求或者设计接近于我们先前已经确定下来的结果，尽力弥补。
● 认为基于新的技术为新的系统交付可信的评估和计划是正确的，特别是在项目的早期。不能做到这一点就意味着缺乏技能 导致RUP失败最常见的策略就是在一定程度上认为RUP阶段和瀑布模型的阶段相似。
关于RUP阶段的一个简洁和准确的描述：
1.初始－开发系统的业务用例；
要求探索少量但是重要的需求（大约10%），以便获得范围、关键风险的尺度，并且决定是否进入细化阶段。
2.细化－迭代地构建核心体系结构和解决技术风险。
构建体系结构意味着真正的编程、集成及测试-这不是纸上谈兵或者丢弃原型。细化阶段，我们需要迭代地详细地探索大部分需求（大约80%），同时实现系统的核心风险部分。在整个细化阶段需求都可能是变化的，通过不断的"反馈－适应"循环，评估已实现的部分。可以看到，这与传统的瀑布风格的需求定义不同，其大部分需求是在开发核心体系结构的同时细化得到的，并且其从实际的开发中得到反馈。我们也能够以此为据来决定是否继续此项目。
3.构造－迭代地构建细化阶段没有做的元素；迭代地集成和进行质量保证；准备部署。由于大部分需求的不稳定性已经在细化阶段澄清，所以在构造阶段需求的变化较少。
4. 发布－完成β测试，确定版本，部署系统。
RUP规则推荐"迭代周期的长度是2－6周"。 迭代开发和RUP的本质是采取小步骤，对于可能不完美的实现，迅速集成，质量保证，测试，及时获得反馈，然后根据反馈，调整需求、设计和实现。小步骤、反馈和调整是核心概念。迭代周期过长与此背道而驰，必将导致RUP应用的失败。
在缺乏反馈的情况下定义和确定需求的想法是与软件开发事实背道而驰的。在项目开始的时候不要指望可信的估计和详细的计划！
在缺乏工作量真实信息的情况下设立确切的计划日期是容易的-这是作计划遇到的典型问题：计划一经发布就没有用了。
迭代方法允许我们边学边走；随着迭代的进行，我们得到越来越多的真实的需求，更加客观的风险，以及完成该项目的更加准确的能力估计。简言之，经验使我们成为更好的计划者。
有时固定成本成为瀑布方法的辩护者，似乎这可以证明在缺乏真实信息的情况下做出计划是正确的。事实上，如果你从未做过此类项目，就被要求给出一个固定成本，你只能胡蒙乱撞。如果想成功，最好尽可能地多做预算，尽可能多地雇用此领域中有经验的人员，并期待最好的结果。在缺乏信息的情况下做出大部分的决定总是有风险的。在迭代方法中，最初的估计你不会做得比上面更好，但是不久你就会十分清楚你做得有多么好，你可以开始协商，预料，更早的管理范围，那时，最初的估计会有所帮助。
RUP所提倡的解决固定成本及合同的合理方法是两步走策略。第一步，约定初始的迭代周期（例如四周）的固定成本，进行充分的调查和试验性的编码，以得到更具观察性的范围、风险和需求说明。这一改进的说明随后作为第二步中估价的基（完成开发）。
方法学家认为过程有重型和轻型，预见性和适应性之分。重型过程是被人蔑视的，它具有如下特征：
● 刻板而控制严格
● 很多活动和工件官僚主义气息浓重
● 文档繁多
● 长期而详细的计划
● 过程高于本质核心的工作
● 面向过程而不是面向人；把人看成机械方法中的插件
● 预见而不是适应
预见性过程是指在一段相对较长的时间内试图详细地计划和预见活动以及资源的分配，例如大多数项目都是这样。其价值观倾向于瀑布模型，强调首先定义需求，然后详细的设计，最后实现。
如果想在应用RUP时失败，不妨采取重型的、预见性的过程的实践：
● 详细地制定项目的整个迭代计划。在早期就定义所有迭代期限，并指定每次迭代结束时会发生什么。
● 创建大部分，或者是尽可能多的创建RUP的工件
● 添加大量项目和过程的形式，甚至几个项目委员会。
● 在项目中坚持机械和钟摆式的运作，将人看作项目系统中专用的齿轮。
RUP的作者并不认为RUP是重型的或者预见性的，这种认为RUP是重型的或者预见性的错误观点是由于加入了不正确的过程思想或者对RUP的误解，RUP本身提供的大量详细的过程文档也加剧了这种认识，以至于RUP被错误的刻画或者蹩脚的实现。
用轻量、敏捷和适应性的过程精神来应用RUP。如何这样做的一些指导如下：
● 创建尽可能少的RUP活动和工件；仅仅是那些真正有价值的。随着项目的进行，如果任何过程活动没有真正价值，剔除它。
● 不存在所有迭代的详细计划。有一个高层的计划（称为阶段计划）估计项目的结束时间和主要的里程碑，但是对于这些里程碑，它没有详细到确切的方法。详细计划（称为迭代计划）仅仅预先制定了一个迭代周期的详细计划。详细计划的制定是适应性的，从一个迭代周期到另一个迭代周期。这并不暗示不能为将来的迭代周期推测地分配一些工作，但这样做是侥幸的，它增加了项目在将来的不可靠性。调整最初的计划并不是制定计划或者执行的失败，而是对于项目现实情况的合理调整。高层的里程碑日期和目标是已知的，但是实现各个里程碑的方法是适应性的发展的。
轻型或者敏捷过程意味着"倾斜和平均"，其特征如下：
● 抛弃不必要的过度的官僚主义过程，消除低价值的及无思想的文档；
● 集中在人本身，令软件开发充满乐趣；并且
● 是适应性的。
RUP的核心思想和关键实践是：
● 需求管理
● 迭代开发
● 变更控制
● 质量审查
● 以体系结构和组件为中心的设计
● ……
相比较而言，迭代开发对于我们如何思考和实践软件开发的影响是最深的。我们应当如下看待上述列表：
● 需求管理
● 迭代开发
● 变更控制
● 质量审查
● 以体系结构和组件为中心的设计
● ……
总的来说，RUP就是一个以迭代的方法培养一个先启－精化－构建－测试－产品化的软件开发过程。
1， 其理论上认为可以弥补流瀑式开发方法带来的风险过大，人力资源利用率不高等不足。
个人认为迭代方式符合人对客观世界的认识：多次反复地实践。目前尚未仔细研究不同迭代阶段之间的承启关系，但最担心的是如何在涉众（如客户、老板们）要求较短的时间内完成合格的迭代
2， 学习及实现关键：如何深刻理解并实施工作流程。
当开发工作到中后期时，最容易暴露分析设计阶段考虑不足的问题，这时候感觉为什么文档不全，不细。所以我刚接触RUP时，第一感觉就是RUP能否提供较全面的文档。粗略地看了一下‘工作流程’后，认识到文档只是工作流程的一个产物，开发工作是一个process，孤立的文档是没有意义的，为文档而分析设计看似目的明确，其实忽视了最重要的过程控制。当然，完整的文档是成功的分析设计最明显的体现。
3， 学习的方法：迭代
灵活的链接对迭代学习很有帮助，不过这些链接也像一张网，很容易就晕了。总之一句好，实践出真知！
4， 目的：
想办法裁减标准RUP，得出适合自己的过程管理。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
