clearcaselt配置

bmccbj

239
3.2.2 配置项的范围
1) 技术文档（Documents）：项目开发计划、需求分析报
告、软件设计书、质量保证计划、概要设计书、详细设计书、测
试文档、技术报告、用户手册、总结报告等；
2) 程序（Program）：阶段产品、计算机程序、源程序、
释放产品等；
3) 工具（Tools）：自动设计工具、开发工具、测试工具、
维护工具等；
4) 交互文档（Communications）：与客户或项目组内交互
产生文档，如会谈记录、E-mail、会议纪要、MSN记录等。
3.3 制定配置管理计划
3.3.1 《配置管理计划》的编制
通常情况下，由CMO 在设计发注后，开始编制《配置管理计划》；
如有特殊需要，根据合同或项目要求，由CMO 在某一项目或项目的某
一阶段开始前制定《配置管理计划》。
3.3.2 《配置管理计划》的内容
《配置管理计划》应包括以下方面的内容：
1) 该项目对配置管理的要求；
2) 实施配置管理的责任人、组织及其职责；
3) 需要开展的配置管理活动及其进度安排；
4) 采用的方法和工具等。

bmccbj

240
3.3.3 《配置管理计划》的由CCB 负责审批。
3.4 配置项标识规则
3.4.1 配置项标识要求
1) 合同有明确标识和追踪要求时，由开发人员按合同要
求进行标识，以保证满足合同追踪要求。
2) 在开发过程中项目组人员提交的配置项，由项目组人
员按照本节相关部分标识规则进行标识。
3) 项目组人员将要标识或已标识的配置项提交给CMO
纳入配置库统一管理，并填写《配置状态报告》。
3.4.2 配置项标识方式
3.4.2.1 标识项
配置项标识属性包括：名称、编号、文件状态、版本、作者、日期
等。本文标识规则对名称、编号、文件状态和版本进行了描述和规定。
3.4.2.2 名称
文件名称的标识按文档模板中统一名称为准。
a) 编号
文档编号格式为CC_XXX_***_$$$_###，其中CC 表示公司，XXX
是项目的三位英文字母缩写表示，***_$$$表示文档类别，###表示文档
顺序号。同时对应每个内容都有固定的一个索引文件
CC_XXX_**_$$$_index，目的是为了为本类别下的文件建立一个概要说
明列表，保证快速对文档进行识别和检索。
3.4.2.3 文件状态

bmccbj

241
文件状态分为“草稿”、“正式发布”和“修改中”三种。
修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，
修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何
人都不能随意修改，必须依据配置变更控制的规则执行。
3.4.2.4 文档版本控制
对于计划性文档、技术文档和用户文档，其版本按修改的先后顺序
确定。新生成的文档第一次发行为第一版，修改后第二次发行为第二版，
以此类推。
3.4.2.5 发行版本控制
最终完成的软件版本用三位符号表示：“s.x.y”。各符号位的含义如
下：
1) “y”为第二次版本号，表示纠正错误时的版本升级，
用一位数字表示：“1~9”，对上一次产品或项目中的缺陷做修正，
第二次版本号增加；
2) “x”为第一次版本号，表示增加功能时的版本升级，
用一位数字表示：“0~9”。与上一产品或项目相比，功能进行了
小量的增加或修正时，第一次版本号增加，第二次版本号为零，
第二版本号为零时可以省略不写；
3) “s”为主版本号。对产品作重大调整，或与已发行的
上一产品相比，在功能与性能上有较大改善时主版本号增加；产
品或项目概念全新，第一次完成，版本号为1.0。
3.4.2.6 基线版本标识
内部基线，如计划基线、设计基线等，在版本号前加Build，如Build

bmccbj

242
1.0；
发行产品基线在版本号前加Release，如Release 2.0。
3.5 配置库管理
3.5.1 配置库（Repository）的分类
配置库分为两类：
1) 文档库（Document Library）：由CMO 负责管理，主
要使用eSM 系统管理除程序以外的文档资料（包括图片等）；
2) 程序库（Program Library）：由PL负责管理，主要使
用CVS版本工具对程序代码进行管理。
3.5.2 配置库的建立
3.5.2.1 CCB 成立之后，PL 即可着手组织建立配置库。所有项目
应建立配置库，以便管理各配置项。
3.5.2.2 文档库空间由eSM 系统创建，PL 仅创建基线文档库，仅
PL 可以对其操作。
3.5.2.3 程序库主要通过设置版本的分支，来实现对配置项权限
管理，基本上要为每个配置项从建立开始就划分成3个不同的分支（如
图1）：
图1 配置库空间分配和版本迁移策略
1) 私有分支（Private Branch）：私有分支对应的是开发
人员的私有开发空间。开发人员根据任务分工获得对相应配置项
的操作许可之后，他即在自己的私有开发分支上工作，他的所有
工作成果体现为在该配置项的私有分支上的版本的推进，除该开

