1.架構優先
RUP的統一過程的一個重要內容就是架構優先以及以架構為核心。架構在整個軟件開發中啟到了很好的承上啟下的作用，要設計一個好的架構必須要求架構師既精通技術又熟悉業務。架構設計完成了整個軟件或系統大概長什么樣子就清楚了。
?
如果說制造一個成年人有兩種方法，一種是從小慢慢制造大;一種則是先直接制造成年人的骨骼，再組建制造來有血有肉。這兩者間就有很大的差別的，第一種方法
使我們在整個生命周期前期很難看到以后這個成年人的大概樣子；而第一種方法骨骼框架先全部出來了，我們就很容易了解到造出來人是什么樣子，也知道了腦袋絕
對不會長在腳底下，也知道了腦袋和脖子是肯定可以銜接上的，不會說腦袋出來了銜接不到脖子上面的問題。而這些就恰恰都是架構要解決的問題，一個軟件系統要
劃分為哪些package，哪些component，各自間的接口究竟是什么樣子的。這些都確定好了基本就不會出現由于前面各自為政導致的全部組件開發出
來后無法集成，本來改在邏輯層實現組件放到了UI層去實現等諸多問題。
?
對于全新的系統架構設計完成后仍然需要進行驗證，如可以實現相關的原型對架構進行驗證。保證架構的可用性，通過架構優先和原型驗證就大大降低了整個項目的風險。
?
2.盡早集成
盡早集成或說持續集成也是有效控制風險的一個重要手段。只有盡早集成才可能及早的發現缺陷和問題，而缺陷在項目生命周期前期得到修復的成本將比后期低得多。
?
盡早集成使開發得進度隨時都使可見得，開發認為是否真正完成只需要對Build出來得應用做一個簡單得冒煙測試就可以搞清楚。
?
架構設計也不能一開始就考慮得很全面，因此及早得集成可以發現架構設計中不合理得地方，使設計得問題及早得暴露并得到修正。
?
及早和持續得集成可以使測試工作更好得迭代起來，測試可以盡早得介入到項目中，減少了后續全部功能開發完成后所需要得較長的系統測試時間。
?
3.Review的改進
設計開發階段的Review對開發的質量控制起到重要作用，好的Review至少可以發現60%的設計開發問題，防止了缺陷的進一步泄漏。
?
Review也是白盒測試的一種重要的方法，Review的重點應該放在黑盒測試無法觸及到的地方。如代碼的規范性，可讀性，健壯性，復用，方法和子函數的劃分，代碼的可讀性和可維護性等方面的內容。
?
XP結隊開發強調開發人員間相互Review代碼以發現問題，Review應該在編碼一開始后就開始啟動和計劃，而不是等全部編碼結束了才進行。Review還應該重點注意的是要盡量多增加Review的次數，減少每次Review的時間。