1、软件文档一般分为三类：开发文档、产品文档、管理文档
1）开发文档描述开发过程本身，基本的开发文档包括：
（1）可行性研究报告和项目任务书
（2）需求规格说明书
（3）功能规格说明书
（4）设计规格说明书，包括程序和数据规格说明书
（5）开发计划
（6）软件集成和测试计划
（7）质量保证计划
（8）安全和测试信息
2）产品文档描述开发过程的产物，基本的产品文档包括：
（1）培训手册
（2）参考手册和用户指南
（3）软件支持手册
（4）产品手册和信息广告
3）管理文档记录项目信息管理的信息，例如：
（1）开发过程的每个阶段的进度和进度变更的记录
（2）软件变更情况记录
（3）开发团队职责定义
（4）项目计划、项目阶段报告
（5）配置管理计划
2、文档的质量可以分为四级：
最低限度文档（1级文档），适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、
测试数据和程序简介。
内部文档（2级文档），可用于没有其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
工作文档（3级文档），适合于由同一单位内若干人联合开发的程序，或被其他单位使用的程序。
正式文档（4级文档）适合那些正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档遵守GB/T8567-2006的有关规定。
3、配置管理包括6个主要活动：制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
4、在信息系统的开流程中需加以控制的配置荐可以分为基线配置和非基线配置项两类
5、所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
6、配置项的状态分为"草稿"、"正式"、"修改"三种。
7、配置项的版本号规则与配置项的相关状态：
1）处于"草稿"状态的配置项的版本号格式为0.XY
2）处于"正式"状态的配置项的版本号格式为X.Y
3）处于"修改"状态的配置项的版本号格式为X.YZ
并且，由于我们不能保证新版本一定比旧版本好，所以不能抛弃旧版本。
8、信息系统的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变更的情况下来控制变化，配置管理引入了"配置基线"的概念。
9、基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。
10、建立基线有以下好处：
1）基线为开发工作提供了一个定点和快照。
2）新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
3）当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
4）可以利用基线重新建立基于某个特定发布版本的配置，以实现以报告的错误
11、配置库可以分为开发库、受控库、产品库3种类型
1）开发库。也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。
2）受控库。也称为主库，包含包含当前的基线加 上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将目前的工作产品存入受控库。
3）产品库。也称为静态库、发行库、软件仓库。在开发的信息系统产品完成测试之后，作为最终产品存入产品库内，等待交付用户或现场包装。
12、配置库的操作权限如下图所示：
13、受控库的权限设置：
14、产品库的权限设置：
15、配置委员会，负责对配置变更做出评估、审批以及监督已批准变更的实施。
CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。小的项目CCB可以只有一个人，甚至只是兼职人员。
CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理、计划审批、基线设立审批、产品发布审批等。
16、配置库的变更控制流程：
1）将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库
2）程序员将欲修改的代码段从受控库中检出（Check Out），放入自己的开发库中进行修改。代码被Check Out后即被"锁定"，以保证员一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check Out。
3）程序员将开发库中修改好的代码段检入（Check in）受控库。Check in后，代码的"锁定"被解除，其他程序员可以Check Out该段代码了。
4）软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的版本V2.1不删除，继续在产品库中保存）
17、配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项目的一致性和完整性。
18、功能配置审计是审计配置项的一致性（配置项的实际功效是否与其一致），具体体现在以下几个方面：
1）配置项目的开发已圆满完成
2）配置项已到达到配置标识中规定的性能和功能特征
3）配置项目 的操作和支持文档已完成并且是符合要求的。
19、物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证如下几个方面：
1）要交付的配置项是否存在
2）配置项中是否包含了所有必须的项目
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
