1.架构优先
RUP的统一过程的一个重要内容就是架构优先以及以架构为核心。架构在整个软件开发中启到了很好的承上启下的作用，要设计一个好的架构必须要求架构师既精通技术又熟悉业务。架构设计完成了整个软件或系统大概长什么样子就清楚了。
如果说制造一个成年人有两种方法，一种是从小慢慢制造大;一种则是先直接制造成年人的骨骼，再组建制造来有血有肉。这两者间就有很大的差别的，第一种方法
使我们在整个生命周期前期很难看到以后这个成年人的大概样子；而第一种方法骨骼框架先全部出来了，我们就很容易了解到造出来人是什么样子，也知道了脑袋绝
对不会长在脚底下，也知道了脑袋和脖子是肯定可以衔接上的，不会说脑袋出来了衔接不到脖子上面的问题。而这些就恰恰都是架构要解决的问题，一个软件系统要
划分为哪些package，哪些component，各自间的接口究竟是什么样子的。这些都确定好了基本就不会出现由于前面各自为政导致的全部组件开发出
来后无法集成，本来改在逻辑层实现组件放到了UI层去实现等诸多问题。
对于全新的系统架构设计完成后仍然需要进行验证，如可以实现相关的原型对架构进行验证。保证架构的可用性，通过架构优先和原型验证就大大降低了整个项目的风险。
2.尽早集成
尽早集成或说持续集成也是有效控制风险的一个重要手段。只有尽早集成才可能及早的发现缺陷和问题，而缺陷在项目生命周期前期得到修复的成本将比后期低得多。
尽早集成使开发得进度随时都使可见得，开发认为是否真正完成只需要对Build出来得应用做一个简单得冒烟测试就可以搞清楚。
架构设计也不能一开始就考虑得很全面，因此及早得集成可以发现架构设计中不合理得地方，使设计得问题及早得暴露并得到修正。
及早和持续得集成可以使测试工作更好得迭代起来，测试可以尽早得介入到项目中，减少了后续全部功能开发完成后所需要得较长的系统测试时间。
3.Review的改进
设计开发阶段的Review对开发的质量控制起到重要作用，好的Review至少可以发现60%的设计开发问题，防止了缺陷的进一步泄漏。
Review也是白盒测试的一种重要的方法，Review的重点应该放在黑盒测试无法触及到的地方。如代码的规范性，可读性，健壮性，复用，方法和子函数的划分，代码的可读性和可维护性等方面的内容。
XP结队开发强调开发人员间相互Review代码以发现问题，Review应该在编码一开始后就开始启动和计划，而不是等全部编码结束了才进行。Review还应该重点注意的是要尽量多增加Review的次数，减少每次Review的时间。