【信息系统项目管理师】第十四章 信息文档管理和配置管理（考点汇总篇）

【信息系统项目管理师】第十四章 信息文档管理和配置管理（考点汇总篇）

考点分析与预测

配置管理在第三版新大纲中内容压缩减少了。它不属于十大管理领域，但是从历年考试来看，一般上午题目考2-3分，下午案例分析也会考到，属于考试的重点和难点。它可能考察的知识点有：文档管理的分类，登记，作用，基线配置项，配置库，配置管理流程和活动，版本的变迁，配置管理中各角色和他们的权限，配置审计，配置管理计划，配置状态报告。

下午案例分析考试出题思路，本知识模块更加趋向于与项目整体管理，质量管理等知识模块相结合后进行案例分析方面的综合命题。具体表现为：给出某项目在变更管理方面的案例场景描述，要求指出在该案例场景中存在哪些问题并说明相关原因；给出解决这些问题的补救措施，或预测项目可能会导致的后果，给出一个该案例涉及且与配置管理基础知识相关的简答题。

知识点回顾与再梳理

高项知识点笔记：https://blog.****.net/Last_Impression/article/details/82054612

软件文档的类型

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

软件文档的质量

文档的分级	级别	适用范围
最低限度文档	1级	适合开发工作量低于1个人月的开发者自用程序。该文档应包含程序清单，开发记录，测试数据和程序简介
内部文档	2级	没有与其他用户共享资源的专用程序
工作文档	3级	适合于同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
正式文档	4级	适合那些要正式发行供普遍使用的软件产品

基线分类（按类型）

基线分类名称	时间点	定义
功能基线	系统分析与定义阶段结束时	在经过正式评审和批准的系统设计规格说明书中对开发系统的规格说明；或是指在经过项目委托单位和项目承办单位双方签字同意的协议书或合同中，所规定的对开发软件系统的规格说明
分配基线	软件需求分析阶段结束时	经过正式评审和批准的软件需求规格说明。分配基线是最初批准的分配配置标识。
产品基线	软件组装与系统测试阶段结束时	经过正式评审和批准的有关软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。

基线分类（按用途）

基线分类名称	定义
发行基线	交付给外部顾客的基线
构造基线	内部开发使用的基线

配置库信息 

配置库	配置库的别名	定义
开发库	动态库，程序员库，工作库	保存开发人员当前正在开发的配置实体，它是开发人员的个人工作区，由开发人员自行控制
受控库	主库	包含当前基线和对基线的变更。某个工作阶段结束时，将当前的工作产品存入受控库。
产品库	静态库，发行库，软件仓库	作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，如真的要修改的话走变更流程。

 

配置建库一般常用的有两种组织形式

配置建库的形式	适用组织	开发模式	内容
按配置项类型建库	通用软件开发组织	并行开发模式	产品继承性较强，工具比较统一，它有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
按开发任务建库	专业软件开发组织	线性开发模式	使用开发工具的种类繁多，所以没有必要把配置项严格的分类存储，人为增加目录的复杂性。

配置审计的分类

配置审计	审计内容	详细审计内容	验证的内容
功能配置审计	一致性	配置项的实际功效是否与其需求一致	配置项的开发已经圆满完成，配置标识中规定的性能和功能特征达到。配置项的操作和支持文档已完成并且是符合要求的。
物理配置审计	完整性	配置项的物理存在是否与预期一致	要交付的配置项是否存在，配置项中是否包含了所有必须的项目

 配置项的状态

状态	表示	定义	备注
草稿	0.YZ	配置项刚建立时的状态	YZ的初值和增幅由用户把握
正式	X.Y	配置项通过评审后，其状态变为正式	X主版本号，Y次版本号
修改	X.YZ	正式评审后，若更改配置项，其状态变为修改。修改完毕评审完变为正式。	修改状态只增加Z值

 

  配置项的分类

  基线中的配置项被冻结了，不能在被任何人随意的修改，对基线的变更必须遵循正式的变更流程。

