|
|
|
信息系统项目中形成的技术性文档和管理性文档，除一些临时性的文档外一般都应该进行配置管理。一般来讲，判定一个文档是否进行配置管理的标准应该是此文档是否有多个人需要使用，这些文档往往在项目的进程中不断地修正和扩展，要保证每个使用者都使用同一版本的文档，就必须将这些文档纳入配置管理，成为受控的配置项。
|
|
|
|
（1）识别配置项。可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码／模块、工具（如编辑器）、接口描述等。在软件工程方面，Roger S. Pressman认为至少以下所列的文档应该成为配置项：系统规格说明书、项目计划、需求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。
|
|
|
|
（2）配置项命名。确定了配置项后，还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构，树状结构上结点之间存在着层次的继承关系。
|
|
|
|
（3）配置项的描述。由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息（名字、描述、一组资源、实现）唯一地标识。配置项间的关系有整体和部分的关系及层次关系，也有关联关系。配置项间的关系可以用MIL语言（Module Interconnection Language）表示。MIL描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。
|
|
|
|
（4）识别配置项的步骤。识别配置项的主要步骤如下：
|
|
|
|
|
|
|
|
.确定每个配置项的重要特征。配置项的特征主要包括作者、文档类型、代码文档的程序设计语言。
|
|
|
|
|
|
|
|
|
|
.审批配置管理表。CCB审查配置管理表是否符合配置管理计划和项目计划文档的规定，审批配置管理表。
|
|
|
