信息系统项目管理师学习笔记14-信息文档管理与配置管理

目录

第14章 信息文档管理与配置管理

14.1 信息系统项目文档及其管理

14.2 配置管理（了解）

14.3 文档管理、配置管理工具

---

第14章 信息文档管理与配置管理

14.1 信息系统项目文档及其管理

1.软件文档一般分为三类：开发文档、产品文档、管理文档。

（1）开发文档描述开发过程本身，基本的开发文档包括：1）可行性研究报告和项目任务书2）需求规格说明3）功能规格说明4）设计规格说明，包括程序和数据规格说明5）开发计划6）软件集成和测试计划7）质量保证计划8）安全和测试信息。

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

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

2.文档的质量可以分为四级：

（1）最低限度文档（1级文档），适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。

（2）内部文档(2级文档），可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。

（3）工作文档（3级文档），适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。

（4）正式文档（4级文档），适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档遵守GB/T 8567-2006的有关规定。

14.2 配置管理（了解）

1.配置管理正式定义为应用技术的和管理的指导和监控方法以识别和说明配置项的功能的物理特征，控制这些特征的变更、记录和报告变更处理过程和实现状态并验证与规定的需求的遵循性。

2.软件配置管理是关于软件资产的管理，什么是软件资产？源代码、设计文档等文档、可以运行的程序、自动测试脚本、编译器等工具和环境……所有在软件研发过程中使用的或产生的，有价值的值得保存的东西，都是软件资产，软件配置管理就是关于这些内容的管理。

3.软件配置管理要管理软件资产的存放和记录，把软件资产主要是源代码，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。还要记录谁“借”出了什么文件，什么时候“还”的，在这一“借”一“还”的过程中，如果开发人员修改了它，软件配置管理就要记录下这些修改。软件配置管理关心：这个文件的各个历史版本是否记录下来了，以便今后翻阅；各次修改的修改者、修改的原因是否记录下来了，以便将来可以理解当时的情形，理解为什么做出这样的改动。

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

（1）制订配置管理计划：制订配置管理计划，规定如何做好配置管理。

（2）配置标识：识别出需要把哪些东西作为配置项来管理。

（3）配置控制：配置项有一些变更，需要做好配置变更的控制。

（4）配置状态报告：需要报告配置项的状态是什么样的。

（5）配置审计：做好审计，看有哪些好的，哪些不好的经验教训，效果怎样。

（6）发布管理和交付：注意发布和交付过程，妥善保存好代码和文档的母拷贝。

5.典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。有些文档生成后不可修改的（如测量报告、会议纪要、工作报告），就不能当做配置项，配置是可以修改的。配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

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

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

8.配置项版本号

（1）处于“草稿”状态的配置项的版本号格式为O.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值设置为O，增加X.Y值。参见上述规则（2）。

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

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

11.一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。

12.—个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线,内部开发使用的基线一般称为构造基线。

13.配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。配置库可以分开发库、受控库、产品库3种类型。

（1）开发库,也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分，可以任意的修改。

（2）受控库,也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库，存放阶段性产物的，可以修改，需要走变更流程。

（3）产品库,也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。存放最终产品的，一般不再修改，真要修改的话需要走变更流程。

14.（了解）配置库的建库模式有两种：按配置项类型建库和按任务建库。

（1）按配置项的类型分类建库，适用于通用软件的开发组织。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。

（2）按开发任务建立相应的配置库，适用于专业软件的开发组织。

15.配置库权限设置：配置管理员负责为每个项目成员分配对配置库的操作权限。

16.配置控制委员会（CCB）负责对配置变更做出评估、审查以及监督巳批准变更的实施。CCB其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。CCB是决策机构，不是执行机构。

17.（了解）配置管理员负责在整个项目生命周期中进行配置管理活动，具体有：

（1）编写配置管理计划

（2）建立和维护配置管理系统

（3）建立和维护配置库

（4）配置项识别

（5）建立和管理基线

（6）版本管理和配置控制

（7）配置状态报告

（8）配置审计

（9）发布管理和交付

（10）对项目成员进行配置管理培训

18.（了解）软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。高级项目经理应确保以下配置管理目标得以实现。

（1）确保软件配置管理计划得以制订，并经过相关人员的评审和确认。

（2）应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取。

（3）应制定控制策略，以确保项目产品在受控制范围内更改。

（4）应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。

19.（了解）配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础。配置控制委员会负责审批该计划。配置管理计划的主要内容为：

（1）配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。

（2）实施这些活动的规范和流程。

（3）实施这些活动的进度安排。

（4）负责实施这些活动的人员或组织，以及他们和其他组织的关系。

20.配置标识也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。配置标识是配置管理员的职能，基本步骤如下。

（1）识别需要受控的配置项。

（2）为每个配置项指定唯一性的标识号。

（3）定义每个配置项的重要特征。

（4）确定每个配置项的所有者及其责任。

（5）确定配置项进入配置管理的时间和条件。

（6）建立和控制基线。

（7）维护文档和组件的修订与产品版本之间的关系。

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

（1）变更评估：CCB负责组织对变更申请进行评估并确定以下内容。

1）变更对项目的影响。

2）变更的内容是否必要。

3）变更的范围是否考虑周全。

4）变更的实施方案是否可行。

5）变更工作量估计是否合理。

CCB决定是否接受变更，并将决定通知相关人员。

（3）基于配置库的变更控制

• 将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。

• 程序员将欲修改的代码段从受控库中检出(cheek out)，放入自己的开发库中进行修改。代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。

• 程序员将开发库中修改好的代码段检入（Check in）受控库。Cheek in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。

• 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存）。

22.配置状态报告也称配置状态统计,其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况,供相关人员了解，以加强配置管理工作。配置状态报告应该包含以下内容。

（1）每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。

（2）每个变更申请的状态和已批准的修改的实施状态。

（3）每个基线的当前和过去版本的状态以及各版本的比较。

（4）其他配置管理过程活动的记录。

配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过 CASE工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况

23.配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求---不允许出现任何混乱现象,例如：

（1）防止向用户提交不适合的产品，如交付了用户手册的不正确版本。

（2）发现不完善的实现^如开发出不符合初始规格说明或未按变更请求实施变更。

（3）找出各配置项间不匹配或不相容的现象。

（4）确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。

（5）确认记录和文档保持着可追溯性。

1）功能配置审计

功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致）,具体验证以下几个方面。

（1）配置项的开发已圆满完成。

（2）配置项已达到.配置标识中规定的性能和功能特征。

（3）配置项的操作和支持文档巳完成并且是符合要求的。

2）物理配置审计

物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证如下几个方面。

（1）要交付的配置项是否存在。

（2）配置项中是否包含了所有必需的项目。

24.发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。

（1）存储（2）复制（3）打包（4）交付（5）重建

14.3 文档管理、配置管理工具

1.配置管理的基线一般分为：功能基线、分配基线、管理基线。基线只能由指定的配置管理员通过配置变更控制流程进行修改。其主要属性一般主要包括名称、标识符、版本、日期。如果把软件系统看作系统的一个组成部分，以下3种基线是最受人们关注的。

（1）功能基线：是指在系统分析和软件定义阶段结束时，经过正式评审批准的系统设计规格说明中对被开发软件系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议或合同中所规定的对被开发软件系统的规格说明；或是指由下级申请上级同意或直接由上级下达的项目任务中所规定的对待开发软件系统的规格说明。

（2）分配基线。分配基线是指在软件需求分析阶段结束时，经正式评审和批准的软件需求规格说明。

（3）产品基线。产品基线是指在软件组装与系统测试阶段结束时，经正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。

2.信息系统项目完成后，最终产品或项目成果应置于产品库内，当需要在此基础上进行后续开发时，应将其转移到受控库后进行。

3.各角色在配置管理活动中的权限（必须掌握）