配置项分类名称	定义
非基线配置项	包括项目各类计划和报告等。向PM，CCB及相关人员开放。
基线配置项	包含所有设计文档和源程序。它向开发人员开放读取的权限。

 配置管理中各个成员的职责

工作负责人	编制配置管理计划	创建配置管理环境	审核配置计划	变更申请	变更实施	变更发布
CCB			○
CMO	○	○		○		○
项目经理				○
开发人员				○	○

大话信息系统文档管理

文档是为项目服务的，在项目中起到沟通和呈现的作用。各类文档需要运用到整个软件工程生命周期中。好的文档会说话，会告诉程序员很多信息。所以个人觉得文档管理应该属于项目沟通管理的一部分。

文档需要做到可管理。没有好好管理的文档往往会传达给干系人错误的或者是过时的信息。配置项管理中提到的版本管理可以运用到文档管理中，有了版本管理，变更管理控制和文档归档就变得更加的简单。

文档也是需要评审的。于是有了需求评审和设计评审两种类型。评审最直接的方式就是评审会。通过老板或者干系人评审后的文档，才可以正式发布。

因为文档要归档要版本控制，所以对信息系统文档的管理，属于配置管理的一部分。

大话配置管理

配置管理和十大项目管理过程一样，贯穿整个项目的生命周期，只要项目有可交付成果物，对其有效的配置管理就变得十分重要了。有效的配置管理可解决多重维护，未知版本等问题。配置管理有六个子过程：规划配置管理，配置标识，配置控制，配置状态报告，配置审计，发布管理和交付。

规划配置管理
在项目经理任命团队中的小王为项目团队CMO之后，小王就开始编制配置管理计划，首先明确人员：谁是项目经理，谁是配置控制委员会成员，每个成员分别对配置库有什么样的访问权限，配置库采用哪款配置管理软件，如何进行包括文档在内的配置项版本管理，如何有效控制变更。如何升级维护和发行产品等。
小王在做完配置管理计划后，和其他项目管理子计划一起，归并到项目管理计划中。

配置标识
在提交配置管理计划后，配置管理员小王开始配置标识。看看管理管理计划中可交付成果，项目文件等信息，还有工作绩效的信息，最终筛选出哪些是需要放入配置库中有效管理的配置项，看看进度管理计划中有哪些里程碑，原则上一个里程碑对应一条基线。

配置控制
项目的可交付成果物就各种状态的话，就要对他进行有效的版本控制。看看之前订下的配置项版本管理的规则是否正确的被使用着。当变更发生的时候，为了不发生混乱的情况，对其流程也要进行控制。

配置审计
和采购审计风险审计一样，在配置管理中也需要用第三方视点来看看配置管理的实施情况，是否出现什么问题，变更流程是否妥善合理的处理，是否出现配置项或基线管理不足的情况。
如果在审计过程中，发现有问题的配置项或者基线，那么就需要追溯要之前稳定的版本。如果发现可交付成果物或者项目文件缺少或有问题的情况后，由配置管理员小王提出变更申请。

配置状态报告
管理经理在任命小王为CMO之后，一定很关心配置管理实施的情况，有没有出现问题，从配置库中取得的可交付成果，项目文档没有问题，项目的变更都已经根据流程完成并反映到产品上。这些信息是作为项目经理必须要通过沟通传达给干系人的信息。所以需要小王的配合，定期将这些信息写成报告，发给项目经理。

发布管理和交付
基线上定义的项目可交付成果物怎么交付给客户呢？需要我们的小王将受控库中的成果物checkout出来，放入产品库，从产品库中将成果交付发布并给客户。当然如果说确认范围是贯穿信息系统项目开发周期的话，发布管理和交付也应该是与之对应的。

配置管理升级流程

1.将待升级的基线从产品库中取出，放入受控库。
2.程序员将欲修改的代码从受控库中检出，放入自己的开发库中进行修改。代码被Checkout后即被锁定。
3.程序员将修改好的代码Checkin到受控库，检入以后代码的锁定被解除。
4.软件产品全部修改完成后，将受控库的新基线存入产品库中，产品库的版本号被升级。