14.1.1信息系统项目相关信息（文档）

知识点1.信息系统项目相关信息（文档）种类
软件文档一般分为三类：开发文档、产品文档、管理文档。
1）开发文档描述开发过程本身，基本的开发文档包括：

• —可行性研究报告和项目任务书。
• —需求规格说明。
• —功能规格说明。
• —设计规格说明，包括程序和数据规格说明。
• —开发计划。
• —软件集成和测试计划。
• —质量保证计划。
• —安全和测试信息。

2）产品文档描述开发过程的产物，基本的产品文档包括：

• —培训手册。
• —参考手册和用户指南。
• —软件支持手册。
• —产品手册和信息广告。

3）管理文档记录项目管理的信息，例如：

• —开发过程的每个阶段的进度和进度变更的记录。
• —软件变更情况的记录。
• —开发团队的职责定义。
• —项目计划、项目阶段报告。
• —配置管理计划。

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

14.1.2信息系统项目文档管理的规则和方法

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

14.2.1配置管理的概念

知识点4.典型配置项包括项目计划书、需求文档、设计文档、源代码、 可执行代码、测试用例、运行软件所需的各种数据基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包项目的各类计划和报告等。
知识点5.CMO（配置管理员）严格管理，基本原则是：基线配非基线配置项向PM、CCB及相关人员开放。
知识点6.配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”；配置项通过评审后，其状态变为“正式”；此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

知识点7.配置项版本号
配置项的版本号规则与配置项的状态相关。
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值设置为0,增加X.Y值。参见上述规则（2）。
知识点8.配置项版本管理
由于我们不能保证新版本一定比 旧版本“好”，所以不能抛弃旧版本。
**

14.2.1配置管理的概念

知识点1.配置基线
产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等） 是基线的一个例子。
基线通常对应于开发过程中的里程碑（Milestone）, 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线（Release）,内部开发用的基线一般称为构造基线（Build）。

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

知识点2.配置库可以分开发库、受控库、产品库3种类型。
1）开发库(DevelopmentLibrary),也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
2）受控库(Controlled Library),也称为主库，包含当前的基线加上对基线的变更。 受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
3）产品库(Product Library),也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

知识点3.配置库的建库模式有两种：按配置项类型建库（通用软件）和按任务建库（专业软件）。
1）按配置项的类型分类建库，适用于通用软件的开发组织。
2）按开发任务建立相应的配置库，适用于专业软件的开发组织。
配置库的权限设置主要是解决：库内存放的配置项什么人可以“看”、什么人可以“取”、什么人可以“改”、什么人可以“销毁”等问题。
配置管理员负责为每个项目成员分配对配置库的操作权限，如表14-1所示。

知识点4.配置控制委员会
配置控制委员会(Configuration Control Board, CCB)，负责对配置变更做出评估、审批以及监督已批准变更的实施。
CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。
CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。

知识点5.配置管理员
配置管理员(Configuration Management Officer, CMO)，负责在整个项目生命周期中进行配置管理活动，具体有：
—编写配置管理计划
—建立和维护配置管理系统。
—建立和维护配置库。
—配置项识别。
—建立和管理基线。
—版本管理和配置控制。
—配置状态报告。
—配置审计。
—发布管理和交付。
—对项目成员进行配置管理培训

14.2.3日常配置管理活动

知识点1.配置管理计划的主要内容为：
1）配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付。
2）实施这些活动的规范和流程。
3）实施这些活动的进度安排。
4）负责实施这些活动的人员或组织，以及他们和其他组织的关系。

知识点2.配置标识是配置管理员的职能，基本步骤如下：
1）识别需要受控的配置项
2）为每个配置项指定唯一性的标识号
3）定义每个配置项的重要特征
4）确定每个配置项的所有者及其责任
5）确定配置项进入配置管理的时间和条件
6）建立和控制基线
7）维护文档和组件的修订与产品版本之间的关系

知识点3.配置控制
1）变更申请
2）变更评估
CCB负责组织对变更申请进行评估并确定以下内容：
—变更对项目的影响
—变更的内容是否必要
—变更的范围是否考虑周全
—变更的实施方案是否可行
—变更工作量估计是否合理
CCB决定是否接受变更，并将决定通知相关人员。
3）通告评估结果
CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个千系人。
如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知给那些正在使用受影响的配置顶和基线的干系人。
4）变更实施
5）变更验证与确认
6）变更的发布
7）基于配置库的变更控制
例如，测试引发了需求的修改，那么很可能要涉及到需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之变更。

知识点4.如果是多个开发人员对信息系统的同一部件做修改，情况会更加复杂。例如，在软件测试时发现了两个故障。项目经理最初以为两故障是无关的，就分别指定甲和乙去解决这两个故障。但碰巧，引起这两个故障的错误代码都在同一个软件部件中。甲和乙各自对故障定位后，先后从库中取出该部件，各自做了修改，又先后送回库中。结果，甲放入库中的版本只有甲的修改，乙放入库中的版本只有乙的修改，没有一个版本同时解决了两个故障。
基于配置库的变更控制可以完美地解决上述问题，如图14-3所示：

现以某软件产品升级为例，简述其流程：
1）将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。
2）程序员将欲修改的代码段从受控库中检出（Check out）,放入自己的开发库中进行修改。代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。
3）程序员将开发库中修改好的代码段检入（Checkin）受控库。Check in后，代码的“锁定”被解除，其他程序员可以Checkout该段代码了。
4）软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2,旧的V2.1版并不删除，继续在产品库中保存)。

14.2.3日常配置管理活动

知识点1.配置状态报告应该包含以下内容：
1）每个受控配置项的标识和状态。
2）每个变更申请的状态和已批准的修改的实施状态。
3）每个基线的当前和过去版本的状态以及各版本的比较。
4）其他配置管理过程活动的记录。

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

知识点3.配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要 求——不允许出现任何混乱现象。
1）功能配置审计
功能配置审计(Functional Configuration Audit)是审计配置项的一致性(配置项的实际功效是否与其需求一致)，具体验证以下几个方面：
—配置项的开发已圆满完成。
—配置项已达到配置标识中规定的性能和功能特征。
—配置项的操作和支持文档已完成并且是符合要求的。
2）物理配置审计
物理配置审计(Physical Configuration Audit)是审计配置项的完整性(配置项的物理存在是否与预期一致)，具体验证如下几个方面：
—要交付的配置项是否存在。
—配置项中是否包含了所有必需的项目。

知识点4.发布管理和交付
发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。
1）存储
2）复制
3）打包
4）交付
5）重建

14.3.1工具综述

知识点5.常用的开源免费的软件配置管理工具有：
—SVN
—GIT
—CVS