瀑布模型的價值觀和實踐：
● 首先，確定大部分的需求，假設用戶在看到其產品之前，就可以妥善的定義需求；
● 第二，進行詳細的設計，假設對于一個定義糟糕的問題，可以為其找到一個精確定義的解決方案；
● 第三，在設計未經證實或者無法證實之前實現；
● 第四，集成、測試和部署。
瀑布模型的一些活動：
● 量完全地實現一些階段產品，例如需求或者設計，然后再向前進行。盡量使這些階段產品完備和穩定，并精益求精。
●隨后發現，先前我們竭力確定下來的需求、模塊或者設計必須要進行重要的變化，這是失敗的跡象。為了使需求或者設計接近于我們先前已經確定下來的結果，盡力彌補。
● 認為基于新的技術為新的系統交付可信的評估和計劃是正確的，特別是在項目的早期。不能做到這一點就意味著缺乏技能 導致RUP失敗最常見的策略就是在一定程度上認為RUP階段和瀑布模型的階段相似。
關于RUP階段的一個簡潔和準確的描述：
1.初始－開發系統的業務用例；
要求探索少量但是重要的需求（大約10%），以便獲得范圍、關鍵風險的尺度，并且決定是否進入細化階段。
2.細化－迭代地構建核心體系結構和解決技術風險。
構建體系結構意味著真正的編程、集成及測試-這不是紙上談兵或者丟棄原型。細化階段，我們需要迭代地詳細地探索大部分需求（大約80%），同時實現系統的核心風險部分。在整個細化階段需求都可能是變化的，通過不斷的"反饋－適應"循環，評估已實現的部分�？梢钥吹�，這與傳統的瀑布風格的需求定義不同，其大部分需求是在開發核心體系結構的同時細化得到的，并且其從實際的開發中得到反饋。我們也能夠以此為據來決定是否繼續此項目。
3.構造－迭代地構建細化階段沒有做的元素；迭代地集成和進行質量保證；準備部署。由于大部分需求的不穩定性已經在細化階段澄清，所以在構造階段需求的變化較少。
4. 發布－完成β測試，確定版本，部署系統。
RUP規則推薦"迭代周期的長度是2－6周"。 迭代開發和RUP的本質是采取小步驟，對于可能不完美的實現，迅速集成，質量保證，測試，及時獲得反饋，然后根據反饋，調整需求、設計和實現。小步驟、反饋和調整是核心概念。迭代周期過長與此背道而馳，必將導致RUP應用的失敗。
在缺乏反饋的情況下定義和確定需求的想法是與軟件開發事實背道而馳的。在項目開始的時候不要指望可信的估計和詳細的計劃！
在缺乏工作量真實信息的情況下設立確切的計劃日期是容易的-這是作計劃遇到的典型問題：計劃一經發布就沒有用了。
迭代方法允許我們邊學邊走；隨著迭代的進行，我們得到越來越多的真實的需求，更加客觀的風險，以及完成該項目的更加準確的能力估計。簡言之，經驗使我們成為更好的計劃者。
有時固定成本成為瀑布方法的辯護者，似乎這可以證明在缺乏真實信息的情況下做出計劃是正確的。事實上，如果你從未做過此類項目，就被要求給出一個固定成本，你只能胡蒙亂撞。如果想成功，最好盡可能地多做預算，盡可能多地雇用此領域中有經驗的人員，并期待最好的結果。在缺乏信息的情況下做出大部分的決定總是有風險的。在迭代方法中，最初的估計你不會做得比上面更好，但是不久你就會十分清楚你做得有多么好，你可以開始協商，預料，更早的管理范圍，那時，最初的估計會有所幫助。
RUP所提倡的解決固定成本及合同的合理方法是兩步走策略。第一步，約定初始的迭代周期（例如四周）的固定成本，進行充分的調查和試驗性的編碼，以得到更具觀察性的范圍、風險和需求說明。這一改進的說明隨后作為第二步中估價的基（完成開發）。
方法學家認為過程有重型和輕型，預見性和適應性之分。重型過程是被人蔑視的，它具有如下特征：
● 刻板而控制嚴格
● 很多活動和工件官僚主義氣息濃重
● 文檔繁多
● 長期而詳細的計劃
● 過程高于本質核心的工作
● 面向過程而不是面向人；把人看成機械方法中的插件
● 預見而不是適應
預見性過程是指在一段相對較長的時間內試圖詳細地計劃和預見活動以及資源的分配，例如大多數項目都是這樣。其價值觀傾向于瀑布模型，強調首先定義需求，然后詳細的設計，最后實現。
如果想在應用RUP時失敗，不妨采取重型的、預見性的過程的實踐：
● 詳細地制定項目的整個迭代計劃。在早期就定義所有迭代期限，并指定每次迭代結束時會發生什么。
● 創建大部分，或者是盡可能多的創建RUP的工件
● 添加大量項目和過程的形式，甚至幾個項目委員會。
● 在項目中堅持機械和鐘擺式的運作，將人看作項目系統中專用的齒輪。
RUP的作者并不認為RUP是重型的或者預見性的，這種認為RUP是重型的或者預見性的錯誤觀點是由于加入了不正確的過程思想或者對RUP的誤解，RUP本身提供的大量詳細的過程文檔也加劇了這種認識，以至于RUP被錯誤的刻畫或者蹩腳的實現。
用輕量、敏捷和適應性的過程精神來應用RUP。如何這樣做的一些指導如下：
● 創建盡可能少的RUP活動和工件；僅僅是那些真正有價值的。隨著項目的進行，如果任何過程活動沒有真正價值，剔除它。
● 不存在所有迭代的詳細計劃。有一個高層的計劃（稱為階段計劃）估計項目的結束時間和主要的里程碑，但是對于這些里程碑，它沒有詳細到確切的方法。詳細計劃（稱為迭代計劃）僅僅預先制定了一個迭代周期的詳細計劃。詳細計劃的制定是適應性的，從一個迭代周期到另一個迭代周期。這并不暗示不能為將來的迭代周期推測地分配一些工作，但這樣做是僥幸的，它增加了項目在將來的不可靠性。調整最初的計劃并不是制定計劃或者執行的失敗，而是對于項目現實情況的合理調整。高層的里程碑日期和目標是已知的，但是實現各個里程碑的方法是適應性的發展的。
輕型或者敏捷過程意味著"傾斜和平均"，其特征如下：
● 拋棄不必要的過度的官僚主義過程，消除低價值的及無思想的文檔；
● 集中在人本身，令軟件開發充滿樂趣；并且
● 是適應性的。
RUP的核心思想和關鍵實踐是：
● 需求管理
● 迭代開發
● 變更控制
● 質量審查
● 以體系結構和組件為中心的設計
● ……
相比較而言，迭代開發對于我們如何思考和實踐軟件開發的影響是最深的。我們應當如下看待上述列表：
● 需求管理
● 迭代開發
● 變更控制
● 質量審查
● 以體系結構和組件為中心的設計
● ……
總的來說，RUP就是一個以迭代的方法培養一個先啟－精化－構建－測試－產品化的軟件開發過程。
1， 其理論上認為可以彌補流瀑式開發方法帶來的風險過大，人力資源利用率不高等不足。
個人認為迭代方式符合人對客觀世界的認識：多次反復地實踐。目前尚未仔細研究不同迭代階段之間的承啟關系，但最擔心的是如何在涉眾（如客戶、老板們）要求較短的時間內完成合格的迭代
2， 學習及實現關鍵：如何深刻理解并實施工作流程。
當開發工作到中后期時，最容易暴露分析設計階段考慮不足的問題，這時候感覺為什么文檔不全，不細。所以我剛接觸RUP時，第一感覺就是RUP能否提供較全面的文檔。粗略地看了一下‘工作流程’后，認識到文檔只是工作流程的一個產物，開發工作是一個process，孤立的文檔是沒有意義的，為文檔而分析設計看似目的明確，其實忽視了最重要的過程控制。當然，完整的文檔是成功的分析設計最明顯的體現。
3， 學習的方法：迭代
靈活的鏈接對迭代學習很有幫助，不過這些鏈接也像一張網，很容易就暈了�？傊痪浜�，實踐出真知！
4， 目的：
想辦法裁減標準RUP，得出適合自己的過程管理。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
