配置管理与变更管理精选(九篇)

前言：一篇好文章的诞生，需要你不断地搜集资料、整理思路，本站小编为你收集了丰富的配置管理与变更管理主题范文，仅供参考，欢迎阅读并收藏。

第1篇：配置管理与变更管理范文

关键词 软件配置管理；软件生命周期；KCFlow

DOI DOI： 10.11907/rjdk.162381

中图分类号： TP301

文献标识码： A 文章编号 文章编号： 16727800（2017）002002603

0 引言

随着软件规模的日益增大，软件复杂度逐步提高，软件产品处于不断更新变化中，为了确保整个软件项目生命周期内产品的完整性、一致性和可追踪性，必须对软件进行配置管理。

软件配置管理（SCM，Software Configuration Management）指标识和确定软件系统配置项的过程，在软件系统的整个生命周期内控制这些项的投放和更改，记录并报告配置的状态和更改要求，验证配置项的完整性和正确性[1]，通常包括配置标识、配置控制、配置状态记录、配置审核等活动。软件配置管理是整个软件开发生命周期中一个非常核心的管理过程，贯穿了从需求分析、架构设计、项目管理、开发、集成及测试的全过程，可以有效管理配置项版本，记录配置项开发过程，保证软件质量，提高软件重用率。

在软件开发这个庞大而复杂的过程中，涉及到各方面人员，产生许许多多产品。由于规程过于繁琐，手工方法实施软件配置管理是难以想象也是不可能的，因此，有效的软件配置管理需要结合工具来实现。使用软件配置管理工具，可以确保软件项目中基线和配置项随时保持条理清晰，迅速找到工作产品，保证工作产品的版本、内容不会出错，提高管理水平。

1 工具介绍

软件配置管理工具KCFlow采用C/S架构，以软件配置管理项的版本管理为核心，具有软件配置策划管理、变更控制、产品一致性管理、软件问题追踪管理、软件配置审计管理等功能，实现了对配置管理工作的全流程、全方位支持。

KCFlow具有以下特点：C/S软件架构使项目中的各类人员可以在工具提供的平台上分布式工作，确保各项工作有序、规范地实施；具有策划配置项标识功能；支持独立的配置项，单独策划入库、出库和更动审批，能够自动按照策划结果实施入库、出库和更动控制；支持基线的多版本管理功能；支持用户自定义软件问题类别、问题级别、更动类别等，以适应不同的使用需求；支持多个软件开发人员在线提交软件入库申请、出库申请、更动申请等。

2 软件配置管理

软件配置管理是CMM重要的过程域，本文结合配置管理工具给出配置管理实施方法。

项目启动后，配置管理组根据项目情况策划配置管理活动并建立配置管理系统。首先制定配置管理计划，根据计划建立配置管理系统，通过版本控制、变更控制、基线管理和配置审核等方法，对配置管理系统中的工作产品实施控制和监督。软件配置管理流程如图1所示。

图1 软件配置管理流程

2.1 配置管理计划

经过批准的软件配置管理计划是实施软件配置管理活动的依据[2]。在进行配置管理前应根据项目的具体情况制定软件配置管理计划，内容包括：

（1）确定配置管理机构和人员职责，审批流程。组织机构主要有软件配置控制委员会、软件配置管理组。软件配置控制委员会负责出入库控制、变更及基线的建立和；软件配置管理组负责相关制度的建立和维护、工具的推广、培训和技术支持、配置管理审核等。

（2）描述具体配置管理活动，包括标识要纳入配置管理的配置项，规定提交时间、确定项目研制各阶段的基线、基线建立的时机和配置管理项等。配置项根据控制力度分为基线配置项和非基线配置项两类。基线配置项一般包括软件研制任务书、软件需求规格说明、设计说明、设计文档、测试文档、代码、用户手册等；非基线配置项包括计划类文档、开发环境、会议纪要等。标识配置项为每个软件配置项赋予唯一的标识符。在软件开发生存周期中，软件配置项标识应包括文档标识、程序标识和数据标识等[3]。

（3）确定更动申请流程及更动申请方法。

（4）描述配置管理报告内容、报告时机、报告人和通告对象等。

（5）制定配置审核时机、审核内容及审核问题的解决方法，软件配置管理所使用的工具、技术和方法。

使用KCFlow配置管理平台，制定配置管理计划，并依据配置管理计划实时自动化约束配置管理活动，客观记录配置管理活动。KCFlow可对配置管理计划中的机构组织、基线、基线下包含的配置管理项、工作产品标识、问题类型、问题来源、更动流程、修改类别、项目基本信息等进行配置策划。一般基线策划有3条：功能基线、分配基线和产品基线。配置项标识应按照相关的配置项标识规范进行，一般文档、程序标识采用以下格式表示：文件名称英文缩写 V主版本号.次版本号；问题类型可分为程序、文档、数据库等；问题来源有计划、方案、设计、编码、数据库、测试、使用和维护等。

2.2 配置管理系统

配置管理计划经过评审后，由配置管理员依照配置管理计划建立开发库、受控库和产品库，对库结构进行策划，明确基线内容，定期备份配置管理库，为相关人员分配权限并发送用户帐号信息单给相关人员。

开发库、受控库和产品库应独立管理。开发库存放开发过程中需保留的各种信息；受控库存放已通过评审且作为阶段性产品的软件配置项；产品库存放已定型（鉴定）供交付生产、检验验收的软件配置项。在KCFlow中创建受控库一般包括功能基线、分配基线、产品基线及非基线配置项。功能基线包含软件研制任务书等文档；分配基线包含软件需求规格说明、接口需求规格说明等文档；产品基线包含软件设计说明、接口设计说明、软件测试说明、软件测试报告、固件保障手册、源代码、目标码、软件版本说明、软件研制总结报告、软件配置管理报告、软件质量保证报告等；非基线配置项主要包含计划类工作产品。

2.3 配置控制

配置控制是配置管理的组成部分，包含评估、协调、批准/拒绝、配置项的变更[4]。配置库建好后，配置管理员按照配置管理计划进行日常的配置管理活动，主要包括版本控制、变更控制、基线管理等。

2.3.1 基线管理

基线是软件生命周期中各开发阶段的一个特定点，它的作用是把开发各阶段工作明确划分，使本来连续的工作在这些点上断开，以便于检查和肯定阶段成果[5]，是进一步开发的基础。

在软件生命周期中主要有3种基线：功能基线、分配基线和产品基线。功能基线是开展软件研制工作的依据，一般是在软件研制任务书评审并纳入受控管理后建立；分配基线在软件需求规格说明评审并纳入受控管理后建立；产品基线在产品后建立。

基线包含的配置项全部入库后才可建立基线，配置管理员提交《基线建立和申请单》，通过软件配置控制委员会审批通过授权后，方可建立和基线。基线后，配置管理员要把基线的结果通告给相关人员，通告内容包括基线名称和标识、所包含的配置项及配置项版本等信息。

对基线的变更需要通过正式的变更流程来完成。首先提出变更请求，然后进行变更评估，变更批准后再进行变更。变更评估包括：软件变更分类、技术影响分析、接口影响分析、进度及预算影响分析。

2.3.2 变更控制

对已进入受控库和产品库的任一软件配置管理项的更改，要履行规定的申请和审批手续。配置管理工具KCFlow提供了两种更动流程供选择，一般采用的更动流程是：填写问题报告、提出更动申请、更动出库、实施和验证更动和更动入库，具体更动流程如图2所示。

（1）发现问题，并填写《问题报告单》。变更人发现问题后首先填写问题报告单，在问题报告单中详细描述问题，说明问题来源并对问题进行分析，确定问题类型。

（2）提出更动申请，填写《更动申请单》。《更动申请单》要详细填写问题来源、问题类别、问题级别、更动类型和修改类别等，描述更动方案、影响域分析及验证办法，待更动申请批准后方可进行更动。

（3）更动出库。更动申请通过审批后，更改实施人填写《更动出库单》，审批通过后，检出待更改的配置项准备实施更动。待更改配置项出库后，处于待更动状态，禁止其他人使用。

图2 更动流程

（4）实施和验证更动。更动出库后可由变更实施人对待更动配置项实施更改，并请同行专家验证变更结果。验证结果合格后将变更后的配置项更动入库，如果验证没通过，则重新实施更改。

（5）更动入库。更动完成并通过验证后，变更实施人填写《更动入库申请单》。审批通过后，将更动后的配置项更动入库。

2.3.3 版本控制

版本控制是全面实施软件配置管理的基A，其目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，保证产品的可追溯性[6]。对配置项在初次完成时确定初始版本，在每次更改后确定新的版本。版本号由主版本号和次版本号组成，当发生更改时，若变动较大，次版本号加0.1，若变动较小，次版本号加0.01。

2.4 配置管理记录和报告

