一般我們可以採用rup的方式來進行開發，即從需求，到分析，到設計，到實現，到測試，rup從最容易理解的需求開始，然後通過需求匯出設計，由設計指導實現…，因此，在使用rup時，最困難的步驟是需求，只有需求分析清楚了，後面的設計和實現就自然的水到渠成。但是rup的乙個缺點是需求要相對固定，因為需求的改變會導致後期的設計和實現的改變，因此對於乙個需求確定的專案rup是乙個不錯的選擇。
另外一種開發方法是xp，他從測試，到**實現，到重構，然後返回測試，一直迭代，直到實現所有的功能。xp從另外乙個側面來說，也是從需求入手，只不過，她的需求是通過測試來表現，這樣的乙個好處就是，能夠很直接的把類的published方法，而不是public方法提取出來。特別的，對於分層系統來說，測試起到乙個模範的作用，測試在測試下層服務的同時，也相當於把自己設定為乙個上層服務的角色，因此上層的服務可以模仿測試的語法來呼叫下層的服務。
一般情況下，我們都喜歡把rup和xp擺在乙個對立的立場上來進行比較，而更多情況下，我們都要非此即彼的選擇一種方法作為我們專案的開發方法。但是，我覺得這樣做完全沒有必要，而且不合適。首先，這兩種方法都是經過了一定專案實踐之後提出來的開發方法，因此，理論上他們都有一定的可取性。另外，這兩種方法之間存在比較明顯的相互補充特性，這表現在rup的缺點往往是xp的優點，而xp的缺點卻正好是rup的優點上。因此，在選擇開發方法時，我們應該適度的把這兩種方法進行糅合。
首先，在開始的時候我們可以採用rup的需求分析策略，它比xp的tdd更加容易入門和上手，因為，在不確實了解需求的情況下，根本不可能提出測試用例。
有了需求文件接下來我們可以開始使用xp中的tdd方法，這裡之所以不使用rup的分析，設計是因為一般來說這兩個步驟占用的時間比較長，這就造成了發布時間的延長。而且，相對於文件，**更有說服力，而且對於程式設計師來說，**的意義很多時候比文件要大。再者，對於需求不穩定的專案，測試用例相對於分析，設計文件具有更快的反應速度和更短的反饋線路。因此，在這一步我們採取開發測試用例的方式。
有了測試用例，很自然的接下來的步驟就是**實現，然後測試，然後重構。標準的tdd方式。
在以上的所有步驟當中，我們都是圍繞著程式設計師在開發，但是，在乙個團隊當中，除了程式設計師以外，還有大部分不直接參與編碼的管理人員和終端使用者，因此，伴隨著測試用例還有**，我們應該根據rup的方式，提取出對應的分析，設計文件。之所以在這步才完成上述文件主要是基於以下考慮。雖然從需求我們可以匯出這些文件，但是由於在那個時候，我們尚未對系統進行任何實現，因此，所有的分析和設計都具有或多或少的猜測和不確定性，因此，在rup當中，我們需要不停的進行迭代，來對系統進行求精。而使用tdd的方式，一開始我們就從**出發，而通過測試和重構，我們就能完成系統的求精，因此相對於rup的文件，**，文件，**…的迭代求精方式，tdd只需要在**一級進行迭代，因此從時間和難易程度上tdd都要比rup要簡單。
RUP與XP的平衡之道
2006年06月22日 22 41 00 rup與xp的平衡之道 人有過什麼經驗，遇到過什麼恐懼的事，就會形成設法避免這種事情的方法學。研究重型方法學的人可能一直以來的經驗就是組織上千人的開發隊伍進行開發，比如說大型電信系統的開發 軍事航天系統的開發.這種專案嚴格強調過程執行的規範，注重文件規範 評...
笨方法「學習python筆記之函式
python也支援函式功能，但是定義了一些簡單規則 任何傳入引數和自變數必須放在圓括號中間，圓括號之間可以用於定義引數 函式的第一行語句可以選擇性地使用文件字串 用於存放函式說明 函式內容以冒號起始，並且要縮排四個空格 return 表示式 結束函式，返回乙個值給呼叫方，不帶表示式的return相當...
TCP擁塞演算法學習之擁塞控制方法
擁塞控制用於防止過多的報文進入網路，造成路由或者鏈路過載。流量控制的重點是放在點到點鏈路的通訊量的區域性控制上，而擁塞控制的重點是放在進入網路報文總量的全域性控制上。tcp協議滑動視窗是實現擁塞控制的最基本的手段。為了使討論簡單，假設報文是單方向傳輸，並且有足夠的快取空間，傳送視窗大小只由網路擁塞程...