專案的階段和里程碑
就管理觀點而言,Rational Unified Process (RUP)
的軟體生命週期在時間上分為四個連續的階段,各階段以一個重大里程碑為總結;各階段基本上就是兩個重大里程碑之間的一段時間。每一個階段最後會進行評量,判斷是否已達成階段目標。令人滿意的評量結果可讓專案繼續進入下一個階段。
規劃階段
各階段的排程和投入成本都不一樣。雖然這大多視專案而定,但中型專案的起始開發週期通常會有下列的投入成本與排程分配情形:
可以用圖形表示為
此分佈情形不固定。例如,產生程式碼和測試案例的工具可以縮短建構階段。另外,在演化週期中,初始階段和詳述階段會很短,因為已建立基本的願景和架構。
規劃策略
在此章節中,我們介紹適用於一般專案設定的許多生命週期型樣。
生命週期型樣:漸進式
「漸進式策略先決定使用者需求,並定義系統需求,然後在一連串建構版本中進行其餘的開發工作。第一個建構版本納入一部分規劃的功能,下一個建構版本增加更多功能,如此延續下去,直到系統完成為止。」[DOD94]
主要的反覆如下:
-
短期的「初始」反覆,建立範圍和願景,並定義商業案例
-
單一「詳述」反覆,此期間會定義需求並建立架構
-
數個「建構」反覆,此期間會實現使用案例並充實架構內涵
-
數個「轉換」反覆,將產品轉換給使用族群
此策略的適用時機:
-
很熟悉問題領域。
-
充分瞭解風險。
-
專案小組經驗豐富。
生命週期型樣:進化型
「進化策略不同於漸進式策略,原因在於未完全瞭解使用者需求,且無法在事前定義所有需求,而是在後續每一個建構版本中修正。」[DOD94]
主要的反覆如下:
-
短期的「初始」反覆,建立範圍和願景,並定義商業案例
-
數個「詳述」反覆,此期間會在每一個反覆中修正需求
-
單一「建構」反覆,此期間會實現使用案例並擴充架構
-
數個「轉換」反覆,將產品轉換給使用族群
此策略的適用時機:
有些作者也會分階段將漸進式功能交付給客戶 [GIL88]。當上市時間急迫時,這有其必要,因為儘早交付某些重要特性可以獲得重大的商業利益。
就階段反覆方法而言,轉換階段很早就展開且包含最多反覆。如果是「史無前例的」系統,則此策略需要一套非常穩定的架構,這在起始開發週期中很難達成。
主要的反覆如下:
-
短期的「初始」反覆,建立範圍和願景,並定義商業案例
-
單一「詳述」反覆,此期間會設定穩定架構的基準線。
-
單一「建構」反覆,此期間會實現使用案例並充實架構的內涵
-
數個「轉換」反覆,將產品轉換給使用族群
此策略的適用時機:
-
很熟悉問題領域:
-
架構和需求在開發週期早期可以趨於穩定
-
新的問題很少
-
團隊經驗豐富。
-
漸進式發行功能對客戶很有價值。
生命週期型樣:單次反覆 (Grand
Design)
傳統的瀑布式方法可視為一種失敗案例,在建構階段中只有一次反覆。[DOD94] 中稱之為「單次反覆 (Grand
Design)」。事實上,在轉換階段很難避免多次反覆。
主要的反覆如下:
-
短期的「初始」反覆,建立範圍和願景,並定義商業案例
-
單一冗長的「建構」反覆,此期間會實現使用案例並充實架構的內涵
-
數個「轉換」反覆,將產品轉換給使用族群
此策略的適用時機:
-
在非常穩定的產品中增加少量明確定義的功能
-
新的功能定義嚴謹又合理
-
團隊在問題領域和現有的產品上經驗豐富
事實上,很少專案會嚴格遵循一種策略。到最後總是變成混合體,只在開頭有一些進化、一些漸進式建構版本及多個交付項目。階段反覆模型的優點在於您可以兼顧混合式方法,只需要延長特定的階段和增加反覆數目:
-
對於需要深入探索的複雜或不熟悉的問題領域:增加詳述階段的反覆數目並延長時程。
-
對於很難將設計轉換為程式碼的複雜開發問題:增加建構階段的反覆數目並延長時程。
-
若要以一連串漸進式發行來交付軟體:增加轉換階段的反覆數目並延長時程。
週期轉換
四個階段歷經一次就稱為一個開發週期;四個階段每歷經一次就會產生軟體的一個世代。除非產品「停產」,否則就會重複同樣的初始、詳述、建構及轉換階段而進化成下一個世代,只是每一次在不同的階段有不同的重點。這些後來繼之而起的週期稱為
演化週期。隨著產品不斷經歷多個週期,新的世代也就不斷推出。
演化週期的推動因素包括使用者建議的強化功能、使用者環境的改變、基礎技術的改變、對競爭採取的反應等,諸如此類。演化週期的「初始」和「詳述」階段通常很短,因為基本的產品定義和架構在先前的開發週期中早已底定。如果演化週期大幅地重新定義產品或架構,則這項定律不成立。
|