工程型软件项目的配置管理实例

工程型软件项目的配置管理实例

配置管理双枪将VSS+SOS

“UserKeys”页面用来生成客户端访问操纵的Key文件：

使用“AddKey..."按钮能够弹出“AddUserKey”的对话框。该对话框的第一个输入框要求输

入要增加的用户在VSS中对应的用户名；第二个输入框要求输入SOS服务器的IP地址，

比如“8”，在局域网中能够设置为“192或68.1.1"；（注意,假如配置管理服务器同

时具有局域网与广域网的IP地址，同时用户需要从局域网与广域网都能够访问SOS,则对

同一个用户需要两个不一致的Key文件。在我们的实际工作中，我们只使用SOS进行Iniernet

上的访问，在局域网内还是使用VSS,因此没有这个问题）。下面的Expiration要求输入用

户的过期有效时间期限，选择“KeyNeverExpired”同意用户水只是期。

输入完相应信息后，点击“0K”确认生成用户Key文件，生成的用户Key文件储存在SOS

安装目录下，文件名为［用户名］.汰y,注意保留此文件，SOS客户端在启动时需要首先导入

一个key文件。

“WebProject”页面用于设置WebProject的公布路径：

在第一个编辑框中填入该工程在VSS中的路径，比如“$/WcbProjcctl/test”，在下面的编辑

框中输入公布的路径，比如"d:\tcmp”。公布路径也能够是在其他机器上的网络路径。

“Debug”页面是两个调试级别的选项：

这两个选项的具体含义在SOS的Manual中也没有明确提到，我们在实际运用中也没有发

现该选项的具体作用，建议不选取。

“ExcludedFileTypes”页面设置不同意添加到VSS库中的文件类型：

添加的条目是文件后缀，具有在列表中的后缀的文件都不能被添加到VSS库中。

“PinSupporl”页面用于设置是否同意PIN操作:

假如同意“PIN”操作，还需要指定ss.exe文件所在的目录。

设置完成后，需要重新启动SOS服务端，具体方法是在“服务''中启动相应服务：启动服

务完成后，服务端的安装设置就已经完成了，接卜.来我们介绍SOS客户端的安装与使用。

SOS客户端的安装与使用

SOS的客户端分为Windows版本、Solaris版本与Linux版本。Windows版本的安装非常简

单，直接执行安装程序就能够顺利安装。Solaris版本的SOS客户端以前形式公布，首先在

Solaris上安装GTK与GLIB,然后展开安装程序到任意目录即可。对Linux版本的SOS客

户端,也需要首先安装GTK与GLIB,然后展开相应tar包到任意目录即可。

Solaris>Linux与Windows版本的SOS客户端运行界面都非常类似，下面以Windows版本

为例说明其使用。

第一次运行SOS客户端时，系统会弹出一个对话框要求输入服务器与端口号。这时用

“Cancel”按钮取消，选择菜单项的“Tools”------“ImportEncryptionKey…”，导入服务端生成的

Key文件:

导入完成后,选择菜单项的“File"——"ConnecttoServer...输入服务器IP地址与端口,

假如连接成功，系统会给出能够连接的数据库列表，能够从列表中选择合适的数据库进行连

接访问。

连接成功后，显示的主界面与VSS的基本一致，SOS的操作方式与VSS的也一样，具体

能够参见VSS的文档。

下图是SOS的主界面：

当然，SOS在操作上也有一些与vss不一致的地方，下面列出这些不一致点：

1、缺省设置卜，SOS中每次登录不可能主动刷新工程树与文件列表，需要用工具条上的

刷新按钮进行刷新；

2、SOS的“Search”功能较VSS弱，只能查找CheckOut的文件；

3、SOS的Oplion设置项目很多，大部分都是SOS增加的为习惯远程连接的设置项：

Options

ExternalProcruts|Fil«Typ«s]Comn»ndDial。/

Gmtral|View|Files]HTTPProxy

rSendKeep7Aliyesi-er：|l

Dopuble-clickon«|Ask

rustconprcssionford&t<trw

rActonproject，recurs

MakeSourctOffSiteyourdeftuliSCCProvic

需定|取消|

【小结】本章介绍了VSS、SOS的使用，重点是SOS的安装与使用方法。SOS在使用上

事实上还有很多小技巧，在此不能一一列举，在sourcegear的网站上都能找到有关的资料。

在下一章中，我们将结合配置管理工具介绍配置管理规范的内容。

配置管理规范

配置管理规范

关于-一个通常的项目来说，配置管理规范的内容至少需要包含下列的内容:

1、配置项及其命名规则；

2、配置库文件目录结构；

3、角色与权限定义；

4、配置项变更流程；

5、配置项公布；

6、基线定义与基线变更。

配置项及其命名规则

对我们的项FI来说，配置项需要包含下列的内容：

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、在某些特殊条件下由于第三方软件的变化引起的基线变更：这种情况极少会发生，

但在我们往常的项H中，确实还遇见过。通常是由于原先选型时使用的第三方软件不能满足

