clearcaselt配置

bmccbj

42
目标平台是否与开发平台一致。
代码更新程度如何，新编代码、重用代码和历史代码各占什么比例。
3.3 现有流程评估
对目标组织现有工作流程的评估直接影响新的配置管理流程和规
章的制订。
调查的方面是：
现有流程的成熟性、适用性和执行情况。
现有流程是否能进一步提高自动化程度。
现用什么开发模型。
对分析、设计、编码、测试、产品管理等过程是否有严格的成文规
范，如何
保证该规范的执行。
开发流程中的哪些质量控制信息被收集，如何使用。
3.4 项目评估
配置管理系统对正在开发的产品、正在进行的项目有直接的影响，
因此对即将纳入管理的项目应有充分的了解。
了解的方面有：
项目的平均工期（人月）。
项目的组织方式，是主程序员制还是开发小组制，按深度结构还
是按广度结构组织。
项目的产品规模（功能模块数、源码行数）。
项目开发支持状况，是否有专门的开发环境、开发工具和配置管理
等方面的 支持人员。

bmccbj

43
3.5 期望值评估
对目标机构的开发、管理人员对新系统的期望值的了解有利于对症
下药，解 决其当前紧要问题，提高对新系统的信心。
调查的方面包括：
对当前本组织的生产率和产品质量的满意程度，期望有怎样的提
高。
对现有流程的评价，现有流程中哪个环节希望改进或加强。
期望增减哪些文档或规则。
期望等到什么样的通信交流方式，现有方式的优缺点是什么。
期望收集哪些新的开发度量数据或简化哪些数据。
4 配置管理工具及其提供商评估
通过对目标组织的评估，了解该组织的现状和需求后，就需要选
择适合该组 织的配置管理工具。市场上现有的配置管理工具不下数十
种，它们各有所长，在功 能，性能等方面有较大的差别，只有经过仔
细地对产品及其提供商进行分析评估， 核对目标机构的需求，才能挑
选出合适的工具，实现一个理想的配置管理过程。
这种评估可从三个方面进行：配置管理工具的评估、供应商评估和
其它用户 使用经验的评估。
配置管理工具评估
对工具的评估应侧重于功能的适用性，而不应一味强调功能的
全面性。产品评估应了解如下问题：
该产品的哪一方面功能可解决目标组织的当前问题满足该组织在
配置管理上 的需求。

bmccbj

44
该产品在目标机构的峰值负荷下的运行效率将如何。
该产品对并发使用的支持情况如何
该产品与现有系统、工具、流程、环境的兼容性如何。
该产品的成熟性和稳定性如何。
该产品是否易学易用。
该产品的购买、安装、实施、维护费用是否可以接受。
供应商评估
供应商的实力和它所能提供的服务和支持对配置管理系统的
实施至关重要。
因为配置管理工具不象其它的工具那样，只要安装完成后按照使用
手册和在线帮助
就能使用，而是必须在系统之外有一系列的操作、管理规范，有一
套完整的方案。
这些些必须在系统提供者或顾问机构的帮助下才能制订、实施。因
此，系统提供商
对配置管理过程的实现有重要影响。对供应商的评估包括：
供应商在相应行业的从业时长。
该产品是否是该供应商的主导产品。
该供应商的年销售额。
供应商在五年之内的稳定情况。
该供应商是否有专业化的客户支持队伍。
是否提供安装、用户培训等服务。
供应商的声望、信誉如何。
供应商的支持人员在地理位置上是否与目标机构邻近。

bmccbj

