1目的
为加强丹东银行项目的组织结构以及贯穿本项目软件生命周期的由组织识别并定义的一系列的软件配置项的实践过程。

规划工作必须在项目最开始时进行，和开发整个软件项目规划保持一致。

软件配置管理规划，连同软件质量保证规划和其他可能的特定约束规划都要符合本项目的软件项目规划，制定本制度。

2范围
本规划适用于“丹东银行项目”的软件配置管理活动的制定。

3术语与定义
计算机配置管理规定是指对机房运行的主机、操作系统、数据库和中间件等操作、维护过程的配置管理。

4职责与权限
4.1 科技信息委员会是计算机系统运行的监督管理部门，对本行的计算机系统运行中所产生的问题做最终决策。

4.2 科技开发部是计算机系统运行的主管部门，负责中心机房所有系统运行的安全管理。

4.3 各系统运行单位负责本部门系统运行的安全管理。

5政策
严密制度、控制风险、规范操作、严格管理
6流程图
7 风险控制要点
详情见风险库
8内容与要求
8.1 建立并维护配置管理的组织方针
这个方针主要确定组织所期望该项目的工作产品范围、产品基线、需要跟踪和控制变更的工作产品，及哪些相关人员应该了解配置管理计划。

8.2 确定配置管理需要使用的资源
确定过程和产品质量保证活动工具及计算机资源。

8.3分配责任
确定配置管理负责人及责任和权限。

8.4 培训计划
主要培训配置管理工作人员的角色、责任和权限，配置管理标准、规程和方法、配置库系统。

8.5 确定配置管理项目干系人
确定项目管理相关的项目干系人及介入时机。

项目干系人介入的主要活动是：建立基线、审查配置管理系统报告和解决问题、评估配置项变更的影响、进行配置审核、审查配置管理审核的结果。

8.5.1 制定识别配置项准则
确定进行配置管理的配置项的范围，并规定识别它们的标准。

8.5.2 制定配置项管理表
8.6配置管理团队
本项目的软件配置管理活动都由配置管理团队负责执行，领导负责规划和控制计算机配置管理规定。

《丹东银行配置管理团队人员组成》
8.7 配置管理标准
8.7.1 所需资源
8.7.1.1 计算机设备
【配置服务器的描述，此处所指的服务器是专门为服务的，不包括软件项目的服务器。

描述服务器所需要的配置，包括硬盘大小、内存大小、光驱等。

】
8.7.1.2 辅助工具
{配置管理工具，即进行所需要的工具，不包括软件开发过程需要的工具。

描述管理工具的名称、发布公司、版本等信息。

】
8.7.2 配置项和基线
项目开始阶段就要确定本项目的配置项，根据其在项目中的作用为每个基线和配置项分配唯一的标识并形成一系列的基线，策划在项目不同时期的版本状态。

8.7.2.1 基线选择
选择适用于本项目的基线。

8.7.2.2 配置项标识
项目开始时，配置人员和项目经理共同选择并确定适用于本项目的配置项，并为配置项标识。

列举说明如下表（如果此处不列举，也可以直接参见附表《配置项状态记录》）：
8.7.3控制基线变更
8.7.3.1 变更控制
正式变更：
项目组填写并提交《丹东银行配置信息登记簿》
按照《计算机配置管理规定》中的变更控制来处理
配置人员应填写《全配置分册》
非正式变更：
按照《计算机配置管理规定》中的变更控制来处理
8.7.3.3 管理问题报告非正式变更是否需要在此处进行描述
软件问题或者是错误（即产品功能与设计与需求不一致），或者是对配置控制下的元素的异常发现（即产品功能与预想的不符），需要更改基线库时，必须填写CCR 表，按基线变更流程解决此类问题。

8.7.4 配置状态信息
【确定项目中配置状态记录的信息、报告和发布频度。

在项目的过程中，需要记录配置管理行动，使得每个配置项的内容和状态都清晰明确，并可恢复配置项以前的版本。

】
本项目按照下表要求记录和发布配置状态信息：
8.8 配置管理策略
8.8.1 基线建立规划
基线是经审查和批准的配置项的集合，在开发周期，基线的建立时间是不同的，会受到不同变更权威的控制。

配置基线建立规划表：
8.8.2 基线审计规划
在每次主要的软件产品发布之前，必须进行基线审计，验证其完整性。

基线审计规划表：
有关审计的要求参见《计算机配置管理规定》中的审计部分。

8.8.3 基线的发布
【基线变更或审计通过之后，由负责人把基线发布给外部客户（如发布运行基线）或内部使用（如为测试而发布）。

完成基线发布之后，负责人应该通知所有受影响的人员，使那些经批准可以使用的人利用此发布。

】，基线的发布应参照过程描述，进行有关发布。

有关基线发布的要求参见《计算机配置管理规定》中的基线发布。

8.8.4 构造产品
产品的构造是指将源代码进行编译，形成可执行文件，发布给客户的过程。

8.8.4.1 构造产品的时机
【产品构造一般应在集成或系统测试前，和产品交付客户前进行。

】
8.8.4.2 构造的次数
【一般至少应为3次。

分别为集成测试前一次、系统测试前一次、产品交付前一次。

】
8.8.4.3构造人员
●【测试前的产品构造由项目经理协助测试人员共同完成；】
●【产品交付前的构造由项目经理协助配置负责人共同完成。

】
8.8.4.4 对应路径
【因在配置库上无法实现对文件的编译等操作，所以产品的构造必须把相关的文件从配置库上对应到客户端，然后进行产品的构造,构造完成后将产品增加到配置库上，并且交付给发行部门或用于测试。

】
8.8.4.5 构造方法和步骤：
【以下内容根据不同的项目方式不同：
首先由构造人员在本地机器上（可是构造人员自已的机器也可是其他机器，如其他服务器）为产品建立一个目录。

再从配置库上的基线域的代码基线中提取源代码到本地目录中，进行编译（编译的方法需根据开发语言的不同而有所分别，各项目的人员根据实际情况在规划中详细描述）。

形成的可执行文件暂存放在本地目录下，批准之后将形成的可执行文件放入到配置库中更新测试基线。

从测试基线中提取可执行文件到测试域并进行测试。

通过一定的测试，经过配置管理团队会批准可以将形成的可执行文件放入到配置库的运行基线下。

“建立对应目录—>从配置库上提取文件—>编译—>测试—>修改—>重新编译”，其中“编译—>测试—>修改—>重新编译”是一个反复的过程，直至最后测试通过，提交最终产品。

最终交付产品前，将要交付的产品对应到本地机器上，用光盘或其他媒体备份，并提交给负责发行的部门。

】
8.8.5 软件配置库的管理
规定项目人员对该库的存取权限，格式见下表：
注：对库的存取权限依次为R（只读）、C（修改）、A（增加）、D（删除）四种情况。

8.8.6 备份
【描述知识库信息备份的频度及备份的保存时间。

】
配置库备份记录表:
9检查与监督
9.1 科技开发部负责对本文件的可操作性、适宜性进行日常监督与检查，必要时对文件进行更改，确保文件适用，具体执行《文件控制程序》。

9.2审计部对该文件的执行情况，相关登记簿登记的完整性等进行集中检查、督促整改。

9.3 合规管理部负责每年一次对该规章制度的合规性进行审查，并督促整改。

10 支持性文件
10.1外部合规文件
无
10.2 内部合规文件
10.2.1《计算机配置管理规定》
10.2.2 《丹东银行配置信息登记簿》
10.2.3《丹东银行全配置手册》
11 支持性记录
无
12附录
无。