要求，只能通过更换新的第三方软件，这就补课避免地需要变更基线（比如需求文档、设计

文档等）；将第三方软件纳入配置管理的范畴能够更方便地管理基线的变更。

关于第三方软件产品酿置项的管理还有一点需要说明：白于第三方软件有可能会比较大，而

且相对我们的项目来说，是很少会发生变更的（通常在一个项目过程中，不可能使用不一致

的配置项的命名能够便于杳找有关配置项。配置项的命名包含两个方面的内容：

1、配置项标识：在我们的项目中，通常使用“项占名_配置类别一配置项特殊标识”来

命名。下表列出了我们在项目中使用的配置类别命名：

配置类别命名配置类别令名

项目任务书PT项目计划PP

项目周报PR个人口报与周报PER

项目会议纪要PM培训记录与培训文档TR

QA不符合报告QAFQA周报QAR

评审记录KR需求文档REQ

设计文档DD代码CODE

测试文档Tl)软件说明书与手册

项目中使用的第三方产品PART3

配置项命名中的“配置项特殊标识”根据配置类别的不一致而不一致。比如，对“设计

文档”，假如细分的话，能够分为“概要设计”与“全面设计”；对“代码”，能够按照模

块来命名配置项。

2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，

配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清晰标识配置项

的状态。通常说来，配置库至少包含个人工作区、受控摩、公布区三个部分，在我们的项目

中，所有的配置项都储存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，

具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下：

a）基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑

的基线；另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。

里程碑基线一一对我们的项目来说，使用的是迭代的开发过程，以一个迭代过程为

例，分为需求、概要设计、全面设计、代码实现、单元测试、集成测试、系统测试七个阶段,

每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。

阶段性成果基线一一阶段性成果要紧表达在代码过程中，比如代码进行到一个阶

段，开发组长认为代码的这个状态能够保留，就能够确定为一个代码基线。这种基线通常不

需要通过评审等正式手段来确定，但也务必有相应的验证手段：比如在我们的项目中，在代

码阶段，确定代码基线的责任人是开发组长,但开发组长务必保证代码基线符合一定的条件。

b）其他版本：除基线版本外，有的时候候还需要在开发与保护过程中确定其他版本。

比如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，如今需要将每次修改

的内容作为一个版本。

关于版本，还有另一个需要注意的问题。通常来说，按照模块来划分，每个模块有自己

的版本演进比较合理。首先，一个模块通常是由一个或者两个开发人员完成的；其次，一个

模块的功能会比较单一且独立，在版本的演化过程中便亍操纵，也不可能与其他模块产生过

于复杂的关系。而产品的版本则需要由各个模块的不一致版本构成，这个纵横的关系需要很

好地管理，我们的做法是在VSS库上用Label来标识，同时保护•张描述产品版本与模块版

本关系的矩阵图便于追踪，

配置库目录结构

在确定了配置项之后，就能够确定配置库的目录结构了。配置库的FI录结构百.接关系到

配置管理的工作量与使用的方便性，因此需要根据自己的需要确定一个合理的结构。

在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是

按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划

分，比如首先是文档、代玛，然后在其下按照模块划分。这两种方式都有自己的优点，最终

我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便

于将同一模块的所有内容组织起来进行版本的管理。

下表是我们在实际中使用的配置库结构（部分）：

第一级第二级第三级第四级说明

\\管理类文档

PM项目管理

0—Init初始阶段

)C

)TR

PN

1—Plan计划阶段

••••••••••••••••••

QA

O-PPQAP质量保证计划

••••••

P项目产品

0—Req需求阶段

O-CRS客户需求

1-SRS需求分析文档

2-RTM需求跟踪矩阵

1—Des设计阶段

O-HLD概要设计

1-DBD数据库设计

2—Imp实现/‘编码阶段

0—Modulel模块1

O-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类文档目录的读写权限。

1说明）除配置管理员外，其他所有成员都没有Destroy目录与文件的权限，这是为了防止

误删除操作带来不可挽回的缺失。假如需要对目录进行Destroy操作，务必由配置管理员进

行。

【小结】在本章中，我们介绍了配置管理规范的配置项及其命名、配置库的目录结构与配置

管理的角色权限分配。在下•章中，我们将介绍完配置管理规范的其他内容并给出配置管理

实施过程中的一些心得体会。

配置项的变更与公布

配置项变更流程

我们所说的配置项变更流程要紧是针对配置项发生变化的操纵,在我们的项目中分为两

个部分，首先是对配置项新建、检入（Checkin）与检出（Checkout）的规定；其次是对入

库的文件类型与大小的规定：

新建、检入、检出及破坏

1、新建：即Add,除特殊情况外，通常不规定由谁来新建（只要有权限即可），但尽

量指定每个project只有一人负责新建。

2、检入：即checkin,检入频率规定如下：

i.在代码编写前，至少每周一次

ii.代码编写阶段，至少每天一次

iii.测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。

iv.为配合检查、备份工作,需在检杳备份周期前全部chockin（不保持checkout）

并退出登录。详见“检杳及备份”部分

3、检出：即checkout。原则上只对要修改的文档方可检出。

