信息系统项目管理师---第十四章信息文档管理与配置管理

信息系统项目管理师—第十四章信息文档管理与配置管理

1、信息系统项目相关信息文档种类

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

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

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

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

2、文档质量分为四级

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

3、信息系统文档管理的规则和方法

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

4、配置管理

配置管理是什么，为什么要做配置管理？
	配置管理是为了系统的控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
	在GB/T11457-2006中，将“配置管理”正式定义为：“应用技术和管理的指导和监督方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”

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

5、配置管理的配置项

配置管理到底要管理什么？
	GB/T 11457-2006对配置项的定义为：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。

配置项的主要内容：
	1.外部交付的软件产品和数据； 
	2.指定的内部软件工作产品和数据； 
	3.指定的用于创建或支持软件产品的支持工具 
	4.供方/供应商提供的软件和客户提供的设备/软件。 

典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。 

所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。 

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。

6、配置项分类及权限

（1）基线与非基线配置项
	基线配置项：基线配置项可能包括所有的设计文档和源程序等（受严格变更控制）；

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

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

（3）配置基线
	配置基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体（也由 CCB 审核）。基线中的配置项被“冻结”了，不能再被任何人随意修改（例如，跟踪和控制变更，像评审通过后的需求文件等）。对基线的变更必须遵循正式的变更控制程序。  
	
	基线通常对应于开发过程中的里程碑, 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线（Release），内部开发使用的基线一般称为构造基线（Build）。 
	
	一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。

（4）基线的定义
	基线定义的内容，对于每一个基线，要定义下列内容：建立基线的事件、受控的项、建立和变更基线的程序、批准变更基线所需的权限。
	在项目实施过程中，每个配置项的基线都要纳入配置控制，对这些基线的更新只能采用正式的变更管理过程。这确保了基线的变更只反映已批准的组件部分的变更。

（5）建立基线的好处
	1.基线为开发工作提供了一个定点和快照。  
	2.新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上） 所进行的变更进行隔离。  
	3.当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。  
	4.可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。 

7、配置项的状态

配置项的状态有三种：草稿（Draft）、正式发布（Released）和修改（Changing）。 

配置项刚建立时其状态为“草稿”。
配置项通过评审（或审批）后，其状态变为“发布”。
此后若更改配置项， 必须依照“变更控制规程”执行，其状态变为“修改”。
当配置项修改完毕并重新通过评审（或审批）时， 其状态又变为“发布”，如此循环。

8、配置项版本号

一、处于“草稿”状态的配置项的版本号格式为：0.YZ。例如：V0.72；YZ 数字范围为 01～99。 随着草稿的不断完善，YZ 的取值应递增。YZ 的初值和增幅由开发者自己把握。
二、.处于“正式发布”状态的配置项的版本号格式为：X.Y。例如：V1.0 
	.X 为主版本号．取值范围为 1~9。Y 为次版本号，取值范围为 0～9。 
	.配置项第一次“正式发布”时，版本号为 1.0。 
	.如果配置项的版本升级幅度比较小,一般只增大 Y 值，X 值保持不变。例如 V1.1 
	.只有当配置项版本升级幅度比较大时，才允许增大X 值。例如 V2.0 


三、处于“正在修改”状态的配置项的版本号格式为：X.YZ。例如：V1.72 
	.配置项在修改时，一般只增大 Z 值，XY 值保持不变。 
	.当配置项修改完毕，状态重新成为“正式发布”时，将 Z 值设置为 0,增加 X．Y 值。 

说明：对配置项的任何修改都将产生新的版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

9、配置库

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

主要作用：
	（1）记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。
	（2）利用库中的信息可以评价变更的后果，这对变更控制有着重要的意义。
	（3）从库中可以提取各种配置管理过程的管理信息。

说明：使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。

配置库包括：动态库（开发库）、受控库（主库）、静态库（产品库）

开发库：
	也叫动态库、程序员库、工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。
	动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制。

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

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


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

10、软件配置管理

11、配置库权限设置

（1）受控库权限设置

（2）产品库权限设置

12、CCB及CMO及配置管理系统

（1）配置控制委员会（Configuration Control Board， CCB）负责对配置变更做出评估、 审抽以及监督巳批准变更的实施。 

	CCB 建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。

	CCB 不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的 CCB。小的项目 CCB 可以只有一个人，甚至只是兼职人员。 

	通常，CCB 不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理、计划审批、基线设立审批、产品发布审批等。 

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

（3）、配置管理系统
	是用来进行配置管理的软件系统，其目的是通过确定配置管理细则和提供规范的配置管理软件，加强信息系统开发过程的质量控制，增强信息系统开发过程的可控性，确保配置项（包括各种文档、数据和程序）的完备、清晰、一致和追踪性，以及配置项状态的可控制性。

13、日常配置管理活动

一、制订配置管理计划 
	配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础。配置控制委员会负责审批该计划。  

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

三、配置控制 
	配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准	或否决申请，实现、验证和发布己修改的配置项。 
	要对软件产品进行升级，对配置库的操作顺序是：
		1）将待升级的基线从产品库中取出，放入受控库。    
		2）程序员将欲修改的代码段从受控库中检出（Checkout）,放入自己的开发库中进行修改。代码被 Check out 后即被"锁定"，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法 Check out。
		3）程序员将开发库中修改好的代码段检入（Checkin）受控库。Checkin 后，代码的"锁定"被解除，其他程序员可以 Check out 该段代码了。 
		4）软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中。 

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

五、配置审计 
	实施配置审核的意义（或功能）：配置审核的实施是为了确保项目配置管理的有效性，体现配置管理的最根本要求一一不允许出现任何混乱现象，例如： 
		•防止出现向用户提交不适合的产品，如交付了用户手册的不正确版本。 
		•发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。 
		•找出各配置项间不匹配或不相容的现象。 
		•确认配置项已在所要求的质量控制审查之后作为基线入库保存。 
		•确认记录和文档保持着可追溯性。 

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

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

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