文档和配置管理基础

背景

项目开发过程中使用SVN作为协同开发工具，那么SVN的作用是什么呢？为什么要使用SVN呢？应用项目管理领域的知识来解释的话，SVN对应着变更控制，而且是基于配置库的变更控制。

本文将整理信息系统文档和配置管理相关的知识，以及SVN版本控制的重要性。

文档分类

信息系统相关的文档是指具有某种数据媒体和其他记录的数据，它具有永久性，包括纸质文档和电子文档。

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

开发文档描述开发过程本身，如可研报告、需求设计文档、集成测试计划、安全和测信息。
产品文档描述开发过程的产物，如用户手册，培训手册，产品信息和广告。
管理文档记录项目管理信息，如每个阶段的进度及进度变更记录、软件变更记录、团队职责定义。

文档的质量可以分为四级（1-4级）：

最低限度文档（1级）：适合工作量低于一个人月的开发者自用程序
内部文档（2级）：没有与其他用户共享资源的专用程序
工作文档（3级）：同一单位若干人联合开发的程序，或可被其他单位使用的程序
正式文档（4级）：正式发行供普遍使用的软件产品，遵守GB8567有关规定

文档管理规则和办法

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

文档书写规范：统一的文档书写规范，包括符号的使用、图标的含义、程序中注释行的使用、文档书写人及书写日期。

图表编号规则：对图表进行有规则的编号，可以方便图表的查找，图表编号一般采用分类结构，根据生命周期法的五个阶段可以用一种6位图表编号规则如下：

第1位：生命周期法各阶段
第2位：各阶段的文档
第3、4位：文档的内容
第5、6位：流水码

文档目录编写标准：为了存档及未来使用方便，应该编写文档目录，目录中应该包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。

文档管理制度：应该建立相应的文档管理制度，以更好地进行信息系统文档管理，主要包括建立文档和相关对方、文档借阅记录的登记制度、文档使用权限控制等。

配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的科学。GB/T11457-2006中，将“配置管理”正式定义为：

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

配置管理的概念

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

2 配置项的状态：分为草稿、修改、正式三种。配置项刚刚建立时，是草稿状态，且草稿状态只有一次，通过评审后变为正式，此后如果需要修改，则变为”修改“。

3 配置项的版本号：草稿状态的版本好为0.YZ；处于正式状态的配置项版本号为X.Y（X为主版本号，1-9；Y为次版本号，0-9）；修改状态的版本号为X.YZ。

4 配置项的版本管理：在项目开发过程中，绝大部分的配置项都要经过多次修改才能最终确定下来，对配置项的任何修改将产生新的版本，我们不能保证新版本一定比旧版本好，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发送版本丢失或者混淆，并且可以快速地查找到配置项的任何版本。

5 配置基线：由一组相对稳定的逻辑实体即配置项组成，基线中的配置项被冻结了，不能被随意修改，对基线的变更必须遵循正式的变更控制程序。基线通常对应开发过程中的里程碑，交付给外部客户的基线称为发行基线；内部开发使用的继续称为构造基线。

