clearcaselt配置

bmccbj

209
比如有一个项目设计文档，当设计基本完成，开发即将开始的时候，
需要把这个文档固定下来，内容不能再频繁改变，否则开发人员就无所
适 从了，可能导致每个人所参照的文档并不是同一个文档。用一句上
海这里的生活用语来说，就叫做要把这个文档“敲定”。
一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被
“基线化”了，然后所有人就可以在这个“基线”的基础上工作。
当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，
但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既
然是“基线”，就不能随便动。
但是到了一定时候，修改积累到一定程度，就需要把很多修改合并
到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的
参考 标准，并把老的版本淘汰掉。这就叫做“基线提升”。
合同基线
当你和客户讨论后，“敲定”的合同
4）发行基线
你会对你要发行的代码，文档版本进行label, 比如
Release2.2,
这样，你可以随时取出此版本作build，进行测试，发布。
5）产品基线
当发布时，你会对产品中所有的配置项进行label,包括可执行
命令，文档手册，库文件。。。
基线是与里程碑相对应的，所以每个里程碑处建立一条基线；
但变更同样属于配置管理的范畴，所以配置项变更后也应建立基
线。

bmccbj

210
但是如果配置项的变更很微小，就没有必要再建一条基线了。
2 配置状态报告及申计
配置状态报告：
提供配置项的状态信息，以反映项目的进展情况，同时可以从中根据配
置项的操作记录对开发团队的工作关系作一定的分析。
-报告应定期进行
-使用CASE工具生成，保证客观性
主要内容：
变更请求列表
基线库状态
Release信息
备份信息
SCM工具状态
其它应予以报告的事项
配置审计：
验证配置项信息与配置标识（需求、标准、流程…）的一致性
功能配置审计(FCA,Functional Configuration Audit)
物理配置审计(PCA,Physical Configuration Audit)
1.配置审计-What
FCA:验证配置项的功能特性与需求（原始需求、变更请求… ）的一致性
PCA:验证配置项的物理特性与期望（命名标准、变更流程… ）的一致性
2.配置审计-Why
预防提交错误的产品

bmccbj

211
捕获未完成的任务（原始需求、变更请求）
识别不同配置项之间的对应关系
确认配置项（们）已经被基线化
确认记录和文档维持可跟踪性
3.配置审计-When
软件交付或release时
每个阶段结束时
对于维护性项目，周期性地进行
4.配置审计-Who
非本项目组成员
其它项目中的配置控制者
内部审计者
SCM小组
5.配置审计-How
审计流程：
识别配置审计的时间[PM]
指派审计者[QA/Audit Group]
定义审计范围[PM&Auditors]
准备配置审计Checklist[Auditor]
通过评审（Review）、文档记录进行审计[Auditor]
识别不符合项[Auditor]
关闭不符合项[PM]
验证[Auditor]

bmccbj

212
3 配置管理标识规范
1 定义
配置项是受配置管理控制和管理的基本单位。配置标识是软件生命
周期中划分选择各类配置项、定义配置项的种类、为它们分配标识符的
过程。配置项标识的重要内容就是对配置项进行标识和命名。
2 必要性
配置标识是软件配置管理的基础性工作，是管理配置的前提。很难
想象缺乏配置项标识的基线管理，如何去区分和定义基线；也很难想象
缺乏配置项标识的变更控制，如何去标明版本的变化规迹。
3 原则
配置项标识可以根据项目的实际情况灵活掌握，但有一些基本的原
则是需要遵从的。
? 标识唯一：这是为了避免混淆
? 与同类配置项不同的信息，应纳入标识：这是为了便于区分、
查找
? 同类配置项的标识方法统一
? 容易记忆：对于经常使用的配置项，标识不宜过长
4 标识范例
4.1文档
对于常见的word、excel、visio等文档而言，标识也就是文档的文
件名。文档的标识可能承载好几项信息，如项目编号、文档名、撰写时
间等等。标识里要包括哪些信息，是和文档的性质有关的。比如每周产
生的一次周报，标识里加上撰写时间，就一目了然了，这样便于查找和

