記錄設定

您可以針對記錄類型使用全系統設定,以協助管理、分類安全原則,並將安全原則套用至工作程序。
下列類型的全系統設定可同時用於管理專案和工作:

ALMSecurityPolicy 記錄與「種類」相關聯,也與「專案」相關聯,因為所建立的「專案」參照該「種類」。對於執行元件開發的團隊,可以有幾個「元件」(各有其專屬的「種類」和「版本」)作為一個以上「供應項目」的一部分。在此情況下,「種類」與 SecurityPolicy 之間的一對一關係,可能會造成部分記錄無法讓需要查看它們的人員看見。為防止發生可見性問題,SecurityPolicy 應包括一個大型 ClearQuest 使用者群組作為其 ratl_context_groups 參照,或是由 SecurityPolicy 參照,並會供處理元件的所有開發團隊共用的每一個元件應具有一個使用者群組。維護一組較小群組而不使用一個大型群組(或將 SecurityPolicy 設為「每個人」群組),並且依元件結構組織群組及 SecurityPolicy 記錄,也會得到效能方面的優點。

元件開發範例

新開發工作的每一個版本化片段可以是一個「專案」,其「種類」指定元件,其「版本」指定該「種類」的版本。

客戶會在開發團隊所產生的主要產品中發現問題。本「產品」(稱為「供應項目」)包括數個「元件」,每一個元件均由個別團隊開發。當客戶看到問題時,他們會認為該「供應項目」有問題,而不是「供應項目」的「元件」有問題。當團隊組長針對該「供應項目」的「要求」遵循分類程序並檢閱該「要求」時,他們會注意到:
  • 問題是在「供應項目」內含的「元件」中,並需要在該元件而不是在「供應項目」進行修正,「供應項目」可能只是一個「元件」集合,除了它所包括的「元件」內容之外,並沒有任何它自己的程式碼
  • 在「元件」修正之後,「供應項目」即需要加入修正後的新版本「元件」,而該「供應項目」的新版本至少需要提供給發現問題的客戶,或者是提供給所有其他客戶。
分類團隊會建立兩個 ALMTask 記錄,其與針對「專案」給定的「種類」和「版本」(例如,種類 ='OfferingA' 且版本 = '1.0')輸入的 ALMRequest 相關聯:
  • 專案種類 ='OfferingA' 且版本 = '1.1' 的 ALMTask
  • 專案種類 ='ComponentZ' 且版本 = '3.4' 的 ALMTask
分類團隊先檢閱了「專案種類 ='OfferingA' 且版本 = '1.0'」的 ALMBaseline 記錄,因為這些值是 ALMRequest 所識別為 FoundInProject 的值,而且他們會看到列在 ALMBaseline ComposedOfBaselines 欄位中的 'ComponentZ' 的「版本」是「版本 = '3.3'」。

會建立 'ComponentZ' 的 ALMTask 活動,並且開發、記載及測試解決方案。當建立「專案種類 = 'ComponentZ' 且版本 = '3.4'」的實際基準線,並建立「專案種類 = 'OfferingA' 且版本 = '1.1'」的第二個 ALMBaseline 時會建立 ALMBaseline 記錄,且該 ALMBaseline 記錄有一個 ComposedOfBaselines 值(另一個基準線記錄),其內容為「專案種類 = 'ComponentZ' 且版本 = '3.4'」。

針對其「專案種類 = 'OfferingA' 且版本 = '1.1'」的 ALMBaseline 建立 BTBuild。測試人員可以看到 BTBuild 顯示在「建置」直欄中,而 'Dev' 活動的 Composite.Build 直欄顯示在該「作業」的「活動表單」控制項(「其專案種類 = 'OfferingA' 且版本 = '1.1'」)中。他們至少可以看到有從複合基準線所產生「建置」的 ID,且在查詢的結果集內可以看到該「建置」的名稱。「元件」測試人員和「供應項目」測試人員可以同時看到有一個根據「複合基準線」的「建置」。

在「複合基準線」記錄,「元件」列在 ComposedOfBaselines 欄位中。


意見