clearcaselt配置

bmccbj

219
revision都是唯一，并且对应配置项的某个版本就可以了。之所以配置
项的版本称作revision，是为了和软件项目的版本release区别。
配置项的初始revision是1.1，通常情况下，CVS是以1.1?1.2?1.3
这样的趋势去变化配置项的revision的。
增加一个新文件的时候，第二个数字将为“1”， 第一个数字等于该
目录中所有文件版本号第一个值的最大值。例如，当前目录包含版本号
为1.7, 3.1和4.12的文件，则一个新文件的版本号应为4.1。
? tag
和VSS的label有一些类似，tag也是用户给CVS里的某个或某些配置
项创建的标识。但CVS对tag的名称控制的比较严格，一个tag必须以字
母开头，后续多个字母，数字，减号和下划线，不能包括点号和空格。
比如“release1-3-2”，“approvdBy Sqa”等。
Tag的作用和VSS的label一致，也是给配置项标明一些我们想保留
的信息的。
6 总结
从以上的标识规范可以看出，配置项标识是一件比较细致的工作，
也是配置管理的基础。每个项目的具体情况不同，可以根据以上的规范
进行适当裁减与修改。但遵循一定的规范是相当必要的，只有这样，才
能方便配置项的查找与规类，才能较清晰的看出配置项的状态，给基线
控制、变更控制工作的开展创造基础。

bmccbj

220
4 配置管理经验
在整个项目过程中如何进行配置管理工作：
１、由PL指派该项目的配置管理者（CC）。
由PL指定比较重要的设计人员或有经验的项目组成员作爲該項目
的配置管理者，配置管理者全面負責該項目的配置管理活動。
2、由配置管理者作成配置管理计划。
配置管理者與PL充分溝通，了解項目的各種情況（项目的流程，客
户的需求），识别配置项和为存放配置项提供的配置库等情況。配置管
理者根據了解的情況，編寫該項目的配置管理计划。
3、由PL组织评审配置管理计划。
根據作成的配置管理计划，由PL组织评审配置管理计划。對於评审
中發現的錯誤，配置管理者應迅速改正。
4、基线化配置管理计划
對於通過评审的配置管理计划进行基线化。以后对项目的配置管理
计划所发生的变更处理，都应根据CI的变更控制处理流程来执行
5、搭建配置管理环境
配置管理者根據配置管理计划中的規定，搭建配置管理环境。
6、获取配置项
配置管理者根據配置管理计划中的規定，获取配置项，並放入配置
管理庫中。
7、培訓項目組成員對配置庫的使用
配置管理者培訓項目組成員對配置庫的使用，以使項目組成員熟練
使用配置庫。

bmccbj

221
8、開始配置管理活動
（1）定期對配置庫進行备份，儅配置庫損壞時，可通過备份數據
及時恢復。
（2）对通过评审的项目的配置項进行基线化。以后对此配置項所
发生的变更处理，都应根据CI的变更控制处理流程来执行
简述配置管理工作流程示意图：
配置管理工作流程目的是概述描述开展SCM活动的整个过程
活动，为参与SCM的人员提供指导。描述了为达到CMM2级（可重复级）
所必需的SCM过程。
SCM的目的是在项目软件生命周期中建立和维护软件项目产品的完
整性。SCM关注以下四个关键过程。
l 配置标识
l 配置控制
l 配置状态记录（CSA）
l 配置审核
流程图以这四项活动为重点进行了说明（见图1）：
（1） SCM实施准备
为项目实施SCM获取适当和充分的资源（人员和工具）、资金和高
层管理者对实施SCM的支持。此外，准备工作还包括为项目建立SCM组织
机构，包括SCM经理、软件配置控制委员会（SCCB）和SCM组或配置管理
员。
SCCB应代表项目经理和所有受软件基线变更影响的组的利益，其负
责：1）授权建立软件基线和对配置项/单元的标识；

bmccbj

222
2）评审和授权对软件基线的变更；
3）授权从软件基线库生成产品。
SCM组协调或实施：
1） 建立和管理项目软件基线库；
2） 制定、维护和分发SCM计划、标准和程序；
3） 标识受控于SCM的软件中间产品；
4） 管理对软件基线库的访问；
5） 变更软件基线；
6） 从软件基线库生成产品；
7） 记录SCM活动；
8） 制定和分发SCM报告。
（2） 编制软件配置管理计划（SCMP）
SCMP应在项目总体策划的初期制定与软件项目策划同步进行。SCMP
描述预期要在项目生命周期中开展的SCM活动，并阐述支持这些SCM活动
的环境和工具。批准的书面的SCMP用来指导项目整个配置管理活动的开
展。
该计划覆盖SCM执行的活动、进度、所需资源（包括人员、工具和
计算机设备）、人员职责分工和项目成员所应遵循的SCM程序。
（3）补充（制定）SCM作业程序
SCM作业程序是指导SCM人员实际操作的文件。企业应具备基本的
SCM作业程序比如配置标识、配置控制等，但针对具体项目需要可以补
充相应的作业程序。
（4）提供SCM培训
按照需要对SCM组成员进行有关实施SCM活动的目的、作业程序和方

