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