概念: 變更要求管理
變更要求管理是一個可確保以標準化方法和程序來提高效率並立即處理所有變更的程序,以將有關變更的意外情況所造成的衝擊降到最低。
關係
主要說明

定義

變更要求 (CR) - 正式提出的工作成果,用來追蹤整個專案生命週期內的所有關係人要求,包括新增特性、加強功能要求、問題、變更的需求,以及相關的狀態資訊。 「變更要求」的所有變更歷程將保留下來,包括所有狀態變更及變更的日期和原因。這項資訊可用於任何複審及最終結案。

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

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

變更要求提出表 - 第一次提出變更要求時會顯示這個表單。表單上只會顯示提出者必須填寫的欄位。

變更要求綜合表 - 當您審查已提出的「變更要求」時會顯示這個表單。其中含有描述「變更要求」所需的全部欄位。

下列「變更要求」流程概要說明變更需求在整個流程內的狀態和現況,以及在變更要求過程中需要通知誰。 作業:建立變更控制流程中說明「變更要求」相關的一般流程。

管理變更要求的作業範例

下列範例顯示專案在整個生命週期內可採用來管理「變更要求 (CR)」的作業範例 (按一下圖中的項目來檢視說明):

CR 已結束 測試失敗 在發行版本中驗證變更 CR 已結束 確認重複或拒絕 已提出 進一步資訊 更新 CR 已提出 拒絕 重複項目 複核者 在測試版本中驗證變更 測試失敗 執行變更 已解決 拒絕 重複項目 在測試版本中驗證變更 已指派 指派及排定工作 提出 CR 指派及排定工作 開啟 審查 CR 已延後 已提出 變更要求 變更控制委員會 提出 CR 上方標題說明的圖解。

變更要求管理 (CRM) 流程作業範例說明:

作業 說明 責任
提出 CR 專案的任何關係人皆可提出「變更要求 (CR)」。「變更要求」會記錄到變更要求追蹤系統中 (例如 Rational ClearQuest),且變更要求狀態會設為已提出來排入 CCB 審查佇列中。 提出者
審查 CR 這項作業的功能是審查已提出的變更要求。CCB 審查會議中會對「變更要求」的內容進行初審,以決定是否為有效的要求。通過初審後,再根據優先順序、排程、資源、投入成本多寡、風險、嚴重性及小組訂定的其他任何相關準則,判斷此變更是否超出現行版次的範圍。 CCB
確認重複或拒絕 如果懷疑「變更要求」是重複已拒絕的無效要求(例如,操作員錯誤、無法重現、運作方式等等),則會指派一位 CCB 委員來確認重複或已拒絕的「變更要求」,必要的話,再請提出者提供詳細的資訊。 CCB 委員
更新 CR 如果需要詳細資訊(進一步資訊)來評估「變更要求」,或「變更要求」在過程中遭到拒絕(例如,確認為重複已拒絕等),則會通知提出者,提出者可以補充新的資訊來更新「變更要求」。接著,更新的「變更要求」會重新送入 CCB 審查佇列來探討新的資料。 提出者
指派和排定工作 當「變更要求」已開啟之後,專案管理人員會指派工作給適當的團隊成員 - 視要求類型而定(例如,加強功能要求、問題、文件變更、測試問題等)- 並在專案時程上進行任何必要的更新。 專案管理人員
執行變更 指派的團隊成員可以執行適當流程區段內(例如需求、分析和設計、實作)定義的作業、產生使用者支援資料,以及設計測試來執行所要求的變更。這些作業包括所有標準的審查和單元測試作業,如同標準開發流程的描述一樣。然後,「變更要求」將標示為 已解決 指派的團隊成員
在測試版本中驗證變更 當指派的團隊成員(分析師、開發人員、測試人員、技術文件撰寫人員等) 已解決變更之後,變更會放入測試佇列中,等待分配給測試人員,並在產品的測試版本中驗證 測試人員
在發行版本中驗證變更 當已解決的變更經過在產品的測試版本中驗證之後,「變更要求」會放入發行佇列中,等待在產品的發行版本中驗證、並產生版本注意事項等,最後結束變更要求。 CCB 委員(系統整合人員)

變更要求的狀態和轉換範例

下列範例圖解顯示在整個「變更要求 (CR)」生命週期內的狀態範例及應通知的對象 [按一下圖中的項目來檢視說明]:

CCB 審查會議 進一步資訊 進一步資訊 更新 CR 更新 CR 確認重複或拒絕 在發行版本中驗證變更 已結束 進一步資訊 複核者 重複項目 拒絕 CCB 審查會議 提出 CR 已提出 測試失敗 在測試版本中驗證變更 已解決 執行變更 開啟 指派及排定工作 已指派 已延後 變更要求 上方標題說明的圖解。