配置状态记录和报告通常称为配置状态纪实。配置状态记录主要对配置管理活动进行记录和报告，一般包括以下内容：配置项纪录（名称、标识和版本）、变更纪录、基线纪录、出入库纪录、审核纪录、备份记录和测量信息等。

配置管理工具KCFlow可以根据配置库中的内容生成配置状态报告，确保配置管理报告和配置管理库的客观一致性。在项目每个阶段结束时，配置管理员从KCFlow导出该阶段的配置状态报告，总结该阶段的配置管理活动，统计配置管理相关数据，并将配置状态报告发送给相关人员。

2.5 配置审核

配置审核是一种软件验证方法，其目的是检查软件产品和过程是否符合标准和规程，是变更控制的补充。配置审核包括功能配置审核、物理配置审核和管理配置审核。

功能配置审核一般由项目经理审核配置项的实际功能特征是否达到功能基线文档中所规定的要求。物理配置审核是通过对配置项的检测，鉴定文、图、物的一致性，保证软件更改的完整性。配置管理组定期（每季度）进行配置管理审核。配置管理审核主要是对配置管理过程进行审核，确认配置管理记录和配置项是否完整、一致和准确。审核过程中，相关人员按照审核内容形成《配置审核检查单》，对不符合项进行记录和处理。

KCFlow具有灵活的配置审核功能，能够策划适合本单位的软件配置管理审核准则。每次入库时，相关人员进行物理审核，在基线建立及变更时进行功能审核。

图3 配置审核策划

3 结语

软件配置管理贯穿整个软件生命周期，在软件开发过程中采用有效的工具进行配置管理，能够弥补人工管理出现的纰漏，规范开发流程，保证软件产品质量，减少软件缺陷，缩短软件开发周期，降低软件维护成本。本文结合配置管理工具，对软件配置管理流程及实施方法进行了研究。为提高软件开发的效率与质量，今后的工作中应结合项目实际情况及本单位的配置管理相关规定，对配置管理工具的适应性进行研究，以满足各种软件开发要求。

参考文献：

[1] 石柱.软件工程标准手册[M].北京：中国标准出版社，2007.

[2] 何新贵，石柱，王纬，等.GJB5000军用软件能力成熟度模型实施指南[M].北京：国防工业出版社，2004.

[3] 王忠贵，刘姝.航天型号软件工程方法与技术[M].北京：中国宇航出版社，2015.

[4] 董越.未雨绸缪理解软件配置管理[M].北京：电子工业出版社，2012.

第2篇：配置管理与变更管理范文

【关键词】配置项 基线配置 标识配置 控制

随着软件技术的发展，组织提升软件研制能力显得越来越重要并且迫切。而军用软件，尤其是嵌入式软件的开发往往伴随硬件设备的研制而开展，其研制周期长，需求变更频繁，参与人员多，可能出现软件版本丢失、多重S护、开发过程混乱等问题。GJB5000A-2008《军用软件研制能力成熟度模型》中明确配置管理的目的和专用实践，通过配置管理可以较好的解决以上问题。

1 组织机构、角色和职责

组织应成立项目的配置控制委员会（以下简称CCB）。CCB一般由来自不同领域的项目利益相关方的代表组成，而且有能力在管理上作出承诺，对提出的配置项的变更进行评价、批准或不批准。其中，配置管员作为配置管理活动的直接责任人负责制定配置管理计划、配置状态报告、实施配置审核。

2 基于GJB5000A的配置管理活动

2.1 建立基线

2.1.1 标识配置项

配置项作为配置管理的对象，在项目策时进行识别，并对其赋予唯一标识号，形成配置项列表。包括：

（1）识别软件配置项：软件配置项主要包括为本项目开发的软件配置项以及重用的软件配置项、订购方提供的软件配置项、分承制方开发的软件配置项、采购的软件配置项等。其中，软件配置项的划分主要从下列因素进行权衡：软件功能、规模、重用计划、关键性、接口考虑等。

（2）识别配置文件：配置文件指定义软件配置项的功能特性或物理特性的文件，或从这些内容发展而来的关于其验证、使用、保障要求的技术文件。一般包括：需求文档、设计文档、测试文档、用户文档等。

2.1.2 建立一个配置管理系统

要使配置项在软件生命周期中受控，应建立有统一的存储介质、规程和访问方式的配置管理系统：

（1）建立配置库。

开发库：存放配置项文件的集合。是一个动态的库，相当于开发人员的工作区，存放在该库中的配置文件只需要开发者进行版本控制即可。

受控库：存放已通过测试或评审且作为阶段性产品的软件配置项的集合。配置项的入库、出库、更改均需通过访问及变更控制规程进行。

产品库：存放已定型（鉴定）且供交付、生产、检验验收的软件配置项的集合。在项目通过定型或鉴定后，将受控库中的产品基线通过流程转入该库。

（2）访问控制规程：对非基线配置文件和基线配置文件可采用以下两类控制方式：

开发控制：开发期间，进行版本管理，若需更改只作简单跟踪即可；

正式控制：若需要更改，必须通过正式更改控制规程才能进行更改，由顾客参与的高层CCB控制。

（3）配置库的备份：制定正确的备份与恢复策略，并加以实施。

2.1.3 基线

在项目策划时定义项目需要建立的基线，对其赋予唯一标识号，并文档化每条基线应包含的配置文件，形成基线列表。

（1）在系统设计与分析阶段结束时建立功能基线：包括经过评审的定义软件配置项技术要求的文件，如：软件研制任务书、接口控制文件、软件技术协议等。

（2）在需求分析阶段结束时建立分配基线：包括经过评审的分配到软件功能模块需求的文件，如：软件需求规格说明。

（3）在产品定型或鉴定时建立产品基线：包括经过确认的作为软件产品生产、交付、使用、保障活动基础相关文件，如：安装包、用户手册等。

2.2 跟踪和控制更改

2.2.1 跟踪更改申请

（1）提交变更申请：需要变更时，提交变更申请，并填写建议的更改方案。

（2）变更影响域分析：项目组主要从以下几方面进行分析。

该软件更改是否满足软件本身功能、性能、软件质量要求；

对项目工作量、进度、成本的影响；

是否引起其他软件配置项、相关的设计文件/图样更改；

对在制品和已交付产品的影响以及处理措施；

对于在多个产品中使用的配置项，其更改可能解决本项目中的问题，而在其他应用中是否有影响；

更改等级分析：按照更改的内容及影响范围，可将更改进行分级控制。

（3）CCB审批：项目组与利益相关方一起评审该变更申请。

（4）跟踪更改申请的状态：更改申请被提交后就应对其进行状态跟踪，直到更改实施完毕并经过批准。

2.2.2 控制配置项

变更申请经过批准后，对问题配置项进行更改控制：

（1）出库：经过批准的变更申请可以作为出库依据，对存在问题的配置项出库。

（2）更改并验证：项目组针对新需求或存在的问题进行更改。更改后，应对更改内容进行评审或测试，以确保更改不会引入新的问题等。

（3）入库：通过验证后，项目组应根据更改级别提交相应CCB审批后检入受控库生成新的版本。

2.3 建立完整性

2.3.1 建立配置管理记录

（1）收集配置管理相关表单：配置管理员收集、整理配置管理过程中产生的相关表单。

（2）生成配置状态报告：在项目配置项状态发生变更后，配置管理员应生成配置状态报告，并向项目组和利益相关方配置状态信息。

2.3.2 执行配置审核

配置审核是指确认所产生的基线和文档符合指定的标准或需求。配置审核类型包括：

（1）功能配置审核：目的是验证配置项的所测功能特征是否已达到其功能基线文档中所规定的需求，且操作和支持文档是否完备和满意。相当于文文相符审查。

（2）物理配置审核：目的是验证构造的配置项是否符合定义它的技术文档。相当于文实相符审查。

（3）配置管理审核：目的是确认配置管理记录和配置项是否完备、一致和准确，配置管理工作开展与配置管理标准和规程是一致的。

3 结束语

软件配置管理作为GJB5000A-2008软件研制能力等级认证中必须开展的活动，也是其他软件工程化活动的基础。通过开展软件配置管理，可使软件在整个生命周期中状态清晰可控、可追溯，是提升软件产品质量的重要保证。

参考文献

[1]GJB5000A-2008，军用软件研制能力成熟度模型[S].

[2]GJB 5716-2006，军用软件开发库、受控库和产品库通用要求[S].

[3]GJB3206A-2010，技术状态管理[S].

第3篇：配置管理与变更管理范文

梁 娜 贾志淳 渤海大学信息科学与技术学院 辽宁锦州 121000

【文章摘要】

在软件整个的生命周期中都伴随着软件配置管理。软件配置管理对于软件而言有着非常重要的作用，能够为软件的研发提供管理办法与活动原则。本文对软件配置管理的地位进行了分析，指出了软件开发过程中软件配置管理的实施与控制。

