在調整開發流程時,這些分類可以用來說明如何使用工作成果(及報告)。這些值可以用一個個別的分類器來補足,以定義工作成果的審查程序。如需有關審查工作成果層次的詳細資訊,請參閱準則: 審查層次。
分類
|
說明
|
必須有
|
您必須使用這個工作成果。它是一個關鍵的工作成果,如果沒有產生,在稍後的開發階段中,可能會發生問題。
|
應該有
|
可能的話,您應該有這個工作成果,但它是可協議的。如果您沒有產生這個工作成果,您應該能夠證明不產生的合理性。
|
可以有
|
可以有表示這個工作成果並不需要產生。只有在會帶來附加價值且有足夠時間的情況下,才產生它。
|
不會有
|
這表示您不會使用這個工作成果。在本端工作成果取代 Rational Unified Process 工作成果之處,便可能出現這個情況。
|
此分類架構可以加以擴充或自訂,以反映貴組織的個別文化。
何時可以調整此分類架構的一個範例是依所執行的調整層次而定。例如,在調整特定專案的流程時,究竟要不要使用特定的工作成果,是作為調整工作的一部分來做決定。在這種情況下,上述的分類架構就可以縮減為「必要的」,和「非必要的」。但若是別的情況,
例如在調整組織的流程時,預期必須針對個別的專案做進一步的調整, 如上述表格說明的更廣泛的分類架構就愈加重要。如需有關不同的調整層次之詳細資訊,請參閱概念:調整 RUP。
分類為必須有或應該有的所有工作成果,都必須定義它們的檢視程序、工具、範本和配置管理作法。
對於分類為可以有的工作成果而言,這些程序的規格是選用的 - 這些決策可以保留給決定產生這些工作成果的開發人員或專案。
所有分類為不會有的工作成果都必須證明省略它們是合理的。
採用此分類架構的主要好處,是此分類架構可以清楚指出流程的自訂內容,以及哪裡有可以協商和做區域決策的選擇。
工作成果的分類架構可以想成是用來設定工作成果的使用方式限制。
比方說,如果您決定專案要採用「分析模型」,則後續的自訂作業就可以調整這些值,來決定專案要符合下列其中一個準則:
-
專案會有「分析模型」
-
專案不會有「分析模型」
-
專案會停留在現行狀態(「分析模型」是選用的)
分類架構甚至可以動態使用 - 可讓工作成果的狀態根據專案所在階段而變更。
下表顯示分析模型的不同處理方式。如何使用直欄定義工作成果在每一個階段的用法。
工作成果
|
如何使用
|
備註
|
初始階段
|
詳述
|
建構
|
轉換
|
分析模型
|
不會
|
不會
|
不會
|
不會
|
不開發任何分析模型
|
分析模型
|
可以
|
可以
|
可以
|
可以
|
一般
|
分析模型
|
可以
|
應該
|
不會
|
不會
|
這是一個發展方法,它用設計模型來取代分析模型
|
分析模型
|
必須
|
不會
|
不會
|
不會
|
這是一個發展方法,它在初始階段強制採用分析模型來協助設定專案範圍,但在詳述期間,用設計模型來取代分析模型
|
分析模型
|
應該
|
必須
|
必須
|
必須
|
這是一個正式流程,它強制採用分析模型,且保留初始階段的選用工作成果
|
|