45
另外，通过了解同一产品的其它用户对该产品的评价可以对该产品
和供应商
有较为客观、综合的认识。这种评价可从所知的用户组、专业会议、
配置管理工具
公告板等途径获得。
5 制订实施计划
经过对目标机构和选用工具的评估，工作小组可以制订出一份
完整的工作计 划作为下一阶段的行动纲要，同时也是向上级主管汇报，
取得支持的有力佐证。
工作计划由如下部分组成：
必要性和影响因素
结合目标机构的开发过程组织和配置管理现状，论证构造或完善配
置管理过程的必要性；根据所选配置管理工具的功能特性和供应商的实
施支持，阐明新的配 置管理系统可对目标机构的开发和管理工作带来
改进和驱动。另外，对该配置管理 系统和相应的配置管理过程对现有
的人员、工序和管理等方面可能带来的影响作出适当的预测，以便减小
将来实施时可能遇到的阻力。 配置管理目标和配置管理过程的构造成
功标准 对正待构建的新的配置管理过程制订出一个较为长远的目标，
即要达到哪种 控制程度，加强哪些方面的管理，是否按照相关的国家
或国际标准实施，达到何种 级别等等。 另外，对构造配置管理过程的
工作本身，如前所述应当作一个项目来做，因 此也必须制订一个明确
的完成标准。该标准应该在本小组内部统一并获得上级主管认可。
人员组织和分工

bmccbj

46
进一步明确工作小组的组织成员和成员关系，为每个成员分派相应
的任务和
职责。这些任务应该具体、细化到可操作的程度，如张三负责与某
部门接洽，了解
原有某一管理规范，李四负责试验环境的准备工作等等。
进度计划
罗列出构造过程中所要解决的问题，设置里程碑。
风险管理
预测构造过程中可能遇到的外在困难因素，如硬件短缺、平台差异、
与相关
部门冲突、试验项目的特殊性等等。为这些风险因素设计出降低或
规避风险的方法。
6 定义配置管理流程
配置管理流程是软件开发机构进行配置管理的依据，也是配置
管理构造工作小组的最重要的工作成果。配置管理流程规定开发过程中
需要做哪些配置管理方面 的工作，由谁做、如何做。前两个问题有较
为通用的答案，在后文将会涉及，第三个问题则必须根据目标机构的具
体情况解决。制订配置管理流程的方法是：通过对目标机构的调查、评
估，定义现有的配 置管理流程，由配置管理技术专家对它进一步分析，
结合常规的配置管理方法制订出新的流程。之后，依据选定的配置管理
工具的功能，将新流程中可自动化的环节交由配置管理工具处理，其它
环节由新制订的配置管理规范控制。除了制订配置管理规范外，该小组
还应制订出适合目标机构的配置管理基本章程。该章程进应包括配置管

bmccbj

47
理部门的设立、该部门的责能（通常是负责监督配置管理规范的执行情
况，对配置规范行完善，并担当日常的内部配置管理过程支持任务），
定义配置管理过程与开发过程的协调关系，以及各开发阶段的开发人员
构
成、在配置管理流程中的责任划分等等。一般说来，配置管理包括
四个方面的活动：配置项标志，配置项控制（修改控制），配置状态报
告和配置审核。配置管理规范的制订也应按这四个方面内容进行。每一
个方面要考虑的问题是：
配置项标志制订文档或文件编号、标记体系。
定义文档和文件之间的联系。
确定受控的配置项的取舍，如软件源码、硬件描述文件、中间文件、
目标文件、测试方案、系统数据等等。
确定产品版本、基线的标志体系。
确定库程序的标志和管理机制。
配置项控制确定产品的版本的演化策略，规定何时、何人创建新的
基线，如何创建。
确定修改请求控制机构（CCB－Change Control Board） 的人员组
成、职能、工作程序。
确定修改请求的处理流程和终止条件。
确定修改请求处理过程中各开发人员的职能。
确定修改请求和所生成的结果的对应机制。
确定文档的修改方式。
确定配置项的提取方式。
配置状态报告定义报告的内容、形式、提交方式。

bmccbj

