clearcaselt配置

bmccbj

229
配置管理员在软件过程中的地位是举足轻重的，主要操作如下：
-- 创建配置库，并且至少创建配置库的所有第一级目录；
--为每个项目成员分配操作权限，一般地，项目成员拥有add,check
in ,check out,download等；
--根据“基线计划”创建与维护基线，冻结配置项，控制变更；
--定期清除配置库里的垃圾文件；
--定期备份配置库。
配置管理员所具备的素质：
1、职业道德是第一位的，这是由于配置管理人员负责管理软件公
司最为重要的资产。
2、软件配置管理的专业知识，最好要精通一种配置管理工具，
没有工具是不可能实施软件配置管理的，否则那只能是效率极其低下的
纸上谈兵。
3、项目管理的知识，对于软件开发流程非常熟悉。一般而言，
最好要经历几个软件项目的开发管理过程，或者担任过项目经理，对软
件开发的全过程有比较清晰的了解；有软件开发经验可以增强说服力，
降低实施的难度，
并且能够切身以开发人员的身份去体会配置管理，才能改进配置管
理过程。
4、有一定的大局观，有一定的IT背景知识,对系统（操作系统、网
络、数据库等方面）比较熟悉。
除了个人素质上的要求，在性格上也有一些共性的东西。
1、沟通技巧：在部署和实施配置管理的时候，肯定会遇到一
些抵触，对于程序员而言，使用配置管理之前，没有什么约束，但是在

bmccbj

230
实施后，会有一些约束，认为这并不是自己的工作。如果在使用中出现
了问题，就需要配置
管理人员进行沟通，并且能够解决问题。
2、稳重、细心、有耐心。配置管理工作需要和开发人员、测
试人员、项目经理打交道，但是他们对于遵循配置管理流程和工具不会
非常的热心，因此需要配置管理人员能够稳重、有耐心。
第二章 相关问题
1 软件配置管理
问：基线审核的内容是什么呢？基线审核是审核计划的基线（在
配置计划中标识了将要在何时建立哪条基线），还是实际开发中当前的
基线配置项提交情况？
答：一般按设计开发阶段来策划，按阶段建立基线，并说明需要
有什么工作产品，有那些工作产品的证据，是否达到策划的质量要求，
如何 配置，如：功能、性能、版本、配置项等内容。
当然，审核的内容就是按这些要求
问：在写变更控制流程的时候，有个问题很困惑。一般来说当配
置项符合什么条件时，对其的修改才需要进入变更控制流程
答：不是配置项的修改导致进行变更控制流程，而是引起配置项
修改的变更项才是变更控制流程的发起者，例如：测试过程中发现的缺
陷，客户提出的新需求等.
变更存在机制是关键，至于需要什么样的有几种机制完全是
灵活的，针对不同的对象或不同的资源可以有成千上万个选择，即

bmccbj

231
便是有了流程，同样可以对变更流程做变更，同样要进入变更流程
的控制之中。不要认为只有一种，或者约定就不变了
问：配置库怎么设计才算合理
答：配置库可分为开发库，受控库和产品库
开发库是存储开发人员正在进行中的文档与代码
受控库是存储整个开发过程各个里程碑点上的文档与代
码，数据库类，它的设计可分为四大类：
系统文档：可分为多小块，根据项目组而定
例如：需求，计划，概要设计，详细设
计，测试用例
数据库
代码
用户文档：名阶段产生的用户手册
产品库主要是存放发布后的版本，及匹配的文档
问：怎样组织结构设计才能满足实际的配置工作？
答：
1. 项目计划地开始编制SCM计划
2. 项目组审批SCM计划，确定SCCB
3. 按SCM计划实施SCM活动，进行标识，版本管理，变更
控制
4. 随项目计划的更新修订SCM计划
5. 每里程碑后提交配置状态报告
6. 配合高层领导及SQA审计SCM活动工作

bmccbj

232
问：配置管理计划在整个开发周期中的作用有多大，如何更好
地做这个计划？
答：SCM计划的作用是决定SCM活动的按时执行，SQA在这方面
也可以监督到SCM是否有按时入产口基线
要做好这个计划，必须要结合项目计划，时刻随项目计划
的更新而更新SCM活动计划
问：配置管理怎么做才算到位？
答：在项目审批SCM计划的基础上实施活活动，让项目成员了
解在SCM的角色与任务，在计划的SCM活动中声明各里程碑要提交的产
物，达成共识．
2 CVS 工具常见问题
问：在服务器上有2 个用户，administrator 和user1，我给user1
设置了1 个工作目录user1wk。这个工作目录被设置了权限，只有user1
可以进行crw。但不知道为什么，每次我在这个目录里add 文件的时候
服务器返回的信息提示：USER administrator cannot change
c:\workroot\user1wk，当时我是用user1 的帐号登陆的，请问能帮我分
析一下问题么？
答：只有用checkout 模块时的用户才可以对checkout 模块进行
操作。
writer 和reader 文件是存放用户权限的，如果有读写权限
的就要在writer中添加用户名，只有读的权限的在reader 文件中添加，
如果同时存在两个文件中的，默认为只读权限

bmccbj

