本资料仅供内部使用！配置管理应用指南XXXXXXXXXXX有限公司2020年01月05日本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属XXXXXXXXXX有限公司所有，受到有关产权及版权法保护。

任何个人、机构未经xxxxxx有限公司的书面授权许可，不得以任何方式复制或引用本文件的任何片断。

配置管理规范仅供内部使用修改记录目录1 概述 (1)1.1目的 (1)1.2适用范围 (1)1.3术语和缩略语 (2)1.4权限与职责 (2)1.5配置管理过程图示 (5)2配置项管理 (5)2.1配置项的范围 (5)3版本控制 (6)3.1基线命名规范 (6)3.2发行版本表示 (6)4配置库管理 (7)4.1配置库的建立 (7)4.2分配权限 (7)4.3基线库建立 (7)4.4配置项基线管理 (8)4.5配置库备份 (9)5配置库使用规范 (10)6系统集成 (11)6.1集成步骤 (12)6.2集成结果存放位置 (13)6.3说明 (13)7配置变更控制 (13)7.1软件及其相关文档的变更 (13)7.2配置库权限变更管理 (15)8配置状态报告 (16)8.1目的 (16)8.2记录内容 (16)8.3生成报告 (16)9CM阶段报告 (16)9.1目的 (16)9.2记录内容 (16)9.3生成报告 (17)10配置审核 (17)10.1类别 (17)10.2执行时机 (17)10.3不符合项处理 (17)11发布管理 (18)11.1交付管理 (18)12 异地项目管理 (18)1概述1.1 目的本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。

配置管理可采用各种工具及手工办法。

1.3术语和缩略语1.4角色与职责项目经理1) 确定配置项、基线、配置库目录权限，审核批准配置管理计划；2) 接收或拒绝小范围的变更申请，审查配置库变更；3) 项目开发过程中，监督配置库使用情况；4) 提出配置管理的建议和要求；5) 配合配置管理工程师的工作。

变更控制委员会CCB 一个虚拟小组，可由EPG成员、项目经理、资深的项目成员、配置管理工程师、QA等组成，项目经理为CCB召集人；CCB对配置管理各项活动拥有决策权（例如评审核划、评审变更请求等）。

开发小组1) 根据确定的配置管理计划和相关规定，提交配置项；2) 负责项目组内部测试；3) 按照软件配置管理工具的使用模型来完成开发任务。

测试小组1)从配置管理工程师处获取版本进行整合测试；2)负责验证代码变更及修改是否正确执行,测试小组测试通过的版本方可放入基线库。

QA 1)负责审核配置管理过程。

2)对配置审核中发现的不符合项，要求相关责任人进行纠正。

3)审核《配置管理计划》。

1.5配置管理过程图示图12配置项管理2.1 配置项的范围软件配置可包括以下几方面：开发文档，代码，第三方控件、插件，参考资料，测试文档，用户文档，项目管理文档，验收文档等。

项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户段性计划、产品需求规格说明书、概要设计报告、详细设计、数需求说明书、项目计划、项目进度计划、项目阶据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录。

代码主要指：源代码等。

工具主要指：脚本文件、插件、第三方控件等。

3版本控制3.1 基线命名规范基线即项目某一阶段配置项的快照，作为下一阶段软件活动的基础。

基线的建立通过打标签的方式实现，具体命名方式如下：[项目名称] + [阶段名称] + [日期] + [版本类型] + [版本号] + [分支版本号][项目名称]：即项目简称，大写。

如：GD_JYPX[阶段名称]：可选，如计划阶段（PP）、需求阶段（RD）、设计阶段（SD）、编码阶段（CD）、测试阶段（TEST）。

[日期]：YYYYMMDD。

如：20110312[版本类型]：I表示增量版本，V表示全量版本。

[版本号]：采用X_Y的形式，X表示大版本，Y表示子版本。

版本号反应了版本变化的程度。

如：1_12[分支版本号]：可选，表示在某个主干上建立的分支。

如：GD_JYPX_20110312_V1_13_Branch1_0表示在主干GD_JYPX_20110312_V1_13上建立版本为1_0的分支。

3.2 发行版本表示发行版本采用标签说明，结构如下：[项目名称] + [大版本] + [版本类型] + [版本号] + [子系统简称(拼音)]+日期+序号[大版本]：可选，表示同一项目为不同用户定制的版本。

[子系统简称]：可选，当一个项目有多个子系统时，为区分不同子系统而设置。

[版本类型]：分为3种Beta表示项目组内部测试，标签：NGTS_B1_0-20111015-01Release系统测试，标签：NGTS_Release1_0-SPmenhu-20111112-01Version正式发行版，标签：NGTS_Version1_0-SPmenhu-20111112-01[版本号] 对于Version正式发行版是必须要注明的，而其它可选。

4配置库管理4.1 配置库的建立项目立项时，由项目经理申请建立项目配置库，配置管理工程师与项目经理确定配置项，并参考《配置库目录结构指南》，建立配置库以及配置库目录结构；项目经理提供配置库权限清单（内容应包括员工姓名、项目名称、目录权限等），由配置管理工程师为相关人员的设置配置权限。