48
确定产品的发行事宜，包括发行时间如何确定、发行说明的生成发
布方式、发行方式等。
配置审核确定审核的执行人员、执行时机，审核的内容和方式。
确定发现问题后的处理方法。
7 试验项目的实施
这一阶段的任务是选取目标机构中的一个现有项目，按既定的配置
管理流程去进行开发和配置管理工作。这种试验的目的是在一定风险范
围内，通过实地运作来确定所选配置管理工具、所制订的配置管理规范
是否能满足目标机构的需要。要做的工作有：
选定试验项目
该项目应该具有一定的复杂性，但又有较强的独立性，不会对目标
机构的关键项目造成重要影响。
选定试验组成员
通常应包括构造小组的部分成员和该项目原有的成员。
定义试验成功的标准和试验时间表
应以配置管理流程和项目开发管理过程的协同程度和总体工作效
率为依据。
人员培训
包括配置管理工具培训和配置管理规范培训。
配置管理工具的安装和项目环境的搭建
包括将历史代码导入到新系统中，将原有配置管理信息转换成新系
统的形成，置于新系统控制之下；搭建项目所需的软硬环境等。
开发过程按新的配置管理流程进行试验项目的开发，及时收集项目

bmccbj

49
开发人员的反馈信息。
调整配置管理流程
根据项目的进行情况和开发人员的反馈信息，找出新配置管理流程
的不足，及时调整改进。
8 全面实施
经过试验项目证实、校正后的配置管理流程就可以在目标机构的各
个项目、各个相关工作环节中去应用、实施，最终使配置管理过程日常
化、规范化。全面实施过程主要由配置管理部门根据新的配置管理流程
来指导。配置管理过程构造小组的作用趋于淡化，主要起监督和支持作
用。该小组在全面实施过程中逐步解散，小组中部分成员可转移到配置
管理部门中去。
全面实施阶段的任务有：
组建或完善配置管理部门，并完成配置管理流程的移交。
由配置管理部门制订各个项目的配置管理实施计划。
进行全组织范围的配置管理系统和规则的培训。
帮助各个开发项目向新流程转移。
进行日常的监督、抽查、评估和规范的完善工作。
9 结束语
配置管理过程的建立是一个复杂而漫长的过程，因为它受软件开发
机构的许多方面的影响，包括技术、设备、项目、制度、人员、文化等
因素。就象其它任何新事物的出现一样，在一个机构内刚刚建立的配置
管理过程必然会受到各方面的挑战和考验，因此需要有一个适应、融合
的过程。另外，配置管理过程的建立也不是一件一劳永逸的事情，不同

bmccbj

51
5、 维护稳定、一致的工作空间；
6、 支持对于工件和控件的并发修改；
7、 尽早集成、持续集成；
8、 保证软件构建的重现能力；
9、 以控件（Component）为单位实施版本控制；
10、 使用“活动”（Activity）来组织和整合版本集。
下文将介绍前5 条最佳实践。
1、标识需要进行存储的工件（Artifact）并保障安全存储
在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、
源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件
（Artifact）。对于一个软件开发组织来说，这些工件就构成了组织的核
心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，
好好地保存；对于软件资产，我们也需要相似的措施。所以，软件配置
管理工作的第一步就是建立一个安全、可靠的存储库（Repository），用
于保存组织的核心软件资产。 这个库对于开发团队来说，就像是财务
室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除
此之外，随着组织的增长，置于库中的数据会越来越多，为保证运行效
率，库的可扩展性也是非常重要的一个属性。

bmccbj

52
对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。
令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也
给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。
在建立好存储库以后，需要做的工作就是确定将哪些工件置于库
中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、
发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，
则不将它们放入库中。我们把放入库中的文件称之为配置项
（Configuration Item）。
2、控制并且审计（Audit）对于工件的修改
在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些
工件的修改控制机制以及审计机制。
库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿
到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作
被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为
什么原因做出这个改动，以及修改了哪些地方（Who、When、Why、
What）。
审计机制通常通过“检出/检入”（Check out/Check in）模式得到实
现。在这种模式下，工件一旦入库，读写权限就变成只读（read only），
如果要对该工件进行修改，则需要通过“检出”这个步骤；在修改结束
以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在
经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人
把上边的过程称之为“版本控制”（Version Control）。在版本控制过