第 19 章：配置管理配置项比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、

配置项

比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。

基于配置项建设过程角度，可将配置项状态分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。

基线通常对应于项目过程中的里程碑（Milestone)，一个项目可以有多个基线，也可以只有一个基线。

建立基线的价值可包括：

配置库可以分幵发库、受控库、产品库 3 种类型。

配置库的建库模式有两种：按配置项类型建库和按幵发任务建库。

按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。
按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。

配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有:

配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：

配置项负责人确保所负责的配置项的准确和真实：

配置管理的日常管理活动主要包括：

配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。

现以某软件产品升级为例，其过程简述为：

将待升级的基线（假设版本号为 V2.1 ) 从产品库中取出，放入受控库。
程序员将欲修改的代码段从受控库中检出（Checkout ), 放入自己的开发库中进行修改。代码被检出后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法 Check outo
程序员将开发库中修改好的代码段检入（Checkin ) 受控库。检入后，代码的“锁定”被解除，其他程序员可以 Check out 该段代码了。
软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为 V2.2，旧的 V2.1 版并不删除，继续在产品库中保存）

( 1 ) 功能配置审计。功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证主要包括：
- ①配置项的开发己圆满完成；
- ②配置项己达到配置标识中规定的性能和功能特征；
- ③配置项的操作和支持文档已完成并且是符合要求的等。
(2) 物理配置审计。物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证主要包括：
- ①要交付的配置项是否存在；
- ②配置项中是否包含了所有必需的项目等。

( 1 ) 文档书写规范。管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
(2) 图表编号规则。在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则地编号，可以方便图表的查找。
(3 ) 文档目录编写标准。为了存档及未来使用的方便，应该编写文档目录。
(4 ) 文档管理制度。为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。