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

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

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

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