配置管理规范.docxVIP

配置管理规范

?对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：

?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)其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，