变更管理 (工程)
系统工程中的变更管理流程,是一种对系统变更的请求、决定可达性、计划、实施、和评估的过程,主要目的系以一系列相互关联的因子,来支援变更的处理和可追溯性[1]。
绪论
[编辑]变更管理、变更控制、和形态管理三者间常有重叠和混淆。下列定义仍未整合这些领域:
变更管理能够带来改善受影响系统、从而满足“客户需求”的好处而被接受。但也为了它潜在混淆和不必要地复杂化变更管理而饱受批评。在某些情况下,特别在资讯科技领域,更多的资金和工作任务被投入于系统维护〈和变更管理〉,而非系统的初始创建[2]。在大型ERP系统初期实施期间的典型企业投资约占整体预算的15-20%。
- 持续变更法则:使用的系统必须变更,否则自动变得不那么有用。
- 增加复杂性法则:透过变更,系统结构变得越来越复杂,需要更多的资源来简化它。
变更管理在制造领域也非常重要,由于不断增加的全球性竞争、技术进步、和苛求的客户[4],也面临着许多的变更。许多系统在使用时往往会发生变更和演变,所以这些行业的问题在很多方面都有一定程度的经验。
注记:在下面的流程中,变更委员应负责不仅仅是接受/拒绝的决策,也要优先考虑变更请求如何批次处理的影响。
流程和交付标的
[编辑]元建模技术常用于有关变更管理流程的描述,图一为描绘在本节中所解释的过程数据图。
活动
[编辑]有六种主要活动共同组成变更管理流程,包括:识别潜在的变更〈Identify potential change〉、分析变更请求〈Analyze change request、评估变更〈Evaluate change〉、规划变更〈Plan change〉、实施变更〈Implement change〉、审查〈Review〉和变更结案〈close change〉。这些活动由四个不同的角色所执行,详列于表一。这些活动(或其下属活动)也详列于表二。
角色 | 说明 |
---|---|
客户 | 客户系遇到问题、或新功能需求而请求变更的角色,可以是个人、或组织实体,可在公司内部或外部要求实施变更。 |
专案经理 | 专案经理是变更请求相关的专案的所有者。在某些情况下,会有一位专门的变更经理,在那种情况下承担这个角色。 |
变更委员会 | 变更委员会决定是否实施一个变更请求,有时,此项任务也可由专案经理履行。 |
变更执行者 | 变更执行者系为规划、实施变更的人,对于规划细节有部分由专案经理负责,可能会有争议。 |
活动 | 下属活动 | 说明 |
---|---|---|
识别潜在的变更 | 需要新功能[5] | 客户需要新功能,并阐述需求。 |
遇到问题[5] | 客户遇到系统上的问题(例如:程式错误),并导致一件问题报告的后果。 | |
请求变更 | 客户透过建立一个变更请求,提案变更。 | |
分析变更请求 | 确定技术可行性 | 专案经理确定变更请求提案的技术可行性,导致一个“变更技术可行性”。 |
确定成本和效益 | 专案经理确定变更请求提案的成本和效益,导致一个“变更成本和效益”。这和上述的下属活动可以任何顺序完成,彼此独立。因此,建模为无序的活动。 | |
评估变更 | 基于变更请求,其“变更技术可行性”和“变更成本和效益”由变更委员会作成通过/未通过的决策。这被建模为一个单独的活动,因为它是一个重要的流程步骤,并且具有执行它的另一个角色。兰柯‧何姆斯〈Remko Helms〉建议将此建模为一个下属活动〈没有任何活动包含它〉 。 | |
规划变更 | 分析变更影响 | 在一个“变更影响分析”确定了变更范围(亦即受变更影响的其他项目),这个活动导致另一个通过/未通过的决策,或甚至构成“分析变更请求”活动的一部分,可能会有争议。 |
建立计划 | 为了实施变更而建立一个变更计划,一些流程说明〈例如:Mäkäräinen, 2000〉阐明可能“保留”变更,并以批式方式处理这些变更,这个活动可被视为一个好做法。 | |
实施变更 | 执行变更 | 变更是“被计划的”,这个活动和普及变更有很强烈的关系,因为系统的其他部分〈甚至其他系统〉有时也需要适应变更。 |
普及变更 | 由“执行变更”活动而来的变更,必须普及于受其影响的系统其他部分,因为这个与上述下属活动彼此高度依赖,而被建模为并行活动。 | |
测试变更 | 变更执行者测试其所执行的变更,是否满足了“变更请求”。如图所示,这可能导致一个和上述二个下属活动一起进行的迭代流程。 | |
更新文档 | “文档”更新,以反映实施的变更。 | |
发布变更 | 一个新的“系统发布”公开化,以反映实施的变更。 | |
审查和变更结案 | 验证变更 | 新的“系统发布”中的变更实施,由专案经理进行最后一次的验证。也许这必须在发布之前发生,但是由于其与文献资料来源和图表复杂性相互矛盾的考量,选择以这种方式进行建模,并包括这个议题。 |
变更结案 | 完成这个变更周期,亦即,结束“变更日志登记”。 |
交付标的
[编辑]除了活动,过程数据图〈如图一〉也显示了每个活动的交付标的,亦即数据。这些交付标的、或概念说明于表三,就此而论,最重要的概念为“变更请求”和“变更日志登记”。
有些概念是由作者所定义〈亦即缺乏参考文献〉,因为未能发现〈好〉定义,或者它们明显是一个活动的结果,这些概念标有星号〈*〉。概念的性质已经被排除在模型之外,因为它们大部分都是微不足道的,图表可能会很快变得太复杂。因此,一些概念〈例如:“变更请求”、“系统发布”〉借助由 Weerd 提出的版本控制方法[6],但是由于图表复杂性的限制,这也被排除在外。
概念 | 说明 |
---|---|
需求 | 一个组件〈或项目; 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)。 |
除了“变更”之外,还可以区分偏差和豁免[7]。偏差是在一个项目创建之前偏离其需求的授权(或其请求)。 豁免本质上是相同的,但是在项目的创建期间、或创建后。 这两种方法可视为简约的变更管理(亦即,对当前的问题没有真正的解决方案)。
范例
[编辑]在软件开发可找到运作中变更管理流程的好范例。用户通常会报告错误、或希望从其软件程式中获得新功能,从而导致变更请求。然后,软件产品公司将探究实施这一变更的技术和经济可行性,从而决定变更是否真的实现。如果确实如此,则必须透过使用功能点来规划变更。变更的实际执行,会导致计算机程序的创建或更改,并且在普及这个变更时,可能会导致其他程式码片段也发生变更。在初步测试结果看起来令人满意之后,可以将文档与软件一起更新并发布。最后,由专案经理验证变更,并在变更日志中登记结案。
![Figure 2: Example change request for the car industry](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Example_change_request.png/350px-Example_change_request.png)
在这里所处理的变更管理的另一个典型范围,就是制造业领域。以一辆汽车的设计和生产为例,如果在长距离驾驶后发现车辆安全气囊自动填充空气,这毫无疑问会导致顾客投诉(或者在测试阶段所期望的问题提报)。反过来,这些会产生一个变更请求(见右图二),这可能会证明变更是合理的。 尽管如此,还是要做一个最简单的成本和效益分析,然后才能批准变更请求。在分析对汽车设计和生产时程的影响之后,就可创建实施变更的计划。依据这个计划,这个变更实际上是可以实现的。随后在这个新版汽车被公开发布之前,有望得到彻底的测试。
在工业厂房
[编辑]由于复杂流程对于即使是小变更也非常敏感,所以对工业设施和流程的变更的适当管理,被认为是安全的关键。美国职业安全与卫生管理局(OSHA)制定了指导如何进行变更和记录的相关规定。主要的需求是由一个多学科小组对一个提案的变更进行彻底审查,以确保尽可能多的观点被用来最大限度地减少发生危害的机会。在这种情况下,变更管理被称为“变更的管理”(MOC),它只是流程安全管理许多要素之一,第 1910.119(l).1节。
参见
[编辑]- 变更控制
- 变更管理
- 工程变更通知、工程变更命令、变更请求
- 受控环境下的专案管理第二版〈PRINCE2〉
- 信息技术基础架构库〈ITIL〉
- 版本控制
- 发布管理
- 软件版本周期
- 软件生命周期管理
- 系统工程
- 事务跟踪管理系统
参考文献
[编辑]- ^ Crnkovic, Asklund & Persson-Dahlqvist, 2003
- ^ Dennis, Wixom & Tegarden, 2002.
- ^ Hinley 1996.
- ^ Huang & Mak, 1999.
- ^ 5.0 5.1 ,实际上,不需要“需要新功能”和“发现问题”两者同时出现才需要变革,一般只要一种即可。然后分别建立两个“起始点”(即初始状态),两者都需要变更。
- ^ Weerd 2006
- ^ Scott & Nisse, 2001.
延伸阅读
[编辑]- 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].