準則: 分類工作成果
本準則提供 一種分類架構,適用於說明個別工作成果的重要性,以及是否要使用這些成果。
關係
主要說明

簡介

分類

說明

必須有

您必須使用這個工作成果。它是一個關鍵的工作成果,如果沒有產生,在稍後的開發階段中,可能會發生問題。

應該有

可能的話,您應該有這個工作成果,但它是可協議的。如果您沒有產生這個工作成果,您應該能夠證明不產生的合理性。

可以有

可以有表示這個工作成果並不需要產生。只有在會帶來附加價值且有足夠時間的情況下,才產生它。 

不會有

這表示您不會使用這個工作成果。在本端工作成果取代 Rational Unified Process 工作成果之處,便可能出現這個情況。

此分類架構可以加以擴充或自訂,以反映貴組織的個別文化。

何時可以調整此分類架構的一個範例是依所執行的調整層次而定。例如,在調整特定專案的流程時,究竟要不要使用特定的工作成果,是作為調整工作的一部分來做決定。在這種情況下,上述的分類架構就可以縮減為「必要的」,和「非必要的」。但若是別的情況, 例如在調整組織的流程時,預期必須針對個別的專案做進一步的調整, 如上述表格說明的更廣泛的分類架構就愈加重要。如需有關不同的調整層次之詳細資訊,請參閱概念:調整 RUP

分類的影響

分類為必須有應該有的所有工作成果,都必須定義它們的檢視程序、工具、範本和配置管理作法。  

對於分類為可以有的工作成果而言,這些程序的規格是選用的 - 這些決策可以保留給決定產生這些工作成果的開發人員或專案。

所有分類為不會有的工作成果都必須證明省略它們是合理的。

採用此分類架構的主要好處,是此分類架構可以清楚指出流程的自訂內容,以及哪裡有可以協商和做區域決策的選擇。

使用範例

工作成果的分類架構可以想成是用來設定工作成果的使用方式限制。

比方說,如果您決定專案要採用「分析模型」,則後續的自訂作業就可以調整這些值,來決定專案要符合下列其中一個準則:

  • 專案會有「分析模型」
  • 專案不會有「分析模型」
  • 專案會停留在現行狀態(「分析模型」是選用的)

分類架構甚至可以動態使用 - 可讓工作成果的狀態根據專案所在階段而變更。

下表顯示分析模型的不同處理方式。如何使用直欄定義工作成果在每一個階段的用法。

工作成果 如何使用 備註
初始階段 詳述 建構 轉換

分析模型

不會

不會

不會

不會

不開發任何分析模型

分析模型

可以

可以

可以

可以

一般

分析模型

可以

應該

不會

不會

這是一個發展方法,它用設計模型來取代分析模型

分析模型

必須

不會

不會

不會

這是一個發展方法,它在初始階段強制採用分析模型來協助設定專案範圍,但在詳述期間,用設計模型來取代分析模型

分析模型

應該

必須

必須

必須

這是一個正式流程,它強制採用分析模型,且保留初始階段的選用工作成果