◆為什么RUP更有意義？
◆我們改變了什么？
◆哪些是我們要保留的相同內容？
◆結果是什么？
◆你應當在何時考慮使用RUP方法替代瀑布法？
◆你首先應當作的事情是什么？
◆結論
本文來自于 Rational Edge：通常，堅定地相信迭代化方法的軟件開發者必須為那些出于各種原因而堅持使用傳統的瀑布方法理念的客戶服務。本文就是討論如何幫助那些人改變觀念，轉為使用Rational Unified Process。
迭代開發技術的支持者——尤其那些花費了若干年掌握如何使用Rational Unified Process和相關的迭代方法進行軟件開發的專業技術人員和顧問——他們經常批評傳統的"瀑布"方法，甚至不理解為什么瀑布法仍然在軟件開發公司中被廣泛使用。為了拿出客戶要求的IT解決方案的項目計劃，我們會涉入到許多項目，它們最初都使用瀑布方法。這些解決方案包含開發新軟件以及擴建新的基礎結構。
我們有許多不錯的使用瀑布方法的理由，包括：
﹡瀑布法在過去的使用中很成功
﹡我們可以重新利用其它瀑布項目的資源
﹡我們的團隊（也就是我們客戶的員工）感到使用瀑布法很方便
﹡我們的團隊希望在進行開發之前完成全部的設計任務
﹡我們的團隊也許和另外一只使用瀑布法的團隊合作 （尤其是那些為我們的整體解決方案和建設基礎結構的團隊）
不論這些理由是什么，使用Rational Unified Process?或者RUP?進行項目開發比使用瀑布法更有意義。我們可以把項目計劃和所有的方法轉換為迭代方法。本文就是基于以上所述，帶您體驗這種方法。
初始計劃是什么以及為什么？
初始計劃通常包括許多設計階段，在這些階段中我們要概述客戶的解決方案。因為這些項目將會有多個軟件發布版本，所以初始的設計階段包括了軟件的整體設計。然后針對每個發布版本我們都會有一個設計階段。隨后的每個設計階段將變得越來越具體，因為我們的客戶逐漸清楚什么是他們所需要的，而此時我們的團隊也可以開始動工了。
為什么RUP更有意義？
對于我們的許多項目，在與客戶一起評審完我們的瀑布法計劃后，就顯示出來一個面向RUP的項目計劃比我們的瀑布法計劃更具加有意義，這里有很多理由，包括：
客戶想要盡早獲得成果。一些客戶不愿等到我們大量的設計工作完成之后才進行開發。它們經常提出一些要求并且想得到應用程序的代碼，然后就可以盡快地把它們拿給股東們看了。
在首次軟件發布日期之前，客戶不會提出所有高水平的要求。在進入到計劃設計階段尾聲之前，一些客戶不會提出全部的要求，或者是因為一些沖突或者其它的一些限制（例如，一個在今后某個時刻才能做出的決定）。
客戶希望牢牢控制項目的周期和預算。 盡管項目會出現一些不確定的要求或者其它的不確定因素，但是客戶依然想控制項目的進度。由于RUP項目的每一個階段是一個時間箱，因此我們可以準確地描述項目的進度以及每個階段所需的資源，還有每個階段完成之后項目的開銷。
客戶和開發者都想盡快消除項目中的風險。盡早地為客戶提供應用程序代碼，可以減少由于應用程序沒有按時交付所造成的風險。對于開發團隊，盡早地發布項目中應用程序的部分內容，特別是與新技術有關的應用程序內容，可以有助于他們降低開發應用程序時遇到的風險。
在資金發生變化時客戶想要終止項目。通過為項目提供高價值的功能，RUP可以使客戶最大限度地靈活地花費他們的資金，并獲得盡可能多的預算，以維持這項工程。如果我們使用瀑布法，就會出現當設計出許多出色的軟件版本后，我們才發現資金僅僅夠開發其中的一個軟件。
我們改變了什么？
在從瀑布法到RUP的調整過程中，有許多需要改變的地方：
﹡項目結構。改變項目結構是非常關鍵的一步。我們將從我們的瀑布法階段，包括高層設計，總體設計，發布設計，構建，測試，部署，發布設計，構建，測試，部署－－轉到RUP階段，包括多個精化階段，隨后是多個構建階段。我們可能重復這個過程，并且每個遷移階段都會按照這個過程進行。
﹡時間框架。在我們開始之前，每個迭代都會被限制在一個時間框架中。如果我們認為在一個精化或構建迭代階段沒有足夠的時間完成我們的工作，我們將把這項工作推延到下一個迭代中去。這個與我們在瀑布項目中處理的方法是不同的，在瀑布法中，為了完成設計，構建，測試或者部署，我們可能會擴展這個階段。
﹡資源使用。在瀑布法中，我們在設計階段擁有的資源在構建／測試／部署階段時將不復存在。利用RUP方法時，我們可以保證資源貫穿于每一個階段。在項目中，我們可讓一個人在不同的階段扮演不同的角色。
﹡早期開發。我們幾乎是立即著手開發應用程序，甚至是精化迭代和設計還未完成。而利用瀑布法設計，開發在設計完成之前是不能進行的，利用RUP的項目，我們通過迅速開發部分項目來降低了風險并且獲得了好處。尤其是項目開發的最初幾周，也就是我們著手開發用戶界面的階段。迭代法可以使我們周期性地提供應用程序的進展，讓我們的客戶感到滿意。迭代法還幫助我們在客戶的要求問題上與他們達成一致。它還可以讓我們持續地檢驗應用程序的品質（例如，讓我們開發的應用程序滿足客戶提出的要求）。它還可以通過讓開發團隊使用新技術來降低風險（例如，使用從未用過的永久性構架技術）。
哪些是我們要保留的相同內容？
從瀑布法到RUP，盡管我們改變了許多，但是我們并沒有全部摒棄傳統的設計方法。
對其它活動的關聯。當我們將項目開發從瀑布法轉到RUP方法時，有許多支持項目和子項目也在同時進行。在我們初始的瀑布法項目中，我們有了一個關鍵路徑，將我們的項目中的關鍵活動與其它項目中的關鍵活動關聯在一起。當把我們的項目轉為RUP后，我們會記錄下其它項目中關鍵活動的日期，然后在我們的項目中創建出與那些活動緊密相關的新活動。
角色與資源。在項目中我們扮演著同一個角色并且保持同樣的資源，盡管項目的結構已經發生了變化。我們仍然想用相同的人員類型得到相同的設計、開發和測試量。還有，一些與應用程序開發無關的角色（例如，基礎結構的開發）也被保留下來。
交付物以及其它文檔。我們希望在瀑布項目中計劃產生的文檔在RUP項目中仍舊產生。不管我們使用什么方法，顧客仍然想要關鍵可交付物（例如，主測試計劃），而不管我們的方法是什么。同樣地，我們創建了一個文檔，讓團隊為每個項目準確地創建基礎結構，如何配置服務器、軟件，等等，無論是瀑布法還是RUP方法，我們都要做這一步工作。
所需工作量。盡管由于從瀑布法到RUP方法的改變導致了構建解決方案的方法發生了變化，但是無論使用哪一種方法，完成相同的工作所需的工作量并沒有改變。
結果是什么？
當從瀑布法改為RUP方法后，我們發現：
﹡RUP幫助我們管理客戶的需求，盡管客戶也許還不清楚他們最初提出的每一個需求。我們需要牢牢地管理變更并且增加額外的階段用于滿足新的需求。時間箱和多個迭代幫助我們管理變更。在精化階段，多個迭代意味著如果因為時間箱而無法在一個迭代中完成任務，但客戶仍舊想要進行這個任務，我們就要把它轉移到另一個迭代中去。同樣地，在精化階段，如果我們發現項目中包含了比計劃還要多的任務，我們就將把一些任務轉移到其它迭代中去。我們甚至可以增加額外的迭代，如果客戶覺得這樣做是值得的。如果客戶被預算所限制，他們將不會再繼續增加迭代，因為他們已經從完成了的迭代中獲得重要的價值�！�
﹡在構建階段中的多個迭代也會幫助進行需求管理。通過使用迭代進行應用程序的開發，我們可以讓客戶確認他們在每個迭代中的要求。如果應用程序沒有和當初設想的一致，我們還可以在下一個迭代中將它改變。這對我們的管理也有所幫助。
﹡RUP幫助我們自始至終中地保證質量。因為我們在每一個迭代結束后都發布代碼，所以RUP讓測試變得簡單，并且降低了在項目的后期發現重大問題的概率。
﹡可視化建模幫助客戶發現什么是他們想要的以及幫助我們了解什么是客戶想要的。間接地，它還幫助我們拉近了與客戶之間的關系�？蛻粲X得可以更進一步參與到應用程序的開發中去，應用程序能夠如期完成并且包含全部他們想要的東西，這些都讓客戶感到非常得滿意。
﹡采用組件架構使我們可以交付獨立的、功能性軟件用于較早的測試。它在幫助開發團隊進行任務分解和分配工作時也顯得十分有用。
你應當在何時考慮使用RUP方法替代瀑布法？
以下是在何時用RUP方法替代瀑布法的一些建議：
1、使用瀑布法無法滿足客戶時。例如，客戶對要花費很長時間才能看到結果感到不滿時�；蛘呖蛻舯г顾麄冃枰屿`活的應用程序，或者他們想在開發的早期就可以解決風險問題�；蛘弋斂蛻粝朐陧椖康拈_發初期就看到它的組成部分，不是簡單的原型或者證實可行的概念，而是即將成為全部應用程序一部分的實際項目代碼，RUP 就為以上這種開發方式提供了框架。
2、客戶當前已經普遍使用一個或多個Rational工具。如果真是如此，那么他們應經看到了IBM Rational軟件的價值以及這種迭代方法所帶來的好處了。你可以告訴客戶，在不久的將來使用RUP可以使這些工具變得更加有價值。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
