clearcaselt配置

bmccbj

32
2 配置项的标识和控制
所有配置项都都应按照相关规定统一编号，按照相应的模板生成，
并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置
管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库

bmccbj

33
中。
所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向
软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开
放。
3 工作空间管理
在引入了软件配置管理工具之后，所有开发人员都会被要求把工作
成果存放到由软件配置管理工具所管理的配置库中去，或是直接工作在
软件配置管理工具提供的环境之下。所以为了让每个开发人员和各个开
发团队能更好的分工合作，同时又互不干扰，对工作空间的管理和维护
也成为了软件配置管理的一个重要的活动。
一般来说，比较理想的情况是把整个配置库视为一个统一的工作空间，
然后再根据需要把它划分为个人（私有）、团队（集成）和全组（公共）
这三类工作空间（分支），从而更好的支持将来可能出现的并行开发的
需求。
每个开发人员按照任务的要求，在不同的开发阶段，工作在不同的工作
空间上，例如：对于私有开发空间而言，开发人员根据任务分工获得对
相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的
所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发
人员外，其他人员均无权操作该私有空间中的元素；而集成分支对应的
是开发团队的公共空间，该开发团队拥有对该集成分支的读写权限，而
其他成员只有只读权限，它的管理工作由SIO负责；至于公共工作空间，
则是用于统一存放各个开发团队的阶段性工作成果，它提供全组统一的
标准版本，并作为整个组织的Knowledge Base。

bmccbj

34
当然，由于选用的软件配置管理工具的不同，在对于工作空间的配置和
维护的实现上有比较大的差异，但对于CMO 来说，这些工作是他的重要
职责，他必须根据各开发阶段的实际情况来配置工作空间并定制相应的
版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做
好基线的推进。
4 版本控制
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都
应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，
自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信
息以外，为了配合软件开发流程的各个阶段，我们还需要定义、收集一
些元数据（Metadata）来记录版本的辅助信息和规范开发流程，并为今
后对软件过程的度量做好准备。当然如果选用的工具支持的话，这些辅
助数据将能直接统计出过程数据，从而方便我们软件过程改进
（Software Process Improvement，SPI）活动的进行。
对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置
相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被
锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行
操作。
5 变更控制
在对SCI 的描述中，我们引入了基线的概念。从IEEE对于基线的
定义中我们可以发现，基线是和变更控制紧密相连的。也就是说在对各
个SCI做出了识别，并且利用工具对它们进行了版本管理之后，如何保

bmccbj

35
证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况
下都能迅速的恢复到任一历史状态就成为了软件配置管理的另一重要
任务。因此，变更控制就是通过结合人的规程和自动化工具，以提供一
个变化控制的机制。
在本文的前面的部分中，已经把SCI分为基线配置项和非基线配置项两
大类，所以这里所涉及的变更控制的对象主要指配置库中的各基线配置
项。
变更管理的一般流程是：
A) （获得）提出变更请求；
B) 由CCB 审核并决定是否批准；
C) （被接受）修改请求分配人员为，提取SCI，进行修改；
D) 复审变化；
E) 提交修改后的SCI；
F) 建立测试基线并测试；
G) 重建软件的适当版本；
H) 复审（审计）所有SCI 的变化；
I) 发布新版本。
在这样的流程中，CMO 通过软件配置管理工具来进行访问控制和同步控
制，而这两种控制则是建立在前文所描述的版本控制和分支策略的基础
上的。
6 状态报告
配置状态报告就是根据配置项操作数据库中的记录来向管理者报
告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过

bmccbj

36
CASE 工具自动生成，用数据库中的客观数据来真实的反映各配置项的情
况。
配置状态报告应根据报告应着重反映当前基线配置项的状态，以作为对
开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录
来对开发团队的工作关系作一定的分析。
配置状态报告应该包括下列主要内容：
A) 配置库结构和相关说明；
B) 开发起始基线的构成；
C) 当前基线位置及状态；
D) 各基线配置项集成分支的情况；
E) 各私有开发分支类型的分布情况；
F) 关键元素的版本演进记录；
G) 其它应予报告的事项。
7 配置审计
配置审计的主要作用是作为变更控制的补充手段，来确保某一变更
需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，
但当软件配置管理是一个正式的活动时，该活动由SQA 人员单独执行。
总之，软件配置管理的对象是软件研发活动中的全部开发资产。所有这
一切都应作为配置项纳入管理计划统一进行管理，从而能够保证及时的
对所有软件开发资源进行维护和集成。因此，软件配置管理的主要任务
也就归结为以下几条：（1）制定项目的配置计划；（2）对配置项进行
标识；（3）对配置项进行版本控制；（4）对配置项进行变更控制；（5）
定期进行配置审计；（6）向相关人员报告配置的状态。

bmccbj

37
在此，我想特别指出的是：由于软件配置管理覆盖了整个软件的开发过
程，因此它是改进我们的软件过程、提高过程能力成熟度的理想的切入
点。希望本文所描述的这个软件配置管理的角色分配和工作流程能在实
践中不断地得到完善，从而使我们的软件开发活动能够更加有序、高效
的进行！
第二节 如何构造软件企业的配置管理方案
1 引言
1.1 什么是配置管理
配置管理(Configuration Management)是通过技术或行政手段对软
件产品及 其开发过程和生命周期进行控制、规范的一系列措施。配置
管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周
期中各个阶段都能得到精确的产品配置。
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过
程。其最 终目标是实现软件产品的完整性、一致性、可控性，使产品
极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改
和每个修改生成的软件组成部件来实现对软件产品的管理功能。
1.2 配置管理在软件开发过程和项目管理过程中的作用
随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置
管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演
着越来越重要的角色。一个好的配置管理过程能覆盖软件开发和维护的
各个方面，同时对软件开过程的宏观管理，即项目管理，也有重要的支
持作用。良好的配置管理能使软件开发过程有更好的可预测性，使软件

