作業: 審查變更要求
這項作業定義如何執行變更要求分類。
規範: 配置 變更管理
目的
  • 這項作業的用途是判斷應該接受變更要求 (CR) 或標示拒絕變更要求。對於所接受的 CR,這項作業會評量優先順序、工作、排程等,以判斷變更是否在現行版本的範圍內。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
步驟
排定 CCB 審查會議

變更(或配置)控制委員會 (CCB) 是負責監督變更過程的委員會,由所有利益關係人代表組成,其中包括客戶、開發人員及使用者。在小型專案中,可能由一個人來扮演這個角色,例如專案管理人員或軟體架構師。在 Rational Unified Process 中,這是用變更控制管理人員角色來表示。

這個會議的功能是審查已提出的變更要求。會議中會對 CR 的內容進行初審,以決定是否為有效要求。通過初審後,再根據優先順序、排程、資源、工作等級、風險、嚴重性及小組訂定的其他任何相關準則,判斷這項變更是否超出現行版本的範圍。這個會議通常每週舉行一次。如果 CR 的數量大幅攀升,或在發行週期即將結束之前突然湧現,則可能需要每天開會。CCB 審查會議的成員通常包括測試管理人員、研發管理人員及行銷部門的成員。成員可以「視需要而定」,要求其他人員出席會議。

擷取變更要求以進行審查

變更要求表單是正式提出且用來追蹤所有要求的工作成果,這些要求包括新特性、加強功能要求、問題、變更的需求等。其中包括在整個專案生命週期裡的相關狀態資訊。所有變更歷程都會隨著 CR 保留下來,這包括所有狀態變更,以及變更的日期和原因。這項資訊可用於任何複審及最終結案。工作成果:變更要求有提供「變更要求表單」範例。

審查提出的變更要求

這項作業的功能是審查已提出的變更要求。這個狀態起因於 1) 提出新的 CR、2) 更新現有的 CR,或 3) 針對新的發行週期考量已延後的 CR。CR 會放在 CCB 審查佇列中。這個動作不會指派任何擁有者。

CCB 審查會議中會對 CR 的內容進行初審,以決定是否為有效的要求。通過初審後,再根據優先順序、排程、資源、工作等級、風險、嚴重性及小組訂定的其他任何相關準則,判斷這項變更是否超出現行版本的範圍。

如果 CR 確定為有效,但對現行版本而言「超出範圍」,它就會進入已延後狀態,它將保留下來,等未來的版本再重新考量它。您可以指派一個目標版本,以指示可以提出 CR 來重新進入 CCB 審查佇列的時間範圍。

如果您相信某 CR 與另一個已提出的 CR 重複,您應該將它指派給 CCB 審查管理或被指派解決它的小組成員。當 CR 進入重複狀態時,會將重複的 CR 號碼記錄下來(在 ClearQuest 的「附件」標籤上)。在提出 CR 之前,提出者應該先在 CR 資料庫中查詢是否有重複的 CR。這樣可以省去許多審查步驟,節省許多時間。重複 CR 的提出者應該加入原始 CR 的通知清單中,以便日後提供解決的通知。

有時 CCB 審查會議或指派的小組成員會判斷 CR 是無效要求,或要求提出者必須提供詳細資訊。如果已獲指派(已開啟),便會從解決佇列中移除這項 CR,並重新審查。這時會指派一位 CCB 授權代表來進行確認。除非必要,否則提出者不須對此狀態的變更需求採取任何動作,但如果需要提出者介入,CR 狀態則將變成進一步資訊。CCB 審查會議會重新審查這個 CR,探討任何新的資訊。如果已確認無效,CCB 將結束這個 CR,提出者也會接獲通知。

當 CR 已確定是在現行版本的「範圍內」,它會被指派已開啟狀態,並等待解決。這時它已列入下一個目標里程碑之前必須解決的名單內。它會被定義為在「指派佇列」中。只有會議成員才有權將 CR 送入解決佇列中。如果發現優先順序 2 以上的 CR,QE 或專案管理人員須立刻處理該變更需求。這時,他們可決定召開緊急的 CCB 審查會議,或只是立即開啟 CR 並送入解決佇列中。

專案管理人員必須負責根據 CR 的類型,為已開啟的 CR 指派工作,並依照需要來更新排程。

變更要求管理中會顯示變更要求可能經歷的一般狀態。



詳細資訊