變更要求 (CR) - 正式提出的工作成果,用來追蹤整個專案生命週期內的所有關係人要求,包括新增特性、加強功能要求、問題、變更的需求,以及相關的狀態資訊。
「變更要求」的所有變更歷程將保留下來,包括所有狀態變更及變更的日期和原因。這項資訊可用於任何複審及最終結案。
變更(或配置)控制委員會 (CCB) -
該委員會負責監督變更過程,由所有利害關係人代表組成,包括客戶、開發人員及使用者。在小型專案中,可能由一位團隊成員扮演這個角色,例如專案管理人員或軟體架構師。在 Rational Unified Process 中,以「變更控制管理人員」角色來表示。
CCB 審查會議 -
這個會議的職責是審查已提出的變更要求。會議中會對「變更要求」的內容進行初審,以決定是否為有效的要求。通過初審後,再根據優先順序、排程、資源、投入成本多寡、風險、嚴重性及小組訂定的其他任何相關準則,判斷此變更是否超出現行版次的範圍。這個會議通常每週舉行一次。如果「變更要求」的數量大幅攀升,或在發行週期即將結束之前突然湧現,則可能需要每天開會。CCB
審查會議的成員通常包括測試管理人員、研發管理人員及行銷部門的成員。成員可以「視需要而定」,要求其他人員出席會議。
變更要求提出表 - 第一次提出變更要求時會顯示這個表單。表單上只會顯示提出者必須填寫的欄位。
變更要求綜合表 - 當您審查已提出的「變更要求」時會顯示這個表單。其中含有描述「變更要求」所需的全部欄位。
下列「變更要求」流程概要說明變更需求在整個流程內的狀態和現況,以及在變更要求過程中需要通知誰。 作業:建立變更控制流程中說明「變更要求」相關的一般流程。
下列範例顯示專案在整個生命週期內可採用來管理「變更要求 (CR)」的作業範例 (按一下圖中的項目來檢視說明):
變更要求管理 (CRM) 流程作業範例說明:
作業
|
說明
|
責任
|
提出 CR
|
專案的任何關係人皆可提出「變更要求 (CR)」。「變更要求」會記錄到變更要求追蹤系統中 (例如 Rational ClearQuest),且變更要求狀態會設為已提出來排入 CCB
審查佇列中。
|
提出者
|
審查 CR
|
這項作業的功能是審查已提出的變更要求。CCB
審查會議中會對「變更要求」的內容進行初審,以決定是否為有效的要求。通過初審後,再根據優先順序、排程、資源、投入成本多寡、風險、嚴重性及小組訂定的其他任何相關準則,判斷此變更是否超出現行版次的範圍。
|
CCB
|
確認重複或拒絕
|
如果懷疑「變更要求」是重複或已拒絕的無效要求(例如,操作員錯誤、無法重現、運作方式等等),則會指派一位 CCB
委員來確認重複或已拒絕的「變更要求」,必要的話,再請提出者提供詳細的資訊。
|
CCB 委員
|
更新 CR
|
如果需要詳細資訊(進一步資訊)來評估「變更要求」,或「變更要求」在過程中遭到拒絕(例如,確認為重複、已拒絕等),則會通知提出者,提出者可以補充新的資訊來更新「變更要求」。接著,更新的「變更要求」會重新送入
CCB 審查佇列來探討新的資料。
|
提出者
|
指派和排定工作
|
當「變更要求」已開啟之後,專案管理人員會指派工作給適當的團隊成員 - 視要求類型而定(例如,加強功能要求、問題、文件變更、測試問題等)- 並在專案時程上進行任何必要的更新。
|
專案管理人員
|
執行變更
|
指派的團隊成員可以執行適當流程區段內(例如需求、分析和設計、實作)定義的作業、產生使用者支援資料,以及設計測試來執行所要求的變更。這些作業包括所有標準的審查和單元測試作業,如同標準開發流程的描述一樣。然後,「變更要求」將標示為
已解決。
|
指派的團隊成員
|
在測試版本中驗證變更
|
當指派的團隊成員(分析師、開發人員、測試人員、技術文件撰寫人員等)
已解決變更之後,變更會放入測試佇列中,等待分配給測試人員,並在產品的測試版本中驗證。
|
測試人員
|
在發行版本中驗證變更
|
當已解決的變更經過在產品的測試版本中驗證之後,「變更要求」會放入發行佇列中,等待在產品的發行版本中驗證、並產生版本注意事項等,最後結束變更要求。
|
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 資料方塊下的「變更要求」狀態。
|