【关键词】

软件开发；软件配置；量化管理

软件配置管理的主要内容包括软件及其相关内容出现的变化。在软件整个的生命周期中都伴随着软件配置管理，在软件开发的过程中发挥着管理办法与活动原则的重要作用。软件配置管理中包括多种管理模式，为软件的质量管理、过程改进与项目管理提供保障。在软件开发过程中配置管理实施方法的研究中，具体项目配置管理的实施措施成为了研究的重点问题，通过有效的配置管理实施措施实现配置管理理论与软件开发过程的相互结合。

1 软件配置管理概念

1.1 软件配置管理的主要内容

软件项目的需求在计算机深入应用的背景之下不断复杂化、多变化。在软件整个的生命周期中，配置管理逐渐成为了非常关键的控制过程，发挥着越来越重要的作用。

在软件整个的生命周期中，软件配置管理主要的作用包括两个方面，一方面是对软件的演化过程进行记录，另一方面是对软件产品进行跟踪与管理。在软件配置管理过程中，具体的内容包括版本控制、软件配置库建立、软件机线记录、配置追踪等，这些内容是通过对软件修改及其修改生产的配置项进行控制、记录与追踪来实现的，从而确保软件产品的可控性与完整性。

在软件开发的整个过程中，完整的软件配置管理应该在软件开发的整个过程中进行覆盖，包括软件的开发、软件的测试、软件的变更及软件的文化等，同时还要从整体上对软件的整个开发过程进行宏观管理与控制，从而确保软件开发过程的可预测性较强。软件产品具有可重复与可追溯的特性，从而促进软件开发效率与质量的提高，实现软件项目产品完整性的建立与维护，对软件开发资源进行维护与集成。

1.2 软件开发中软件配置管理的重要性

软件配置管理方法的发展主要包括三个阶段：第一，以文件为基础的软件配置管理，该阶段的软件配置管理特征为以版本控制为主。第二，随着软件项目规模的扩大与复杂程度的提高，实现了以项目为基础的软件配置管理，实现了元数据与配置项隔离存储。第三，以文件访问为基础的软件配置管理，在保持了第二代配置管理特征的前提下实现了更多特性的增加。例如，能够实现文件的透明访问，开发人员可以在不保留本地副本的情况下对受控制配置项进行访问。此外，还实现了软件配置管理与软件变更管理、软件分析、软件测试等软件开发各个环节结合的强化，从而形成了更加全面的软件开发管理法方案。

在软件开发的过程中，由于技术不断发展与人员流动频繁等原因，需要对开发过程中形成的文档、数据及代码等进行统一的管理与维护，实现知识产权库的建立，将较为零散的研发进行积累，进而将其转化为项目所共有的知识产权，从而提高软件开发工作的效率，实现软件研发周期的缩短，增强软件产品的核心竞争力。 软件配置管理与软件项目开发之间存在着非常密切的联系。实现软件产品的管理是配置管理的最终目标。随着用户需求的变动，软件也处于不断的变化过程中，为了能够有效地对软件产品进行跟踪与控制，配置管理需要对静态的与动态的产品都进行管理工作。因此，软件配置管理与软件开发有着紧密的联系。在软件开发的各个环节中都必须贯穿配置管理：对用户需求进行管理，对其实施进行监控， 从而确保用户的需求能够在产品的各个版本中都得到最终的落实，同时用户需求能够在软件产品的开发过程中提供相应的帮助；对用户出现的新的需求进行及时、有效地相应；实现新的开发周期的推动等。通过有效的软件配置管理工作实现了对软件开发的控制，用户对软件产品的需求遵循严格的流程经过受控的生产流水线之后形成产品，最后将用户发售给用户。在整个过程中，不同的角色都有着自身非常明确的职责，但是相互之间有能够互相衔接与协调。

在软件开发的过程中，软件配置管理奠定了非常坚实的基础，提供了协作开发的环境，规范了软件开发的流程，实现软件开发流程的规范化，促进软件研发效率的提高。

2 软件开发过程中的软件配置管理实施分析

2.1 软件开发中配置管理的实施流程

在软件开发的过程中，其主要的流程为：分析需求——设计体系结构——开发与变更代码——集成软件——测试—— 交付等几个环节。软件配置管理的主要活动阶段集中在软件项目开发与维护的阶段中。在项目计划阶段中，配置管理的主要活动包括配置管理计划的制定。项目开发维护阶段是软件项目研发中非常关键的阶段，开发维护阶段包括软件设计、软件研发、测试与等。软件配置管理在整个的项目开发、维护阶段中都实现了覆盖。

2.2 软件开发中配置管理的工作流程

软件配置管理在项目开发与维护阶段中主要的活动包括以下几个方面：第一，配置管理人员所承担的管理与维护工作；第二，开发人员、集成人员执行的配置管理策略；第三，流程的变更。这三个方面的活动之间存在既相互独立有相互联系的关系。

2.3 软件配置管理实施的关键活动

在软件开发的整个过程中，软件配置管理活动的实施内容主要包括标识配置、版本控制、状态统计、配置审计等几个方面。配置标识指的是对配置项的名称进行定义；版本管理指的是在软件开发的过程中，对各种变更行为或版本信息进行记录工作；状态统计指的是对软件的开发进度实现量化；配置审计指的是检验软件实施过程与软件信息项的正确性。

3 软件开发过程中的软件配置管理策略

3.1 软件开发过程中的版本管理策略

在软件配置管理中，版本控制是非常关键的问题之一。版本的主要功能是对配置项的当前状态进行记录，从而为后续的开发提供参考与借鉴，同时还能够对之前的版本状态进行追溯。在对版本进行管理的过程中，其主要的功能指的是对软件生存期中信息项的修改与变化进行管理。除此之外，版本对于并行开发实现了支持， 从而能够对版本同步问题进行有效的解决，还能够为不同开发者之间的交流提供便利，降低由于版本不同、沟通不畅等原因造成的编码错误、重复劳动等问题。

在软件配置管理策略中包括多个方面的内容，例如可变粒度策略、并行开发策略、构件策略等，其中应用最为广泛的就是并行开发策略，能够对不同的用户需求及频繁的更改要求进行满足，尤其适用于大型软件研发项目。

并行开发策略在对软件项目进行管理的过程中，通过团队模式实现其整体同步的变更，从而确保所有的开发人员能够在同一软件模块上进行工作，而且能够在相同的时间针对相同的代码进行不同的修改，这些修改之间并不会产生干扰情况。通过并行开发策略一方面实现了软件开发人员的协同工作，另一方面也实现了对软件开发过程的整体控制。应用并行开发策略能够实现资源最大限度的调动，在相同的时间内研发出更多的软件功能，降低软件研发的周期，促使软件研发过程实现了规模化与规范化。

3.2 软件开关过程中的配置项标识策略

在软件配置管理中，其控制与管理的工作单元就是配置项。在配置项管理中包含有所有的需要记录变更或者状态的元素。例如，开发环境中的开发工具，维护环境中的项目管理工具、产品设计中的产品规格说明文档、编码过程中的执行元素等，这些都能够成为软件配置管理中的配置项。

配置项的粒度可大可小，元素可多可少。配置项的粒度越大，其管理成本的就越低，其配置进度也越低。一般情况下，将相同的工作任务之下的一组元素称之为一个配置项，通过对元素的组合管理来实现管理成本的节约。

3.3 软件开发过程中的策略

在软件的过程中，系统目标码版本包括系统执行码、系统参数等。软件开发过程中的策略为软件的构建了统一的环境，为软件的正确集成提供了保障，为开发人员的后续研发工作奠定了非常坚实的基础。在软件版本进行的过程中，首先需要项目经理对软件版本的交付进行确定，在其确定交付之后，配置管理人员开始实现软件版本标签的建立，对版本的开发环境进行标识。首先从之前的软件版本中对发行版本进行检出，之后针对软件版本进行链接编译工作，在可执行代码完成之后由测试人员进行各项测试工作，测试成功之后将软件版本交由配置管理委员会进行审核，审核通过之后配置管理人员就能够进行文件生成工作，同时还要实现开发权限的解冻工作。

4 总结

与西方发达国家相比，我国的软件配置管理发展还存在较大的差距。在未来的发展过程中，软件配置管理将发挥越来越重要的作用，将逐渐实现自动化、规模化。在未来的研究过程中，要将持续改进与针对性作为管理模式的研究方向。通过过程管理质量的提高，实现软件配置管理的规范化，提高我国软件产业的发展速度。因此，实现通用、便捷、高效的软件配置管理模式的设计与开发成为了未来软件配置管理研究工作中的重点内容。

【参考文献】

[1] 杨丽红, 李志蜀, 袁晓玲, 肖静.CMMI2 级中配置管理过程域的研究和实施[J]. 计算机应用， 2012，S1（53）：404-406+409.

