Baseline an executable architecture early on
        很多項目風險與所選用的框架有關。因此你總會希望選擇正確的框架。實際上，能夠把基線建立在一個功能性框架上，就是說盡可能早的設計、實現、測試這個框架對于一個成功的項目來說是很關鍵的。因此RUP把它作為一個精化階段的主要目標，比如在一個有四個階段的項目中，這個過程會占到兩個階段。
        首先，框架對我們來說有什么意義？框架包含一個軟件系統的絕大多數重要的模塊和接口--即子系統和子系統的接口、組件和組件的接口。這個結構為系統提供了一個“骨架”，它會占到最終代碼的百分之十到百分之二十。這個框架同樣包含所謂的“框架機制”。就是指對于一些通用問題的經典解決方法，比如持久化機制和垃圾回收機制。要想得到一個正確的框架是相當困難的，因此你需要選用你手下最有經驗的人來從事這項工作。
        當手頭有了合適的框架以后，也就相當于擁有了一套健全的模塊或組件，進而為最終的產品做好準備。同時，遵照RUP的迭代過程，你的團隊可能已經在分析、設計、實現以及測試中得到了很多重要的經驗，所以你需要牢牢地抓住這些“無形的財富”來使你的系統不斷完善。以一個可以運轉的框架為基線，你可以更加準確的估算出項目所需要的資源和時間。掌握了這些重要的信息，你就可以優化你的資源配置并通過對邊界的管理來更好的與商務運作相配合。
        一個正在運轉的框架，傳達了這樣一種信息：就是你已經處理好了大多數建造系統的難點。現在想要向項目中引入一個新成員，變得更加容易；邊界已經被那些關鍵的組件、基本的接口定義好了；并且框架機制已經開始被越來越多的使用，普通的問題可以很上手的解決。

Build your system with components
        隨著功能分布到系統的各個部分，數據也隨著功能被隨處堆放。結果導致維護系統需要很大的花費。比如如果改變數據的存儲模式，將會給相當數量的功能造成壓力，并且通常情況下很難知道在這個系統中到底哪些功能會真正受到影響。
         另外，這種開發模式把數據和施之于數據上的一組操作封裝到一個組件里面。當你需要修改數據的存儲方式，又或者想要修改數據的處理方式的時候，這些變化都會被組件所隔離。這回導致系統變得更加具備“柔性”。
        和組件打交道，使用它所能提供的功能和代碼，你只需要知道組件的接口即可，你完全不用關心它內部是如何工作的。更甚至一個組件可以被完全重寫，而不會給當前的系統和系統代碼帶來任何的影響，當然前提是接口不能變動。這就是面向組件開發的重要特色，我們叫它“封裝性”，這使得組件更加易于重用。
        組件同樣可以被另外一個組件所集成，從而使集成者具備更加高級的能力。連接、封裝以及大型組件的出現更加促進了重用帶給應用程序開發的生產力。
        組件技術同時也是WebService的基礎。所以WebService幾乎具備組件的一切優點，同時它還有“跨平臺”的特點。

Work together as on team
        人是一個項目中最寶貴的資產。軟件開發越來越變得像是一個團隊競技，并且迭代式的軟件開發方法對你管理團隊的方式、你的團隊使用的工具以及每一個團隊成員的價值都有深遠的影響。
         傳統意義上，很多公司都有各司其職的小組織：所有的分析人員在一個小組里，設計者在一個小組里，測試者在一個小組里，甚至說會在另一幢建筑里。盡管這個組織讓有相應資格的人在一起工作，但是會這會削弱交流的效果。這會導致如需求小組產生的需求不會被開發者或測試者所吸收這種情況的出現。這會導致交流上出現斷層，附加額外的工作，甚至使項目延期。
        按照職責對人進行劃分是瀑布方法時代常用的管理方法，如果你有20個月以上的時間，你完全可以這樣去管理。但是現實是你只有一半的時間，甚至只有三個月的時間。你需要一個暢通無阻的平臺去讓團隊進行交流。為了達到這一點，你需要：
在你的項目中打破“職責組”的劃分。
確保團隊成員本著“我要盡可能的為提高項目質量而工作”的思想參與項目，而不是成天想著只完成“指派給我的本職工作”。
為不同職責的人提供有效的交流工具。
現在看一下具體怎樣做：
        項目團隊應該包含分析人員、開發人員、測試人員，一個項目經理，若干構架師等等等等。你可能會說對于小項目來說，這樣做還算不錯，但是對于更大的項目，比如需要50個人參與的時候，這樣還合適嗎？答案是圍繞框架再進行劃分。建立一個“架構師”小組，讓這些人把握架構；讓他們決定自系統和接口。同時，每一個子系統所對應的團隊應該包含分析員、開發員、測試員，讓他們處在高度交流和高速決策的狀態中。他們可以與另外一個團隊進行交流，討論架構方面的問題。

        為了確保分析員、開發員和測試員能夠更加緊密地工作，他們需要良好的基礎設施。你需要讓每個人都能夠接觸到需求、次品率、測試狀態等等。
        在這樣一個團隊中，不會出現某個成員擁有某樣東西的情況。比如你的設計、我的代碼等等。因為工作是建立在思想高度統一的交流機制上的。
Make quanlity a way of life,not an afterthought
        迭代的一個最主要的好處就是，你可以盡早的開始測試工作。早在第二階段--精化階段，就已經有可執行的軟件出現了，它實現了框架。這表明你可以通過測試來印證這個框架是不是工作良好。你可以對框架進行一些負載測試。盡可能早得得到這方面的反饋會贏得大筆的時間并會降低花費。
        通常RUP要求你在實現的時候就進行測試。從注重重要功能實現的早期，一直到項目的結束，軟件會逐漸成長并一直運轉，同時也被測試了相當的時間。按照這樣進行，軟件的質量的提高是顯而易見的。
        另外一種思路就是在設計時期就抓質量。這意味著把設計和測試緊綁在一起。在設計時考慮系統在測試時會被如何測試，會讓你的測試變得高度自動化，因為測試代碼可以從設計模型生成。這大量的節省了時間，鼓勵早期測試，并且提高了測試的質量。
         質量是關乎所有團隊成員的東西，它需要滲透到項目進程中的方方面面。你需要反復查看項目所產生的文檔、報告，考慮如何測試一個需求以及如何通過設計來產生測試等等。