4、破坏（Destroy）：通常情况不能够破坏文件、目录。

5、假如是误操作，则可在一天内提交管理员处

6、假如超过天，则需要由项IR经理同意，且管理员破坏前要备份。

7、各阶段环境职责

环境阶段负责人职责

每周及需要评审前cheekin工作产品（包含版本公布说

开发人员

明）到VSS上

编码前

开发组长每周

SCM人员每周统计

开发人员每天checkin工作产品（包含版本公布说明）到vss上

开发组长每周检查

编码

经理及组长抽查及走读

SCM人员每周统计，检查代码风格

每天工作产品到上（如当天没有修改能够

公司内部checkinvss

不进行checkin）

开发人员

测试以LABEL形式提交一个新版本给测试，附带版本公布说

明

测试人员对测试完成后的程序打LABEL

将新版本checkin到vss,打测试LABEL,向测试人员提

开发人员

交申请

公布后测试人员对测试完成后的程序打LABEL

SCM人员对变更做好操纵与记录，并公布

现场开发负责人将公布后的产版本更新至现场，或者指定人员进行

在无法通过sos连到公司vss的情况下，需要在现场建

公司外部编码现场开发负责人立配置库（文件方式或者VSS等），做到基本的版本操

纵与备份。每周至少通过SOS提交一次至公司的VS5库

中。

每天checkin工作产品到现场配置库（包含版本公布说

现场开发人员

明）。

做好督促与监督工作，每周将现场开发负责人提交的现

SCM人员

场版本更新到公司配置库（vss）。

每天checkin工作产品到现场配置库（如当天没有修改

能够不进行checkin）o

如已经回公司则每天checkin工作产品到公司配置库

现场开发人员VSS（如当天没有修改能够不进行checkin）«,

测试

每周通过SOS提交一个新版本给测试，打测试LABEL,附

带版本公布说明（如没有更新可不提交）

对测试完成后的程序打LABEL

SCM人员做好督促与监督工作

在无法通过sos连到公司VSS的情况卜\需要在现场建

立配置库（文件方式或者VSS等），做到基本的版本操

现场开发负贡人

纵与备份。每冏至少通过SOS提交一次至公司的VSS库

中。通过LABEL提交测试版本

公布后

现场调对修改后的版本通过SOScheckin新版本到vss,打测

试现场现场开发人员试LABEL,向测试人员提交申请（由修改至提交测试人员

保护不应超过三天）

测试人员对测试完成后的程序打LABEL

对变更做好操纵与记录，并公布

SCM人员

做好督促与监督现场提交更新版本到VSSo

关于VSS库内存放文件类型及大小的规定

1、文件名及目录规定：以英文名字命名

2、文件大小规定：最大不超过20M

3、同意类型：

4、表2.1中提至的文档类

5、代码及脚本类及为配合编译需要的类库等

6、下列类型不同意存放在VSS库中：

7、备份数据

8、安装程序、打包程序（zip'rar）

9、超过20M以上的非代码类及开发文档类文件

10、关于特殊情况或者不确定情况，需向配置管理人员咨询后再加入

11、关于不同意存放类型的配置类文件，可与配置管理员联络，随件附《说明清单》，

以文件型式储存于服务器。

配置项公布

配置项公布是指配置项进行到一定的阶段（比如，旦程碑阶段），需要对外公布时的规

则。在我们的项目中，配置项公布是通过标签，即LABEL,来实现的。

阶段触发事件操作人标签类型打标签的级别

单元测试单元测试完成，能够提交集成测试开发人员FOR_TEST模块级

集成测试完成，不通过（如通过进入系统

测试人员TESTED模块级

测试阶段）

集成测试

BUG修改完成，能够提交测试开发人员FOR.TEST模块级

集成测试通过，能够提交系统测试测试负责人TESTED模块级

系统测试完成后，不通过，（如通过进入

测试负责人TESTED项目级

系统测试阶段）

系统测试

BUG修改完成，能够提交恻试开发人员I'OK.TEST项目级

系统测试通过测试负责人TESTED项目级

验收前的版本，可公布到现场安装配置管理员LOAD项目级

验收测试

验收后的版本，可公布的正式版本配置管理员LOAD项目级

模块级/项目级/

修改BUG后提交测试保护工程师FORTEST

文件级

现场保护

模块级/项目级/

测试通过与否测试人员TESTED

文件级

基线确立与变更

基线的确定在上一部分中已经说到过，我们的项目基线分为两类，一类是作为里程碑与

其他工作依靠的基线（比如需求文档、设计文档等），另一类是开发过程中有必要保留的一

种状态（比如代码过程中某个模块的一个有保留价值的snapshot）o对这两种不一致的基

线，其影响的范围不一致，确立与变更方式也不一样。

我们项目的基线变更操纵委员会由客户代表、产品经理、项目经理与技术经理构成，对

公布的里程碑类基线的变更务必由变更操纵委员会确认并由QA进行变更记录，所有被变更

影响的配置项都需要重新同步后再次公布；而关于仅仅作为工件