標籤: 暫無標籤

變更請求(CR)用於記錄和追蹤缺陷、擴展請求和任何其他類型的產品變更請求。變更請求的優點在於,它們提供了決策記錄,且其評估的流程還確保了變更的影響可在整個項目範圍內得到認同和理解。

      變更請求(CR)用於記錄和追蹤缺陷、擴展請求和任何其他類型的產品變更請求。變更請求的優點在於,它們提供了決策記錄,且其評估的流程還確保了變更的影響可在整個項目範圍內得到認同和理解。

目的

變更的必要性是演進中的軟體或現有軟體系統所固有的。變更控制經理負責確定變更請求管理的過程,維護變更請求(CR),並確保以可控制的方式變更系統,以便預測變更對系統的影響。變更請求可以用於記錄和追蹤所有類型的系統變更請求,包括擴展請求和缺陷。

系統分析員可以利用擴展請求確定將來要在產品中包含的特性。為了理解涉眾需要,在收集涉眾請求時,擴展請求將用作輸入。

缺陷就是已交付工作產品中的異常情況或瑕疵。缺陷包含諸如在生命周期早期階段發現的遺漏和缺點,和/或是用於測試或操作的成熟軟體中包含的故障癥狀(瑕疵)。缺陷還包括與預期目的的偏差或任何要加以跟蹤並進行解決的問題。

缺陷的目的在於反映問題的細節,以便可以採取糾正措施、解決方法,並跟蹤發生的情況。下列人員使用變更請求:

  • 系統分析員,使用確定為擴展請求的變更請求,來確定產品的新特性,
  • 項目經理,使用變更請求分配工作,
  • 測試員,使用變更請求確定和說明在測試過程中發現的缺陷,
  • 實施員,使用變更請求分析缺陷,查找變更請求的故障或起因,
  • 測試設計員,使用變更請求計劃核實已解決的變更請求的測試,分析收集的缺陷來評測軟體和流程的質量。

管理變更請求工作流程明細

變更請求

提交變更請求的步驟

完成變更請求表單
變更請求表單是一個正式提交的工件,用於在整個項目周期內跟蹤所有的請求(包括新特性、增強請求、缺陷、變更的需求等)與相關的狀態信息。所有變更歷史記錄,包括所有狀態變更及變更的日期和原因,都將隨 CR 一起保存。進行重複複審和結束項目時都可使用此信息。在工件:變更請求中提供了一個變更請求表單的示例。

提交變更請求
一旦完成 CR 后,它應當通過適當的途徑來提交,以確保它符合已建立的變更請求管理流程。項目的任何涉眾均可提交變更請求 (CR)。通過將 CR 狀態設置為已提交,CR 被記錄到 CR 跟蹤系統中(例如 ClearQuest)並放置到 CCB 複審隊列中。

更新變更請求的步驟

檢索變更請求表單
變更請求表單是一個正式提交的工件,用於在整個項目周期內跟蹤所有的請求(包括新特性、增強請求、缺陷、變更的需求等)與相關的狀態信息。所有變更歷史記錄,包括所有狀態變更及變更的日期和原因,都將隨 CR 一起保存。進行重複複審和結束項目時都可使用此信息。在工件:變更請求中提供了一個變更請求表單的示例。

更新並重新提交變更請求
如果評估 CR 需要更多的信息(詳細信息),或者如果 CR 在流程中的某個點遭到拒絕(例如,被確認為是重複、拒絕等),那麼將通知提交者,並用新的信息來更新 CR。然後將更新過的 CR 重新提交到 CCB 複審隊列,以便對其中的新數據進行審議。

 

提要

在進行與任何已提交的變更請求有關的決策時,以下屬性非常實用:

大小

  • 必須要變更的現有工作量是多少?
  • 需要添加的多少新工作量?

備選方案

  • 是否有備選方案?

複雜程度

  • 提議的變更是否容易實現?

  • 變更可能導致哪些連鎖反應?

嚴重性

  • 不實施這個請求的會導致哪些影響?

  • 是否涉及到工作或數據丟失?
  • 是否為擴展請求?
  • 是否為次要的錯誤?

進度

  • 何時需要進行變更?
  • 是否可行?

影響

  • 進行變更的後果如何?
  • 不進行變更的後果如何?

成本

  • 進行變更的成本或節約的資金是多少?

與其他變更的關係

  • 其他變更是否可以取代此變更或使其無效嗎,或者此變更是否依賴於其他變更?

測試

  • 是否存在任何特殊的測試需求?

