信息文档管理与配置管理
1 信息系统项目相关信息（文档）及其管理
2 配置管理

信息系统项目相关信息（文档）及其管理

一、信息系统项目相关信息（文档）种类

1、软件文档分为三类：开发文档、产品文档、管理文档。
（1）开发文档描述开发过程本身，基本的开发文档是：
•可行性研究报告和项目任务书；
•需求规格说明；
•功能规格说明；
•设计规格说明，包括程序和数据规格说明；
•开发计划；
•软件集成和测试计划；
•质量保证计划；
•安全和测试信息。

（2）产品文档描述开发过程的产物，基本的产品文档包括：
•培训手册；
•参考手册和用户指南；
•软件支持手册；
•产品手册和信息广告。

（3）管理文档记录项目管理的信息，例如：
•开发过程的每个阶段的进度和进度变更的记录；
•软件变更情况的记录；
•职责定义。
•项目计划、项目阶段报告。
•配置管理计划。

2、文档的质量可以分为四级：
（1）最低限度文档（1 级文档），适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
（2）内部文档（2 级文档），可用于没有与其他用户共享资源的专用程序。除 1 级文档提供的信息外， 2 级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
（3）工作文档（3 级文档），适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
（4）正式文档（4 级文档），适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要 4 级文档。4 级文档遵守 GB 8567 的有关规定。

二、信息系统项目相关信息（文档）管理的规则和方法

信息系统文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。

1、文档书写规范
无论是哪种类型的文档都应该遵循统一的书写规范。例如，在程序的开始要用统一的格式包含程序名称、程序功能、调用和被调用的程序、程序设计人等。

2、图表编号规则
在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则的编号，可以方便图表的查找。图表的编号一般采用分类结构。

3、文档目录编写标准

4、文档管理制度
文档的管理制度需根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。

配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，在标识系统在不同时间点上配置的学科。

配置管理包括 6 个主要活动：制定配置管理计划、配置标识、配置控制、配置状 态报告、配置审计、发布管理和交付。

一、配置管理的概念

1、配置项（对象）
（1）GB/T 11457-2006 对配置项的定义为： “为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

（ 2）在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

（3）所有配置项的操作权限应由 CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向 PM、CCB 及相关人员开放。

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

配置项状态变化如图所示。

3、配置项版本号
配置项的版本号规则与配置项的状态相关。
（1）处于“草稿”状态的配置项的版本号格式为 0.YZ，YZ 的数字范围为 01～99。随着草稿的修正，YZ 的取值应递增。YZ 的初值和增幅由用户自己把握。

（2）处于“正式”状态的配置项的版本号格式为 X.Y，X 为主版本号，取值范围为 1～9。Y 为次版本号，取值范围
为 0～9。配置项第一次成为 “正式”文件时，版本号为 1.0。

如 果 配 置 项 升 级 幅 度 比 较 小 ， 可 以 将 变 动 部 分 制 作 成 配 置 项 的 附 件 ， 附 件 版 本 依 次 为
1.0，1.1，……。当附件的变动积累到一定程度时，配置项的 Y 值可适量增加，Y 值增加一定程度时，X 值将适量增加。当配置项升级幅度比较大时，才允许直接增大 X 值。

（3）处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时 ，一般只增大 Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为 “正式”时，将 Z 值设置为 0，增加X.Y 值。

4、配置项版本管理
（ 1）在项目开发过程过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本 “好”，所以不能抛弃旧版本。
（ 2）版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

5、配置基线
（1）为了更好的进行管理，配置管理引入了 “配置基线”这一概念。
（2）配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
（3）基线通常对应于开发过程中的里程碑。一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。
（4）对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
（5）测试基线的一个例子：需求分析说明书、概要设计说 明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等。
（6）建立基线还可以有如下好处：
① 基线为开发工作提供了一个定点和快照。
② 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始
项目（在主要分支上）所进行的变更进行隔离。
③ 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
④ 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

6、配置库
配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。

（1）配置库可以分为开发库、受控库、产品库 3 种类型。
① 开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。

② 受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。

③ 产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

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

7、配置库权限设置
Read：看；Check：取；Add：改；Destroy：销毁。

配置管理员负责为每个项目成员分配对配置库的操作权限，如表 15-1 所示。

针对受控库，项目相关人员的操作权限通常设定如表 15-2 所示。

针对产品库，项目相关人员的操作权限通常设定如表 15-3 所示。
如表 15-3 产品库的操作权限

8、配置控制委员会（ CCB）
CCB 不必是常设机构，完全可以根据工作需要组成，小的项目 CCB 可以只有一个人，甚至是兼职。

9、配置管理员
配置管理员（CMO），负责在项目的整个生命周期中进行配置管理活动，具体有：
•编写配置管理计划；
•建立和维护配置管理系统；
•建立和维护配置库；
•配置项识别；
•建立和管理基线；
•版本管理和配置控制；
•配置状态报告；
•配置审计；
•发布管理和交付；
•对项目成员进行配置管理培训。

二、制定配置管理计划

配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形
成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
配置管理计划的主要内容为：
（1）配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付；
（2）实施这些活动的规范和流程；
（3）实施这些活动的进度安排；
（4）负责实施这些活动的人员或组织，以及他们和其他组织的关系。

三、配置标识

配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
配置标识是配置管理员的职能，基本步骤如下：
（1）识别需要受控的配置项；
（2）为每个配置项指定唯一性的标识号；
（3）定义每个配置项的重要特征；
（4）确定每个配置项的所有者及其责任；
（5）确定配置项进入配置管理的时间和条件；
（6）建立和控制基线；
（7）维护文档和组件的修订与产品版本之间的关系。

四、配置控制

1、配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。

2、变更实施：项目经理组织修改相关的配置项，并在相应的文档 或程序代码中记录变更信息。

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

五、配置审计

1、功能配置审计
功 能 配 置 审 计 是 审 计 配 置 项 的 一 致 性 （ 配 置 项 的 实 际 功 效 是 否 与 其 需 求 一 致 ）， 具 体验
证以下几个方面。
（1）配置项的开发已圆满完成。
（2）配置项已达到配置标识中规定的性能和功能特征。
（3）配置项的操作和支持文档已完成并且是符合要求的。

2、物理配置审计
物 理 配 置 审 计 是 审 计 配 置 项 的 完 整 性 （ 配 置 项 的 物 理 存 在 是 否 与 预 期 一 致 ）， 具 体 验证
如下几个方面。
（1）要交付的配置项是否存在。
（2）配置项中是否包含了所有必需的项目。

六、发布管理和交付

1、存储；
2、复制；
3、打包；
4、交付；
5、重建。