[2] 张晓燕, 孙亮清. 软件配置管理在船舶监控软件项目中的实施[J]. 上海船舶运输科学研究所学报， 2013，02（53）：57-61.

[3] 张昭瑜，韩学为，张建伟，吴仲光， 彭君凯. 解析软件配置管理在软件开发平台中的应用[J]. 知识经济， 2014，10（63）：93.

[4] 钟林辉, 陈宇, 刘洋, 谢冰, 邵维忠. 软件配置管理系统XML 数据模型及原型研究[J]. 计算机工程与应用，2011，19（64）：82- 84+120.

[5] 邹祎久. 基于DO-178B 及CMMI 的机载软件开发配置管理技术研究[J]. 南京广播电视大学学报（计算机光盘软件与应用），2013，11（36）： 230+232.

[6] 张彬. 软件企业质量管理核心过程——设计开发过程的控制[J]. 世界标准化与质量管理，2012，01 （53）：11-14.

[7] 郭萍, 潘振海. 软件配置管理系统── CIMS 实验工程软件配置管理的计算机辅助工具[J]. 冶金自动化，2014，02（51）：7-10+21+58.

[8] 裴树军, 陈德运, 陈晓雪. 软件配置管理在软件开发平台中的应用[J]. 哈尔滨理工大学学报，2010， 01（54）：28-32.

【作者简介】

第4篇：配置管理与变更管理范文

关键词：运维体系、服务台、事件管理、问题管理、变更管理、管理、配置管理

运行维护方案

1.1 方案设计思路

本方案的设计思路是：按照IT服务管理理论、方法和标准，结合用户实际和建设需要，遵循立足需求、统一规划、保障重点、分步实施、务求实效的原则，建立一套融合组织、制度、流程、人员、技术为一体的IT服务管理体系，建立组织机构，制定规章制度，规范管理流程，明确职责分工，强化技术支撑，使技术团队能够以此为依托，实现对用户应用的综合管理监控和日常技术支持，快速响应和及时解决信息系统运行过程中出现的各种问题和故障，确保用户应用的正常、稳定、高效运行。

建立一个完善的IT服务管理体系，首先需要切合用户需求和用户特点。

本方案运行维护的用户群可归纳为两大类：

 内部用户：包括用户、相关单位等；

 外部用户：进行用户业务办理、查询的单位和个人。

在方案实施时，将进行详细调研，系统整理和规划服务对象类型和数量，制定针对性的服务设计，满足不同用户的服务期望。

维护对象包括机房、网络、主机和服务器、应用软件等。

在需求调研中，需要规划配置管理方案，确定配置属性，梳理配置关系。同时对于不同维护对象，各有技术特点，需要制定针对性的运维技术手册。

运维团队由用户信息中心、（总）集成商、集成商、应用开发商共同组成，可概括为三个服务团队体系：服务台、内部运维团队和外部运维团队。

1.1.1 本项目运维体系设计重点

在本项目运维服务体系设计中，重点投入在服务支持建设上，服务支持描述了所提供的IT 服务日常支持和维护活动相关的过程，是在实现运维支撑平台中最常用到的模块。

服务支持主要功能模块有：服务台与事件管理、问题管理、变更管理、管理、配置管理。

1.1.1.1 服务台与事件管理

服务台是组织机构内为所有IT 用户所提供的单一、集中的联系点，它处理所有事故、查询和请求。它为所有其它服务支持过程提供了一个接口。

事件管理负责管理所有事故从检测和记录到解决和完成的所有内容。事故管理的目标是快速有效地响应最终用户，使它们能够迅速恢复工作，以减小对最终用户的影响。

事件管理涉及主要活动如下：

(1) 事件查明和记录

(2) 分类和初步支持

(3) 调查和诊断

(4) 解决和恢复

(5) 关闭

1.1.1.2 问题管理

问题管理的目标是最小化事故和问题对业务的负面影响。为了达到这个目标，问题管理通过管理所有主要事故和问题来辅助事故管理，问题管理尽力记录所有的工作环境并对相应已知错误进行“快速修补”，并且在可能时产生变更以实施持久的结构性的解决方案。问题管理也对事故和问题进行分析和趋势分析，以预见性的预防进一步事故和问题的发生。

问题管理涉及主要活动如下：

(1) 问题识别、记录和归类

(2) 问题评审

(3) 调查和诊断

(4) 解决和关闭

(5) 已知错误识别和记录

(6) 已知错误分类和评估

(7) 已知错误解决和关闭

1.1.1.3 变更管理

一个单一的集中化的有效和高效地处理变更的变更管理过程，是任何IT 机构成功运营的关键。在变更从启动和记录到过滤、评估、分类、授权、调度、建设、测试、实施以及最终的审核和收尾的整个生命周期中，必须谨慎仔细地对其进行管理。此过程的一个关键成果是前向变更调度（FSC-Forward Schedule of Change），它是基于业务影响和紧急性的所有领域都同意变更的一个中央程序。

变更管理涉及主要活动如下：

(1) 启动、接受和分类

(2) 评估和审批

(3) 安排和分配

(4) 建设

(5) 实施

(6) 关闭

1.1.1.4 管理

管理过程采用了对IT 服务变更的整体全局视野，它考虑的所有技术和非技术方面。管理负责组织机构内所使用的所有硬件和软件的所有法律和合同义务。为了实现此目标并保护IT 资产，管理为定义硬件库（DHS-Definitive Hardware Store）中的硬件和定义软件库（DSL- Definitive Software Library）中的软件建立了一个安全的环境。

管理负责控制版本变更的频度。这涉及到对变更的整合或将变更分拆成更小的版本模块。这些举措基于一系列对业务需求、员工需求（开发、测试、实施、运作）和用户/业务影响的权衡考虑。

管理涉及主要活动如下：

(1) 启动、接受请求

(2) 策略制定

(3) 实施计划制定

(4) 方案审批

(5) 构建测试环境

(6) 实施

(7) 对实施结果测试

(8) 结束

1.1.1.5 配置管理

配置管理提供了成功的IT 服务管理的基础，它支持着所有其它过程。其基础成果是配置管理数据库（CMDB)，在数据库中包含了一个或多个综合数据库详细描述了组织机构中的所有IT 基础设施组件以及其它重要的相关的资产。就是这些资产提供了IT 服务，它们也被称之为配置项（CIs)。CMDB 同普通的资产注册所不同之处在于那些关系、或链接，它们定义了每个配置项（CI）如何互连以及如何同其邻居相互依赖。这些关系允许执行例如影响分析和“如果..将会…”等的活动。理想情况下，CMDB 也包含了同每个CI 相关的所有事故、问题、已知错误和变更的细节。

配置管理涉及主要活动如下：

(1) 登记组成服务的资产信息；

(2) 登记这些资产之间的关系；

(3) 确保配置管理信息库中的各类相关信息能够得以及时更新。

1.2 运维体系设计内容

运维体系设计内容包括：运维组织架构、角色与职责、运维相关流程、运维工作表单、服务度量指标。

1.2.1 运维组织架构

运维组织架构包括涉及运维管理的所有单位、部门、人员的组织信息，用树形层次结构记录，作为运维系统基础数据管理。

为确保整个运维工作的协调运转，建议采用分级管理模式规划运维组织架构，即组建运维服务台，三级运维支持部门协同工作，共同完成运维工作。

建立统一接入的服务台，实行中央控制，分级授权的集中式加分布式的服务台设计。当最终用户提出请求或者需对应用系统进行主动运维时，运维服务台作为呼叫受理反馈部门接受服务请求，并提供一线帮助。对于无法解决的问题，提交二线也即系统运维组处理，运维服务台同时进行跟踪和催办。

系统运维组包括内部运维团队和外部运维团队，作为核心团队负责运行维护和管理工作，针对应用系统进行主动运维，并解决运维服务台转交的请求，在必要时协调供应商、开发商等外部资源。

供应商、开发商作为三线支持，对运维中心提供二线不能解决的问题支持。

采用上述分级管理的工作模式，可以按照运维人员的不同技术能力分配到一、二、三线，实现了运维人员的专业化分工；对于技术要求相对较低的一线可根据工作量的增长及时增加，确保服务呼叫处理率，对于承担核心运维工作的二线人员，避免了初级服务请求的直接处理，保证其对关键应用和紧急故障的处理，可以大大提高运维服务效率和质量；同时，分级管理的工作模式充分发挥不同人员的技术能力，克服了高能低用情况的发生，降低了运维服务总体成本。

1.2.2 角色与职责

