clearcaselt配置

bmccbj

22
补。
对变更请求的有效管理可以提高产品管理的透明度，经理可以清楚
的知道当前产品的进展情况，比如有多少个新产生的CR，已经解决了多
少CR 等等，有利于经理做出正确的决策。
基线管理
基线是指经过正式评审和批准，可作为下一步工作的基准的一个配
置。软件开发过程中，无论是需求分析、设计、测试都需要在完成时建
立基线，以作为下一步工作的基础。通过基线管理可以使用户能够通过
对 适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的
“组装”策略使得配置管理系统像搭积木似的使用已有的积木（版本）
组装成各种各样、不同功能的模型。基线的变更需要一个严格的流程，
需要提出申请，经过审批，然后才能进行。
构建管理
在做构建时，我们需要首先取出正确的配置，然后再做构建。我们
可以利用基线，可以取出某个基线的所有配置项，也可以利用配置管理
系统的构建功能直接在工作空间内做构建。构建管理需要配置管理工具
的支持。
发布管理
软件产品的每个版本都是一组配置项（源代码、文档、数据）的集
合。举个例子来说，我们要发布软件的32.6 版本，那么我们就要把源
代码、文档、数据中所有应该包含到这个版本中的正确配置项检出。
所以如何管理每个版本中包含哪些配置项是非常重要的。
状态报告
状态报告要回答所谓4W 的问题：
What：发生了什么事？

bmccbj

23
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告要能够报告所有配置项以及变更请求的状态，通过量化的
数据和报表反映项目开发进度的状态。
配置审核
配置审核要审查整个配置管理过程是否符合规范，配置项是否与需
求一致，
记录正确，配置的组成是否具有一致性等等。比如，需求分析文档
提交后，需要由一个由相关人组成的小组进行正式评审，只有通过了评
审才能基线化。对于源代码也一样，一般说来，每行代码都要进行评审
（Review），只有通过评审才能交由测试人员进行测试。
实施配置管理的好处
我们知道软件有三个要素：时间、预算和质量。一个成功的软件就
是要在限定的时间内，不超过预算，交付符合质量要求的产品。真正实
施配置管理后，我们会对产品的开发过程进行有效的控制，可以加快开
发进度，降低开发成本，保证产品的质量。
产品经理可以得到什么好处呢？
准确掌握项目的开发进度。配置管理系统可以提供详尽的状态
报告，例如当前系统有多少个Bug，所有Bug 的状态如何？已经解决了
多少Bug？
了解项目组成员的工作负荷、工作效率以及工作质量。例如，
我们可以知道当前分配给每个成员的工作量，每个成员已完成的工作

bmccbj

24
量，每个成员未通过正式评审的工作比例等等。
减少人员流动所带来的影响。每个成员的所有变更，包括文档、
代码的增删都是可追踪的，而且对于变更的原因、描述也都有记录。这
样，一旦成员离开，其它成员就可以在最短的时间里接手。
有效提高过程管理，配置管理产生的许多数据可作为管理者度
量项目的依据。
开发人员和测试人员可以得到什么好处呢？
提交的代码被有效保存，开发人员再也不用花费精力去保存各
个版本了。
提高团队的协作效率。开发人员之间以及开发人员和测试人员
之间可以有效的沟通，大家都互相知道其它人的工作状态。
提高修复缺陷的效率。可以依据Bug 发现的版本，迅速重建环
境，重现Bug，快速定位代码，找出根源。
职责清楚，任务明确。每一步的工作都是基于某一基线的，比
如，设计文档是依据基线化了的需求分析文档，这样一旦出现问题，就
可以找出问题出在什么地方。当然，实施配置管理的好处远不止这些。
软件配置管理作为软件开发的基石，它提供了一个协作开发的环境，只
有大家共同遵守配置管理规范，互相协作才能保证项目的成功。
结束语
配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置
管理应用于“知识库”的管理就产生了“内容管理”这一新的领域。配
置管理提供的状态报告和数据统计也为软件度量提供了决策依据。配置
管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握

bmccbj

25
项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，
在此平台上，大家能够更有效率的交流和协作。可以说，配置管理是软
件开发的基石！配置管理近年来在中国得到了极大的认可，可以毫不夸
张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈
不上软件业的发展。随着软件业规模的扩大，配置管理的实施不是要不
要的问题，而是什么时间、如何实施的问题了。
第四章 过程支持
第一节 软件配置管理过程及其关键活动
随着软件产业的崛起，软件工程技术正吸引着越来越多关注的
目光。特别是以CMM 为代表的先进的软件工程理念在国内也正日益受到
业界广泛的重视。
软件配置管理（Software Configuration Management，SCM）作
为CMM 2 级的一个关键域（Key Practice Area，KPA），在整个软件的
开发活动中占有很重要的位置。正如Pressman 所说的：“软件配置管
理是贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，
（2）控制变化，（3）保证变化被适当的发现，以及（4）向其他可能
有兴趣的人员报告变化。” 所以，我们必须为软件配置管理活动设计
一个能够融合于现有的软件开发流程的管理过程，甚至直接以这个软件
配置管理过程为框架，来再造组织的软件开发流程。
本章参照了CMM 2 级中软件配置管理的相关的要求，充分考虑了

