配置管理计划示例
ITSMS配置管理计划(含配置清单)
是否经过评审 任务
状态
是
制定计划 完成
是
制定周报 完成
是
制定月报 完成
是
制定控制报告 完成Biblioteka 是填写问题跟踪 记录表
完成
是
记录事件 完成
是
制定配置管理 计划
完成
是
填写变更记录 完成
编制人： 审核人： 批准人：
日期： 日期： 日期：
FXTS-ITSMS-P07R01
配置管理计划
项目名称： 项目编号：
目的：编写本配置管理计划的目的是描述项目生命周期过程中所需 执行的所有配置管理活动。
所包含的主要配 置项 配置项计划 配置项周报 配配置置项 偏月 差报 控制报 告 问题跟踪记录表
事件记录
配置管理计划
配置变更记录
[要求定期检查，一周一收集]
配置管理计划模板-V2.1-b
所需人员
项目人员及其职责在《项目开发计划》文档中进行描述，此处不再赘述。
所需资源
服务器名称
计算机资源 备注
工具名称
辅助工具 发布公司
基线名称 软件需求基线 概要设计基线 详细设计基线 代码基线
测试基线
运行基线
基线缩写 SRBL PDBL DDBL SCBL
STBL
PRBL
基线标识 SR PD DD SC
ST
PR
基线定义
版本号 1.0 1.0 1.0 1.0
1.0 1.0
计划建立日期 2003/3/10
文档名称 《软件配置管理计划》
SCM报告
记录方法 发布日期或频度
手工
YYYY-MM-DD
《配置项状态记录》 《变更日志》
《基线发布报告》 《基线审计报告》
《产品发布报告》 《项目成员周报》
手工
每两周一次
软件配置管理计划
计划简介
【文档的目的是定义SCM的职责、所需资源以及描述在项目开发以及维护阶段所需要实施的一系列SCM活 【项目是不同的，但是每个项目都应该有SCM计划，SCM计划的执行应该与开发活动计划相一致，以保证 同开发工作的范围一致。通过识别要置于配置管理之下的配置项和将要建立基线的点，可以确定SCM工作 和时间。在此背景之下，制定本软件配置管理计划。】
软件工程组 项目经理或其 他人员
软件工程组、 SQA 人员 项目经理 软件工程组、 SQA人员及其他 相关人员
项目经理
计划审计日期 计划审计人员 YYYY-MM-DD XXX YYYY-MM-DD XXX
变更权威 正式基线：CCB 开发基线：项目经理 项目经理
项目经理
测试负责人 使用者本人
配置管理计划（范文）
配置管理计划配置管理计划篇一：配置管理计划公司名称项目名称配置管理计划版本1.0 ? [注：以下提供的模板用于R atinal Uni fied Prces s。
其中包括用方括号括起来并以蓝色斜体（样式=InfBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式（样式=Bd y Text）。
]修订历史记录Cnfi dential ?公司名称 , 1999 Page 2 f 6目录1.简介1.1目的1.2范围1.3定义、首字母缩写词和缩略语1.4 参考资料1.5 概述 2. 软件配置管理2.1 组织、职责和接口2.2 工具、环境和基础设施3. 配置管理活动3.1 配置标识3.1.1 标识方法 3.1.2项目基线3.2 配置和变更控制3.2.1 变更请求的处理和审批3. 2.2 变更控制委员会 (CCB) 3.3 配置状态统计3. 3.1 项目介质存储和发布进程3.3.2 报告和审计4. 里程碑5. 培训和资源 6. 分包商和厂商软件控制 Cnfid ential ? 公司名称 , 19994 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 6 6 6 Page3 f 6配置管理计划1. 简介 ? [配置管理计划的简介应提供整个文档的概述。
它应包括此配置管理计划的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。
]1.1 目的 ? [阐明此配置管理计划的目的。
]1.2范围 ? [简要说明此配置管理计划的范围；它的相关模型，以及受到此文档影响的任何其他事物。
] 1.3 定义、首字母缩写词和缩略语?[本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。
配置管理基线计划
配置管理基线计划
1. 引言
本计划旨在建立和维护组织内部计算机系统的配置管理基线。
该计划目的是通过创建和跟踪已知好的配置来最大限度地减少系统配置错误和安全漏洞。
2. 范围
该计划适用于组织内所有物理和虚拟服务器、桌面计算机、路由器、交换机和防火墻等设备。
移动设备当前暂不在计划范围内。
3. 基线定义
我们将为组织内主要系统和设备制定以下配置管理基线:
- 服务器基线
- 服务器基线
- 网关路由器基线
- 枢纽交换机基线
- 桌面计算机基线
- 应用程序基线
- 数据库服务器基线
每种基线将描述系统的期望配置,包括常用软件版本、安全设置、账户和访问控制等。
4. 基线维护
部门将负责创建和维护各种配置管理基线。
基线将每季度或根据业务需要进行审阅和更新。
5. 合规性检查
每月我们将对随机选择的系统进行检查,查看是否符合相关的配置管理基线。
超出基线配置的系统将记录下来并进行调整。
6. 报告和督导
每月生成基线合规报告并报送给高层管理层。
不合规系统将列入下个月的优先处理对象。
以上就是初步的配置管理基线计划。
日后需要根据实际情况不断完善和优化该计划。
软件项目之配置管理计划(范文1)
XXXX项目配置管理计划简介本计划描述了配置组织结构以及贯穿项目组日常工作，由项目组识别并定义的一系列的配置项的实践过程。
1.1文档目的定义配置管理的职责、所需资源以及描述实施过程中一系列的配置管理活动，指导项目软件配置管理工作。
1.2适用范围本计划适用于XXXX项目的软件配置管理活动的制定。
1.3项目背景描述略。
1.4术语与缩略语软件配置管理：简称 SCM（Software Configuration Management），是在项目开发中，标识、控制和管理软件变更的一种管理。
配置项目标识：（Configuration Indentification）对软件项目在开发过程中的资源进行标识，以便标识。
配置审计：（Configuration Audit）对软件配置管理过程中的行动进行检查。
资源2.1配置管理组织架构图配置管理的组织架构主要角色有公司的配置管理（Configuration Management，CM），项目的配置管理（Configuration Management，CM），项目经理（Project manager，PM），以及配置管理审批人和项目成员。
图1 组织架构图2.2关键角色和职责配置管理员项目组中负责配置管理工作的角色，负责计划和控制配置管理过程。
在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统计添加或修改相关产出物的最新有效版本以及审核证明。
配置管理委员会（CCB）CCB 是一个虚拟的小组，对配置管理各项活动拥有决策权（例如审批配置管理计划，审批配置项变更请求等）。
CCB 的决策采用“少数服从多数”的原则。
主要成员：甲方项目经理、高层领导、需求专家、架构专家、配置管理人员、测试专家和质量保证人员。
2.3所需资源表1 配置管理工具及辅助软件工具名称发布公司用途GitLab GitLab 配置库管理工具，主要源代码SVN Apache软件基金会配置库管理工具，主要是文档Microsoft Office Microsoft 办公工具Microsoft Project Microsoft 办公工具SCM 活动3.1配置库的创建和授权项目配置库创建项目配置库申请审批通过后，项目经理通过一体化运维平台的工作单给项目组配置管理员，要求开通配置库，并说明项目人员权限。
组织级配置管理计划-模板
XXX有限公司组织级配置管理计划文档修订记录♦变化版本编号简要说明日期变更人批准日期批准人状态VI. 0 A*变化状态：A——增加• M1前言本计划是组织级配置项目计划的组成部分，它规定了在组织级配置项目中如何开展配置管理工作，以便在项目的整个生存周期中，建立和维护软件工作产品的完整性和一致性。
1.2适用范围本计划是遵照组织级的《配置管理过程》、《配宜管理il•划》等标准规范和《裁剪指南》，结合本项目的实际情况制订：适用于整个产品生命周期的配置管理柑关活动。
1.3读者对象EPG组成员2组织级配置项管理2.1配置结构曰丄Ol-OSSPil丄0】•工程过程创丄02■顶目过程刮丄支持过程创丄04・組织过程il 丄05-Sm a 一j 02・EPG丄OF针计划二02■姐织培训m Q3・EFG活动口01 ■俎织月报□ 0Z溯监管LJ 03•配置监普LJ W发布公吿 a 二03-FAL丄01 ■风险库丄02・最侄实践丄03■度量库2-2配置项管理01-OSSP目录下文档为组织过程改进的知识库，作为组织改进的指导性文件：放入SVN库中归档管理，全体人员有可读权限。
当OSSP中文档需要修改时需要走正式的变更流程。
02-EPG目录下文档为改进组活动产生的文档：放入SVN库中归档管理。
'01-组织方针'全体可读，当'01-组织方针'中文档需要修改时需要走正式的变更流程。
'02-组织培训*中的文档培训人员（顾晓丹）在有培训需求进入的情况下是期进行更新，配置管理人员左期（每月）检查培训中产出的文档做配置审计。
'03-EPG活动管理'改进组可写，配置管理人员立期（每月）检查组织月报、质量保证报告、配置项状态的提交情况并做配置审计，EPG组世期更新。
03-PAL目录下存放改进中优秀的资产，当有新资产加入的时候，及时更新并做配置审计。
变更流程：对配置管理下的工作产品作变更（如：OSSP标准文档的改变、新资产入库等），都需要被跟踪和控制，用来保证工作产品配置信息的完整性和可跟踪性。
配置管理计划模板完整版
项目编号：xxxxxx项目名称：xxxxxx 配置管理计划修订历史记录目录1. 简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4参考资料 (5)1.5概述 (5)2. 软件配置管理 (5)2.1组织、职责和接口 (5)2.2工具、环境和基础设施 (6)3. 配置管理活动 (8)3.1配置标识 (8)3.2配置项变更控制 (10)3.3配置管理活动计划 (10)3.4报告和审计 (17)4. 培训和资源 (18)4.1培训所需环境 (19)4.2培训参加人员 (19)4.3培训具体安排 (19)5. 分包商和厂商软件控制 (19)错误!未指定书签。
1.简介1.1目的在项目的生命周期内，为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整，特制定本计划。
1.2范围纳入项目配置管理的配置项、过程记录及其它相关资料。
1.3定义、首字母缩写词和缩略语本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。
这些信息可以通过引用项目词汇表来提供。
1.3.1CM (Configuration Management）配置管理。
1.3.2配置项（Configuration item)指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。
1.3.3基线（baseline）一种通过正式评审和认可的规范说明或产品，此后将其作为进一步开发的基础，只有通过正式的变更控制过程才可以变更。
1.3.4基线库（Software baseline library）项目软件生命周期中基线的集合。
用VSS软件工具管理时，基线库可以是一个独立的VSS系统，也可以是VSS系统中的一个目录。
1.3.5配置审计（Configuration audit）审核配置管理库系统的结构和设施，验证软件基线库内容的完备性和正确性，验证与适用的配置管理标准和规程的符合性1.3.6配置控制委员会（CCB）有权力管理项目基线的委员会，它代表项目经理和所有可能受到项目基线更改影响的组的利益，由它审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。
配置管理配置管理计划
作为对“软件工程协会”(SEI) 的“能力成熟度 模型”(SEI CMM) 的解释，“配置与变更请求 管理控制对项目工件的变更，并且维护项目工 件的完整性”。 目的
同时更新 有限通知 多个版本
1
概念——配置与变更管理（Ⅱ）
目的
同时更新
• 当两个或更多的角色分别对同一个工件进行操作时，最后进行变
• 是共享工作区，项目团队所有
成员都有权访问。整个产品是 在集成工作区中构建并建立基 线的。
3
概念——基线（Ⅰ）
基线是项目储存库中每个工件版本在特定时期的一 个“快照”
它提供一个正式基准，随后的工作基于此基准，并且只有经过 授权后才能变更这个基准。
建立一个初始基线后，以后每次对其进行的变更都将记录为一 个差值，直到建成下一个基线。
项目基线
• 基线提供一项正式基准，随后的工作都基于此基准，并且只有
经过授权后才能对此基准进行变更。
• 说明要在项目或产品生命周期中的哪些时间点处建立基线。最
常用的基线在先启阶段、精化阶段、构建阶段和产品化阶段结
束时建立。 也可以在不同阶段中的各次迭代结束时生成基线，
甚至可以更频繁些。
• 说明由谁来对基线授权，以及基线中包含的内容。
16
配置管理计划——时机
一旦项目资金得到批准，就可在精化阶段初 期编写CM 计划。应该在每阶段开始时再次 审查计划，并进行相应更新。
CM 计划需要存档，以便在布署之后的维护 活动中，用于确定特定软件资产的保存位置。
17
配置管理计划——软件配置管理
2.1 组织、职责和接口
说明谁将负责执行 CM 工作流程中所述的各种配置管理 (CM) 活动。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
酒店管理系统
分类:专题计划使用者:项目经理、配置变更控制经理、集成员、项目组成员
配置管理计划
Version 1.0
项目承担部门：配置管理部门
撰写人（签名）：
完成日期： 2010/7/18
本文档使用部门：□主管领导■项目组
□客户（市场）□维护人员□用户
评审负责人（签名）：
评审日期：
目录
1. 简介 4
1.1 目的 4
1.2 范围 4
1.3 定义、首字母缩写词和缩略语 4
1.4 参考资料 4
4
2. 软件配置管理 4
2.1 组织、职责和接口 4
2.2 工具、环境和基础设施 4
3. 配置管理活动 6
3.1 配置标识 6
3.1.1 标识方法 6
3.1.2 项目基线 6
3.2 配置和变更控制8
3.2.1 变更请求的处理和审批8
3.2.2 变更控制委员会 (CCB)10
3.3 配置状态统计11
3.3.1 项目介质存储和发布进程11
3.3.2 报告和审计11
4. 里程碑11
5. 培训和资源12
6. 分包商和厂商软件控制错误!未定义书签。
配置管理计划
1.简介
项目CM计划说明在产品生命周期中将执行的所有与CM相关的活动。
它详细说明了活动时间表、分配的职责以及必需的资源（包括人员、工具和计算机设备）。
1.1目的
CM 计划的目的在于，定义或参考那些描述要在软件产品开发中执行配置和变更控制管理 (CM) 方式的步骤和活动。
1.2范围
本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。
本规范适用于软件特别是重要软件的配置管理计划的制订工作。
对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。
1.3定义、首字母缩写词和缩略语
CCB - configuration control board 变更（或配置）控制委员会
CI - configuration item 配置项
CM - configuration management 配置管理
Baseline：基线。
PCA：物理审计，在配置管理系统中建立基线的工件是否为“正确”版本。
FCA：功能审计，是核实软件配置项的实际性能是否符合它的需求。
CMP - configuration management plan 配置管理计划
CR - change request 变更请求
SCM - software configuration management 软件配置管理
任意角色–项目中所有角色
1.4参考资料
《Rational Unified Process 2000》
《SDP Plan》
《Develop Case》
2.软件配置管理
2.1组织、职责和接口
2.2工具、环境和基础设施
1.工具
1）产品数据量的预期大小：我们期望本项目至少有150个文件，50M的磁盘空间。
2）产品团队的分配：
服务器和客户机的实际位置：1台。
2G内存、160G硬盘。
Win7。
服务器位置在C2-6,客户端在C2-
1.3.4.5.7.8.9.10
3.配置管理活动
3.1配置标识
3.1.1标识方法
最终的工件的命名方式是大写字母+缩写+编号+名称例：HMS-CM-101-配置管理计划
相应的工件的中间版本命名方式是以对应的阶段大写字母缩写加类别大写缩写加版本编号命名
发布标志为产品缩写加版本号,阶段发布为阶段号加版本号
3.1.2工件存储目录及分类
项目开发过程产生的工件由相应的负责人及时上传至SVN服务器，由配置管理员统一管理。
SVN服务器文件存放目录分类如下图
3.1.3文件上传管理
所有模块负责人必须与每日工作结束之前上传当日工作内容上传至SVN服务器。
所有上传工件必须符合标识方法中的命名方式。
3.1.3项目基线
基线创建
非代码类基线：由配置经理根据《开发案例》创建
代码类基线：由集成员根据产品架构文档创建
3.2配置和变更控制
3.2.1变更请求的处理和审批
软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。
变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。
所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。
进行多次复审和结束项目时都可使用此信息。
变更过程中的活动
3.2.1.1变更过程中的变更请求状态
了。
已关闭变更请求不再引人注意。
这是可以指定给变更请求的最后一个状态。
只有 CCB
复审管理员有权关闭变更请求。
变更请求被关闭后，提交者将收到一份有关对
变更请求的最终处理结果的电子邮件通知。
在下列情况中可能关闭变更请求：
1) 其已核实的解决结果在发布工作版本中得到确认之后；2) 其拒绝状态得到
确认时；或 3) 被确认为对现有变更请求的重复。
在后一种情况中，会将重复
变更请求通知给提交者，并将提交者添加到该变更请求中，以便以后通知他们
（详情请参见状态“拒绝”和“重复”的定义）。
如果提交者希望对关闭变更请求
有异议，则必须更新变更请求并且重新将其提交供 CCB 复审。
变更过程的变更请求状态(状态图)：
3.2.1.2保存变更历史记录
如果工件为Word文档，则在文档的修订文档历史记录。
如果工件为其他工件，必须在相应的记录中保存变更历史纪录。
3.2.1.3变更请求中受影响配置项的变更
在变更请求中受影响配置项需要变更时，首先由CCB协调员通知受影响配置项的变更人员，其次被通知人员按照标准变更流程进行变更。
3.2.2变更控制委员会 (CCB)
1.职责：CCB 的基本任务是明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执
行。
2.选择成员标准：从用户、开发人员、测试小组、项目管理中选择。
3.项目的CCB成员为：
B 主席：
5.处理变更请求和确认的过程：
CCB以事触发为主要工作方式，必须定期(每个阶段结束时)按需召开会议。
确保变更提议及时
得到了复审和处理。
拟定变更复审通知协议。
确保变更请求提交后，各有关人员都得到了通知，决定由谁复审各种
工件。
传达给同事和团队负责人，以及变更提议的接受者，并让他们有机会复审并参与意见。
3.3配置状态统计
3.3.1项目介质存储和发布进程
3.3.1.1项目介质保留策略、备份计划、事故处理计划、恢复计划
1.备份机制及保留策略：
1)每天实验结束时将主服务器的数据备份到ftp服务器中。
2)ftp服务器只保留最近一周的备份。
2.事故处理和恢复机制：
如果出现事故(如：主服务器当机、遭病毒、硬件损坏等)，采用ftp服务器上的数据进行恢复。
3.防病毒/杀毒机制：
1)杀毒/防病毒软件：Antivir
2)频率：每日杀毒。
3)负责人：系统管理员(施皓)。
3.3.1.2介质保留方式：
介质保留方式：联机。
类型：移动硬盘。
格式：Windows的文件。
3.3.2报告和审计
目的：让项目经理确定需要报告哪些产品的相关变更数据，以及报告人和报告频率。
频率：每日/每个阶段结束时进行报告。
报告人：配置管理经理。
1.基于变更请求的报告。
1) 龄期：基于时间的报告。
内容和格式如下：
2) 分布：基于计数的报告。
内容和格式如下： 3)
4) 趋势：与时间和计数有关的报告。
内容和格式如下：
2. 工作版本报告。
工作版本报告中列出了构成软件某一特定版本的一个工作版本的所有文件、它们的位置以及已并入的变更。
3. 审计。
包含功能审计和物理审计。
1) 功能审计：核实软件配置项的实际性能是否符合它的需求。
2) 物理审计：验证在配置管理系统中建立基线的工件是否为“正确”版本。
4. 配置状态报告（参见附录2）
4. 里程碑
在每一次迭代完成时，设立一个里程碑。
CM 计划：在先启阶段创建，精化阶段各迭代中进行CM
计划更新，精化阶段完成时CM 计划完成。
5. 培训和资源
培训：
6.附录配置管理报表及其格式附录1
附录2
Configuration State Accounting 1、配置项状态
3
4
5、CM环境状态
5．1、主服务器状态
5．
6。