6 配置库：存放配置项并记录与配置项相关的所有信息，分为开发库（也称为动态库、程序员库或工作库）、受控库（也称为主库）、产品库(静态库、发行库、软件仓库）。

配置基线的意义

一组拥有唯一标识的需求、设计、源代码文卷以及相应可执行代码、构造文卷和用户文档构成一条基线。

对于每一个基线，要定义以下内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的变更只能采用证书的变更控制程序。

建立基线的好处：
1 基线为开发工作提供了一个定点和快照
2 新项目可以在基线提供的定点上建立
3 当认为变更不稳定或不可信时，基线为团队提供一种取消变更的方法
4 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误

配置库的意义

配置库可以回答许多配置管理的问题，例如：
1 哪些客户已经提取了某个特定的系统版本：操作记录
2 运行一个给定的系统版需要什么硬件和系统软件：配置
3 一个系统到目前生成了多少个版本，何时生成：版本记录
4 如果某一个特定的构件变更了，会影响到系统的哪些版本：控制
5 一个特定版本层提出过哪些变更请求：变更记录
6 一个特定的版本有多少已报告的错误

配置库的建库模式有两种：按配置项的类型创建和按任务创建。

按配置项的类型分类建库，适用于通用软件的开发组织。在该组织内部，产品的继承性往往较强，工具比较统一，对并发有一定的要求。
优点：有利于配置项的统一管理和控制，也能提高编译和发布效率。
缺点：结构不是面向各团队的开发任务的，可能会造成开发人员工作目录过于复杂，带来不必要的麻烦。

按开发任务建立，适用于专业软件的开发组织，产品开发工具繁多，开发模式以线性发展为主，配置项的目录设置策略比较灵活。

基于配置库的变更控制

信息系统的一处变更，通常会引起连锁反应，牵涉到其他开发工作的许多人员。不难理解，在软件协同开发过程中，下面的场景作为开发人员并不陌生。

测试引起了需求的修改，那么很可能涉及到需求规格说明书、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之改变。

协调开发过程中，如果是多个开发人员对信息系统同一部件进行修改，情况会更复杂。例如：在软件测试时发现了两个故障，PM最初认为这两故障是无关的，就分别指派甲和乙两人去解决故障，但是碰巧这两个故障的错误代码都在同一个软件部件中。甲和乙各自定位故障后，先后从库中取出该部件，各自做了修改，又先后送回库中。结果：甲放入库的版本只有甲乙的修改，而乙放入库中的版本只有乙的修改，没有一个版本同时解决了两个故障。即：乙最终版本会覆盖掉甲的修改，导致故障不能同时修正。

基于基线和的变更控制可以完美解决上述问题，流程如下：

1 待升级的基线从产品库中取出，放入受控库。
2 程序员将待修改的代码从受控库中检出，放入自己的开发库进行修改。此时，受控库被锁定，以保证同一个时刻只能有一个人修改。
3 程序员将开发库中修改完成的代码检入受控库存，代码解除锁定。
4 软件升级修改工作完成后，将受控库中的新基线存入产品库，更新版本号。

配置状态报告

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

应该包含的内容如下：

1 每个受控配置项的标识和状态
2 每个变更申请的状态和已批准的修改的实施状态
3 每个基线的当前和过去版本的状态及各版本的比较
4 其他配置管理过程活动的记录

配置状态报告可以回答以下问题：

1 某个程序的某个版本在哪个备份中可以使用
2 发行基线的不同版本直接实现了哪些变更请求
3 发行基线的某个版本中哪些程序被修改过了
4 某个变更请求对哪些配置项进行了修改？变更前后程序的版本是什么？变更是否并入库

配置状态报告还可以供PM和CCB追踪变更的情况：

1 某个变更请求是否被批准
2 某个变更请求目前处于什么状态
3 某个已完成的变更投入了多少时间和工作量
4 配置项与哪几个变更请求有关

配置审计

配置审计包括功能配置审计和物理配置审计，分别用来验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目的配置管理的有效性，体现了配置管理的根本要求就是不允许出现任何混乱现象，例如：

防止向用户提交不合适的产品
找出配置项间的不匹配或不相容的地方
确认配置项已在所要求的质量控制审核之后纳入基线库
确认记录和文档保持着可追溯性

功能配置审计：是审计配置项的一致性，即配置项的实际功效是否与其需求一致，具体验证以下几方面：

1 配置项的开发已圆满完成
2 配置项已经达到配置标识中规定性能和功能要求
3 项的操作和支持文档已完成且是符合要求的

物理配置审计：是审计配置项的完整性，即配置项的物理存在是否与预期一致，具体验证：

1 要交付的配置项是否存在
2 配置项中是否包含了所必须的项目

启示录

整个结合配置关联相关知识来看，使用SVN进行项目开发，应该只是配置管理的一部分，并且只是一小部分。

工作中也遇到过SVN各版本混乱的情况，甚至现在也没有标准的版本管理流程。上周解决的一个问题，让我深切体会到版本控制的重要性。过程是这样的，代码加固之后，发给客户一个升级包，发包之前已经检查过修改文件，目测文件都是正确的，没有专门在虚拟机上测试验证，就发送了。

结果实施人员反馈升级后，应用启动失败。于是就开始追踪，结果发现一个Controller类中包含了一个Bean的boolean类型的变量的setter方法被修改成了isXXX了，客户现场代码是getXXX，反编译的class文件直接抛出编译错误了，导致项目无法启动。

真是大意了，虽然修改代码跟客户现场没有大的出入，但是现在SVN 分支中代码已经跟现场版本隔着几代了，修改之前应该先检查一下版本状态的。