变更管理 (工程)

系统工程中的变更管理流程，是一种对系统变更的请求、决定可达性、计划、实施、和评估的过程，主要目的系以一系列相互关联的因子，来支援变更的处理和可追溯性。

## 绪论

变更管理、变更控制、和形态管理三者间常有重叠和混淆。下列定义仍未整合这些领域：

变更管理能够带来改善受影响系统、从而满足“客户需求”的好处而被接受。但也为了它潜在混淆和不必要地复杂化变更管理而饱受批评。在某些情况下，特别在资讯科技领域，更多的资金和工作任务被投入于系统维护〈和变更管理〉，而非系统的初始创建。在大型ERP系统初期实施期间的典型企业投资约占整体预算的15-20%。

同样的道理，Hinley描述二种雷曼软件演化法则：

- 持续变更法则：使用的系统必须变更，否则自动变得不那么有用。
- 增加复杂性法则：透过变更，系统结构变得越来越复杂，需要更多的资源来简化它。

变更管理在制造领域也非常重要，由于不断增加的全球性竞争、技术进步、和苛求的客户，也面临着许多的变更。许多系统在使用时往往会发生变更和演变，所以这些行业的问题在很多方面都有一定程度的经验。

注记：在下面的流程中，变更委员应负责不仅仅是接受/拒绝的决策，也要优先考虑变更请求如何批次处理的影响。

## 流程和交付标的

元建模技术常用于有关变更管理流程的描述，图一为描绘在本节中所解释的过程数据图。

<image>

### 活动

有六种主要活动共同组成变更管理流程，包括：识别潜在的变更〈Identify potential change〉、分析变更请求〈Analyze change request、评估变更〈Evaluate change〉、规划变更〈Plan change〉、实施变更〈Implement change〉、审查〈Review〉和变更结案〈close change〉。这些活动由四个不同的角色所执行，详列于表一。这些活动(或其下属活动)也详列于表二。

角色｜说明

客户｜客户系遇到问题、或新功能需求而请求变更的角色，可以是个人、或组织实体，可在公司内部或外部要求实施变更。

专案经理｜专案经理是变更请求相关的专案的所有者。在某些情况下，会有一位专门的变更经理，在那种情况下承担这个角色。

变更委员会｜变更委员会决定是否实施一个变更请求，有时，此项任务也可由专案经理履行。

变更执行者｜变更执行者系为规划、实施变更的人，对于规划细节有部分由专案经理负责，可能会有争议。

活动｜下属活动｜说明

识别潜在的变更｜需要新功能｜客户需要新功能，并阐述需求。

遇到问题｜客户遇到系统上的问题(例如：程式错误)，并导致一件问题报告的后果。

请求变更｜客户透过建立一个变更请求，提案变更。

分析变更请求｜确定技术可行性｜专案经理确定变更请求提案的技术可行性，导致一个“变更技术可行性”。

确定成本和效益｜专案经理确定变更请求提案的成本和效益，导致一个“变更成本和效益”。这和上述的下属活动可以任何顺序完成，彼此独立。因此，建模为无序的活动。

评估变更｜基于变更请求，其“变更技术可行性”和“变更成本和效益”由变更委员会作成通过/未通过的决策。这被建模为一个单独的活动，因为它是一个重要的流程步骤，并且具有执行它的另一个角色。兰柯‧何姆斯〈Remko Helms〉建议将此建模为一个下属活动〈没有任何活动包含它〉。

规划变更｜分析变更影响｜在一个“变更影响分析”确定了变更范围(亦即受变更影响的其他项目)，这个活动导致另一个通过/未通过的决策，或甚至构成“分析变更请求”活动的一部分，可能会有争议。

建立计划｜为了实施变更而建立一个变更计划，一些流程说明〈例如：Mäkäräinen, 2000〉阐明可能“保留”变更，并以批式方式处理这些变更，这个活动可被视为一个好做法。

实施变更｜执行变更｜变更是“被计划的”，这个活动和普及变更有很强烈的关系，因为系统的其他部分〈甚至其他系统〉有时也需要适应变更。

普及变更｜由“执行变更”活动而来的变更，必须普及于受其影响的系统其他部分，因为这个与上述下属活动彼此高度依赖，而被建模为并行活动。

测试变更｜变更执行者测试其所执行的变更，是否满足了“变更请求”。如图所示，这可能导致一个和上述二个下属活动一起进行的迭代流程。