本方案运维管理的角色与职责设置，将以ITILV3标准为参考，结合总集成商历年来大量的运维服务实践，针对本项目用户进行设计。所涉及的角色及职责的定义，主要包括服务台、事件管理、问题管理、变更管理、管理、配置管理各个角色和职责。例如，服务台、一线工程师、二线工程师、事件经理、问题经理、问题分析工程师、变更经理、变更咨询委员会、配置管理员等角色。

各类角色在运行维护过程中承担不同的职责，并将在方案实施时根据用户特点进行完善。

1.2.3 运维相关流程

运维相关流程的定义和设计，根据用户的业务需求特点进行定义，主要包括服务台、事件管理、问题管理、变更管理、管理、配置管理、知识管理等流程。

在本方案实施时，将进行运行服务流程设计。主要流程设计工作内容包括：

1、服务台/事件管理流程设计

2、问题管理/知识管理流程设计

3、变更管理流程设计

4、配置管理流程设计

1.2.4 运维文档体系

建立文档体系是进行运行维护服务中持续进行的工作。完善的文档体系有助于维护团队工作持续性，维持稳定的客户服务能力。如运维流程类文档（事件报障信息表单、发起问题信息表单、变更申请表单、管理申请表单、配置信息记录表单等）、服务器、数据库日常维护操作类文档；日常检查模板；日常沟通工作模板、应用流程等等，这类标准化文档的建立，将规范运维管理，改善运维效率。

文档体系的建立并非易事，因此需要从思想上重视并不断更新文档，严格按文档实施操作，要监督文档质量等。

文档体系的建设包括两方面内容：

1、文档体系完善

2、规范梳理和固化

在实际运维中，由于运维活动具有多样性、复杂性，规范的制订往往跟不上运维实际的要求。但结合客户业务需要，有选择地制订关键的运维规范不失为一种有效方法。

定义：这里的规范指运维过程中应该遵循的、客户导向的行为约定。包括操作方法、结果提交方式、运维过程控制点的确认等。以升级为例：故障出现后，故障的等级判断标准，处理时长与升级的关系，升级的途径和相关人等，都受升级规范的约束。

流程的梳理是一个渐进的过程，规范内容也会随用户系统生命周期、运维局势不同而及时调整。对于规范梳理，需关注两方面的内容：

 其一是目前运维中影响较大、问题较多急需明确的流程；

 其二是明确确认规范的主体。

另外和规范相关的接口有客户和项目组，需分别进行梳理，并区分其各自不同的特点。明确责任，合理分工。这部分工作是服务持续改善计划的难点所在。

1.2.5 服务度量指标

制定服务度量指标，对运维系统制定内部和外部服务管理级别，对员工制定员工绩效考核标准。

规划的工作内容如下：

 配合用户技术支持部门梳理所有现有SLA相关资料编制服务目录；

 完善和巩固服务目录，同时加强客户沟通和宣传，让更多客户充分了解服务团队目前提供的服务内容；

 基于ITIL建立标准的服务水平管理流程，规范定义包括服务水平管理计划、客户需求管理、服务水平确定、OLA磋商、UC需求确定、SLA签署、监控和回顾等在内的各项服务水平管理活动；

 建议采用需求调研表和访谈的方式对客户的IT服务需求进行收集、整理和分析，从而确定服务水平需求；

 由客户服务部依据与客户签订的SLAs将相关的具体指标细化为各分相关职能部门的OLA，并与分解相应UC到对应供应商；

 利用工具监控和收集实际的服务水平管理数据，并通过与SLA的比较发现差距生成报告，交由OLA和UC支持团队进行改进；

 建立服务水平协议回顾和检查过程；

第5篇：配置管理与变更管理范文

图2 渐进式实施ITIL流程图

对企业IT部门来说，实施ITIL Service Support（服务支持）的意义在于清晰梳理日常IT运维管理过程中遇到的各种各样的事，使IT运维过程变得有序连贯，从而提高IT服务的能力和水平。

ITIL Service Support能够形象地描述IT运维的工作内容。在ITIL框架下，一项IT服务已经像工业化流水线上的商品一样，体验着IT运维流程化带来的高效率和高质量。

当条件不成熟的时候，爆发式实施ITIL，一锅端的方式是不合适的，实践证明效果也很差的。目前较为普遍的方式是渐进式，通过初期、中期和远期三个阶段循序渐进地实施ITIL。

对企业来说，实施ITIL的最大意义在于把IT与业务紧密地结合起来，从而让企业的IT投资回报达到最大；对IT部门来说，实施ITIL Service Support的意义在于清晰地梳理出日常IT运维管理过程中各种各样的事，使IT运维过程变得有序连贯，从而提高IT服务的能力和水平。

流程化做事风格

ITIL Service Support的流程（图1所示）清晰地表达出一个认知：服务因事而起，因事而终。

在ITIL框架下，一项IT服务已经像工业化流水线上的商品一样，体验着IT运维流程化带来的高效率和高质量。流水线式的服务引发了对原有IT服务组织结构的调整，统一的服务台配合新的管理制度解除了客户直接调用工程师的弊端。不同的事经过服务台识别、分配后，进入事件管理，随之事的身份变换为事件、事故、问题、已知错误、变更、，完成一项服务由事发到消除的生命周期。

凡事皆有因。对IT运维来说，因自用户而起，事自服务台而入。服务台作为一项管理功能，它每天遇到的事最多，包括报修、投诉、咨询、商业机会乃至骚扰等。如果没有服务台，这些事都会混杂在一起进入IT运维的各个服务小组。有了服务台，每一件事都会经过梳理、分配，然后站队、排位，该去哪里去哪里。作为IT运维流程的起点，服务台做事始终要将“下一个流程”的意识贯穿于工作之中，不能乱排位置、乱指挥。

安排妥当后进入事件管理环节。事件管理需要解决的事都是属于已知的可控服务范畴的，也可以理解为是事件管理根据与问题管理协商而定的事件管理范围，是经过识别处理后服务台转过来的事。事件管理其实就是响应速度的管理。响应时间短、处理速度快是事件管理的要求。只要影响事件响应速度的事一旦发生，事件管理就需要做一个简要的分析和诊断，要么提出可行的快速解决方案或应急措施，要么在没有更好办法的情况下将其立即升级为事故。

超出事件管理能力范畴并提请升级的事故在ITIL中称之为“问题”。虽然事的性质在升级之后发生了变化，但事件管理里有关它的所有信息都将作为问题管理的参考依据，协助问题管理寻找问题发生的根源。同样，问题管理需要想办法尽快将问题转变为已找到问题根源的“已知错误”，提供应急措施或最终的解决方案以帮助事件管理尽快地恢复用户的业务运行。

并不是每一个问题都需要走变更管理流程。变更管理的目的是纠正错误、解决问题。从这一点看，变更管理是在纠正错误的事。一般而言，问题管理分析出已知问题，提交RFC到变更管理，变更管理进行解决。可是一旦变更管理控制得不严，没有对进行充分地测试，那么对事件管理和问题管理而言那又将是新事件、新问题的起源。

管理做什么？管理是对变更做实质性执行的流程，不仅要忠实地执行变更，而且还要考虑将要安装的配置项、将要停止使用的配置项以及退出使用的配置项。成功与否，需要事件管理提供的错误记录来确认。由于事关重大，有计划、有步骤地做事是管理过程的重要特征。

配置管理是一项基础性的管理工作。配置管理做的事不比服务台少，而且做好了容易被忽视，做得不好又很容易被发现。吃力不易讨好地做事是配置管理工作的真实写照。有人认为ITIL Service Support中最重要的就是配置管理，因为它是服务台和5个管理流程稳定运行的基础。一个及时、完整、准确的配置库将会给IT服务带来极大的自信：我之所以能够做到准确地提供IT服务，是因为我有一个非常完备的配置库和运作良好的配置管理流程。

对于IT部门来说，实施ITIL Service Support最大的改变是做事的方法：从忙乱过渡为井井有条，从过去的跨组协调转变为一以贯之的流程间协作。这样，不仅提高了效率，更关键的是流程化的工作方式在慢慢改变着员工的工作思路。IT运维强调的是“服务”二字，与职能化的管理模式相比，流程协作更能体现出服务意识，从而影响到员工的工作习惯，进而形成工作成习惯、习惯成自然的效果。

渐进式实施

ITIL带给IT部门的好处让人心动，但如何实施ITIL是很多人心中的疑惑：是十个流程同时实施，还是一个接一个地实施，抑或是某些流程打包在一起先实施？如何通过实施ITIL最终实现IT运维的可控、在控和能控？虽然没有具体统一的实施标准，但根据经验来看，ITIL流程的实施基本上是两种方式：渐进式和爆发式。爆发式实施曾在一些企业的IT部门使用过，但效果很差。究其原因，最根本的是当条件不成熟的时候，一锅端的ITIL实施方式是不合适的。目前较为普遍的方式是渐进式实施。

