【信息系统项目管理师】第十四章 文档与配置管理思维导图

【信息系统项目管理师】第十四章 文档与配置管理思维导图

文档管理和配置管理是第十四章总两大知识板块。

• 文档管理

信息系统中的文档按质量分级可以分为1-4级分别是最低限度文档，内部文档，工作文档，正式文档；而软件文档的分类分为：产品文档，开发文档，管理文档三类。开发量低于一个人月且是自己用用的文档就是最低限度等级为1的文档，而正式发行普遍使用的文档是等级为4级的正式文档，工作文档是同一单位若干人联合开发使用的文档。四个质量分级，1最低4最高。

按照文档分类有三种：开发文档，管理文档和产品文档。这三种文档之间的区别和联系也要会区分。开发文档用来描述开发过程本身，而管理文档是用来记载管理的信息，这两者要学会区别，尤其是要明白开发计划书，项目任务书看名字往往会认为是管理文档，其实不然，它们应该属于开发文档，团队成员职责定义才属于管理文档；而产品文档是用来描述开发过程的产物，比如培训手册，产品手册用户指南等都属于产品文档。

• 配置管理

想较于文档管理，配置管理的重要性更加高于文档管理。配置管理过程一共有六个：编制配置管理计划，配置标识，配置控制，配置状态报告，配置审计，版本发行与交付。

• 1.编制配置管理计划

该过程的计划书是由配置管理员来做成，由配置控制委员会也就是CCB来审批计划。主要审批的就是配置管理计划中的进度安排，配置管理的人员或组织，配置管理的规范流程方面，配置管理活动的定义。

• 2. 配置标识（配置项与配置库的概念）

在介绍配置标识之前，还有几个重要的配置管理概念一定要搞搞清楚。包括了配置项和配置库的概念。配置项的定义就是纳入配置管理的所有的项目，而配置库是配置项保存管理的一个地方；这两个概念很好区别，一个是需要配置管理的项目，一个是需要配置管理项目存放的地方。因为配置项的分类中，配置项分为基线配置项（文档源程序）和非基线配置项（项目计划和报告），所以我们也要延伸了解一下基线和基线管理这两个概念。

配置标识(configuration identification)是定义各类配置项、建立各种基线、描述相关软件配置及其文档的过程。配置标识的主要工作内容有：识别需要配置的配置项，为配置项指定唯一的标号，定义每个配置项的责任归属，进入配置管理的时间和条件，建立和控制基线，对包括文档在内的版本信息进行维护。

2.1 基线和配置基线

一个产品可以有一个或者多个基线，基线按用途可以分为发行基线和构造基线。发行基线是交付给外部顾客的，而构造基线是供内部开发使用的。按类型则可以把基线分为三大类：功能基线（在系统分析于定义阶段），产品基线（系统测试结束阶段）和分配基线（软件需求分析结束阶段）。其中分配基线是最初批准的分配配置标识。
从某种意义上来说，配置基线对应的内容应该是配置库中的主库，对应于开发过程中的里程碑。
配置基线是由一组配置项组成。一般基线上的配置项都是冻结的，不能随便的修改，如果要对基线基线修改的话，要走变更管理流程。

2.2 配置项

配置项包括了项目计划书，需求文档，源代码，测试报告，会议纪要等。配置项的属性有：名称标识符，文件状态，作者日期等。而配置项状态是最主要的考点，它包括了三个选项：草稿，正式，修改三个状态，小于1.0版本的就是草稿；1.0就是正式；大于1.0就是修改，不管是从哪里到正式状态，都需要通过评审。配置项中也包含了文档，文档的状态转换也是和这个状态是一起通用的。为了更好的管理配置项，于是就有了配置管理的原则：针对基线的配置项，向开发人员开放读取的权限；针对非基线配置项，向PM和CCB开放。

2.3 配置库

配置库有三个部分组成：静态库（发行库，产品库），主库（受控库），动态库（开发库）。产品库一般是用来向客户向项目干系人发布产品用的，一般最终的产品或服务才会放在产品库中；主库一般在也是不太会该的时候才会放进去，如果要对主库进行修改的话，要走变更管理流程，开发某一个阶段结束的时候，就把当前的工作产品放入主库中；而开发库作为开发者是可以随意修改的，用于保存开发人员开发的配置实体。针对配置库中的配置项，配置管理员还需要对每一个用户设置相应的权限，权限种别有四种：Check，Read，Add，Destory。

• 3.配置控制

配置控制是指控制配置项及其组件的演化，配置控制往往需要和变更控制一起来谈。在这里还需要了解一下在配置管理中人物的职责。配置管理中最重要的人物只有两个：一个是配置管理员（CMO），一个是配置控制委员会（CCB）。

• 4.配置状态报告

配置状态报告就是报告当前配置项的状态情况，变更申请的执行情况和基线配置项的变化情况等，具体报告的内容有以下五项：每个受控配置项的状态，每个变更申请的状态和已经批准的修改的实施情况，每个基线版本和过去版本相比的变化情况，其他配置活动的记录。 

• 5.配置审计

配置审计是验证当前配置项的一致性和完整性，它也叫配置审核或者配置评价。它包括审计物理完整性和功能一致性两项内容。功能配置审计是确认并审计配置项已经开发完成，配置项已经达到配置标识中规定的性能特征；而物理完整性是指要交付的配置项是存在的，且包含了必须的项目，所以物理配置审计和功能配置审计他们对于配置项的侧重点是不一样的。 最后说说配置审计有什么作用，为什么在配置管理中需要做配置审计。配置审计可以防止用户不必要的提交，交付不正确的版本，并发现不完善的实现，确认配置项已经纳入了基线，包括文档在内的配置项是可追溯的，这样当出现问题的时候更容易追溯，类似于需求的双向跟踪。

• 6.发布管理与交付

存储，复制，打包，交付，重建。突然想到在敏捷开发中有每日构筑一说，这样每天都需要在产品库中发行新的产品。