更新文档｜“文档”更新，以反映实施的变更。

发布变更｜一个新的“系统发布”公开化，以反映实施的变更。

审查和变更结案｜验证变更｜新的“系统发布”中的变更实施，由专案经理进行最后一次的验证。也许这必须在发布之前发生，但是由于其与文献资料来源和图表复杂性相互矛盾的考量，选择以这种方式进行建模，并包括这个议题。

变更结案｜完成这个变更周期，亦即，结束“变更日志登记”。

### 交付标的

除了活动，过程数据图〈如图一〉也显示了每个活动的交付标的，亦即数据。这些交付标的、或概念说明于表三，就此而论，最重要的概念为“变更请求”和“变更日志登记”。

有些概念是由作者所定义〈亦即缺乏参考文献〉，因为未能发现〈好〉定义，或者它们明显是一个活动的结果，这些概念标有星号〈*〉。概念的性质已经被排除在模型之外，因为它们大部分都是微不足道的，图表可能会很快变得太复杂。因此，一些概念〈例如：“变更请求”、“系统发布”〉借助由 Weerd 提出的版本控制方法，但是由于图表复杂性的限制，这也被排除在外。

概念｜说明

需求｜一个组件〈或项目; NASA, 2005〉的必需功能。

问题报告｜说明第一级服务台雇员无法解决的问题的文件，包括：日期、报告问题者的连络资讯、问题的地点和说明、采取的行动和处置 ... 等项目，但是这在图中并无描述〈Dennis, et al., 2002〉。

变更请求｜说明请求的变更、以及为何它很重要的文件，可源自“问题报告”、系统强化、其他专案、底层系统的变更、和高层管理者，这里总结为“需求”〈Dennis, et al., 2002〉。重要的属性：“通过/未通过决策”，亦即，要执行变更？或不要执行变更？

变更日志登记、｜在所有变更〈例如：为了一个专案〉的集合中的不同输入，是由“变更请求”、“变更技术可行性”、“变更成本和效益”、“变更影响分析”、“变更计划”、“测试报告”、“变更验证”所组成。如果这个过程被提前终止〈亦即，如果变更没有执行〉，并非所有这些项目都必须包含在内。

变更技术可行性｜这个概念表明是否“可靠的硬件和软件、技术资源能够满足提案系统的需要〈亦即，变更请求〉、并在需要的时间内可借由组织获得、或开发”〈Vogl, 2004〉。

变更成本和效益｜实施所需的预期工作、和实施变更所带来的优势（如节约成本，增加收入），也被称为经济可行性〈Vogl, 2004〉。

变更影响分析｜评估变更的程度〈Rajlich, 1999〉。

变更计划｜“为实现某些目标、或实现某种目的（亦即，变更）而采取的计划、方法、或设计”（Georgetown University, n.d.）, 在这种情况下就是变更。

项目｜“用于表示任何产品的非特定术语，包括系统、子系统、组件、下属组件、部件、套件、附属件、计算机程序、电脑软件或部件”（Rigby, 2003），具有〈重叠的〉子类型：“新增项目”和“变更项目”。

新增项目、｜不言自明：一个新创建的“项目”；“项目”的子类型。

变更项目、｜不言自明：一个已经存在，但已被改变的“项目”；“项目”的子类型。

测试报告｜“说明对（受变更影响的〉系统或组件进行测试的实施和结果的文件”（IEEE, 1991〉。

文档｜根据宾夕法尼亚州立大学图书馆（2004）的定义，文件是“附有其他材料（通常非书本）的印刷材料，并说明、给出使用说明、或以其他功能作为主要材料的指南”。在这方面，它也可以是数位材料、甚至是训练教材，只要和系统（或部分的系统〉关连。

系统发布｜“出售或公开展示的商品”（Princeton University, 2003），由一个或多个“项目”、和随附的文档所组成。

变更验证｜确认变更实施的结果，是否满足早先所建立的要求（Rigby, 2003）。

除了“变更”之外，还可以区分偏差和豁免。偏差是在一个项目创建之前偏离其需求的授权（或其请求）。豁免本质上是相同的，但是在项目的创建期间、或创建后。这两种方法可视为简约的变更管理（亦即，对当前的问题没有真正的解决方案）。

### 范例