233
第三章 配置管理流程
1 概要
1.1 内容
规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证
基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建
立和维护项目产品的完整性和可追溯性。
1.2 适用范围
对于不同类别的软件项目，配置管理的流程不同，可在本流程的基
础上进行裁减。
1.3 术语和缩略语
1.3.1 软件配置管理（Software Configuration Management，SCM）
软件配置管理是对软件修改进行标识、组织和控制的技术，用来协
调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和
生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产
品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精
确的不同版本的产品配置。
1.3.2 配置（Configuration）
配置是在技术文档中明确说明并最终组成软件产品的功能或物理
属性。因此配置包括了即将受控的所有产品特性，其内容及相关文档、
软件版本、变更文档、软件运行的支持数据，以及其他一切保证软件一

bmccbj

234
致性的组成要素，相对与硬件类配置，软件产品的配置包括更多的内容
并具有易变性。
1.3.3 配置项（Configuration Item，CI）
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration
Item, CI），配置项逻辑上组成软件系统的各组成部分，一般是可以单独
进行设计、实施和测试的。一个纯软件的CIs 通常也称之为软件配置项
（Computer Software Configuration Items，CSCIs）。
配置项主要有两大类：
1) 属于产品组成部分的工作成果，例如需求文档、设计
文档、源代码、测试用例等；
2) 项目管理和机构支撑过程产生的文档。这些文档虽然
不是产品的组成部分，但是值得保存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、
日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置
项及其历史记录反映了软件的演化过程。
1.3.4 基线（Baseline）
在配置管理系统中，基线就是一个CI 或一组CIs 在其生命周期的不
同时间点上通过正式评审而进入正式受控的一种状态，些配置项构成了
一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线
都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一
个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑
（Milestone）处创建，并与项目中的里程碑保持同步。每个基线都将接
受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何

bmccbj

235
人随意修改，对其的修改将严格按照变更控制要求的过程进行，在一个
软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一
个基线。
基线的主要属性有：名称、标识符、版本、日期等。通常将交付给
客户的基线称为一个“Release”，为内部开发用的基线则称为一个
“Build”。
建立基线的好处：
1) 重现性：及时返回并重新生成软件系统给定发布版的
能力，或者是在项目中的早些时候重新生成开发环境的能力。当
认为更新不稳定或不可信时，基线为团队提供一种取消变更的方
法。
2) 可追踪性：建立项目工件之间的前后继承关系。目的
是确保设计满足要求、代码实施设计以及用正确代码编译可执行
文件。
3) 版本隔离：基线为开发工件提供了一个定点和快照，
新项目可以从基线提供的定点之中建立。作为一个单独分支，新
项目将与随后对原始项目（在主要分支上）所进行的变更进行隔
离。
2 相关人权责
2.1 项目经理（Project Manager，PM）
责任：
1) 与CCB 协商确定项目起始基线和开发里程碑；
2) 接受配置管理计划，并按相关规定贯彻执行；

bmccbj

236
3) 接受配置控制委员会的报告。
权利：
1) 提出配置管理计划的修改要求；
2) 提出管理管理的建议和要求。
2.2 配置控制委员会（Configuration Control Board，CCB）
责任：
1) 制定和修改项目的配置管理策略；
权利：
1) 批准、发布配置管理计划；
2) 建立、更改基线的设置，审核变更申请；
3) 根据配置管理员的报告决定相应的对策。
2.3 配置管理员（Configuration Management Officer，CMO）
责任：
1) 编制配置管理计划；
2) 执行配置项管理方案；
3) 执行版本控制和变更控制方案；
4) 编制配置状态报告；
权利：
向CCB 汇报有关配置管理流程中的不符合情况。
2.4 程序库管理员（Program Librarian，PL）
责任：
1) 配置库的建立和权限分配；

bmccbj

237
2) 配置管理工具的日常管理与维护；
3) 配置库的日常操作和维护；
权利：
1) 各配置项的管理与维护；
2) 对开发人员进行相关的培训。
2.5 开发人员（Developer）
责任：
1） 根据确定的配置管理计划和相关规定，提交配置项和基
线；
2） 负责软件集成和版本生成。
权利：
按照软件配置管理工具的使用模型来完成开发任务。
2.6 测试人员（Tester）
责任：
根据配置管理计划和相关规定，提交测试配置项和测试基线；
权利：
负责软件变更的测试验证。
2.7 软件质量保证员（Software Quality Assurance，SQA）
责任：
负责配置审核并提交报告。
权利：
对配置审核中发现的不符合项，要求相关责任人进行纠正。

bmccbj

238
3 实施细则
3.1 CCB 的成立
3.1.1 项目在设计发布后，由项目经理负责组织成立CCB。
3.1.2 CCB 成员组成
CCB 成员人数一般为奇数，人数在3～7人范围内。CCB 成员一般
包括：
1) 项目经理PM；
2) 配置管理员CMO；
3) SQA；
4) 测试人员Tester；
5) 顾客代表；
6) 主要开发人员等。
3.1.3 CCB 的决策机制
寻求CCB 成员的一致意见。若不能达成一致，可采取由顾客代表
做出决策；或采取少数服从多数的原则，由CCB 成员投票确定，投票
超过半数即为通过。
3.2 确定配置策略
3.2.1 配置策略确定的时机
CCB 成立后，由CCB 组织会议根据项目的开发计划确定各个里程
碑和开发策略，CMO 负责整理确定的项目基线和配置项列表，并在编
制《配置管理计划》时列明，按约定的时机收集配置项和建立初始基线。