第十四章 项目采购管理

配置管理过程构造小组应该包括如下成员。
④小组负责人。其对整个构造过程负责。主要职责是协调与其他部门或与上级主
管的关系， 监督工作进程，协调小组内部关系。
②技术支持专家。其负责在技术、设备方面为本组提供支持和服务，井负责本组
同其他部门就技术问题进行联络，如了解相关项目情况、开发环境和开发人员状况等。
③配置管理技术专家。其对配置管理过程的构造和配置管理工具十分熟悉。主要
任务是指导配置管理过程的构造，帮助制订配置管理规章，负责对开发人员进行配置管
理工具的培训。通常由配置管理工具提供商或专门的配置管理顾问机构的人员担当此任。
④配置管理系统用户代表。他们是从将来要在实际的项目开发过程中使用该系统、
遵循该过程的开发人员中挑选出来的。他们负责从构造初期了解配置管理系统和规程，
根据开发羟验协助制订、修改配置管理规程，并在试验项目中担任部分开发角色。这部
分成员应包括软件开发项目经理、设计人员、编码、测试和构造、发布人员。该项目小
组成立后，将按后述步骤开展配置管理过程的构造工作。

目标机构的调查评估工作由配置管理技术专家领导，配置管理系统用户代表参与，
提供基本信息，并由小组负责人协调，对相关部门人员进行深入调查获得较全面的数据。
对目标机构的了解、评估应从人员、技术、工作流程、现有项目和期望值几方面入手。

通过对组织的评估，了解该组织的现状和需求后，就需要选择适合该组织的配置管
理工具。市场上现有的配置管理工具不下数十种，它们各有所长，在功能、性能等方面
有较大的差别，只有对产品及其提供商进行仔细地分析评估，核对目标机构的需求，才
能挑选出合适的工具，实现一个理想的配置管理过程。这种评估可从三个方面进行：配
置管理工具的评估、供应商评估和其他用户使用经验的评估。

实施计划由如下部分组成；必要性和影响因素、人员组织和分工、进度计划和风险
管理。

制订配置管理流程的方法是：通过对目标机构的调查、评估，定义现有的配置管理
流程，由配置管理技术专家对它进一步分析，结合常规的配置管理方法制订出新的流程。
之后，依据选定的配置管理工具的功能，将新流程中可自动化的环节交由配置管理工具
处理，其他环节由新制订的配置管理规范控制。除了制订配置管理规范外，该小组还应
制订出适合目标机构的配置管理基本章程。该章程应包括配置管理部门的设立、该部门
的职能（通常是负责监督配置管理规范的执行情况，对配置规范进行完善，并担当日常
的内部配置管理过程支持任务），定义配置管理过程与开发过程的协调关系，以及各开发
阶段的开发人员构成、在配置管理流程中的责任划分等。
一般来说，配置管理包括配置项标识，配置项控制（修改控制）、配置状态报告和配
置审计4 个方面的活动。配置管理规范的制订也应按这4 个方面内容进行。每一个方面
要考虑的问题如下。
①配置项标志制订文档或文件编号、标记体系，定义文档和文件之间昀联系。
②确定受控的配置项的取舍，如软件源码、硬件描述文件、中间文件、目标文件、
测试方案和系统数据等。确定产品版本、基线的标志体系。
③确定库程序的标志和管理机制。配置项控制确定产品版本的演化策略，规定何
时、何人创建新的基线，如何创建。确定修改变更控制委员会的人员组成、职能和工作
程序。
④确定修改请求的处理流程和终止条件。
⑤确定修改请求处理过程中各开发人员的职能。确定修改请求和所生成结果的对
应机制。
⑥确定文档的修改方式。
⑦确定配置项的提取方式。配置状态报告定义报告的内容、形式和提交方式。
⑧确定产品的发行事宜，包括发行时间如何确定、发行说明的生成发布方式及发
行方式等。配置审计确定审计的执行人员、执行时机，审计的内容和方式。
⑨确定发现问题后的处理方法。

这一阶段的任务是选取目标机构中的一个现有项目，按既定的配置管理流程进行开
发和配置管理工作。这种试验的目的是在一定风险范围内，通过实地运作来确定所选配
置管理工具、所制订的配置管理规范是否能满足目标机构的需要。

经过试验项目证实、校正后的配置管理流程就可以在目标机构的各个项目、各个相
关工作环节中去应用、实施，最终使醌置管理过程日常化、规范化。全面实施过程主要由配置管理部门根据新的配置管理流程来指导。配置管理过程构造小组的作用趋于浈化，
主要起监督和支持作用。该小组在全面实施过程中逐步解散，小组中部分成员可转移到
配置管理部门中去。

配置库可以分为动态库（开发库、程序员库、工作痒）、受控库（主库）、静态库（软
件仓库）和备份库4 种类型。
(l)动态库。也称为开发库、程序员库或工作库，用于保存开发人员当前正在开发
的配置实体。动态库通常包括新模块、文档、数据元素或进行修改的已有元素。动态库
是软件工程师的工作区，由工程师控制。
(2)受控库。也称为主库或系统库，是用于管理当前基线和控制对基线的变更。受
控库包括配置单元和被提升并集成到配置项中的组件。软件工程师和其他人员可以自由
地复制受控库中的单元或组件。然而，必须有适当的权限授权变更。受控库中的单元或
组件用于创建集成、系统和验收测试或对用户发布的构建，
(3)静态库。也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基
线。静态库用于控制、保存和检索主媒介。
(4)备份库。包括制作软件和相关构架、数据和文档的不同版本的复制品。在各点
的及时备价，可以每天、每周或每月执行备份。

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配
置项类型分类建库和按任务建库。
按配置项的类型分类建库的方式经常被一些咨询服务公司所推荐，它适用于通用的
应用软件开发组织。这样的组织，往往产品的继承性较强，工具比较统一，对并行开发
有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编
译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可
能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
而接任务建立相应的配置库，则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分
类存储，人为增加目录的复杂性。因此，对于研发性的软件组织来说，还是采用这种设
置策略比较灵活。

可以用vss、cvs 等工具建立配置库，进行选择时考虑以下内容。
(1)所支持的组件类型。工具是否支持文档（文本）、代码（源代码、目标代码和
可执行文件）、图解的表示和数据。
(2)版本策略。用于维护版本历史的方法是什么。
(3) SCM 模型。模型是否仅基于源文件修改或者关注版本、基线和软件工程学范例。
(4)数据管理。如何存储配置实体。
(5)系统生成什么类型的报告。
(6)用户界面和查询能力。系统是否有易用和健壮的用户界面？有哪种类型的信息
查询可供使用，是否易用。
(7)可追溯性。将一个配置实体和其他实体联系是否容易。
(8)自动构建方法。当发生变更时，使用什么技术来创建新的版本。
(9)安全性。使用什么机制来控制配置实体的存取。
(10)测试管理。能否使用工具管理测试用例和测试结果。
(1])定制化管理。能否定制这个工具以满足本土化的SCM 过程和需要。
(12)集成。这个工具是否能和其他的SCM 工具集成，或者这个工具是否能和连接
SCM 环境的工具集成。