神马文学网RUP和IPD流程的优缺点
来源：百度文库 编辑：神马文学网 时间：2024/04/16 16:55:32
RUP的过程改进，倡导针对不同类型项目进行适当的裁剪，实际上这也是一种灵活适应的方式、随需而变的思想。我对此是理解并赞同的，但是我对RUP却一直保持一种相对谨慎的态度。
对于RUP来说，首先，我认为它过于理想化和理论化，RUP 是过程组件、方法以及技术的框架，你可以将其应用于任何特定的软件项目，由用户自己限定 RUP 的使用范围。对于各种类型的软件项目，RUP并未给出具体的自身裁减及实施策略，总有些无依据可循的感觉。你既可以说它能解决任何问题，也可以说它什么都不是；其次，RUP从本质来说还是一个强调设计和规范的软件方法，从这个角度来讲，与传统的瀑布模型没有太大差别，它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预测的软件项目开发中，面临着各种紧急需求、面临着时间压力，沿用RUP是很难应付自如的。但是在另一方面，RUP强调对知识的收集、整理和加工定义，强调在软件开发的时候要有好的体系结构。所以它还是很有利于知识的积累和共享的。
相比RUP ，敏捷方法如XP则更为灵活，倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟通取代详尽的文档，强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法，这里有很多的东西是未知的，知识只存在于两个地方：开发者的头脑和最后的代码。对于项目管理者来说，他们会认为敏捷开发方法弱化了知识管理的概念，而实际上敏捷开发注重的是最有价值的知识的积累和沉淀。
如何灵活应对各种项目风险、如何最大化优先满足用户价值、又如何能够有效的控制项目开发过程、如果做好项目过程中的知识管理，是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调RUP裁剪，实际上我认为RUP不仅仅是需要自身的裁剪，还需要学会融合。在RUP裁剪的同时，适宜的融合敏捷开发的各种实践。不要认为RUP与XP是矛盾的，其实不然，它们具有不同的原理、具有不同的应用领域。在 RUP 中融合了 XP 技术时，才会得到过程的正确量，既满足了项目所有成员的需要，又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队，其中用户是团队的一部分，那么 XP 完全可以胜任。对于团队越来越分散，代码量越来越大，或者构架没有很好定义的情况，您需要做一些其他工作。在用户交互具有"契约"风格的项目中，仅有 XP 是不够的。RUP 是一个框架，可以从 RUP 出发，在必要时以一组更健壮的技术来扩展 XP。
RUP最佳实践包括：
1． 迭代开发: RUP的开发过程建立在一系列迭代之上，每次迭代都有一个固定的时间限制（例如四个星期），称为"时间盒"，每次迭代结束的时候都发布一个稳定的小版本，该版本是最终系统的子集。"时间盒"是迭代开发中的关键概念：它意味着迭代周期的期限是固定的，如果目标没有完成，则放弃本次迭代的需求，而不是延长迭代的时间。
2． 管理需求
3． 使用基于组件的构架
4． 可视建模
5． 持续的质量验证
6． 控制变更
关于RUP阶段的一个简洁和准确的描述：
1.初始－开发系统的业务用例；要求探索少量但是重要的需求（大约10%），以便获得范围、关键风险的尺度，并且决定是否进入细化阶段。
2.细化－迭代地构建核心体系结构和解决技术风险。构建体系结构意味着真正的编程、集成及测试-这不是纸上谈兵或者丢弃原型。细化阶段，我们需要迭代地详细地探索大部分需求（大约80%），同时实现系统的核心风险部分。在整个细化阶段需求都可能是变化的，通过不断的"反馈－适应"循环，评估已实现的部分。
可以看到，这与传统的瀑布风格的需求定义不同，其大部分需求是在开发核心体系结构的同时细化得到的，并且其从实际的开发中得到反馈。我们也能够以此为据来决定是否继续此项目。
3.构造－迭代地构建细化阶段没有做的元素；迭代地集成和进行质量保证；准备部署。由于大部分需求的不稳定性已经在细化阶段澄清，所以在构造阶段需求的变化较少。
4. 发布－完成&beta测试，确定版本，部署系统。RUP规则推荐"迭代周期的长度是2－6周"。 迭代开发和RUP的本质是采取小步骤，对于可能不完美的实现，迅速集成，质量保证，测试，及时获得反馈，然后根据反馈，调整需求、设计和实现。小步骤、反馈和调整是核心概念。
迭代方法允许我们边学边走；随着迭代的进行，我们得到越来越多的真实的需求，更加客观的风险，以及完成该项目的更加准确的能力估计。简言之，经验使我们成为更好的计划者。
12 个 XP 实践包括：
有计划的开发：通过结合使用优先级"故事"和技术估算，确定下一版本的功能
小版本：以小的增量版本经常向客户发布软件
隐喻：隐喻是一个简单、共享的"故事"或描述，说明系统如何工作
简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除
测试驱动开发：用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容
重构：这是一项简化技术，用来移除代码中的重复内容和复杂之处
结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动，另一个人同时审查代码的正确性和可理解性
集体代码所有权：任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码
持续集成：每天多次创建和集成系统，只要任何实现任务完成就要进行
每周 40 个小时：程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的
现场客户：一名真实的客户全时工作于开发环境中，帮助定义系统、编写测试内容并回答问题
编码标准：程序员采用一致的编码标准证
RUP与XP的融合，是各自特点的相互补充，也是软件开发方法的平衡之道。而对软件技术平衡的思考也可以说是技术成熟的开始吧。
最后，再阐明我对软件项目开发的理解。在软件项目开发过程中，应该能够识别、分析不同软件项目的特点，采用相对适合的开发实践来适应软件开发过程，保证对软件开发的有效支持，以便能够创造出&ldquo足够好的&rdquo软件。而这个足够就是对进度、成本、质量之间的平衡，最大化满足客户需要的实现。
对于RUP来说，首先，我认为它过于理想化和理论化，RUP 是过程组件、方法以及技术的框架，你可以将其应用于任何特定的软件项目，由用户自己限定 RUP 的使用范围。对于各种类型的软件项目，RUP并未给出具体的自身裁减及实施策略，总有些无依据可循的感觉。你既可以说它能解决任何问题，也可以说它什么都不是；其次，RUP从本质来说还是一个强调设计和规范的软件方法，从这个角度来讲，与传统的瀑布模型没有太大差别，它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预测的软件项目开发中，面临着各种紧急需求、面临着时间压力，沿用RUP是很难应付自如的。但是在另一方面，RUP强调对知识的收集、整理和加工定义，强调在软件开发的时候要有好的体系结构。所以它还是很有利于知识的积累和共享的。
相比RUP ，敏捷方法如XP则更为灵活，倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟通取代详尽的文档，强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法，这里有很多的东西是未知的，知识只存在于两个地方：开发者的头脑和最后的代码。对于项目管理者来说，他们会认为敏捷开发方法弱化了知识管理的概念，而实际上敏捷开发注重的是最有价值的知识的积累和沉淀。
如何灵活应对各种项目风险、如何最大化优先满足用户价值、又如何能够有效的控制项目开发过程、如果做好项目过程中的知识管理，是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调RUP裁剪，实际上我认为RUP不仅仅是需要自身的裁剪，还需要学会融合。在RUP裁剪的同时，适宜的融合敏捷开发的各种实践。不要认为RUP与XP是矛盾的，其实不然，它们具有不同的原理、具有不同的应用领域。在 RUP 中融合了 XP 技术时，才会得到过程的正确量，既满足了项目所有成员的需要，又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队，其中用户是团队的一部分，那么 XP 完全可以胜任。对于团队越来越分散，代码量越来越大，或者构架没有很好定义的情况，您需要做一些其他工作。在用户交互具有"契约"风格的项目中，仅有 XP 是不够的。RUP 是一个框架，可以从 RUP 出发，在必要时以一组更健壮的技术来扩展 XP。
RUP最佳实践包括：
1． 迭代开发: RUP的开发过程建立在一系列迭代之上，每次迭代都有一个固定的时间限制（例如四个星期），称为"时间盒"，每次迭代结束的时候都发布一个稳定的小版本，该版本是最终系统的子集。"时间盒"是迭代开发中的关键概念：它意味着迭代周期的期限是固定的，如果目标没有完成，则放弃本次迭代的需求，而不是延长迭代的时间。
2． 管理需求
3． 使用基于组件的构架
4． 可视建模
5． 持续的质量验证
6． 控制变更
关于RUP阶段的一个简洁和准确的描述：
1.初始－开发系统的业务用例；要求探索少量但是重要的需求（大约10%），以便获得范围、关键风险的尺度，并且决定是否进入细化阶段。
2.细化－迭代地构建核心体系结构和解决技术风险。构建体系结构意味着真正的编程、集成及测试-这不是纸上谈兵或者丢弃原型。细化阶段，我们需要迭代地详细地探索大部分需求（大约80%），同时实现系统的核心风险部分。在整个细化阶段需求都可能是变化的，通过不断的"反馈－适应"循环，评估已实现的部分。
可以看到，这与传统的瀑布风格的需求定义不同，其大部分需求是在开发核心体系结构的同时细化得到的，并且其从实际的开发中得到反馈。我们也能够以此为据来决定是否继续此项目。
3.构造－迭代地构建细化阶段没有做的元素；迭代地集成和进行质量保证；准备部署。由于大部分需求的不稳定性已经在细化阶段澄清，所以在构造阶段需求的变化较少。
4. 发布－完成&beta测试，确定版本，部署系统。RUP规则推荐"迭代周期的长度是2－6周"。 迭代开发和RUP的本质是采取小步骤，对于可能不完美的实现，迅速集成，质量保证，测试，及时获得反馈，然后根据反馈，调整需求、设计和实现。小步骤、反馈和调整是核心概念。
迭代方法允许我们边学边走；随着迭代的进行，我们得到越来越多的真实的需求，更加客观的风险，以及完成该项目的更加准确的能力估计。简言之，经验使我们成为更好的计划者。
12 个 XP 实践包括：
有计划的开发：通过结合使用优先级"故事"和技术估算，确定下一版本的功能
小版本：以小的增量版本经常向客户发布软件
隐喻：隐喻是一个简单、共享的"故事"或描述，说明系统如何工作
简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除
测试驱动开发：用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容
重构：这是一项简化技术，用来移除代码中的重复内容和复杂之处
结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动，另一个人同时审查代码的正确性和可理解性
集体代码所有权：任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码
持续集成：每天多次创建和集成系统，只要任何实现任务完成就要进行
每周 40 个小时：程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的
现场客户：一名真实的客户全时工作于开发环境中，帮助定义系统、编写测试内容并回答问题
编码标准：程序员采用一致的编码标准证
RUP与XP的融合，是各自特点的相互补充，也是软件开发方法的平衡之道。而对软件技术平衡的思考也可以说是技术成熟的开始吧。
最后，再阐明我对软件项目开发的理解。在软件项目开发过程中，应该能够识别、分析不同软件项目的特点，采用相对适合的开发实践来适应软件开发过程，保证对软件开发的有效支持，以便能够创造出&ldquo足够好的&rdquo软件。而这个足够就是对进度、成本、质量之间的平衡，最大化满足客户需要的实现。