示例變更請求表

  1. 標識信息

  • 項目:
  • 變更請求號:
  • 變更請求類型:(問題或擴展)
  • 標題:
  • 提交日期:
  • 始發人:
  • 變更請求優先順序:
  1. 當前問題

  • 當前問題的說明:
  • 嚴重故障:
  • 障礙:
  • 擴展:
  • 新請求:
  • 觀察問題的環境:
  • 當前環境:硬體
  • 操作系統
  • 編譯器
  • 當前問題的來源:
  • 當前問題的成本影響:
  1. 提議的變更(始發人)

  • 提議的變更的說明:
  • 實施提議變更的預計成本:
  1. 提議的變更(變更複審團隊)

  • 操作:
  • 批准:
  • 不批准:
  • 延期:
  • 提議的變更的說明:
  • 影響的配置項:
  • 類別:
  • 錯誤修復:
  • 擴展:
  • 新特性:
  • 其他:
  1. 解決方案

  • 實施提議變更的預計成本:
  • 實施員:
  • 實施變更的實際時間:
  • 分析:
  • 實施:
  • 測試:
  • 文檔:
  • 影響的代碼行數:
  1. 評估

  • 測試方法:
  • 檢查
  • 分析
  • 演示
  • 測試:
  • 測試平台:
  • 測試實例:
  1. 變更複審團隊的處理

  • 批准的變更和接受的變更:
時機

通常在項目生命周期的初期使 CM 操作制度化或建立 CM 操作。因此,變更請求(CR)作為構成變更流程整體的一部分,可以隨時在項目過程中提出。

缺陷的主要來源是運行測試的結果(集成、系統和性能測試)。然而,缺陷可以隨時出現在軟體開發生命周期過程中,缺陷還可包括缺失的或不完整的用例、測試用例或文檔的確認。

職責

有關項目的任何人員都應該可以提出變更請求。然而,變更請求要得到提出變更請求角色上司的複審和批准才能成為合法請求。變更請求的最後仲裁由複審團隊或變更控制委員會(CCB)執行。

變更控制經理負責缺陷的完整性,以確保:

  • 所有確定缺陷、說明缺陷和如何發現缺陷的信息都是準確的。
  • 缺陷是唯一的,或不是再次出現的已確定缺陷。
定製

準確確定、說明和追蹤缺陷需要的實際欄位/數據取決於實施的標準、指南和變更控制系統。

© 1987 - 2001 Rational Software Corporation。版權所有。

變更請求表

      在變更管理中,變更請求(CR)是非常重要的。它貫穿變更管理整個過程,不僅是變更管理的輸入,同時也是變更管理的輸出。同時,變更請求(CR)作為配置管理的配置項內容,是配置管理和變更管理交互和協作的「橋樑」。變更請求(CR)可以由突發事件,服務級別協議等內容的變更需求開始。

      變更請求表,是變更請求(CR)的載體,是需要變更的客戶與變更管理經理的信息媒體。它主要有以下幾個部分組成。

      在變更初始階段,變更請求表需要記錄:

      · 變更請求號,如果與問題管理相關,還需要記錄相關的問題號
      · 變更請求號,如果與問題管理相關,還需要記錄相關的問題號
      · 變更描述
      · 變更原因
      · 不實施變更,可能帶來的後果

      在變更評估階段,變更請求表主要需要記錄:

      · 影響和風險評估:影響可以圍繞變更管理質量和變更管理帶來的好處等實際情況進行設置,例如,可以進行變更管理對項目總進度,項目質量,項目資源等等多個角度,進行影響和資源評估。
      · 變更優先權:在進行影響和風險評估后,可以進行變更優先權的設置。

      在變更批准階段,變更請求表主要需要記錄:

      · 變更諮詢委員會的建議和決定。變更諮詢委員會是來自於企業的各個部分,有利於綜合、客觀地評價變更對於企業其他部門的影響。
      · 批准簽名,也可以使用電子方式。
      · 批准的日期

      在變更行動計劃階段,變更請求表主要需要記錄:

      · 變更執行計劃,用於詳細說明如何進行變更,必要時候,也可以獨立於變更請求表。
      · 變更負責人
      · 變更開始執行時間和完成期限
      · 恢復計劃(Back-out planning),一旦變更管理的執行計劃沒有效果,就需要恢復計劃來穩定企業的運作,減少經營風險

      在變更執行計劃成功一段時間后,變更請求表主要需要記錄:

      · 變更核查日期(review data)
      · 核查結果。
      · 企業在連續性等方面影響 如果核查結果顯示此次變更是失敗的,則將根據現有情況,進行新的變更管理;如果核查結果認為此次變更是成功的,則變更管理結束。

      值得大家注意的是,變更管理與配置管理是緊密結合的。變更請求,作為配置項,隨著變更管理的開展,配置資料庫則不斷地進行更新。在資料庫中,變更請求還將有一個屬性隨著變更管理不斷變化,那就是變更請求的狀態,它可能是「記錄的」(logged),「結束的」,「已批准的」等等。 (COSOLU)

 

上一篇[《最後的日子》]    下一篇 [數值孔徑]

相關評論

同義詞:暫無同義詞