bmccbj

26
在CASE 工具的辅助下实现自动的软件配置管理的可能性，描述了在一
个比较理想的软件研发组织中软件配置管理的流程及其关键活动。
一. 角色职责
对于任何一个管理流程来说，保证该流程正常运转的前提条件就是
要有明确的角色、职责和权限的定义。特别是在引入了软件配置管理的
工具之后，比较理想的状态就是：组织内的所有人员按照不同的角色的
要求、根据系统赋予的权限来执行相应的动作。因此，在本文所介绍的
这个软件配置管理过程中主要涉及下列的角色和分工：
项目经理（Project Manager，PM）：
项目经理是整个软件研发活动的负责人，他根据软件配置控制委员
会的建议批准配置管理的各项活动并控制它们的进程。其具体职责为以
下几项：
制定和修改项目的组织结构和配置管理策略；
批准、发布配置管理计划；
决定项目起始基线和开发里程碑；
接受并审阅配置控制委员会的报告。
配置控制委员会（Configuration Control Board，CCB）：
负责指导和控制配置管理的各项具体活动的进行，为项目经理的决
策提供建议。其具体职责为以下几项：
定制开发子系统；
定制访问控制；

bmccbj

27
制定常用策略；
建立、更改基线的设置，审核变更申请；
根据配置管理员的报告决定相应的对策。
配置管理员（Configuration Management Officer，CMO）：
根据配置管理计划执行各项管理任务，定期向CCB 提交报告，并列
席CCB的例会。其具体职责为以下几项：
软件配置管理工具的日常管理与维护；
提交配置管理计划；
各配置项的管理与维护；
执行版本控制和变更控制方案；
完成配置审计并提交报告；
对开发人员进行相关的培训；
识别软件开发过程中存在的问题并拟就解决方案。
系统集成员（System Integration Officer，SIO）：
系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为
以下几项：
集成修改；
构建系统；
完成对版本的日常维护；
建立外部发布版本。

bmccbj

28
开发人员（Developer，DEV）：
开发人员的职责就是根据组织内确定的软件配置管理计划和相关
规定，按照软件配置管理工具的使用模型来完成开发任务。
二．过程描述
一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段
和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活
动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。
项目计划阶段：
一个项目设立之初PM 首先需要制定整个项目的计划，它是项目研
发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以
展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件
配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是
造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救
火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目
成功的重要保证。
在软件配置管理计划的制定过程中，它的主要流程应该是这样的：
CCB 根据项目的开发计划确定各个里程碑和开发策略；
CMO根据CCB 的规划，制定详细的配置管理计划，交CCB 审核；
CCB通过配置管理计划后交项目经理批准，发布实施。

bmccbj

29
项目开发维护阶段：
这一阶段时项目研发的主要阶段。在这一阶段中，软件配置管理活
动主要分为三个层面：（1）主要由CMO 完成的管理和维护工作；（2）
由SIO和DEV 具体执行软件配置管理策略；（3）变更流程。这三个层
面是彼此之间既独立又互相联系的有机的整体。
在这个软件配置管理过程中，它的核心流程应该是这样的：（1）
CCB设定研发活动的初始基线；（2）CMO 根据软件配置管理规划设立配
置库和工作空间，为执行软件配置管理做好准备；（3）开发人员按照
统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工
作；（4）SIO 按照项目的进度集成组内开发人员的工作成果，并构建系
统，推进版本的演进；（5）CCB根据项目的进展情况，审核各种变更请
求，并适时的划定新的基线，保证开发和维护工作有序的进行。
这个流程就是如此循环往复，直到项目的结束。
当然，在上述的核心过程之外，还涉及其他一些相关的活动和操作
流程，下面按不同的角色分工予以列出：
各开发人员按照项目经理发布的开发策略或模型进行工作；
SIO负责将各分项目的工作成果归并至集成分支，供测试或发布；
SIO可向CCB 提出设立基线的要求，经批准后由CMO 执行；
CMO定期向项目经理和CCB 提交审计报告，并在CCB 例会中报告项目在
软件过程中可能存在的问题和改进方案；
在基线生效后，一切对基线和基线之前的开发成果的变更必须经CCB 的
批准；
CCB定期举行例会，根据成员所掌握的情况、CMO 的报告和开发人员的

bmccbj

30
请求，对配置管理计划作出修改，并向项目经理负责。
综上所述，配置管理的工作流程如图1 所示：

bmccbj

31


三．关键活动
1 配置项（Software Configuration Item，SCI）识别
Pressman对于SCI 给出了一个比较简单的定义：“软件过程的输出
信息可以分为三个主要类别：（1）计算机程序（源代码和可执行程序），
（2）描述计算机程序的文档（针对技术开发者和用户），以及（3）数
据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的
信息，总称为软件配置项。”
由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计
划的重要内容。
软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严
重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线
（Base Line）”这一概念。IEEE 对基线的定义是这样的：“已经正式
通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并
且只能通过正式的变化控制过程改变。”
所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配
置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括
所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和
报告等。