bmccbj

213
整理。
不同的信息之间，可以用下划线“_”分割，也可以用括号“（）”分割，
如果前后两项信息分别是字母、汉字；或汉字、数字等情况，不必加分
割符号也是可以的。
以下是常用文档的标识规范，供参考：
? 次要的文档
命名方式：[文档名]
如：配置库使用规范
? 比较正规的文档
命名方式：[项目编号＋文档名]
如：GC21007E技术规划书
? 有版本变化的
命名方式：[文档名＋版本号]
如：GC21007E需求规格说明书V1.2
? 主要区别在于时间的
命名方式：[文档名＋撰写时间]
如：周例会会议纪要20030901
? 主要区别在于人员的
命名方式：[文档名＋人员名称]
如：工作周报_赵明
? 主要区别在于系统模块的
命名方式：[文档名＋模块名]
如：需求实现跟踪表_申报征收；
? 为了能排列顺序，需要加上数字的

bmccbj

214
命名方式：[序号＋文档名]
如，某一测试流程，不是写在一个文档里，而流程的执行是有时间
顺序的：
02银税联网的电子税票日常对帐、03现金票证汇总
? 其它，加上能和同类文档区别的文字
命名方式：[文档名＋简单文字]
如：联调环境确认_暂行；联调及修改记录_模版；GC21007E项目WBS
计划_提交稿
4.2版本号
版本号是比较抽象的配置项。
? 方式一：以版本发布日期作为版本号
这种版本号的标识方法比较简单，虽然无法看出系统一共发布的版
本数量，以及各版本之间的不同性质，但可以直观的看出版本的发布日
期。也比较容易记忆。
如果项目组成员需要对版本的情况进行统计或者沟通，不需要依靠
任何记录就可以定位出某个版本发布的日期。
适用于：小型项目、版本频繁发布的项目。
举例：2003-9-7发布了两个版本，分别是20030907A，20030907B
应用的项目：ctais2.0。
? 方式二：采用“主版本号. 从版本号. 维护版本号. 补丁版本
号”的形式
这是大部分系统版本号的基础标识形式，每个版本号是阿拉伯数
字，主版本号以1为起始数字，其他版本号以0为起始数字。可以进行裁

bmccbj

215
减，类似“主版本号. 从版本号”的形式也是可以的。以这种方式来标识
版本之后，当前版本的状态，以及版本发布的轨迹，都可以看得比较清
楚。
至于何谓主版本和从版本，每个项目组可以有自己的约定。比如功
能的大幅度修改、正式发布给客户、上线等里程碑事件，都是应该反应
在版本号的变化上的。
适用于：比较正式的软件项目
举例：第一个版本为 1.0.0.0，上线使用的版本为5. 11.18
? 可选方式三：给版本加上前缀以区分
方式三、四并不是一种新的软件版本标识方法，它们通常增加在方
式二的基础之上，以更好的标识版本。
我们通常在软件前面看到alpha、beta、demo、release等前缀，这
些标识有它们公认的含义，主要以区别版本的性质和用途。以下是参考
资料。
Alpha版(内部测试版)：一般只在软件开发公司内部运行，不对外
公开。主要是开发者自己对产品进行测试，检查产品是否存在缺陷、错
误，验证产品功能与说明书、用户手册是否一致。
Beta版(外部测试版)：软件开发公司为对外宣传，将非正式产品免
费发送给具有典型性的用户，让用户测试该软件的不足之处及存在问
题，以便在正式发行前进一步改进和完善 。一般可通过Internet免费
下载，也可以向软件公司索取。
Demo版(演示版)：主要是演示正式软件的部分功能，用户可以从中
得知软件的基本操作，为正式产品的发售扩大影响。如果是游戏的话，
则只有一两个关卡可以玩。该版本也可以从Internet上免费下载。

bmccbj