从图2中我们可以看到，渐进式实施ITIL是一个循序渐进的过程。它有初期、中期和远期三个阶段。初期一般只实现服务台、事件管理和配置管理。虽然这只是一小部分的流程，但走好这一步不仅可以提高ITIL实施的信心，而且能够为以后的实施打下牢固的基础。

第6篇：配置管理与变更管理范文

关键词 ITIL；运维；服务；流程

中图分类号：TP311 文献标识码：A 文章编号：1671-7597（2014）03-0149-03

随着黄山烟草信息化建设的深入推进，信息系统的规模不断扩大，公司各种业务对信息系统的依赖性越来越大，同时IT系统日趋复杂、系统维护要求越来越高。尤其是专卖管理、卷烟营销、物流配送等业务对IT运维管理的要求越来越高。IT硬件和软件应用的也不断增涨，其环境复杂，多系统、多数据库和多应用平台、多厂商网络及系统设备的网络运行环境，使网络维护难度成几何倍数的增长，系统管理人员的工作压力越来越大。ITIL作为运维IT管理的新理论、方法和工具，正在发挥着越来越重要的作用。

1 黄山烟草IT运维的特点及问题

在IT系统生命周期中。系统建设的时间和成本只占相对小的一部分，而系统运行维护阶段占了整个时间和成本的主要部分，可以说IT系统是三分建设、七分运维，足见IT运维的重要性。当前，黄山烟草的信息化工作已从IT系统建设为主逐步进入建设和运维并重的新阶段。传统的IT运维管理思路及方法所带来的弊端逐渐显现，具体如下。

1）由于实施经验、行业视角的原因，难免在体系建设的科学性、系统性及完整性等方面存在缺陷，更缺乏从服务运维生命周期全局的角度去审视思考的经验。

2）由于受到信息部门人力资源逐步收缩的限制，如何平衡好、处理好系统建设与服务运维、应急处理与项目管理控制之间的关系，往往成为长期困扰运维人的难题。

3）缺乏对运行维护工作的规范性管理，信息中心服务运维团队依然常常扮演应急排障的救火者角色，往往缺乏对信息系统的适用性、主动性运维。

4）缺乏统一的集中监控与管理平台，无法快速定位故障源，更无法发现潜在故障，都是问题发生时才想解决办法，缺乏提前预警机制。

5）缺乏对日常运行维护工作的管理工具，目前的系统管理工具已无法满足日常管理的需要，值班、运维等工作流程还体现在纸介质记录上。

6）缺乏量化运行质量的工具，无法对运维人员进行有效考核，运维人员运维的价值得不到体现

如何尽快建立规范、高效的IT运维管理运行体系，实现对企业核心业务系统的IT 监控管理，提高IT 运维管理水平，如何在有限的资源基础上支撑起庞大而复杂的信息系统服务运维，达到稳定、规范及高效的IT运维的管理目标，已经成为黄山烟草信息化管理亟待解决的重要问题。

2 基于ITIL的IT运维平台的构建与应用

ITIL即IT基础架构库，目前已经发展到了第三个版本，该标准旨在于通过对企业流程进行梳理提升企业IT资源的利用率和服务质量。本文拟提出基于ITIL的服务台管理系统的总体业务模型，从流程、服务及管理活动等方面对该系统进行阐述，以期提供较为全面的业务服务管理解决方案。

ITIL最佳实践基于IT运维管理的四大核心流程组，即业务与IT规划（Businss-IT Alignment）、IT运营维护（IT Operations Management）、IT运维保障（IT Operations Assurance）、IT服务管理（IT Service Management），并采用IT运维管理质量改进循环（Deming Circle）进行持续改进。

图1 PDCA模型

计划（Plan）阶段：IT高层管理者或IT部门经理根据业务部门的需求制定相应的IT服务策略与目标，在评估实现这些目标所需的服务水平与成本等因素后，产生详细的实施计划。

实施（Do）阶段：IT服务经理执行计划（Plan）阶段产生的实施计划，对流程、表单、报表、KPI等做出修正，使之更加符合实际业务的需要，同时收集相关运行数据以度量它的绩效。

检查（Check）阶段：在成功实施了新的计划后，IT服务经理检查实施的效果，发现IT运维中出现的新的问题与瓶颈，并通过分析相关运行数据找到问题与瓶颈的根本原因，并汇报给IT高层管理者。

改进（Improve）：IT高层管理者或IT部门经理根据检查（Check）阶段的检查结果决定需要采取的进一步行动，例如，修正流程缺陷、进一步标准化流程等，以提高IT运维管理的效率。

1）系统建设目标。服务台作为受理用户服务申请或报障的服务窗口，运维中支持级别：一线支持、二线支持和三线支持。一线人员主要由服务台人员及桌面服务人员组成，其中桌面服务采取外包方式进行；二线主要由系统及应用维护负责人组成；三线人员主要由信息中心系统研发人员、外部专家与合约期内的外部维护商组成。这三线服务运维服务人员通过运维管理系统内的服务运维流程实施运维管理，各个支持级别人员负责各个级别的系统事件或故障，由服务台统一协调服务运维资源，跟踪督促实事件进度，促进事件高效解决。

图2 IT服务运维管理体系

2）功能模块逻辑架构，如图3。

图3 功能模块逻辑架构

从总体上看，可以将IT运维管理的功能模块分为两大类：流程模块和非流程模块，流程模块有自助服务台、有服务台&事故、问题、变更、、作业计划和自定义流程扩展模块（任务管理），非流程模块有CMDB，服务水平管理和知识库管理。

在功能模块之外，IT运维管理提供2类重要的接口，它们是监控系统告警接口和二次开发接口。这两个接口主要为IT运维管理的扩展提供重要的支撑。整个IT运维管理系统的最底层是业务管理流程（BPM）引擎，该引擎支撑IT运维管理的所有流程模块。

服务台主要支持IT基础设施的日常运行和维护管理，包括事件管理、问题管理、变更管理、管理和配置管理等ITIL服务支持流程，如图4所示。

图4 ITIL服务支持流程架构图

①服务台&事故管理：事故管理的目的主要是支撑ITIL中的事件管理流程，涵盖事件的整个生命周期。目的是记录、解决及跟踪IT服务运作过程中发生的事故，并使用户可以尽快恢复自己的正常工作，避免业务中断，将事故对业务运营的影响降至最低。服务台即连接用户与IT部门以处理上述事故的连接点。于是，服务台与事故管理相结合就构成了从事故发生到得到解决的首要流程，同时，服务台记录下事故以及事故解决方案的有效信息，以备其他流程（例如问题管理）参考。由于监控系统中发现的告警是事件的一个重要来源，因此，IT运维管理提供与监控系统告警的接口。

②问题管理：问题是指一个或几个已暂时处理但根本原因尚不明确的事件，许多事件往往是由同一个问题引起的。

问题管理流程查明突发事件或错误产生的根本原因，并制订解决问题的方案和防止错误再次发生的措施，将由问题和突发事件对业务产生的负面影响减少到最低。用户能够非常方便地将问题与突发事件和变更关联起来，并且很快地找到相应的解决方案。或者在定位问题的根本原因后，产生相应的应急措施以及最终解决方案。对于那些由于成本、技术等原因，暂时不予消除的问题，可以置为已知错误，留待日后解决。

③变更与管理：变更管理确保在变更实施过程中使用标准化的方法和流程，尽快和有效地实施变更，从而把由于变更所导致的事件对IT 服务的影响减小到最低，同时改善了公司的日常运作。它包括一套完整的变更管理功能，包括变更的发起、审批、影响评估、派发实施等功能，以工单的形式在各部门和责任人之间流转。

通过管理流程能够有计划的将软件和硬件的成功地导入实际应用环境中。也可以设计一些有效的流程来将变更导入系统中，同时在整个和导入过程中保持IT 部门和客户之间的信息沟通。

变更与管理、配置管理紧密结合的，当新引起IT基础架构的变化时，配置管理数据库也需要进行实时的更新，同时的内容：如最终软件版本，硬件规格说明、装配指南、升级安装手册和网络配置等都要关联到配置管理数据库中。

④配置管理：配置管理的总体目的是提供一个统一、一致的流程来管理IT基础架构中的各个组成部份，以确保：所有资源被正确识别、资源当前和历史状态得到记录、资源记录的完整性得到维护和确认、IT生产环境的稳定性、确保IT设备的有效控制和管理。

配置管理的活动包括：配置规划、配置识别、配置项基线控制、配置审计等。配置管理提供系统配置功能，包括报警配置、事件配置、视图配置、用户权限、监测配置等供配置控制模块调用。IT部门可以通过此模块简单的进行配置控制，对配置信息进行变更，对系统设置进行管理。

