配置管理规范
对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：
1、配置项及其命名规则；
2、配置库文件目录结构；
3、角色和权限定义；
4、配置项变更流程；
5、配置项发布；
6、基线定义和基线变更。
配置项及其命名规则
对我们的项目来说，配置项需要包括以下的内容：
1、项目管理过程文档；
a) 项目任务书；
b) 项目计划；
c) 项目周报；
d) 个人日报和周报；
e) 项目会议纪要；
f) 培训记录和培训文档；
2、QA过程文档；
a) QA不符合报告；
b) QA周报；
c) 评审记录；
3、工作产品
a) 需求文档；
b) 设计文档；
c) 代码；
d) 测试文档；
e) 软件说明书和手册；
4、项目中使用的第三方产品
上文中用红色部分标识的是容易遗漏的配置项，尤其是第4个（项目中使用的第三方产品），实际上，一个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了IBM 的MQSeries、Oracle、一些第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：
1、版本配合的问题：大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过程中，版本的配合问题是一个需要关注的问题；
2、发布的完整性问题：一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第三方软件来说，比如我们使用的许多perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，很容易就会发生遗漏；
3、在某些特殊条件下由于第三方软件的变化引起的基线变更：这种情况极少会发生，但在我们以前的项目中，确实还遇见过。一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方软件，这就补课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更。
关于第三方软件产品配置项的管理还有一点需要说明：由于第三方软件有可能会比较大，而且相对我们的项目来说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相关配置项。配置项的命名包括两个方面的内容：
1、配置项标识：在我们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。下表列出了我们在项目中使用的配置类别命名：配置类别命名配置类别命名
项目任务书PT 项目计划PP
项目周报PR 个人日报和周报PER
项目会议纪要PM 培训记录和培训文档TR
QA不符合报告QAP QA周报QAR
评审记录RR 需求文档REQ
设计文档DD 代码CODE
测试文档TD 软件说明书和手册MAN
项目中使用的第三方产品PART3
配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”，如果细分的话，可以分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。
2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下：a) 基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。
里程碑基线――对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。
阶段性成果基线――阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基线符合一定的条件。
b) 其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。
关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在VSS库上用Label来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪。
配置库目录结构
在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用的方便性，所以需要根据自己的需要确定一个合理的结构。
在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照模块划分。这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。
下表是我们在实际中采用的配置库结构（部分）：第一级第二级第三级第四级说明M 管理类文档
PM 项目管理
0－Init 初始阶段
PC
PTR
PN
1－Plan 计划阶段
…………………………
QA
0－PPQAP 质量保证计划
…………………………
P 项目产品
0－Req 需求阶段
0－CRS 客户需求
1－SRS 需求分析文档
2－RTM 需求跟踪矩阵
1－Des 设计阶段
0－HLD 概要设计
1－DBD 数据库设计
2－Imp 实现/编码阶段
0－Module1 模块1
0－COD 代码
1－DDS 详细设计
2－HLD 概要设计
3－UNT 单元测试
…………………………
3－Test
0－Int 集成测试
1－Syt 系统测试
…………………………
4－Man 手册
…………………………
5－Others 其他
…………………………
从这里的配置库结构中可以看到，我们在最上层将配置项分为管理类和产品类：管理类中的项目管理部分基本是按照初始－计划－执行－收尾四个阶段来划分。在项目产品类别中，我们按照需求－设计－实现－测试四个阶段划分目录，在实现阶段，为每个模块划分了代码、详细设计、概要设计和单元测试四个目录，需要说明的是，在第三层中有一个HLD的目录，在模块下同样有一个HLD的目录，在我们的实际工作中，第三层的HLD目录用来存放系统级别的概要设计文档，而模块下的HLD目录用来存放模块级别的概要设计文档。
当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module的级别上可以增加一个SubSystem的层，便于在产品集成时更加方便。
角色定义及权限分配
角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。
下面是该项目中我们的角色定义：
配置管理员
整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。
开发经理
开发经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；
开发组长
开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；
开发工程师
开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；
测试组长
测试组长负责组织测试，给出测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，对测试目录有读写权限；
测试工程师
测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编写。测试工程师对自己负责的模块有读取权限，对测试用例目录有读写权限。
QA工程师
QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。
〔说明〕除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。
配置项变更流程
我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：
新建、检入、检出及破坏
1、新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量
指定每个project只有一人负责新建。
2、检入：即check in，检入频率规定如下：
i. 在代码编写前，至少每周一次
ii.代码编写阶段，至少每天一次
iii. 测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。
iv. 为配合检查、备份工作，需在检查备份周期前全部check in (不保持check out)并退出登录。详见“检查及备份”部分
3、检出：即check out。原则上只对要修改的文档方可检出。
4、破坏（Destroy）：一般情况不可以破坏文件、目录。
5、如果是误操作，则可在一天内提交管理员处
6、如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。
7、各阶段环境职责
环境阶段负责人职责
公司内部编码前开发人员
每周及需要评审前check in工作产品（包括版本发布说明）到SVN上
开发组长每周
SCM人员每周统计
编码开发人员
每天check in工作产品（包括版本发布说明）到SVN上
开发组长每周检查
经理及组长抽查及走读
SCM人员每周统计，检查代码风格
测试开发人员
每天check in工作产品到SVN上（如当天没有修改可以不进行check in）
以LABEL形式提交一个新版本给测试，附带版本发布说明
测试人员对测试完成后的程序打LABEL
发布后开发人员将新版本check in到SVN,打测试LABEL,向测试人员提交申请
测试人员对测试完成后的程序打LABEL
SCM人员对变更做好控制和记录，并发布
现场开发负责人将发布后的产版本更新至现场，或指定人员进行
公司外部编码现场开发负责人
在无法通过sos连到公司SVN的情况下，需要在现场建立配置库（文件方式或SVN等），做到基本的版本控制和备份。每周至少通过SOS提交一次至公司的SVN库中。
现场开发人员每天check in工作产品到现场配置库（包括版本发布说明）。
SCM人员做好督促和监督工作，每周将现场开发负责人提交的现场版本更新到公司配置库（SVN）。
测试现场开发人员每天check in工作产品到现场配置库（如当天没有修改可以不进行check in）。
如已经回公司则每天check in工作产品到公司配置库SVN（如当天没有修改可以不进行check in）。
每周通过SOS提交一个新版本给测试，打测试LABEL,附带版本发布说明(如没有更新可不提交)
对测试完成后的程序打LABEL
SCM人员做好督促和监督工作
发布后现场调试现场维护现场开发负责人在无法通过sos连到公司SVN的情况下，需要在现场建立配置库（文件方式或SVN等），做到基本的版本控制和备份。每周至少通过SOS 提交一次至公司的SVN库中。通过LABEL提交测试版本
现场开发人员对修改后的版本通过SOS check in 新版本到SVN,打测试LABEL,向测试人员提交申请（由修改至提交测试人员不应超过三天）
测试人员对测试完成后的程序打LABEL
SCM人员对变更做好控制和记录，并发布
做好督促和监督现场提交更新版本到SVN。
关于SVN库内存放文件类型及大小的规定
1、文件名及目录规定：以英文名字命名
2、文件大小规定：最大不超过20M
3、允许类型：
4、表2.1中提至的文档类
5、代码及脚本类及为配合编译需要的类库等
6、以下类型不允许存放在SVN库中：
7、备份数据
8、安装程序、打包程序（zip\rar）
9、超过20M以上的非代码类及开发文档类文件
10、对于特殊情况或不确定情况，需向配置管理人员咨询后再加入
11、对于不允许存放类型的配置类文件，可与配置管理员联络，随件附《说明清单》，以文件型式保存于服务器。
配置项发布
配置项发布是指配置项进行到一定的阶段（例如，里程碑阶段），需要对外发布时的规则。在我们的项目中，配置项发布是通过标签，即LABEL，来实现的。
阶段触发事件操作人标签类型打标签的级别
单元测试单元测试完成，可以提交集成测试开发人员FOR_TEST 模块级
集成测试集成测试完成，不通过（如通过进入系统测试阶段）测试人员
TESTED 模块级
BUG修改完成，可以提交测试开发人员FOR_TEST 模块级
集成测试通过，可以提交系统测试测试负责人TESTED 模块级
系统测试系统测试完成后，不通过，（如通过进入系统测试阶段）测试负责人TESTED 项目级
BUG修改完成，可以提交测试开发人员FOR_TEST 项目级
系统测试通过测试负责人TESTED 项目级
验收测试验收前的版本，可发布到现场安装配置管理员LOAD
项目级
验收后的版本，可发布的正式版本配置管理员LOAD 项目级
现场维护修改BUG后提交测试维护工程师FOR_TEST 模块级/项目级/文件级
测试通过与否测试人员TESTED 模块级/项目级/文件级
基线确立与变更
基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑和其
他工作依赖的基线（例如需求文档、设计文档等），另一类是开发过程中有必要保留的一种状态（例如代码过程中某个模块的一个有保留价值的snapshot）。对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。
我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记录即可。
检查与备份
1、检查：
根据SVN白皮书建议，要定期检查数据的正确性。SVN库管理员应每周检查一次，流程如下：
a) 开发人员于每周五下午5:30前check in（(不保持check out)）并退出登录
b) SVN库管理人员用analyze工具检查SVN数据库，操作如下：
在dos命令行中输入：analyze –f –d –c –v4 c:\svn\data
其中“c:\svn\data”为SVN库的数据目录
2、备份：
a) 每天增量备份，通过windowsNT以上自带的备份工具进行增量备份，备份以硬盘存放即可。
b) 每周全备份：每周检查完毕之后，对svn数据库进行全备份，建议以光盘介质备份。配置管理实施后记
应该说，这次我们对项目的配置管理实施是非常成功的，在整个开发过程中，基本没有出现因为配置管理的问题导致的对开发进度的延误。当然，在开发过程中也发生了由于需求变化导致基线变更引起开发进度的延迟，不过这不应该算作是配置管理的失误，因为作为配置管理来说，只能尽量保证基线变更不会导致项目失控。
总结我们这次的配置管理实施工作，除了这几篇文章中讲到的需要注意的问题外，我觉得有一些应该算做是决定实施成败的关键因素：
1、一个好的执行人员是成功的关键；
一个好的执行人员的重要性怎么强调都不过分。所谓的一个好的执行人员应该具备这样的
素质：
a) 对配置管理工作有较为深刻的理解；
b) 对使用的配置管理工具运用熟练；
c) 具有好的沟通能力，能和开发组长、开发人员以及其他干系人沟通；
d) 有好的执行力，对流程的执行能起到监督和推动作用；
e) 耐心细致，很多时候，细节决定了成败；
2、好的工具能起到事半功倍的效果；
选择一个合适的配置管理工具绝对是必要的，我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案，事实证明，我们选择的配置管理工具对我们项目管理实施的效果是决定性的。
3、在配置管理实施的初期，及时的指导起的作用是巨大的，甚至可以说是成功的主要因素；
对不熟悉配置管理的开发工程师来说，配置管理工作容易在一开始就让他们产生厌烦情绪，一点点使用上的不方便就会导致开发人员对配置管理的怨言，这个时候，及时的指导就显得非常重要了，我们在配置管理实施过程中，准备了《SVN操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册，进行了三次的培训，并在实施过程中随时解决开发人员在使用配置管理工具中的问题。而且，在实施初期，我们以奖励为主，在一个月的时间内没有将配置管理工作作为考核内容。
4、每周的配置状态检查非常重要；
在配置管理基本走上正规后，每周的配置状态检查是我们对配置管理执行效果的检查，一旦发现问题，会作为QA问题报告发出并要求限期改正。如果没有这个检查制度，配置管理工作很难持续受控
软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程，制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则，不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1)。 ２、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用，综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2）。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得，编制《软件采购计划表》（附件3）。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年
限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得，需经过信息化部门鉴定,严格履行资产处置报批手续：?(１）已经达到规定得最低使用年限,且无法继续使用得.?（２）未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?（3）未达到规定得最低使用年限,因计算机硬件报废，且无法迁移到其她计算机上继续使用得. ８、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4)。
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________
目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)
1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图
1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员
软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
软件三库管理规范-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
1目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2参考文献 《软件三库管理制度》 3术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
软件配置管理规范1 1．简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退
出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能 通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1
页眉 软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline)
己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 页脚 页眉 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范 项目计划与控制规范 1.5.4 指南 配置管理计划指南 基线策略指南 配置状态报告编制指南 配置审计工作活动指南 配置管理工具指南 VSS 使用指南 组织管理配置库使用指南 软件开发文档命名约定 1.5.5模板 配置管理计划 配置状态报告 配置审计报告 文档变更请求 1.5.6 检查表 无 1.5.7 培训 《软件配置管理教材》 《软件变更控制管理教材》 《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop
软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理
2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
版本管理规范(草案) 研发部 2009-2-4
目录 文档类别使用对象....................................................... 错误!未定义书签。1．引言................................................................ 错误!未定义书签。 目的 .................................................................. 错误!未定义书签。 范围 .................................................................. 错误!未定义书签。 术语定义 .............................................................. 错误!未定义书签。 版序控制记录 .......................................................... 错误!未定义书签。 版本更新记录 .......................................................... 错误!未定义书签。2．版本管理............................................................ 错误!未定义书签。 2．1版本标识方法...................................................... 错误!未定义书签。 2．1．1正式版本..................................................... 错误!未定义书签。 2．2目录结构.......................................................... 错误!未定义书签。 2．3文档的存放........................................................ 错误!未定义书签。 当前版本和历史版本的存放 ........................................... 错误!未定义书签。 开发文档的存放 ..................................................... 错误!未定义书签。 源代码的存放 ....................................................... 错误!未定义书签。 SQL语句的存放...................................................... 错误!未定义书签。 发行文档的存放 ...................................................... 错误!未定义书签。 2．4权限控制管理...................................................... 错误!未定义书签。3．更新管理（版本升级） ................................................ 错误!未定义书签。 版本升级原则 ........................................................ 错误!未定义书签。 新版本的发布 ....................................................... 错误!未定义书签。4．备份管理............................................................ 错误!未定义书签。5．用户版本管理........................................................ 错误!未定义书签。6．研发部统一管理阶段性版本............................................. 错误!未定义书签。 阶段性版本的提交到研发部............................................... 错误!未定义书签。 阶段性版本的发布到公司网站上........................................... 错误!未定义书签。 各项目组新版本内部及时备份。........................................... 错误!未定义书签。7．版本工具的使用...................................................... 错误!未定义书签。 研发部采用SVN配置管理工具............................................. 错误!未定义书签。8．各项目组提交文档及源码以及规则....................................... 错误!未定义书签。 各项目组需要提交的文档................................................ 错误!未定义书签。 目前所管理的产品列表................................................... 错误!未定义书签。9．周报管理制度........................................................ 错误!未定义书签。10．风险管理制度....................................................... 错误!未定义书签。
1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动，确保配置项正确地唯一标识并且易于存取，保证基线配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动，针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法，本文件以CVS（并行版本系统）配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理（Software Configuration Management，SCM） 软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项（Configuration Item，CI） 凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线（Baseline） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一
软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书
需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。
配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA
软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则，不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关的各类软件。 3.优先采用场地授权（许可）方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1）。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》，对软件使用部门需要的相关软件进行统一测试和试用，综合考虑软件的价格、兼容性、安全性和售后服务等因素，确定软件选型，明确软件名称和版本。涉及使用免费软件的，更新《可使用免费软件清单》（附件2）。 3.信息化部门依据单位软件使用管理台账，梳理单位软件需求与现有软件许可的差异。单位软件许可不足的，编制《软件采购计划表》（附件3）。
4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件，因以下情况申请报废的，需经过信息化部门鉴定，严格履行资产处置报批手续：（1）已经达到规定的最低使用年限，且无法继续使用的。 （2）未达到规定的最低使用年限，因技术进步等原因无法继续使用的。 （3）未达到规定的最低使用年限，因计算机硬件报废，且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4）。
软件配置管理规范精编 W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】
软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分：
参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求 中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的 信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit)
软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线 (Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。
中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)
配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责
(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
软件配置管理流程
目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)
1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图
软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项
软件配置管理规范 版本：V1.0
目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 2规范概述 (1) 3规范详述 (1) 3.1配置库管理规范 (1) 3.1.1配置库说明： (1) 3.1.2配置库目录结构： (2) 3.1.3配置库权限设置： (4) 3.1.4配置库备份机制： (5) 3.2配置项管理规范： (5) 3.2.1配置项入库： (5) 3.2.2配置项标识： (5) 3.3基线管理规范： (8) 3.3.1基线说明： (8) 3.3.2基线分类： (8) 3.3.3基线命名规则 (9) 3.4其它项配置规则： (9) 3.4.1分支命名规则 (9) 3.4.2Eclipse工作空间命名 (9) 3.4.3版本标签命名规则 (9) 3.5过程简称表： (10) 3.6配置类别简称表: (10)
1 介绍 1.1 目的 本规范目的在于指导配置管理人员如何利用配置库管理所有配置项，从而加强对公司软件产品的控制，保持软件产品在其整个生命周期中的一致性、完整性、可追溯性。 1.2 范围 本规范适用于重要软件产品和软件项目的配置项管理。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。 2 规范概述 本规范应用于软件配置管理过程，主要包括配置库的设置，配置项的标示，基线命名等。 3 规范详述 3.1 配置库管理规范 整个项目开发中，把所有的工作成果存放在四个库中，分别为：开发库、受控库、基线库、产品库，每个库下面对应的分为文档库和代码库两部分。前三个库存放到配置管理工具数据库中，产品库建立在文件服务器\\192……\project目录中，根目录名称为项目编号。 配置管理员根据项目情况（项目规模、人员使用工具习惯等）、开发模式（本地开发、异地分布式开发）、财力等因素，确定配置管理工具软件（如：ClearCase、SVN、VSS等）以及计算机资源（内存、CPU、网络环境）；确定存储库备份环境（备份服务器、备份介质）。 3.1.1 配置库说明： 开发库，包括整个开发过程中处于动态变化过程中的工作成果。 受控库，存放项目计划中定义的需要进行控制工作产品。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。 基线库，存放项目过程的基线配置项。
1 目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2 参考文献 《软件三库管理制度》 3 术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4 职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5 管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 5.1.2 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 5.1.3 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2制定三库管理规定 5.2.1 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。 b)访问控制 各仓库设置权限管理，一般来说，给予库管理员写权限，给予相关人读权限，详见三库管理要求（第5.4、5.5、5.6节）。