第十五章：组织保障（15.1信息和文档管理--15.2配置管理）

15.1 信息和文档管理

15.1.1 信息和文档

1.信息系统信息

信息系统中的信息可以分为用户信息、业务信息、经营管理信息和系统运行信息等。

2.信息系统文档

类型	含义	包括
开发文档	描述开发过程本身	①可行性研究报告和项目任务书;②需求规格说明;③功能规格说明;④设计规格说明，包括程序和数据规格说明;⑤开发计划;⑥软件集成和测试计划;⑦质量保证计划;⑧安全和测试信息
产品文档	描述开发过程的产物	①培训手册;②参考手册和用户指南;③软件支持手册;④产品手册和信息广告
管理文档	记录项目管理的信息	①开发过程的每个阶段的进度和进度变更的记录;②软件变更情况的记录;③开发团队的职责定义;④项目计划、项目阶段报告;⑤配置管理计划

文档的质量通常可以分为4级：

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

15.1.2 信息(文档)管理规则和方法

1.信息(文档)编制规则

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

2.信息(文档)定级保护

应根据侵害可能影响对象和影响程度，对信息系统项目的信息(文档)进行分析并定级，按相应的定级保护策略进行管理。

特别要注意的是，在项目应用时，应结合客户要求和合同要求，建立项目信息(文档)管理策略。文档中有密级要求的
应注意保密和权限管理。项目干系人签字确认后的文档要与相关联的电子文档-一对应，这些电子文档还应设置为只读。

3.信息(文档)配置管理

在信息系统项目中，配置管理可用于问题分析、变更影响度分析、异常分析等

因此，配置项与真实情况的匹配度和详细度非常重要。

在组织实施信息系统项目过程中，常常会遇到变更的发生。变更一般有主动变更和被动变更两种。

·主动变更是主动发起的变更，常用于提高项目收益，包括降低成本、改进过程以及提 高项目的便捷性和有效性等;

·被动变更常用于范围变化、异常、错误和适应不断变化的环境等，如随需求的增加，相应需要增加系统的功能或投资等。

15.2 配置管理

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

15.2.1 基本概念

1.配置项

配置项的定义为:“为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一单个实体来对待

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

配置项可以分为基线配置项和非基线配置项两类

基线配置项 可能包括所有的设计文档和源程序等

非基线配置项 可能包括项目的各类计划和报告等

所有配置项的操作权限应由配置管理员严格管理，基本原则是

基线配置项 向开发人员开放读取的权限;

非基线配置项 向项目经理、CCB及相关人员开放。

2.配置项状态

配置项的状态可分为“草稿、“正式”和“修改”三种。

3.配置项版本号

①处于“草稿” 状态的配置项的版本号格式为0.YZ

②处于“正式”状态的配置项的版本号格式为X.Y，x为主版本号，取值范围为1-9。为次版本号，取值范围为0-9

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

4.配置项版本管理

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

5.配置基线

配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

