客戶和開發者都想盡快消除項目中的 風險。盡早地為客戶提供應用程序代碼,可以減少由于應用程序沒有按時交付所造成的風險。對于開發 團隊,盡早地發布項目中應用程序的部分內容,特別是與 新技術有關的應用程序內容,可以有助于他們降低開發應用程序時遇到的風險。
在資金發生變化時客戶想要終止項目。通過為項目提供高價值的功能,RUP可以使客戶最大限度地靈活地花費他們的資金,并獲得盡可能多的預算,以維持這項工程。如果我們使用瀑布法,就會出現當設計出許多出色的軟件版本后,我們才發現資金僅僅夠開發其中的一個軟件。
我們改變了什么?
在從瀑布法到RUP的調整過程中,有許多需要改變的地方:
﹡項目結構。改變項目結構是非常關鍵的一步。我們將從我們的瀑布法階段,包括高層設計,總體設計,發布設計,構建,測試,部署,發布設計,構建,測試,部署--轉到RUP階段,包括多個精化階段,隨后是多個構建階段。我們可能重復這個過程,并且每個遷移階段都會按照這個過程進行。
﹡時間框架。在我們開始之前,每個迭代都會被限制在一個時間框架中。如果我們認為在一個精化或構建迭代階段沒有足夠的時間完成我們的工作,我們將把這項工作推延到下一個迭代中去。這個與我們在瀑布項目中處理的方法是不同的,在瀑布法中,為了完成設計,構建,測試或者部署,我們可能會擴展這個階段。
﹡ 資源使用。在瀑布法中,我們在設計階段擁有的資源在構建/測試/部署階段時將不復存在。利用RUP方法時,我們可以保證資源貫穿于每一個階段。在項目中,我們可讓一個人在不同的階段扮演不同的角色。
﹡早期開發。我們幾乎是立即著手開發應用程序,甚至是精化迭代和設計還未完成。而利用瀑布法設計,開發在設計完成之前是不能進行的,利用RUP的項目,我們通過迅速開發部分項目來降低了風險并且獲得了好處。尤其是項目開發的最初幾周,也就是我們著手開發用戶界面的階段。迭代法可以使我們周期性地提供應用程序的進展,讓我們的客戶感到滿意。迭代法還幫助我們在客戶的要求問題上與他們達成一致。它還可以讓我們持續地檢驗應用程序的品質(例如,讓我們開發的應用程序滿足客戶提出的要求)。它還可以通過讓開發團隊使用新技術來降低風險(例如,使用從未用過的永久性構架技術)。
哪些是我們要保留的相同內容?
從瀑布法到RUP,盡管我們改變了許多,但是我們并沒有全部摒棄傳統的設計方法。
對其它活動的關聯。當我們將項目開發從瀑布法轉到RUP方法時,有許多支持項目和子項目也在同時進行。在我們初始的瀑布法項目中,我們有了一個關鍵路徑,將我們的項目中的關鍵活動與其它項目中的關鍵活動關聯在一起。當把我們的項目轉為RUP后,我們會記錄下其它項目中關鍵活動的日期,然后在我們的項目中創建出與那些活動緊密相關的新活動。
角色與資源。在項目中我們扮演著同一個角色并且保持同樣的資源,盡管項目的結構已經發生了變化。我們仍然想用相同的人員類型得到相同的設計、開發和測試量。還有,一些與應用 程序開發無關的角色(例如,基礎結構的開發)也被保留下來。
原文轉自:http://www.anti-gravitydesign.com