bmccbj

38
系统具有可重复性，使用户和主管部门用软件质量和开发小组有更强的
信心。 软件配置管理的最终目标是管理软件产品。由于软件产品是在
用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制
和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必
须对动态的、成长的产品进行管理。 由此可见，配置管理同软件开发
过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户
所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本
中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，
推动新的开发周期。通过配置管理过程的控制，用户对软件产品的需求
如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产
流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开
发的不同阶段通常有不同的任务，由不同的角色担当，各个角色职责明
确，泾渭分明，但同时又前后衔接，相互协调。好的配置管理过程有助
于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接
合，使整个开发团队象一个交响乐队一样和谐而又错杂地行进。正因为
配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是
项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起
着重要。 配置管理过程演化出的控制、报告功能可帮助项目经理更好
地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付
日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于
管理者应付开发人员流动的困境，使新的成员可以快速实现任务交接，
尽量减少因人员流动而造成的损失。

bmccbj

39
1.3 配置管理方案的构成
配置管理过程对软件开发有如此重要的影响，它的构造、实施过程
也必定相当复杂。不借助工具，纯粹靠手工方式或只利用简单的工具来
实现配置管理是很难做到满意程度的，而且其中的繁琐庞杂最终必定让
管理者一愁莫展。因此，实现配置管理过程的通常做法是借助于专业化
的配置管理工具，结合开发组织的实际情况制订出相应的配置管理规
范，由开发人员在工作过程中依据规范，通过配置管理工具来实现。在
这整个过程中，由配置管理工具负责那些非智能的、可自动化的管理过
程，如身份角色验证、修改轨迹记录、版本控制等；由配置管理规范来
控制那些 需要开发人员行方案确用智力去判断的因素，如需求合理性
和优先级判定、任务分工、产品 的结构定义、版本发定等等。配置管
理工具的采用和配置管理规范的制订 是紧密联系的，二者构成了一个
软件开发机构的整体配置管理方案。这种方案是因组织的差异和配置管
理工具的差异而变化的。构造一个配置管理方案涉及到软件开发组织和
开发过程的各个方面，是一个复杂的工程应该当作一个项目来做。本文
试图给出一个构造配置管理方案的基本策略和主要步骤。
2 组建配置管理方案构造小组
构造或完善一个软件开发组织的配置管理过程需要在构造初期花
费较大的人力物力。这种工作一般是由一个临时组成的软件配置管理过
程构造小组来完成。这个小组负责构造配置管理过程中的所有工作，包
括了解本组织的现有开发、管理现状，选择配置管理工具，制订配置管
理规范，安排试验项目的实施，沟通部门间关系，获得管理者支持和开
发人员的认同。

bmccbj

40
配置管理过程构造小组的成员应该包括：
小组负责人
其对整个构造过程负责。主要职责是协调与其它部门或与上级主管
的关系， 监督工作进程，协调小组内部关系。
技术支持专家
其负责在技术、设备方面为本组提供支持和服务，并负责本同其它
部门就技 术问题进行联络，如了解相关项目情况、开发环境、开发人
员状况等。
配置管理技术专家
其对配置管理过程的构造和配置管理工具十分熟悉。主要任务是指
导配置管 理过程的构造，帮助制订配置管理规章，负责对开发人员进
行配置管理工具的培 训。通常是配置管理工具提供商或专门的配置管
理顾问机构的人员担当此任。
配置管理系统用户代表
他们是从将来要在实际的项目开发过程中使用该系统、遵照该过程
的开发人 员中挑选出来的。他们负责从构造初期了解配置管理系统和
规程，根据开发经验协 助制订、修改配置管理规程，并在试验项目中
担任部分开发角色。这部分成员应包括软件开发项目经理、设计人员、
编码、测试和构造、发布人员。 该项目小组成立后，将按后述步骤开
展配置管理过程的构造工作。
3 对目标机构进行了解、评估
"知已知彼，百战不殆验"。配置管理过程的构造过程也是如此，必
须对相互 作用的双方都有较透彻的了解才能达到预期的效果。因此首

bmccbj

41
先要做的事情是调查了 解，既要了解目标机构（即将要采用该配置管
理过程的软件开发组织）的情况，又
要了解配置管理工具的情况。 目标机构的调查评估工作由配置管
理技术专家领导，配置管理系统用户代表参与，提供基本信息，并由小
组负责人协调，对相关部门人员进行深入调查获得较 全面的数据。 对
目标机构的了解、评估应从这几个方面入手：人员、技术、工作流程、
现 有项目和期望值。
3.1 人员评估
人员评估的目的是了解目标机构的员工对现有配置管理过程的评
价和对采用新工具、制订新规范的态度，预测新的配置管理过程构造中
的工作难点和可能遇到 的阻力。调查的方面包括： 该组织员工对引入
新工具的反应，以前是否有过类似的偿试。 该组织负责人对新工具、
新流程的支持程度。 开发人员的素质、教育程度、沟通能力。开发队
伍的稳定性。 该组织的沟通渠道是否通畅。
3.2 技术评估
对目标机构技术方面的的调查、评估将直接导致对工具的选择。要
了解的信息有：
目标机构有哪些可用的计算资源。
在什么软硬件平台上进行开发。
是否存在资源瓶颈，是什么。
现用什么开发工具，用户对该工具评价如何。
现用什么网络环境。
使用什么编程语言。