bmccbj

223
法方面的培训，比如SCM概念和SCM工具；对软件开发人员和软件相关组
人员进行实施SCM活动的培训。
培训可能包括：
针对SCM组的：
l SCM标准、作业程序和方法
l SCM工具
针对软件开发组和软件相关组的：
l 在组内实施SCM活动应遵循的标准、作业程序和方法
l SCM组的任务、职责和权限
（5）执行配置标识
配置标识一词用于定义产品生命周期某点上软件集合的文档。配置
标识是选择、标识和命名软件配置项（SCI）的过程。
SCI是作为单一项开发和管理，能独立于其它同类项启动和运行，
来执行某一满足最终用户需求功能的软件的集合。例子有：代码模块、
构件脚本和文档。
标识通常由简短的名称和版本号组成。唯一地标识使SCMG能准确跟
踪和控制SBM项目地软件变更，和维护软件中间产品地多个版本。
（6）执行配置控制
配置控制主要包括配置管理库运作和变更申请处理.。配置管理库
运作即以有组织的方式组织配置项、基线的登入和检出，从受控库发行
基线和软件产品。 对配置项的变更是由提交对项目的SCM系统的变更请
求开始的。变更
请求应具有一种机制，使与项目有关的任何人员（如，开发人员，

bmccbj

224
质量工程师，经理，用户）可提出问题或建议。
（7）配置状态记录(CSA)
CSA文档记录并向SBM软件项目经理汇报影响CI的措施。通过使用工
具能让经理们能获取他们所需要的信息。CSA主要记录“批准的配置”（基
线）和对基线变更的实施状态，为经理们提供反馈信息来确定SCCB的决
策是否按自由化照指示实施。
（8）软件配置审核
SCM审核一般分为两类：功能配置审核（FCA）和物理配置审核（PCA）。
这两种审核共同来保证项目开发出为进入下一阶段所必需的产品。
功能配置审核的目的是保证在需求和策划阶段规定的用户需求得
到文档化，并转化到产品生命周期的设计和构造阶段。
物理配置审核的目的是检查产品已经生成，并在建立基线和进入下
一生命周期阶段前进行了配置控制。
5 经验谈：
●目前的配置管理还处于一种版本控制的管理和可追溯性,我目前
所做的配置管理是帮助我现在的公司建立一套完整、规范的配置管理体
系，让软件的开发过程是可控的、受控的，每一配置项是可标识的和可
追溯的，我想请教你，
做了五年的配置管理，你的主要经验是什么？还有配置管理与开发
人员的关系问题你是如何处理的？再就是公司应该赋予ＳＣＭ人员什
么样 的权利和职责，才能保证Ｓ ＣＭ的管理活动的有效，而不流于形
式。谢谢你，如有可能
▲做了这么久的SCM，我的主要收获是要做好公司的配置管理工作，

bmccbj

225
需制订一套适合公司开发项目的配置管理规范文档，并培训项目人员熟
悉了解 配置管理流程，知道自己在里面的角色．这样使他们能在项目
的每个阶段配合SCM活动的实施，确保进入配置库的工件是受控的、可
用的且可追溯的。
SCM计划是通过项目组评审的，那么开发人员就应按照SCM计划在每
个里程碑点上提交审批过的文档或代码类文件；若没按时提交，SCM人
员可依 项目计划去追查项目人员．基于你的第三个问题，我觉得要保
证SCM的活动不是流于形式，首先是你的SCM计划是参照配置管理规范做
出来且经过项目组评审认可的。那么 ，在实施SCM活动时，SCM人员就
有权利在这个里程碑点上去追查项目组应提交的文档或代码类。
为了不让项目组人员觉得增加了SCM反而是增加项目组开发过程的
负担，你就得在配置管理规范里定义清楚，哪个阶段作为里程碑点这很
重要。 我们现在一般分为三个重要里程碑点:需求分析\实现\测试.
在实现过程中,就是完全进行这个项目的详细设计及代码开发过
程。 所以,在实现阶段开始时就要求项目经理逐渐细化项目计划,分出
各个内部测试版的提交时间作为小里程碑点,这样就便于SCM在小里程
碑点上去追查测试人员的测试用例及版本发布.进行各小里程碑点上的
版本入库管理、标识。而实施严格的变更控制,1,一般在于当需求发生
变更,就得由项目经理 根据变更的级别决定是否召开SCCB会议.当确定
变更后由项目经理提交,SCM人员记录此次发生的变更;2. 当发布一个
Beta版给客户后,所有的变更都要求进行控制,项目人员需要提交变更
申请表,项目经理(PM)根据变更 申请表确定是否召开SCCB会议,小的变
更由PM决定,当提交变更给SCM时,就需提交与上个版本的文件异常列表
及变更描述.SCM人员在检查变更符合时,提交给测试人员,测试人员测

bmccbj

