15.1 信息系统项目相关信息（文档）及其管理

15.1.1 信息系统项目相关信息

总结

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

15.1.2 信息系统项目相关信息（文档）管理的规则和方法

信息系统文档的规范化管理主要体现在

• 文档书写规范：涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
• 图表编号规则：开发过程中用到很多的图表，对这些图表进行有规则的编号，可以方便图表的查找。
• 
• 文档目录编写标准：为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。
• 文档管理制度：文档的管理制度需根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。

  15.2 配置管理

  1、配置管理定义：应用技术的和管理的指导和监控方法以标识和说明配置项的 功能和物理特征 ，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性
  2、配置管理包括6个主要活动：

1. 制定配置管理计划
2. 配置标识
3. 配置控制
4. 配置状态报告
5. 配置审计
6. 发布管理和交付

15.2.1 配置管理的概念

1、典型配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理
2、所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。
3、在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类，例如，

• 基线配置项可能包括所有的设计文档和源程序等
• 非基线配置项可能包括项目的各类计划和报告等。

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

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

配置项状态变化
6、配置项版本号
配置项的版本号规则与配置项的状态相关。
（1）处于“草稿“状态的配置项的版本号格式为0.YZ，YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

（2）处于“正式“状态的配置项的版本格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9。
配置项 第一次 成为“正式”文件时，版本号为 1.0 。
如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，1.2，……当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配项升级幅度比较大时，才允许直接增大X值。

（3）处于“修改“状态的配置项的版本格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式“时，将Z值设置为0，增加X.Y值。参见上述规则（2）。

例子：
V0.1 草稿
V 0.99 草稿
V1.0 正式版本
V1.1 正式版本
V2.2 正式版本
V2.23 正在修改
V3.01 正在修改
V3.09 正在修改
V3.1 正式版本
B项目借鉴了A项目的3.0版本的SRS生成一份新的SRS，那么B项目的SRS版本为：V0.1

7、配置项版本管理
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
8、配置基线（Configuration Baseline）（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结“了，不能再被任何人随意修改（可以改，但要走变更控制程序）。对基线的变更必须遵循正式的变更控制程序。一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成

9、一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。

中间某个配置项修改，将会影响下游的的配置项，但不影响上游

10、基线通常对应于开发过程中的里程碑（Milestone），一个产品**可以有多个基线**，也可以只有一个基线。

• 交付给外部顾客的基线一一般称为发行基线（Release Baseline）
• 内部开发使用的基线一般称为构造基线（Build Baseline）。

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

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

13、配置管理员（Configuration Management Organation，CMO）负责为每个项目成员分配对配置库的操作权限
配置库的权限设置主要是解决库内存放的配置项

• 什么人可以“看“ —— 只读权限
• 什么人可以“取“—— 下载、另存为权限
• 什么人可以“改＂—— 新建、修改权限
• 什么人可以“销毁”等问题。——删除权限

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

15、配置管理员（Configuration Management Organation，CMO）
配置管理员（GMO），负责在项目的整个生命周期中进行配置管理活动，具体有：
（1）编写配置管理计划；
（2）建立和维护配置管理系统；
（3）建立和维护配置库；
（4）配置项识别；
（5）建立和管理基线；
（6）版本管理和配置控制；
（7）配置状态报告；
（8）配置审计；
（9）发布管理和交付；
（10）对项目成员进行配置管理培训。

15.2.2 制定配置管理计划

配置管理计划是对如何开展**项目配置管理工作**的规划，是配置管理过程的 基础 ，应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。

15.2.3 配置标识（Configuration Identification）

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

15.2.4 配置控制

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

1．变更评估
CCB责组织对变更申请进行评估并确定以下内容
（1）变更对项目的影响。
（2）变更的内容是否必要。
（3）变更的范围是否考虑周全。
（4）变更的实施方案是否可行。
（5）变更工作量估计是否合理。

1. 基于配置库的变更控制

• 信息系统在一处出现了变更，经常会连锁引起多处变更，会涉及到参与开发工作的许多人员。例如，测试引发了需求的修改，那么很可能要涉及到需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之改变。
• 如果是多个开发人员对信息系统的同一部件做修改，情况会更加复杂。例如，在软件测试时发现了两个故障。项目经理最初以为两故障是无关的，就分别指定甲和乙去解决这两个故障。但碰巧，引起这两个故障的错误代码都在同一个软件部件中。甲和乙各自对故障定位后，先后从库中取出该部件，各自做了修改，又先后送回库中。结果，甲放入库中的版本只有甲的修改，乙放入库中的版本只有乙的修改，没有一个版本同时解决了两个故障。
  

基于配置库的变更控制

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

15.2.5 配置状态报告（Configuration Status Reporting）

1、配置状态报告也称配置状态**统计**（Configuration Status Accounting），其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
2、配置状态报告应该包含以下内容：
（1）每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
（2）每个变更申请的状态和已批准的修改的实施状态。
（3）每个基线的当前和过去版本的状态以及各版本的比较。
（4）其他配置管理过程活动的记录。
3、配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。配置状态报告应定期进行，并尽量通过CASE工具自动生成。

15.2.6 配置审计（Configuration Audit）

1、配置审计（Configuration Audit）也称为配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。
2、配置审计也的实施是为了确保项目配置管理的**有效性，体现了配置管理的最根本要求一不允许出现任何混乱现象，例如：
（1）防止向用户提交不适合**的产品，如交付了用户手册的不正确版本；
（2）发现**不完善**的实现，如开发出不符合**初始规格说明或未按变更请求实施变更；
（3）找出各配置项间不匹配或不相容的现象；
（4）确认配置项己在所要求的质量控制审核之后纳入基线并入库保存；
（5）确认记录和文档保持着可追溯性。
3、功能配置审计（Functional Configuration Audit）
功能配置审计是审计配置项的一致性（配置项的**实际功效是否与其需求一致）具体验证以下几个方面
（1）配置项的开发已圆满完成。
（2）配置项已达到配置标识中规定的性能和功能特征。
（3）配置项的操作和支持文档已完成并且是符合要求的。
4、物理配置审计（Physical Configuration Audit）
物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证如下几个方面。
（1）要交付的配置项是否存在。
（2）配置项中是否包含了所有必需的项目。

15.2.7 发布管理和交付

1、发布管理和交付活动的主要任务是：有效控制软件产品和文档的发行和交付，在软件产品的生存期内妥善保存代码和文档的母拷贝。
存储 Storage
复制 Copy
打包 Pack
交付 Deliver
重建 Rebuild

每个角色在配置管理活动中权限