⑤CMDB（Configuration Management Database）：CMDB全称为Configuration Management Database，即配置管理库。它是最佳实践的核心模块，所有的用户关注的资源，包括各种软件、硬件、应用、业务单位、人员等，均被识别为配置项（Configuration Item ）并存储在CMDB。默认配置项类型包括主机、网络设备、无线AP、存储设备、办公设备、数据库、邮件服务器、中间件、Web Server、基础应用、业务服务、资源等。

CMDB模块是整个ITOM一个核心，主要支撑ITIL中的配置管理。CMDB模块是一个非流程模块，主要是管理各类配置项的属性信息和关系信息，为其它流程模块集成配置项信息。

⑥知识库模块：知识库模块的目的为用户提供一个IT运维经验和知识积累与共享的平台。IT运维人员可以将自己的经验总结为知识出来，其它的人员就可以对该知识进行查找和借鉴，这样就能在IT组织内有效的实现知识共享机制，从而提高整个组织的工作效率。在知识库库模块中，可以对知识进行新建、审核、和查询，还提供对知识的关注和收藏、转发、评价等功能。

3 实施ITIL的几点建议

建立任何高可用性的系统，都必然要涉及人员、流程和技术三个方面，实施ITIL也不例外，著名的“木桶理论”告诉我们：一只木桶盛水的多少，并不取决于桶壁上最高的那块木块，而恰恰取决于桶壁上最短的那块。人员、流程和技术三个要素也就像组成一个木桶的三块木板，任何一个要素的短缺，都会影响到最终提供服务质量的高低。

充分了解ITIL体系，全面领会ITIL思想，培养ITIL人才。ITIL不是一种产品，而是一系列最佳实践经验，充分了解ITIL体系是项目成功实施的基础。ITIl的实施，大多都是对现行IT服务管理的颠覆，不光要IT部门人员要成为ITIL专家，普通客户也要了解ITIL体系。ITIL不是可以“包治百病”，ITI项目实施完毕，并不等于服务质量和运维风险都得到了控制或改善。

循序渐进的实施ITIL，结合企业自身实际，建立科学合理的流程。

ITIL是管理科学在信息技术中的应用，它描述了一系列基于过程的IT服务管理最佳实践经验，并没有说明具体的日常运营活动，也没有特别针对任何特殊的平台或技术，只是理论上的指导，如同质量、安全体系一样，如何结合实际应用进行落地，是整个项目的关键所在。哪些流程是必须的？组织内所有的流程都要实施吗？哪些流程需要重组、变革？投入的资源足够做所有的流程吗？所有流程都需要结合企业自身实际，循序渐进的、科学合理的进行设计。

实行严格的项目管理制度，重视沟通管理。一方面要建立专门的项目小组，确定项目管理的内容，制定项目管理跟踪、考核机制。根据项目进度制定项目控制节点（基线、里程碑）；另外要重视项目的沟通管理，既要注重业务部门和IT部门的沟通，更要重视与项目实施单位乙方的沟通。

4 结束语

企业IT服务管理的建设是一个长期的过程，虽然有ITIL理论作为指导，但是要真正形成适应自身企业发展的IT服务管理体系，仍需要经过不断探索完善，规划好足够的充裕时间来实施ITIL是非常关键的一点，此外，在实施任何新的ITIL流程之前，必须了解组织目前所处的状态和想要达到的目标，这是确保实现成功实现ITIL最佳实践的关键成功要素。

参考文献

[1]曹汉平，王强，贾素玲.现代IT服务管理：基于ITIL的最佳实践[M]. 北京：清华大学出版社.

[2]朱海林，等.IT服务管理、控制与流程[M]. 北京：机械工业出版社.

[3]左天祖，刘伟.中国IT服务管理指南[M].北京：北京大学出版社，2005.

第7篇：配置管理与变更管理范文

关键词:管道;生产管理系统;运行维护;管理

中图分类号：C93文献标识码： A

1 管道生产管理系统

管道生产管理系统主要包括调运管理、运销计量管理、计划管理、能耗及周转量管理、天然气用气需求预测、日指定、辅助功能、统计报表、SCADA数据采集、对外接口等10 个模块。

1.1 调运管理

实现调度日报的生成，调度指令、场站作业的起草、审批及下达，值班日志的填报，成品油批次计划的起草及下达、收发球管理等功能；实现生产调度过程的监管与控制。

1.2 运销计量管理

从SCADA 系统及相关系统自动获取计量交接数据，并实现管道计量交接数据、气质分析数据、原油化验数据的审核和上报、统计报表的汇总、运销台帐及销售结算单的自动生成。

1.3 计划管理

实现原油、成品油、天然气销售计划的制定、审批及下发及计划完成情况的跟踪分析。

1.4 能耗及周转量管理

实现输油气周转量的自动计算、能耗统计数的上报、自动汇总及报表展现，实现能源统计指标和工艺参数的自动计算。

1.5 天然气用气需求预测

根据历史用气量、气象数据、经济模式等因素预测客户的天然气用气需求，为日指定、销售计划、管输计划等的制定提供支持。

1.6 日指定

根据合同要点进行客户用气日指定管理，实现气田、终端供应量、储气库吞吐能力及客户需求量的综合平衡。

2 运行维护管理体系

管道生产系统以运行维护管理的最佳实践ITIL（信息技术基础架构库）理念为核心，以先进的运行维护管理平台为手段，开展各项运行维护工作。

2.1 运行维护工作内容

运行维护计划制定：主要包括运行维护工作目录的确定、运行维护工作进度安排、服务级别管理、服务改进计划、成本及费用预算。

日常运行维护管理：主要包括用户支持、系统巡检、用户培训、软硬件维护及配置及变更管理等。

突发事件处理：主要包括应急预案的编制及演练、灾备系统建设、突发事件的处理等等。

系统拓展：主要包括新投管道及新建组织机构的系统实施工作。

功能提升：主要包括新功能的开发建设、软硬件平台的升级、系统性能优化等等。

2.2 运行维护流程

以ITIL v3 体系为蓝图，结合项目自身特点制定了配置管理、变更管理、事件管理、问题管理、管理、知识管理等6 个操作流程。

配置管理：指识别和确认系统的配置项，记录和报告配置项状态，根据用户的请求完成变更及检验配置项的服务管理流程。变更管理：在规定时间内完成基础架构或服务的变更而对其进行控制的服务管理流程。事件管理：指对引起或有可能引起服务中断或服务质量下降的事件进行处理的管理流程。问题管理：指通过调查分析查明事件发生的潜在原因，并制定解决方案和防止再次发生的措施，将问题对业务产生的负面影响降到最低的服务管理流程。管理：是负责计划与实施IT 服务变更的管理流程，通过规范的流程控制服务及测试的过程，确保应用系统的质量。知识管理：是进行知识库内容收集、更新、检索以及知识应用、知识关联的服务管理流程。

2.3 运行维护理论

ITIL 是CCTA（英国国家计算机和电信局）于20 世纪80 年代末开发的一套IT 服务管理标准库，其将英国各个行业在IT 管理方面的最佳实践归纳起来变成规范，旨在提高IT 资源的利用率和服务质量。

管道生产管理系统的运行维护工作在借鉴ITIL理念的基础上，制定了配置管理、变更管理、管理、事件管理和问题管理的具体操作流程，并在服务规划、成本控制、年度总结等工作中充分吸收了ITIL 的服务级别管理、能力管理、IT 财务管理、IT 服务持续性管理、可用性管理的理念和方法论，实现了服务成本、服务能力与服务目标（用户需求）的平衡与统筹规划。

2.4 运行维护平台

系统运行维护平台主要包括事件报警平台和运行维护流程管理平台。事件报警平台为HPOpenView 平台中的OVO 和OVIS 软件套件，能够实现系统状态的监控和自动化报警。运行维护流程管理平台主要实现日常运行维护工作的流程化管理。事件报警平台和运行维护流程管理平台通过报表平台进行数据展现，并为帮助台的日常工作提供支持。

2.5 运行维护的实施

以ITIL v3 体系为基础，对配置管理、变更管理、事件管理、问题管理、管理等进行了深入的梳理与研究，在借鉴最佳实践的基础上摸索出了符合项目实际的运行维护方法论，对运行维护工作起到了很大的支持作用。

在处理系统变更请求的过程中，项目组根据工作类型的不同对变更管理流程进行了细分，针对新建天然气客户这一类操作的规律性和重复性，制定了新增天然气客户的操作流程，作为变更管理的子流程专门用于新增客户所需完成的基础信息、权限、报表、工作流、数据流等一系列的操作。同时在运行过程中根据业务发展变化更新完善业务流程，使其运转更加流畅。

通过运用可用性管理、服务级别管理、成本管理与持续性管理，对自身的服务提供能力进行了深入的分析与研究，进而明确了针对不同的服务所能达到的不同级别，同时将各种服务级别与对应的成本关联起来，进一步量化了运行维护工作，也为运行维护工作的考核提供了科学的依据。

