狀態模型設計的考量

此主題解釋了有效率的狀態模型在設計階段中必須解決的問題。

困境

您必須確定可轉移變更要求、繼而忽略變更要求的模型中沒有任何狀態。例如,如果模型有「已延後」狀態,且沒有指派任何人來處理此狀態的記錄,則部分變更要求可能永遠不會被發現或修正。

此問題的原因很微妙。可能有三個工程師被指派來處理「開啟」狀態的變更要求,其中元件欄位的值分別是紅色、綠色和藍色。元件欄位值是黃色或空白的變更要求則可能永遠不會被發現。

狀態數目

在具有較少狀態但每一個狀態有較多開發活動的模型與具有許多狀態但較少開發活動的模型之間,您必須考量要如何取捨。例如,如果驗證活動發生在變更要求的生命週期中的數個時間點,您可以只有一個驗證狀態,而不必將驗證活動併入其他狀態中。將這些活動組成一個狀態,更容易確保能夠適當處理驗證。但建立許多狀態會使模型變得笨重,更難維護。

重複的記錄

「重複」動作提供一種方式將一組重複記錄中的一筆記錄標示為作用中記錄,將其他記錄標示為重複;標示為重複的記錄是無法修改的。此動作可確保此變更要求的所有工作是由一筆記錄追蹤。此動作使用內建欄位;可透過將「重複相依項」和「重複基礎」控制項新增到表單中,或透過建立「重複」和「取消重複」動作,將此動作新增到綱目中。「取消重複」動作使記錄返回其被標示為重複之前的狀態。

預先定義的綱目

有各種預先定義的綱目可供使用,這些綱目納入特定的功能或配置。您可以使用它們作為開發綱目的起始點,但您必須仔細地將預先定義的綱目的功能與您的需求做比較。如需預先定義綱目的相關資訊,請參閱 Rational ClearQuest 預先定義的綱目

\

平行開發

將綱目設計成支援平行開發多個分享共用構件的產品(或產品變式)是一項挑戰。此設計必須預期並因應這些狀況:當所知的問題報告溯源至共用構件,而需要修正多個產品時該如何擷取及處理資訊,以及當需要多個建置(在可能不同的排程上)時該如何追蹤問題報告的現行狀態。

使用單一記錄來追蹤這些不同工作並不是有效率的方式。

替代方案是為每一個受影響的產品提交多筆記錄,這樣可以獨立追蹤每一個活動的狀態。如果您對第一筆輸入的記錄使用「儲存預設值」機制,對後續記錄使用「載入」,便可避免在每一個副本上重複資料輸入。(Rational ClearQuest Web 用戶端不提供此功能)。其缺點是每一筆記錄與其他記錄是隔離的;如果其他相關問題的工作未經過協調,則可能徒勞無功。

更有效的方式是使用階層式結構,其中母項記錄將問題特徵化,再使用子項記錄來追蹤每一個產品、變式或版本的問題。母項記錄的類型與子項記錄可以不同,也可以相同。有些綱目對母項和子項記錄使用相同的記錄類型,因此所有資訊都可包含在子項中(這樣可減少母項與子項之間的導覽機會)。有些綱目使用簡單的子項記錄類型來實作一種備忘,以解決其他受影響產品、變式或版本的相同問題,及追蹤其狀態。如需利用階層式結構之綱目的相關資訊,請參閱應用程式生命週期管理 (ALM) 綱目的文件。


意見