项目文档与配置管理
分档分类
开发文档|产品文档|管理文档
—|—|—
可行性研究报告和项目任务书；
需求规格说明；
功能规格说明；
设计规格说明，包括程序和数据规格说明；
开发计划；
软件集成和测试计划；
质量保证计划；
安全和测试信息|培训手册；
参考手册和用户指南；
软件支持手册；
产品手册和信息广告;|开发过程的每个阶段的进度和进度变更的记录；
软件变更情况的记录；
开发团队的职责定义；
项目计划、项目阶段报告；
配置管理计划;
文档等级
文档的质量可以按文档的形式和列出的要求划分为四级。
- 最低限度文档（1级文档）：适合开发工作量低于一个月的开发者自用程序，包含程序清单、开发记录、测试数据和程序简介。
- 内部文档（2级文档）：可用于没有与其他用户共享资源的专用程序，除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
- 工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其它单位使用的程序。
- 正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质的程序需要4级文档。4级文档遵守GB/T 8567-2006的有关规定。
配置管理
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。
制订配置管理计划->配置标识->配置控制->配置状态报告->配置审计->发布管理和交付
典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
配置项可以分为基线配置项和非基线配置项两类，例如，
- 基线配置项可能包括所有的设计文档和源程序等；
- 非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由CMO严格管理，基本原则是：
- 基线配置项向开发人员开放读取的权限；
- 非基线配置项向PM、CCB及相关人员开放;
配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又 变为“正式”。
- 处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01〜99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
- 处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1〜9。Y为次版本号，取值范围为0〜9。配置项第一次成为“正式”文件时，版本号为1.0。
- 如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，…。当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。
- 处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。
开发库
开发库 也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的 使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改。
受控库
也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时,将当前的工作产品存入受控库。可以修改，需要走变更流程。
产品库
也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。
配置管理员（CMO）
配置控制委员会负责对配置变更做出评估、审查以及监督巳批准变更的实施。CCB其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。
配置管理员（CMO）负责在整个项目生命周期中进行配置管理活动，具体有如下内容：
- a)编写配置管理计划。
- b)建立和维护配置管理系统。
- c)建立和维护配置库。
- d)配置项识别。
- e)建立和管理基线。
- f)版本管理和配置控制。
- g)配置状态报告。
- h)配置审计。
- i)发布管理和交付。
- j)对项目成员进行配置管理培训。
配置控制即配置项和基线的变更控制，包括下述任务：
- 标识和记录变更申请；
- 分析和评价变更；
- 批准或否决申请；
- 实现、验证和发布已修改的配置项。
变更评估：CCB负责组织对变更申请进行评估并确定以下内容。
- a)变更对项目的影响。
- b)变更的内容是否必要。
- c)变更的范围是否考虑周全。
- d)变更的实施方案是否可行。
- e)变更工作量估计是否合理。
CCB决定是否接受变更，并将决定通知相关人员。
配置状态报告
配置状态报告也称配置状态统计,其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况,供相关人员了解，以加强配置管理工作。 配置状态报告应该包含以下内容：
- a)每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
- b)每个变更申请的状态和已批准的修改的实施状态。
- c)每个基线的当前和过去版本的状态以及各版本的比较。
- d)其他配置管理过程活动的记录。
配置审计
配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求—不允许出现任何混乱现象,例如：
- 防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
- 发现不完善的实现,如开发出不符合初始规格说明或未按变更请求实施变更。
- 找出各配置项间不匹配或不相容的现象。
- 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
- 确认记录和文档保持着可追溯性。