参考文献：

[1] 赵宏振. FLUKE744在天然气管道控制系统测试中的应用[J]. 自动化仪表. 2009(07)

[2] 周中.天然气管道防腐问题的探讨[J]. 煤气与热力. 2001(03)

第8篇：配置管理与变更管理范文

关键词：IT运维；BSM；云网络

航空服务管理是复杂的，并且是高度动态的，数千名乘客和行李在数以千计的飞机中转移，在保持对所有细节监控的同时确保客户获得最佳体验对于管理是一个挑战。同样，云的运营环境是复杂和不断变化的。数以千计的工作量在实体服务器之间传输，对各项数据细节进行持续监测并确保最佳的终端用户体验也很难。

要积极主动地管理云环境，需要解决四大难题:

(1) 了解环境：收集、整合、分析和更新来自内外部的各种不同数据来源；

(2) 掌控高度动态的环境；

(3) 应对“多米诺骨牌效应”――运营环境中的一个变化或问题可能会影响到数百个服务；

(4) 将服务请求管理自动化，使您可以对至少数百位用户的服务请求进行快速响应。

业务服务管理(BSM)解决方案可以帮助您解决以上四个方面的挑战。BSM以一个综合性的方法和统一的平台来帮助IT机构削减成本、降低风险，并提高业务利润。BSM解决方案提供了多种自动化、管理和分析服务，使您能够主动地管理云环境。

本文以下的四个战略，可有助于您在云环境中实现主动运维：

一、了解环境：收集、整理、分析数据

如果您想有效地管理日新月异的混合数据中心，那么必须先了解您现有的实体的、虚拟的和云的环境，以及它们如何组合在一起来提供商业服务。因为管理虚拟和云环境的复杂性在不断增加，所以获得实时数据会是一个挑战。您可以利用很多不同的内部资源――内部服务器、主机、网络设备、应用、存储设备来收集详细的数据。

挑战来自于如何通过巩固、规范和分析数据得到一个整体的IT服务状态的概览，BSM解决方案可以帮助您满足这些要求。首先，BSM的自动探索和依赖映射解决方案，从不同来源收集数据，协调、规范并合并成一个可以供不同的服务管理工具共享的单一并统一的数据资源库(即配置管理数据库CMDB)。与此同时，BSM系统管理解决方案实时监控系统性能和不同资源的情况，可以与实时服务框架以及CMDB同步，以确保服务框架不变的情况下仍然可以作出准确和及时的IT决策。该解决方案跨多种不同的平台、供应商和数据来源，并规范、巩固和分析性能数据以确定系统性能问题的根源。

二、保持对动态环境的控制

虚拟化为云计算提供了基础，也大大增加了数据中心的动态性。在虚拟和云的环境中，包括服务器、网络、应用和存储在内的资源都是虚拟化的。随着工作量和业务需求的变化，这些虚拟化的资源正在被不断配置和重新配置。因此，您要面对不断变化并拥有大容量资源的环境。

1.探索

自动探索和依赖映射解决方案可以帮助您通过不断扫描环境，持续维护当前的应用程序和基础设施数据并相应更新服务模式。此外，一些绩效管理解决方案能够通过实时监测环境的变化，通知CMDB数据库来协调这些变化，确保服务模式的实时准确性。

2.变更和配置管理

影响动态数据中心的另一个要素是变更和配置管理。无论变化多么迅速，您都需要确保所有的变化遵守内部政策和外部法规。您还需要确保变更管理流程不妨碍敏感的虚拟和云环境。在这里，BSM变更和配置管理解决方案可以助您解决该问题，BSM将一个包括变更审批、调度、执行、验证和跟踪的闭环过程实现自动化。

3.操作

动态的云环境使操作也变得复杂。虚拟和云环境的根本就是一个高容量的变化体，这就要求您迅速适应不断变化的容量需求。因此，您还需要了解和跟踪容量变化的正常节奏，以及通过行为学习以支持未来的变化走向。只有这样，您才能区分正常和非正常的波动，并消除虚假的警报。

BSM的系统管理解决方案集成了性能和配置管理解决方案，因此，就更容易确定近期配置的变化是否会造成性能问题，还可以自动学习和跟踪虚拟和云环境的变化。如果没有这项技术，那么，在动态的虚拟和云环境中，当变化对服务水平产生影响的时候，依靠手动的分析是无法确认的。

三、有效应对“多米诺骨牌效应”

虚拟化和云计算的主要目标是最大限度地提高资源利用率，同时确保最佳的性能。这意味着在同一个共享的资源上放置多项服务。然而，共享资源越多，发生问题时的影响越大。而且由于很多服务是共享的，一种服务的出现可能是与其他服务结合的结果。所以，任何一个服务产生问题都会对其他服务造成“多米诺骨牌效应”，这个骨牌效应特别会对公共云产生影响，因为公共云有广泛的客户基础，而且会扩大商业影响。

BSM系统管理解决方案可以主动监测物理、虚拟和云资源，并为潜在问题提供预警，然后自动评估并面向业务优先解决关键问题，自动生成故障单，并附加根源和影响信息，加快生成问题的优先顺序和诊断。

您还需要注意容量管理，从而做到在保持服务质量的前提下实现资源的高利用率。BSM解决方案可以对业务、应用、基础设施和工作量的数据进行分析，以确保为业务服务提供更准确的容量。BSM解决方案还可以执行“假设”分析来帮助您确定和规划未来的容量需求。有了这些解决方案，无论现在还是未来，您都可以在不超支和增加运营资源的情况下规划和安排您实际真正需要的容量。

四、自动化服务请求管理

第9篇：配置管理与变更管理范文

为了解决学生动手能力差、缺乏质量观念等问题，本文提出了以项目为驱动的基于CMM的软件工程教学方案。其核心思想为：学生以项目组形式进行软件项目研发，理论教学围绕方法和工具来支撑项目，教师及组员共同把握CMM3级的“需求管理过程改进、项目跟踪与监督过程改进、软件质量保证过程改进、软件配置管理过程改进”四个关键过程域，使软件的开发过程文档化、标准化。具体实施如下：

1.1项目组人员构成

依据项目规模，4-6名学生构成一个项目组，职责及任务分配如下（可兼职）：组长：协同教师组织管理整个开发过程。配置管理人员：对各种文档、数据、代码进行管理。质保人员：执行质量保证计划、测试计划，并设计测试用例进行评审。需求专员：需求汇总以及需求规格说明文档的撰写。设计专员：概要设计和详细设计，并撰写相应的文档。编码及维护人员：依据设计编码实现软件系统，对实现的单元模块进行单元测试、集成测试，完成交付后的维护工作。

1.2教师职责。

课堂教学应与项目进度无缝衔接，围绕项目所处阶段的技术和工具进行讲解。项目伊始，教师指导小组长制定开发计划及进度表，并在全程跟踪和监督执行情况；其次，深入企业调研并结合GB8567-2006等软件过程标准，制定CMM3文档体系标准；最后，作为专家评审参与各项目组的测试与评审工作。

1.3需求管理过程改进。

需求管理是软件工程非常关键的一个步骤，需求分析的完整与否直接影响到产品的成功交付，甚至导致软件项目的终结。小组成员、用户通过会议论证形式确定需求，由需求专员记录并形成文档资料，评审通过后提交至配置管理人员。

1.4项目跟踪与监督过程改进。

教师及小组组长在整个研发周期中执行项目的跟踪和监督工作。根据项目的计划，在指定的时间对项目的产品进行检测，目的是规范软件过程的流程，避免开发周期延迟的情况。

1.5软件质量保证过程改进。

软件质量保证是CMM中的一个关键过程域，直接影响软件产品的质量及交付。项目初期，质保人员在教师的指导下制定质量保证计划并分阶段检查，如软件结构的合理性、兼容性、易维护检查等；其次，协同教师采用W模型对软件产品进行测试和评估。在需求分析分析结束后，采用静态测试方法，对需求规格说明文档进行测试评审并提交测试报告；概要设计结束后结合需求规格说明，对概要设计说明书进行静态测试并提交测试报告；详细设计阶段对详细设计说明书进行评审，质保人员着手设计测试用例，提交测试报告及测试用例文档；编码和集成阶段，开发人员实现某一单元模块后进行单元测试、模块间的集成测试，提交测试报告；质保人员依据设计的测试用例进行确认测试、系统测试工作，并最终提交软件产品质量评估报告。

1.6软件配置管理过程改进。

软件配置是一种通过标识和文档来记录配置项的管理工作，控制这些资料的变更、记录和报告变更的过程状态。每一过程活动结束都应提交评审通过的文档、数据等资料，配置管理人员通过工具（比如VSS）进行入库、授权修改管理，形成需求基线、设计基线、代码基线及测试基线，使整个软件产品资料齐全且版本一致，规范化管理。

2结束语