變更要求管理 (CRM) 狀態範例說明:

狀態 定義 存取控制
已提出 這個狀態起因於 1) 提出新的「變更要求」、2) 更新現有的「變更要求」,或 3) 考量對新的發行週期提出已延後的變更要求。「變更要求」會放入 CCB 審查佇列中。這個動作不會指派任何擁有者。 所有使用者
已延後 「變更要求」確定為有效,但對現行版次而言「超出範圍」。在已延後狀態下的「變更要求」將保留到後續發行時再重新考慮。可指定目標發行,以表示可提出變更要求來重新進入 CCB 審查佇列的時間範圍。 管理者

專案管理人員

重複 此狀態下的「變更要求」被認為是另一個已提出之變更要求的重複項目。「變更要求」可以由 CCB 審查管理者或已指派的團隊成員來設為這個狀態。當「變更要求」進入重複狀態時,將記錄重複的「變更要求」號碼 (在 ClearQuest 的「附件」標籤上)。在提出「變更要求」之前,提出者應該先在「變更要求」資料庫中查詢是否有重複項目。這樣可以省去許多審查步驟,節省許多時間。重複「變更要求」的提出者應該加入原始「變更要求」的通知清單中,供以後解決時可以通知。 管理者

專案管理人員

QE 管理人員

開發部門

拒絕 在此狀態下的「變更要求」由 CCB 審查會議或指派的團隊成員判斷為無效的要求,或要求提出者必須提供詳細資訊。如果已指派(開啟),「變更要求」會從解決佇列中移除,並重新審查。將指定一位 CCB 授權代表來確認。除非必要,否則提出者不須對此狀態的變更要求採取任何動作,但如果需要提出者介入,「變更要求」狀態則將變成進一步資訊。「變更要求」將於 CCB 審查會議中重新審查,探討任何新的資訊。如果已確認無效,CCB 將結束「變更要求」,提出者也會接獲通知。 管理者

專案管理人員

研發管理人員

測試管理人員

進一步資訊 資料不足,無法確認拒絕重複「變更要求」的有效性。擁有者會自動成為被通知提供其他資料的提出者。 管理者
已開啟 此狀態下的「變更要求」已確定是在現行發行的「範圍內」,且正在等待解決。此變更需求已列入在下一個目標里程碑之前必須解決的名單內。預設會放在「指派佇列」中。只有會議成員才有權限將「變更要求」送入解決佇列中。如果發現優先順序 2 以上的「變更要求」,QE 或研發管理人員須立刻處理該變更要求。此時,他們可能決定召開緊急的 CCB 審查會議,或只是立即開啟「變更要求」並送入解決佇列中。 管理者

專案管理人員

研發管理人員

QE 部門

已指派 專案管理人員必須根據「變更要求」的類型,負責為已開啟的「變更要求」指派工作,並視需要來更新排程。 專案管理人員
已解決 表示這項「變更要求」已解決,現在可以準備驗證。如果提出者是 QE 部門的成員,則擁有者會自動成為提出的 QE 成員;否則就交由 QE 管理人員來手動重新指派。 管理者

專案管理人員

研發管理人員

QE 管理人員

開發部門

測試失敗 在測試版本或發行版本中測試失敗的「變更要求」,即會進入這個狀態。擁有者會自動成為解決「變更要求」的團隊成員。 管理者

QE 部門

已驗證 在此狀態下的「變更要求」已在測試版本中驗證,可以準備納入發行。 管理者

QE 部門

已結束 不必再注意「變更要求」。這是可指定給「變更要求」的最終狀態。只有 CCB 審查管理者有權限結束「變更要求」。 當「變更要求」已結束之後,提出者將收到電子郵件通知,內含「變更要求」的最終處置說明。 「變更要求」可能結束的時機包括:1) 已驗證的解決方案在發行版本中驗證之後、2) 確認拒絕狀態時,或 3) 確認重複現有的「變更要求」時。在後面的案例中,提出者將接獲重複「變更要求」的通知,並新增至該「變更要求」,供以後繼續通知 (如需詳細資訊,請參閱拒絕重複狀態的定義)。如果提出者想要爭取最後結案的權利,「變更要求」必須更新並重新提出供 CCB 審查。 管理者

「標示」狀態提供製作「變更要求」統計資料報告的基礎(存在期間、分佈及趨勢)。

下方標題說明的圖解。

CM 資料方塊下的「變更要求」狀態。