2021-05-18-项目文档及配置管理笔记

软件文档分类

开发文档

开发文档描述开发过程本身，基本的开发文档包括：

1. 可行性研究报告和项目任务书
2. 需求规格说明
3. 功能规格说明
4. 软件集成和测试计划
5. 质量保证计划
6. 安全和测试信息

产品文档

产品文档描述开发过程的产物，基本的产品文档包括：

1. 培训手册
2. 参考手册和用户指南
3. 软件支持手册
4. 产品手册和信息广告

管理文档

管理文档记录项目管理的信息，例如：

1. 开发过程的每个阶段的进度和进度变更的记录。
2. 软件变更情况的记录。
3. 开发团队的职责定义。
4. 项目计划、项目阶段报告。
5. 配置管理计划

文档质量等级

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

配置管理

配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

配置项

1. 配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
2. 所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
3. 配置项的状态可分为“草稿” “正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。 配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
4. 配置项版本号：处于“草稿”状态的配置项的版本号格式为0.YZ,YZ的数字范围为01〜99。随着草稿的修 正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1〜9。Y为 次版本号，取值范围为0〜9。配置项第一次成为“正式”文件时，版本号为1.0。处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值， X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0,增加X.Y值。

基线

1. 配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。 基线中的配置项被“冻结” 了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
2. 一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线,内部开发使用的基线一般称为构造基线。

配置库

配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。配置库可以分开发库、受控库、产品库3种类型。

1. 开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体， 如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。可以任意的修改
2. 受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全 的配置管理之下。在信息系统开发的某个阶段工作结束时,将当前的工作产品存入受控库。可以修改，需要走变更流程。
3. 产品库,也称为静态库、发行库、软件仓库，包含己发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内， 等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。

配置控制

1. 配置管理员负责在整个项目生命周期中进行配置管理活动，具体有：
   （1） 编写配置管理计划。
   （2） 建立和维护配置管理系统。
   （3） 建立和维护配置库。
   （4） 配置项识别。
   （5） 建立和管理基线。
   （6） 版本管理和配置控制。
   （7） 配置状态报告。
   （8）配置审计。
   （9） 发布管理和交付。
2. 配置控制委员会
   配置控制委员会负责对配置变更做出评估、审查以及监督巳批准变更的实施。CCB其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB不必是常设机构，完全可以根据工作的需要组成。CCB决定是否接受变更，并将决定通知相关人员。通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、 产品发布审批等。
3. 配置控制即配置项和基线的变更控制，包括下述任务：标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布己修改的配置项。
   （1） 变更评估：CCB负责组织对变更申请进行评估并确定以下内容。
   1）变更对项目的影响。
   2）变更的内容是否必要。
   3）变更的范围是否考虑周全。
   4）变更的实施方案是否可行。
   5）变更工作量估计是否合理。
   （2） 配置管理中的角色和分工：
   1）项目经理(PM )：是整个信息系统开发和维护活动的负责人，他根椐配置控制委员会的建议，批准配置管理的各项活动并控制它们的进程。其具体工作职责如下：制订项目的组织结构和配置管理策略；决定项目起始基线和软件开发工作里程碑；接受并审阅配置控制委员会的报告。
   2）配置控制委员会(CCB)：负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体工作职责如下：批准配置项的标志，以及软件基线的建立；制订访问控制策略；建立、更改基线的设置，审核变更申请；根椐配置管理员的报告决定相应的对策。
   3）配置管理员(CMO)：根据配置管理计划执行各项管理任务，定期向CCB提交报告，并列席 CCB的例会，其具体工作职责如下：软件配置管理工具的日常管理与维护；提交配置管理计划； 各配置项的管理与维护；执行版本控制和变更控制方案；完成配置审计并提交报告；对开发人 员进行相关的培训；识别开发过程中存在的问题并制订解决方案。
   4） 开发人员的职责就是根据项目组织确定的配置管理计划和相关规定，按照配置管理工具的使用模型来完成开发任务。

配置状态报告

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

1. 每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
2. 每个变更申请的状态和已批准的修改的实施状态。
3. 每个基线的当前和过去版本的状态以及各版本的比较。
4. 其他配置管理过程活动的记录。

配置审计

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