216
Release版(发行版)：不是正式版，带有时间限制，也是为扩大影
响所做的宣传策略之一。比如Windows Me的发行版就限制了只能使用几
个月，可从Internet上免费下载或由公司免费奉送。
Full Version版(完全版)：也就是正式版，是最终正式发售的版本。
举例：beta2.0，release1.02
适用于：较正式的软件、商用软件、游戏软件等
? 可选方式四：使用外部版本、内部版本两套机制
当我们点击word帮助菜单的“关于”时，在抬头部分看到的是
“word2002 （10. 2627. 2675）”。这里的2002、10. 2627. 2675分别是
外部、内部版本号。因为让客户记住繁琐的内部版本号是困难的，另一
方面，出于宣传等商业原因，很多商业软件不但有外部版本号，还把功
能有大幅度改善的版本以不同的名称命名。比如windows98- windows
Me- windows2000- windowsXP； RealPlayer8.0- RealOne Player V2.0
等。
适用于：商业软件
4.3 其他配置项
以下配置项没有对应实际的物理文件，但通常都由配置人员分配
（特别是在小型项目中）。另一方面它们和项目组每个成员相关、经常
被使用。对它们的标识需要容易记忆、规则统一，但由于涉及安全性，
不能过于简单和容易猜测。
? 配置机、服务器的访问密码
例：用户名 guest；密码 ctais123（若有多台服务器，其用户名
和密码最好都一致，容易记忆）
? VSS数据库、butterfly等配置工具的用户名和口令

bmccbj

217
例：用户名 zhouyan；初始密码 zhouyan（所有人员的命名规则都
相同，VSS的和butterfly的最好一致）
? 数据库的SID、用户名和口令
例：IP为10.1.120.11的服务器，在上面搭建的数据库SID为 11sid；
（由于有多台服务器设有数据库，所以SID最好和服务器的IP相关）
给测试人员使用的库，用户名 test；密码 test；
给开发人员调试使用的库，用户名 dev；密码 dev （用户名和密
码表明了其功能和作用）
5辅助标识
配置工具有一些辅助方法来标识配置项，这里介绍VSS和CVS的方
法。
5.1 VSS
VSS提供以下三种方式为配置项标识
? version
version通常是纯数字型的，它由VSS自动管理。每当用户对一个配
置项进行了修改并提交变更（check-in）、分支等操作后，VSS都会将
配置项的version自动加1。
Version的最大好处是能一目了然的看出配置项的变更规迹。在计
算配置项的变更次数、在比较配置项两个版本之间的差异时，发挥了较
大的作用。
? user/date/time Stamp
user/date/time Stamp也是由VSS自动管理的。和version类似，每
当用户对文件做了更改、分支、删除等操作时，VSS都会自动记录操作

bmccbj

218
的时间和用户名。
严格的说user/date/time Stamp并不是标识，只是在配置项发生变
化时，对修改人员、时间信息的记录。它在跟踪配置项变更、跟踪责任
人方面，起到了很重要的作用。对于一个多人的团队，某一配置项可能
由多人修改。如果没有user/date/time Stamp，当我们发现一个公共的
源代码被更改有误之后，如何去查找修改人呢？如果没有
user/date/time Stamp，如何去取得某一配置项在20日产生的版本呢？
? label
和以上两种方式不同，label是用户自发给某个配置项、或某些配
置项的当前version创建的标识信息。因为同一配置项可能经历过多次
变化，有对应的version，label能对应某个具体的version是最确切的，
否则就很难通过label来查找和定位配置项的某个状态了。
Label之后， 配置项的version号自动加1，并和配置项做当次label
的上一个version相对应。也就是说，我们可以选中某个label，对它进
行view、get的操作，取得的内容是所选label的上一个version的内容。
如果一个或一组配置项达到了某种里程碑状态，配置人员想标明这
种状态，使用label是个不错的主意。它可以在配置项的某个版本上随
意增加一些我们想保留的信息。label是最长可达31个字符的字符串，
比如“beta2.1.5”，“08.25评审通过”，“客户环境第一版”等等。
5.2 CVS
CVS有以下两种方式来标识配置项：
? revisions
和VSS的version一样，revision也是CVS自动分配的，通常操作人
员不需要过于关心它变化的细节，只需要知道一个配置项的每个