配置管理工程师组织建立配置库。

程序库主要通过设置版本的分支来实现对配置项权限管理：1) 编辑区：开发人员相对比较自由的存储空间，开发人员可以在自己的权限范围内任意取出提交。

2）管理区：项目质保人员，测试人员，需求分析人员均有读写权限。

3）基线区：配置管理工程师有最高权限，其余相关人员均为读的权限，发生变更时变更人员须提交变更申请后方可修改基线库内的配置项。

Ø 文档评审通过后，文档严格受控。

由配置管理工程师将通过评审后的文档移植到基线库里同时将该配置项从开发库移除。

Ø 代码一般在移交系统测试时纳入基线库受控，可根据项目的具体情况设置基线。

3) 产品区：产品库的产品均出自于基线库，产品库存储的产品用于交付和存档。

配置库统一由配置管理工程师管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。

在变更发生时，应及时做好基线的推进。

4.2 分配权限项目开始后配置管理工程师编写配置库目录结构，明确项目组成员以及相关人员的权限。

一般配置库可设立的权限有两种，读（r）、写（w）权限。

在编辑区内，文档部分项目组成员有rw权限，其他相关人员只r权限；代码部分项目组成员有rw权限，其他相关人员没有任何权限。

在基线库内，项目组成员仅有r权限，其他相关人的权限视情况而定。

在产品区内，除配置管理工程师外其他人没有任何权限。

配置管理工程师在整个配置库内均拥有最高权限。

配置库权限设置完成之后，由配置管理工程师将配置库名称、访问路径、访问权限等信息以邮件方式通知各相关人员；配置库使用人员以各自的用户名和密码进行访问配置库。

配置库密码只能在服务器上设置，如配置库使用人员密码遗忘，可以与配置管理工程师取得联系，进行修改密码。

4.3 基线库建立基线存在于基线库中，它是进一步开发和修改的基准和出发点。

对基线的变更只有配置管理工程师能实施。

进入基线前不对基线进行管理或者较少管理，进入基线后，对变化进行有效管理，而且这个基线作为后续工作的基础。

对于每一时期基线库的建立都应遵循以下原则：1.需要建立基线时，由项目经理提出基线建立申请，并填写《基线建立通知单》。

如项目经理未在计划时间点申请建立基线，配置管理工程师需主动提醒项目经理，CCB对基线建立申请进行评审，以保证组成基线的配置项是协调一致的、完整的、正确的。

B评审并批准基线建立申请后，配置管理工程师根据《基线建立通知单》中相应内容建立基线库，将正确的版本对应的所有资料纳入基线库管理。

3.基线区的使用者的权限只能为只读权限。

使用者向项目经理或部门经理提出权限需求，在领导同意之后，配置管理工程师设置相应权限，并通知相应人员。

纳入基线的原则：1.不会变化的东西不要纳入基线。

例如：会议纪要，周报，规范，方案2.变化对其他没有影响的可以不纳入基线例如：风险跟踪表等3.变化对其他有影响的配置项需要纳入基线。

例如：需求规格书4.4 配置项基线管理配置管理工程师根据配置管理规范及配置管理计划，对配置项进行分阶段管理，每一阶段在项目经理申请建立基线并且正式评审通过后纳入基线库，作为该项目的一个基线。

项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档，评审或审批通过后建立功能基线。

需求阶段：系统调研后开发人员进行需求分析，并整理产品需求规格说明书。

产品需求规格说明书经过客户的确认后，建立需求基线。

如需升级版本则必须通过评审或审批并得到客户的确认。

项目计划：需求分析完成后即可制定项目的开发计划，包括项目计划和主要下属计划。

包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。

项目开发计划评审通过后，建立项目计划基线。

设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。

针对用户需求规格说明书进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。

设计说明书评审或审批通过后，建立设计基线。

编码（设计实现）：编码按功能模块分子项目，即每个模块记作一个配置项。

代码在开发内部测试时提交Beta版，提交测试组系统测试时建立Release版本，系统测试产品正式发布后建立Version 版本。

测试：单元测试和系统测试。

单元测试通过提交《单元测试报告》，项目启动后应提交《测试计划》，系统测试完成后应提交《测试报告》。

配置时应说明测试的版本与编码版本的对应关系。

系统测试完成后建立测试基线。

版本发布：指发布测试组测试，项目组提交《代码交付清单》，CME根据清单获取代码进行编译，并按照《代码交付清单》中的内容将缺陷管理流程中已经FIX的BUG状态置为Deliver，发布到测试区，并对版本进行维护。

测试组仅需测试已经Deliver的BUG。

待测试完毕后将发布测试的版本转移到基线区中的产品，以备发布。

交付与验收：在交付前配置审核完成后建立产品基线，产品基线包含程序以及有关文档配置项，包括交付文档、代码、工具等。