在软件开发可找到运作中变更管理流程的好范例。用户通常会报告错误、或希望从其软件程式中获得新功能，从而导致变更请求。然后，软件产品公司将探究实施这一变更的技术和经济可行性，从而决定变更是否真的实现。如果确实如此，则必须透过使用功能点来规划变更。变更的实际执行，会导致计算机程序的创建或更改，并且在普及这个变更时，可能会导致其他程式码片段也发生变更。在初步测试结果看起来令人满意之后，可以将文档与软件一起更新并发布。最后，由专案经理验证变更，并在变更日志中登记结案。

<image>

在这里所处理的变更管理的另一个典型范围，就是制造业领域。以一辆汽车的设计和生产为例，如果在长距离驾驶后发现车辆安全气囊自动填充空气，这毫无疑问会导致顾客投诉（或者在测试阶段所期望的问题提报）。反过来，这些会产生一个变更请求（见右图二），这可能会证明变更是合理的。尽管如此，还是要做一个最简单的成本和效益分析，然后才能批准变更请求。在分析对汽车设计和生产时程的影响之后，就可创建实施变更的计划。依据这个计划，这个变更实际上是可以实现的。随后在这个新版汽车被公开发布之前，有望得到彻底的测试。

## 在工业厂房

由于复杂流程对于即使是小变更也非常敏感，所以对工业设施和流程的变更的适当管理，被认为是安全的关键。美国职业安全与卫生管理局（OSHA）制定了指导如何进行变更和记录的相关规定。主要的需求是由一个多学科小组对一个提案的变更进行彻底审查，以确保尽可能多的观点被用来最大限度地减少发生危害的机会。在这种情况下，变更管理被称为“变更的管理”（MOC），它只是流程安全管理许多要素之一，第 1910.119(l).1节。

## 参见

- 变更控制
- 变更管理
- 工程变更通知、工程变更命令、变更请求
- 受控环境下的专案管理第二版〈PRINCE2〉
- 信息技术基础架构库〈ITIL〉
- 版本控制
- 发布管理
- 软件版本周期
- 软件生命周期管理
- 系统工程
- 事务跟踪管理系统

## 延伸阅读

- Crnković I., Asklund, U. & Persson-Dahlqvist, A. (2003). Implementing and Integrating Product Data Management and Software Configuration Management. London: Artech House.
- Dennis, A., Wixom, B.H. & Tegarden, D. (2002). System Analysis & Design: An Object-Oriented Approach with UML. Hoboken, New York: John Wiley & Sons, Inc.
- Georgetown University (n.d.). Data Warehouse: Glossary. Retrieved April 13, 2006 from: https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html.
- Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730.
- Huang, G.H. & Mak, K.L. (1999). Current practices of engineering change management in UK manufacturing industries. International Journal of Operations & Production Management, 19(1), 21-37.
- IEEE (1991). Standard Glossary of Software Engineering Terminology (ANSI). The Institute of Electrical and Electronics Engineers Inc. Retrieved April 13, 2006 from: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6.
- Mäkäräinen, M. (2000). Software change management processes in the development of embedded software. PhD dissertation. Espoo: VTT Publications. Available online: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf.
- NASA (2005). NASA IV&V Facility Metrics Data Program - Glossary and Definitions. Retrieved March 4, 2006 from: https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html.
- Pennsylvania State University Libraries (2004). CCL Manual: Glossary of Terms and Acronyms. Retrieved April 13, 2006 from: https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/ cataloging/ccl/glossary.htm.
- Princeton University (2003). WordNet 2.0. Retrieved April 13, 2006 from: http://dictionary.reference.com/search?q=release.
- Rajlich, V. (1999). Software Change and Evolution. In Pavelka, J., Tel, G. & Bartošek, M. (Eds.), SOFSEM'99, Lecture Notes in Computer Science 1725, 189-202.
- Rigby, K. (2003). Managing Standards: Glossary of Terms. Retrieved April 1, 2006 from: https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm.
- Scott, J.A. & Nisse, D. (2001). Software Configuration Management, Guide to Software Engineering Body of Knowledge, Chapter 7, IEEE Computer Society Press.
- Vogl, G. (2004). Management Information Systems: Glossary of Terms. Retrieved April 13, 2006 from Uganda Martyrs University website: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm.
- Weerd, I. van de (2006). Meta-modeling Technique: Draft for the course Method Engineering 05/06. Retrieved March 1, 2006 from: https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions for the process-data diagram.pdf restricted access.