产品的一个测试版本(可能包括需求分析说明书,概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。

基线通常对应于开发过程中的里程碑一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。

对于每一个基线，要定义下列内容:建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

6.配置管理数据库

配置管理数据库主要内容包括:

①发布内容，包括每个配置项及其版本号

②经批准的变更可能影响到的配置项

③与某个配置项有关的所有变更请求

④配置项变更轨迹

⑤特定的设备和软件

⑥计划升级、替换或弃用的配置项

⑦与配置项有关的变更和问题

⑧来自于特定时期特定供应商的配置项

⑨受问题影响的所有配置项

7.配置库

配置库可以分开发库、受控库、产品库3种

配置库	描述
开发库	称为动态库、程序员库或工作库，是开发人员的个人工作区，由开发人员自行控制。无须对其进行配置控制【可以任意的修改】
受控库	称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
产品库	也称为静态库、发行库、软件仓库,包含已发布使用的各种基线的存档被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。【一般不再修改，真要修改的话需要走变更流程】

配置库的建库模式有两种:按配置项类型建库和按开发任务建库

建库模式	描述
配置项类型建库	这种模式适用于 通用软件 的开发组织。在这样的组织内往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。【如:通用产品】
开发任务建库	这种模式适用于 专业软件 的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。【如:定制产品】

15.2.2 角色与职责

配置管理相关角色常包括:配置控制委员会(CCB)、配置管理负责人、配置管理员和配置项负责人等

1.配置控制委员会

配置控制委员会也称为变更控制委员会，它不只是控制变更，也负有更多的配置管理任务，具体工作包括:

①制定和修改项目配置管理策略

②审批和发布配置管理计划

③审批基线的设置、产品的版本等

④审查、评价、批准、推迟或否决变更申请

⑤监督己批准变更的实施

⑥接收变更与验证结果，确认变更是否按要求完成

⑦根据配置管理报告决定相应的对策

2.配置管理负责人

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

①管理所有活动，包括计划、识别、控制、审计和回顾

②负责配置管理过程

③通过审计过程确保配置管理数据库的准确和真实

④审批配置库或配置管理数据库的结构性变更

⑤定义配置项责任人

⑥指派配置审计员

⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态

@评估配置管理过程并持续改进

⑨参与变更管理过程评估

⑩对项目成员进行配置管理培训

3.配置管理员

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

①建立和维护配置管理系统

②建立和维护配置库或配置管理数据库

③配置项识别

④建立和管理基线

⑤版本管理和配置控制

⑥配置状态报告

⑦配置审计

⑧发布管理和交付

4.配置项负责人

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

①记录所负责配置项的所有变更

②维护配置项之间的关系

③调查审计中发现的配置项差异，完成差异报告

④遵从配置管理过程

⑤参与配置管理过程评估

15.2.4 管理活动

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

① 制订配置管理计划(写一个文档，叫做配置管理计划，规定如何做好配置管理

② 配置项标识(识别出需要把哪些东西作为配置项来管理 )

③ 配置项控制(配置项有一些变更，需要做好配置变更的控制)

④ 配置状态报告(需要报告配置项的状态是什么样的)

⑤ 配置审计(做好审计，看有哪些好的，哪些不好的经验教训，效果怎么样)

⑥ 配置管理回顾与改进(定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有无问题，找到改进点，继而优化配置管理过程)

1.制定配置管理计划

配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。

2.配置项标识

配置项识别是针对所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构进行识别的过程。它包括为配置项分配标识和版本号等
配置项识别是配置管理员的职能。

配置项识别的基本步骤如下

①识别需要受控的配置项

②为每个配置项指定唯一的标识号

③定义每个配置项的重要特征

④确定每个配置项的所有者及其责任

⑤确定配置项进入配置管理的时间和条件

⑥建立和控制基线

⑦维护文档和组件的修订与产品版本之间的关系

3.配置项控制

配置项控制即配置项和基线的变更控制，包括:变更申请、变更评估、通告评估结果、变更实施、变更验证与确认、 变更的发布、基于配置库的变更控制等任务

4.配置状态报告

配置状态报告应该包含以下内容

①每个受控配置项的标识和状态

②每个变更申请的状态和已批准的修改的实施状态

③每个基线的当前和过去版本的状态以及各版本的比较

④其他配置管理过程活动的记录等

5.配置审计

配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。

功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求- 致)，验证:

①配置项的开发已圆满完成

②配置项已达到配置标识中规定的性能和功能特征

③配置项的操作和支持文档己完成并且是符合要求的

物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致)验证:

①要交付的配置项是否存在

②配置项中是否包含了所有必需的项目

一般来说，配置审计应当定期进行，应当进行配置审计的场景包括:

①实施新的配置库或配置管理数据库之后

②对信息系统实施重大变更前后

③在一项软件发布和安装被导入实际运作环境之前

④灾难恢复之后或事件恢复正常之后

⑤发现未经授权的配置项后，

⑥任何其他必要的时候等。

6.配置管理回顾及改进

配置管理回顾与改进是指定期回顾配置管理活动的实施情况，目的是发现在
配置管理执行过程中有无问题，找到改进点，优化配置管理过程。

配置管理回顾与改进活动包括:

①对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议
根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息

②召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行
汇报，听取各方意见，回顾上次过程改进计划执行情况

③根据会议结论，制订并提交服务改进计划

④根据过程改进计划，协调落实改进

PS: 更多关于系统集成项目管理工程师笔记 点击专栏订阅(持续更新~~~)