226
试需求满足时,再向SCM汇报,SCM将此版本纳入基线标识.并将变更记录
纳入文档.在每个里程碑点之后提交配置变更记录报告到高层领导及项
目经理。
●目前我们在公司建立的配置管理系统是从产品规划开始，我们有
一个委员会根据市场信息＼行业背景＼调研报告负责提出新产品定义
和产品计 划，并提供给研发中心进行策划，在开发过程我们设定了概
要需求基线，详细需求基线，概要设计基线，详细设计基线，产品基线，
产品开发阶段我们分了产品定义，产品计划，开发策划，需求，设计，
编码与单元测试，客户化 应用，测试，产品发版，开发总结，维护等，
我们编写了＜配置管理程序＞，＜配置项管理规范＞和＜配置项和版本
控制规范＞，不知道这么做，分得这么细，是不是让开发人员觉得很烦，
有什么可以精简的，可以使配置管理既 切实可行，又适合开发人员的
开发习惯．
▲依你所说你们公司SCM的规划，在我看来，可以分为重点四
大类．系统文档，数据库，编码，客户文档，这样就会清晰许多．在系
统文档内又 可分出：计划、需求、概要设计、详细设计、测试等这些
类别了。做基线标识时就分别在各类别的目录上建立标签即可。
从你说的你们编写的SCM文档来看，我觉得分得还不够明确。或
者分为〈配置管理控制程序〉〈配置管理规范〉〈配置计划编制程序〉
是不是 会好些呢？
〈配置管理控制程序〉来描述整个配置管理的工作程序之类，而不
细化它的活动及流程。比如ＳＣＭ计划的前提是什么？如何度量ＳＣＭ
工作 ？等等。
〈配置管理规范〉来描述整个配置管理活动规范与标准，象标识、

bmccbj

227
版本管理、变更控制的执行标识和规范在里面安排。
〈配置管理计划编制程序〉来描述适合于不同项目与产品的一个模
板。包括目的、范围、角色、ＳＣＭ活动（SCCB的确定、配置库的构架、
配 置项的建立与入库）、环境说明、SCM审核、SCM报告、培训这些。
其实象这些文档，需要要项目人员熟悉的就是
1.他们在里面的角色是什么
（从他们知道自己在ＳＣＭ里面的角色，来了解自己要配合ＳＣＭ
什么活动的执行）
2.提交文档与变更的流程。
（从他们清楚2点，来了解自己在哪个时候有责任提交完成（或变
更）代码文档类。）
其它内容仅是用于公司多个SCM的情况下统一、规范ＳＣＭ工作流
程与ＳＣＭ活动。
" ★若没按时提交，SCM人员可依项目计划去追查项目人员。
基于你的第三个问题，我觉得要保证SCM的活动不是流于形式，首
先是你的SCM计划是参照配置管理规范做出来且经过项目组评审认可
的。那么 ，在实施SCM活动时，SCM人员就有权利在这个里程碑点上去
追查项目组应提交的文档或代码类。"
我可告诉你，你是没权去要提交的配置文档的。你按计划，本来你
的计划是随项目计划的变更而变更的，因为你的计划是项目计划的附属
计划 ，文档没提交可能有多种原因，这在SPTO、SQA报告中可以反映出
来，他们会管些东西。你管你的配置标识、建立和维护配置库、配置项
的变更及变更的控制就可以了。至于对配置库的审核那也不是你的工
作，SQA会来检查你的。

bmccbj

228
▲SCM计划是项目计划的附属计划这点说的没错,但如果说项目计
划在那个时间点上没提交产出物却没提交,且项目计划时间没变,那么
请问是否SCM 有权利去追问呢?? 当然文档没提交可能有多种原因,那
么延迟提交的原因是否PM应该向相关组及时反应才对呢?若没反应,项
目计划与实际应存在差异了. 不过确实这些原因应该在SPTO与SQA报告
能反应出来,不过遗 憾的是我们公司这方面还做的尚未成熟(我想许多
公司若SCM没做好,其它方面应该也处于尚未成熟阶段吧),所以当项目
计划时间与实际提交时间出现偏差时,我一般就会去追问.当然若整个
CMM过程都做顺了,公司 过CMM5级是没问题了.国内在做CMM过级及与实
践真正能达到相吻合的还是较少吧.至于配置库的审核,由SQA来检查没
错,不过将配置审核作为配置人员为保证有关人员完成他们的工作，并
满足外面要求的一个手段列出我想也不 为过吧?
●你所说的配置管理人员应该是属于一个项目立项后在组内设的
配置管理员,他只是根据配置管理计对该项目进行配置管理,那么他确
实没有被赋 予那样的权利，他只是配合公司最高配置管理员做好配置
工作。作为公司最高配置管理员，我觉得公司赋与他的权利应该是负责
编制配置管理计划，并组织实施，负责建立配置库，参与配置库的审核，
配合SQA人员检查配置计划 的完成情况，向公司最高层定期报告配置状
态，并对配置计划的完成情况进行考核，考核的结果纳入公司对开发人
员的业绩评定，这样才能确保开发计划的顺利完成。
▲我赞成你的观点，我觉得应该赋予配置人员更多的权利，才能保
证配置管理工作的有效进行。而且在公司的管理处于这种初级阶段时，
配置管理就显得更重要了。
配置管理员角色