配置管理规范
对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：
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、配置项标识：在我们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。下表列出了我们在项目中使用的配置类别命名：
配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”，如果细分的话，可以分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。
2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下：
a) 基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。
里程碑基线――对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。
阶段性成果基线――阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基线符合一定的条件。
b) 其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。
关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在VSS库上用Label来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪。
配置库目录结构
在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用的方便性，所以需要根据自己的需要确定一个合理的结构。
在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照模块划分。这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。
下表是我们在实际中采用的配置库结构（部分）：
从这里的配置库结构中可以看到，我们在最上层将配置项分为管理类和产品类：管理类中的项目管理部分基本是按照初始－计划－执行－收尾四个阶段来划分。在项目产品类别中，我们按照需求－设计－实现－测试四个阶段划分目录，在实现阶段，为每个模块划分了代码、详细设计、概要设计和单元测试四个目录，需要说明的是，在第三层中有一个HLD的目录，在模块下同样有一个HLD的目录，在我们的实际工作中，第三层的HLD目录用来存放系统级别的概要设计文档，而模块下的HLD目录用来存放模块级别的概要设计文档。
当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module的级别上可以增加一个SubSystem的层，便于在产品集成时更加方便。
角色定义及权限分配
角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。
下面是该项目中我们的角色定义：
配置管理员
整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。
开发经理
开发经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；
开发组长
开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；
开发工程师
开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；
测试组长
测试组长负责组织测试，给出测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，对测试目录有读写权限；
测试工程师
测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编写。测试工程师对自己负责的模块有读取权限，对测试用例目录有读写权限。
QA工程师
QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。
〔说明〕除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。
【小结】在本章中，我们介绍了配置管理规范的配置项及其命名、配置库的目录结构以及配置管理的角色权限分配。在下一章中，我们将介绍完配置管理规范的其他内容并给出配置管理实施过程中的一些心得体会。
对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：
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 | 其他 | |||
| …… | …… | …… | …… | …… |
当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module的级别上可以增加一个SubSystem的层，便于在产品集成时更加方便。
角色定义及权限分配
角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。
下面是该项目中我们的角色定义：
配置管理员
整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。
开发经理
开发经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；
开发组长
开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；
开发工程师
开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；
测试组长
测试组长负责组织测试，给出测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，对测试目录有读写权限；
测试工程师
测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编写。测试工程师对自己负责的模块有读取权限，对测试用例目录有读写权限。
QA工程师
QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。
〔说明〕除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。
【小结】在本章中，我们介绍了配置管理规范的配置项及其命名、配置库的目录结构以及配置管理的角色权限分配。在下一章中，我们将介绍完配置管理规范的其他内容并给出配置管理实施过程中的一些心得体会。