bmccbj

243
发人员外，其他人员均无权操作该私有空间中的元素。
2) 集成分支（Integration Branch）：集成分支对应的是开
发团队的公共空间。凡是要为同组人员共享的配置项都从该分支
获得。即各开发人员必须将私有工作空间中的开发成果归并
（Merge）到该分支后才能进入下一个开发活动。所有涉及多人
协调的开发工作（如集成测试等）都必须工作在这一空间中。该
开发团队拥有对该集成分支的读写权限，而其他成员只有只读权
限。该分支的管理工作由PL及相关指定人员负责。
3) 公共分支（Common Branch）：公共分支对应的是整个
软件开发组织的公共空间。各个开发小组在现阶段的任务完成
后，将可以发布的版本归并到该分支上，将来需要查阅相关资料
时，以该分支上的版本为准。该分支对组织内的全体软件人员开
放只读权限。该分支的管理工作由PL 负责。
3.5.2.4 上述定义的3 类分支以及文档库由CMO 统一管理，根据
各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正
常运作。在变更发生时，应及时做好基线的推进。
3.5.3 分配权限
PL 为每个项目成员分配配置库操作权限。一般地，项目成员拥有
Add、 Checkin/Checkout、Download 等权限，但是不能拥有“删除”权
限。PL 的权限最高。
3.5.4 配置库的操作与管理
3.5.4.1 开发人员根据获得的授权的资源进行项目的研发工作，
操作配置库，例如Add、Checkin/Checkout、Download 等。

bmccbj

244
3.5.4.2 PL 根据配置管理计划创建与维护基线，“冻结”配置项，
控制变更。
3.5.4.3 配置库的检出
当发生变更且变更评审通过后，或者发现Bug且Bug 评审通过后，
由PL将Common Branch 中CIs 检出至开发人员的Private Branch 上，供
开发人员进行变更。
3.5.4.4 配置库的检入
当变更实施结束或Bug 修正和测试结束，并通过配置审核后，由
PL将变更后的CIs 检入到Common Branch。
3.5.4.5 PL 定期清除配置库里的垃圾文件。
3.5.4.6 PL 定期备份配置库。
3.6 配置项和基线管理
3.6.1 CMO 根据配置管理计划，对配置项和基线进行分阶段管理。
3.6.2 项目启动
配置项包括需求说明、订单及其评审结果等；项目发布后应封锁该
子项目，建立发布基线。
3.6.3 需求分析
系统调研后开发人员进行系统分析，并整理需求分析报告。需求分
析报告通过评审并需取得客户的确定。在需求分析报告取得客户的确认
后，封锁该子项目，建立需求基线。如需升版，则必须通过评审并得到
客户的确认

bmccbj

。

245
3.6.4 项目计划
需求分析完成后即可制定项目的开发计划，包括项目总体进度说
明、进度跟踪、计划修改、配置管理计划、质量保证计划、测试计划等。
项目开发计划评审通过后，封锁该子项目，建立项目计划基线。
3.6.5 系统设计
系统设计可分为概要设计、详细设计和数据库设计等部分。针对需
求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报
告版本的对应关系。设计书评审通过后，建立设计基线。
3.6.6 编码
编码按功能模块分子项目，即每个模块计作一个配置项。代码基线
分别在单元测试结束后建立Alpha 版，Alpha 测试后建立Beta 版，在集
成测试时建立Merge 后版。
3.6.7 测试
各测试阶段应提供测试计划、测试用例、测试结果和测试分析报告，
项目启动后应提供项目测试计划书，项目验收结束后应提交项目测试总
结报告等。配置时应说明测试的版本与编码版本的对应关系。各阶段测
试（如单元测试、集成测试）完成后建立测试基线。
3.6.8 交付与验收
在交付前配置审核完成后建立产品基线，产品基线包含程序以及有
关文档配置项，包括交付施工文档、工具等。

