「变更请求」修訂間的差異檢視原始碼討論檢視歷史
(创建页面,内容为“变更请求,是指当事人申请裁决改变或消灭一定民事法律关系的仲裁请求。如请求解除合同关系、变更违约金数额等。 [1] 用…”) |
|||
行 1: | 行 1: | ||
− | |||
− | 用于记录和追踪缺陷、扩展请求和任何其他类型的产品变更请求。变更请求的优点在于,它们提供了决策记录,且其评估的流程还确保了变更的影响可在整个项目范围内得到认同和理解。 | + | 变更请求,是指当事人申请裁决改变或消灭一定民事法律关系的仲裁请求。如请求解除合同关系、变更违约金数额等。 <ref>[[左卫民.中国司法制度.中国政法大学出版社.2012]]</ref> |
+ | |||
+ | 用于记录和追踪缺陷、扩展请求和任何其他类型的产品变更请求。变更请求的优点在于,它们提供了决策记录,且其评估的流程还确保了变更的影响可在整个项目范围内得到认同和[[ 理解]] 。 | ||
==释义== | ==释义== | ||
'''概念''' | '''概念''' | ||
− | 在项目管理(project management)中,变更请求(change request)常在客户端想添加或变更某项目的商定交付时出现。这样的变更也许包括一个额外功能或者定制或扩展的服务,还有其它东西。由于变更请求超过了协议范围,它们一般意味着客户端将不得不为满足它们所需的额外资源付费。 | + | 在项目管理(project management)中,变更请求(change request)常在客户端想添加或变更某项目的商定交付时出现。这样的变更也许包括一个额外功能或者定制或扩展的服务,还有其它东西。由于变更请求超过了协议[[ 范围]] ,它们一般意味着客户端将不得不为满足它们所需的额外资源付费。 |
变更管理(change management)更具挑战的一个方面是确保所有的细节都充分说明了,且所有当事人都在有关解释内容的协议里。明确详细的文件让必须提交变更请求时的识别更容易。 | 变更管理(change management)更具挑战的一个方面是确保所有的细节都充分说明了,且所有当事人都在有关解释内容的协议里。明确详细的文件让必须提交变更请求时的识别更容易。 | ||
行 18: | 行 19: | ||
系统分析员可以利用扩展请求确定将来要在产品中包含的特性。为了理解涉众需要,在收集涉众请求时,扩展请求将用作输入。 | 系统分析员可以利用扩展请求确定将来要在产品中包含的特性。为了理解涉众需要,在收集涉众请求时,扩展请求将用作输入。 | ||
− | 缺陷就是已交付工作产品中的异常情况或瑕疵。缺陷包含诸如在生命周期早期阶段发现的遗漏和缺点,和/或是用于测试或操作的成熟软件中包含的故障症状(瑕疵)。缺陷还包括与预期目的的偏差或任何要加以跟踪并进行解决的问题。 | + | 缺陷就是已交付工作产品中的异常情况或瑕疵。缺陷包含诸如在[[ 生命周期早期阶段]] 发现的遗漏和缺点,和/或是用于测试或操作的成熟软件中包含的故障症状(瑕疵)。缺陷还包括与预期目的的偏差或任何要加以跟踪并进行解决的问题。 |
缺陷的目的在于反映问题的细节,以便可以采取纠正措施、解决方法,并跟踪发生的情况。 | 缺陷的目的在于反映问题的细节,以便可以采取纠正措施、解决方法,并跟踪发生的情况。 | ||
行 24: | 行 25: | ||
'''时机''' | '''时机''' | ||
− | 通常在项目生命周期的初期使CM 操作制度化或建立CM 操作。因此,变更请求(CR)作为构成变更流程整体的一部分,可以随时在项目过程中提出。 | + | 通常在[[ 项目生命周期]] 的初期使CM 操作制度化或建立CM 操作。因此,变更请求(CR)作为构成变更流程整体的一部分,可以随时在项目过程中提出。 |
缺陷的主要来源是运行测试的结果(集成、系统和性能测试)。然而,缺陷可以随时出现在软件开发生命周期过程中,缺陷还可包括缺失的或不完整的用例、测试用例或文档的确认。 | 缺陷的主要来源是运行测试的结果(集成、系统和性能测试)。然而,缺陷可以随时出现在软件开发生命周期过程中,缺陷还可包括缺失的或不完整的用例、测试用例或文档的确认。 | ||
行 30: | 行 31: | ||
'''职责''' | '''职责''' | ||
− | 有关项目的任何人员都应该可以提出变更请求。然而,变更请求要得到提出变更请求角色上司的复审和批准才能成为合法请求。变更请求的最后仲裁由复审团队或变更控制委员会执行。 | + | 有关项目的任何人员都应该可以提出变更请求。然而,变更请求要得到提出变更请求角色上司的复审和批准才能成为合法请求。变更请求的最后仲裁由复审团队或[[ 变更控制委员会]] 执行。 |
变更控制经理负责缺陷的完整性,以确保所有确定缺陷、说明缺陷和如何发现缺陷的信息都是准确的。缺陷是唯一的,或不是再次出现的已确定缺陷。 | 变更控制经理负责缺陷的完整性,以确保所有确定缺陷、说明缺陷和如何发现缺陷的信息都是准确的。缺陷是唯一的,或不是再次出现的已确定缺陷。 | ||
行 39: | 行 40: | ||
==变更请求表== | ==变更请求表== | ||
− | 在变更管理中,变更请求(CR)是非常重要的。它贯穿变更管理整个过程,不仅是变更管理的输入,同时也是变更管理的输出。同时,变更请求(CR)作为配置管理的配置项内容,是配置管理和变更管理交互和协作的“桥梁”。变更请求(CR)可以由突发事件,服务级别协议等内容的变更需求开始。 | + | 在变更管理中,变更请求(CR)是非常重要的。它贯穿变更管理整个过程,不仅是变更管理的输入,同时也是变更管理的输出。同时,变更请求(CR)作为配置管理的配置项内容,是配置管理和变更管理交互和协作的“桥梁”。变更请求(CR)可以由突发事件,[[ 服务级别协议]] 等内容的变更需求开始。 |
变更请求表,是变更请求(CR)的载体,是需要变更的客户与变更管理经理的信息媒体。它主要有以下几个部分组成。 | 变更请求表,是变更请求(CR)的载体,是需要变更的客户与变更管理经理的信息媒体。它主要有以下几个部分组成。 | ||
行 70: | 行 71: | ||
'''视频''' | '''视频''' | ||
+ | |||
+ | '''经常见的“变更请求”是什么?''' | ||
+ | |||
+ | [https://www.bilibili.com/video/BV1b341157gQ/哔哩哔哩] | ||
+ | |||
+ | ==参考文献== | ||
+ | {{Reflist}} |
於 2024年7月3日 (三) 22:00 的修訂
變更請求,是指當事人申請裁決改變或消滅一定民事法律關係的仲裁請求。如請求解除合同關係、變更違約金數額等。 [1]
用於記錄和追蹤缺陷、擴展請求和任何其他類型的產品變更請求。變更請求的優點在於,它們提供了決策記錄,且其評估的流程還確保了變更的影響可在整個項目範圍內得到認同和理解。
釋義
概念
在項目管理(project management)中,變更請求(change request)常在客戶端想添加或變更某項目的商定交付時出現。這樣的變更也許包括一個額外功能或者定製或擴展的服務,還有其它東西。由於變更請求超過了協議範圍,它們一般意味着客戶端將不得不為滿足它們所需的額外資源付費。
變更管理(change management)更具挑戰的一個方面是確保所有的細節都充分說明了,且所有當事人都在有關解釋內容的協議里。明確詳細的文件讓必須提交變更請求時的識別更容易。
變更請求(change request)還能從內部發起。內部的變更請求可能包括很多行為,如修復和軟、硬件升級。
目的
變更的必要性是演進中的軟件或現有軟件系統所固有的。變更控制經理負責確定變更請求管理的過程,維護變更請求(CR),並確保以可控制的方式變更系統,以便預測變更對系統的影響。變更請求可以用於記錄和追蹤所有類型的系統變更請求,包括擴展請求和缺陷。
系統分析員可以利用擴展請求確定將來要在產品中包含的特性。為了理解涉眾需要,在收集涉眾請求時,擴展請求將用作輸入。
缺陷就是已交付工作產品中的異常情況或瑕疵。缺陷包含諸如在生命周期早期階段發現的遺漏和缺點,和/或是用於測試或操作的成熟軟件中包含的故障症狀(瑕疵)。缺陷還包括與預期目的的偏差或任何要加以跟蹤並進行解決的問題。
缺陷的目的在於反映問題的細節,以便可以採取糾正措施、解決方法,並跟蹤發生的情況。
時機
通常在項目生命周期的初期使CM 操作制度化或建立CM 操作。因此,變更請求(CR)作為構成變更流程整體的一部分,可以隨時在項目過程中提出。
缺陷的主要來源是運行測試的結果(集成、系統和性能測試)。然而,缺陷可以隨時出現在軟件開發生命周期過程中,缺陷還可包括缺失的或不完整的用例、測試用例或文檔的確認。
職責
有關項目的任何人員都應該可以提出變更請求。然而,變更請求要得到提出變更請求角色上司的複審和批准才能成為合法請求。變更請求的最後仲裁由複審團隊或變更控制委員會執行。
變更控制經理負責缺陷的完整性,以確保所有確定缺陷、說明缺陷和如何發現缺陷的信息都是準確的。缺陷是唯一的,或不是再次出現的已確定缺陷。
定製
準確確定、說明和追蹤缺陷需要的實際字段/數據取決於實施的標準、指南和變更控制系統。
變更請求表
在變更管理中,變更請求(CR)是非常重要的。它貫穿變更管理整個過程,不僅是變更管理的輸入,同時也是變更管理的輸出。同時,變更請求(CR)作為配置管理的配置項內容,是配置管理和變更管理交互和協作的「橋樑」。變更請求(CR)可以由突發事件,服務級別協議等內容的變更需求開始。
變更請求表,是變更請求(CR)的載體,是需要變更的客戶與變更管理經理的信息媒體。它主要有以下幾個部分組成。
在變更初始階段,變更請求表需要記錄:
變更請求號,如果與問題管理相關,還需要記錄相關的問題號變更描述變更原因不實施變更,可能帶來的後果在變更評估階段,變更請求表主要需要記錄:影響和風險評估:影響可以圍繞變更管理質量和變更管理帶來的好處等實際情況進行設置,例如,可以進行變更管理對項目總進度,項目質量,項目資源等等多個角度,進行影響和資源評估。變更優先權:在進行影響和風險評估後,可以進行變更優先權的設置。在變更批准階段,變更請求表主要需要記錄:變更諮詢委員會的建議和決定。變更諮詢委員會是來自於企業的各個部分,有利於綜合、客觀地評價變更對於企業其他部門的影響。批准簽名,也可以使用電子審批。批准的日期在變更行動計劃階段,變更請求表主要需要記錄:變更執行計劃,用於詳細說明如何進行變更,必要時候,也可以獨立於變更請求表。變更負責人變更開始執行時間和完成期限恢復計劃(Back-out planning),一旦變更管理的執行計劃沒有效果,就需要恢復計劃來穩定企業的運作,減少經營風險在變更執行計劃成功一段時間後,變更請求表主要需要記錄:變更核查日期(review data)核查結果。企業在連續性等方面影響如果核查結果顯示此次變更是失敗的,則將根據現有情況,進行新的變更管理;如果核查結果認為此次變更是成功的,則變更管理結束。 值得大家注意的是,變更管理與配置管理是緊密結合的。變更請求,作為配置項,隨着變更管理的開展,配置數據庫則不斷地進行更新。在數據庫中,變更請求還將有一個屬性隨着變更管理不斷變化,那就是變更請求的狀態,它可能是「記錄的」(logged),「結束的」,「已批准的」等等。
變更請求承諾
變更請求承諾是指變更請求負責人所做出的承諾,承諾在計劃完成日期內完成該變更請求。如果變更請求未能按時完成,或者變更請求負責人終止承諾,那麼就是違背了 承諾。
變更請求承諾的被承諾人
變更請求的被承諾人是接受承諾的人,可以是:
1. 變更請求的監管人
2. 變更請求的請求人
3. 變更請求負責人的直接上司
變更請求承諾的審批人
承諾的審批人負責審批變更請求承諾,確保其真實性和有效性。變更請求承諾的審批人可以是:
1. 變更請求的監管人
2. 變更請求負責人的直接上司
視頻
經常見的「變更請求」是什麼?