bmccbj

246
3.6.9 项目总结
项目总结应经过部门内部评审，包括项目质量报告、测试报告等。
3.6.10 相关资料与培训
相关资料与培训也应作为配置项纳入配置管理，此部分包括：
1) 相关法律、法规；
2) 必须遵照或项目组约定的技术规范；
3) 与客户或项目组内部重要的交互信息记录，如
Question Sheet、会议记录、会谈记录、e-mail 和MSN 记录；
4) 必要的业务或技术培训等。
3.7 配置变更控制
3.7.1 变更的分类
软件及其相关文档的变更按照变更的影响范围进行分类：
1) A级：变更会影响系统级需求、外部接口、产品价格
或者交付期；这类变更必须经过CCB 审核并有客户批准和确认。
2) B级：变更会影响配置项间的功能接口、组件级成本
或者项目Schedule；这类变更必须由CCB 或上级管理部门的批准
和认可。
3) C级：变更会影响配置项内部功能的设计和分配；这
类变更可以由配置项的管理人员负责批准。
图2 变更控制流程

bmccbj

247
3.7.2 变更请求的提出
3.7.2.1 由发起者（客户、最终用户或开发部门）确定变更，填
写《变更请求/评审单》，描述变更原因和变更内容，并提交给CMO。
3.7.2.2 CMO 对填写的申请表是否清晰、明确和完整性进行审查，
若CMO发现变更不明确或不完整，应返回申请表给发起者。CMO 对通过
审查的变更申请分配变更ID，以便跟踪和记录变更信息。
3.7.3 变更评估
3.7.3.1 CMO 将《变更请求/评审单》发送给项目经理（或者其他
授权人员），由项目经理负责对变更进行评估。
3.7.3.2 变更控制的一个重要环节就是变更评估，变更评估要分
析每个变更对系统功能、接口、成本、进度以及约定需求的影响，同时
还要分析对软件安全性、可靠性、可维护性、可移植性和性能的影响。
3.7.3.3 变更评估产生的文档应描述若实施变更必须变更的配置
项、文档和资源；变更评估文档在完成变更评估后发送给CMO。
3.7.3.4 CMO 收到评估后的《变更请求/评审单》后，更新变更记
录，并安排CCB 会议日程。
3.7.4 变更审核
3.7.4.1 CCB 对提交的变更申请进行审核，并根据变更评估确定变
更的影响级别；CCB 审核可能的结果有三种：接受变更；拒绝变更；延
期变更。CCB 也可能需要更多的变更分析的信息。
3.7.4.2 CCB 批准的变更，由CMO 将变更项目发送到指定的开发人
员（Assigner）进行下一步的实施变更工作；对于拒绝的变更，由CMO
将CCB拒绝变更的原因发送给发起者，并保存《变更请求/评审单》，

bmccbj

248
更新变更记录，关闭变更活动；需要进一步分析的，由CMO 将变更项目
随同CCB 的Question Sheet 发送给评估分析人员；对于延期的变更，
由CMO对变更的相关文档进行归档，以便在适当时机提交CCB 审核。
3.7.4.3 CMO 负责整理CCB 会议记录，填写《变更请求/评审单》
中相应审核项；更新变更记录，如果是接受变更，还需将要变更的CIs
状态改为“修改中”；将变更文档分发给相关人员。
3.7.5 变更实施
3.7.5.1 变更被批准后，PL 负责将要变更的CIs 以及相关文档迁
移至变更负责人的Private Branch 上，由变更负责人开始实施变更，
并详细记录变更的内容；项目管理部门要对变更的实施进行跟踪。
3.7.5.2 对于代码变更，必须修改设计、代码、测试以及变更正
确性的验证。而且与变更相关的文档必须修订，以反映变更。当变更以
及测试完成后，进行Merge。
3.7.5.3 对于开发计划、配置管理计划发生变更的，项目组人员
要按照变更过的开发计划、配置管理计划提交配置项。
3.7.6 变更确认
3.7.6.1 变更后的程序Merge 后必需经过测试组进行回归测试，
以确保变更没有引入新的Bug。不会引起程序变更的文档（如计划文档）
的变更不需经过测试。
3.7.6.2 通过Merge 后测试后，SQA 需对变更进行审核，审核的范
围一般涉及以下方面：
1) 测试记录；
2) 变更请求；