注：
博客：
https://blog.csdn.net/badao_liumang_qizhi
关注公众号
霸道的程序猿
获取编程相关电子书、教程推送与免费下载。
3、文档的规范化管理主要体现在
①文档书写规范
②图表编号规则
③文档目录编写标准
④文档管理制度等几个方面。(掌握)
(1)文档书写规范:
应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等;
(2)图表编号规则:
对这些图表进行有规则的编号，可以方便图表的查找;
(3)文档目录编写标准;
(4)文档管理制度:
应该建立相应的文档管理制度
1、配置管理包括6个主要活动:
制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
(掌握)
2、典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、
测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。(掌握)
注意点:测试报告、会议纪要、工作记录不计入配置项的内容;因为一经形成就不好修改了!
3、在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线
配置项两类
基线配置项可能包括所有的设计文档和源程序等;
非基线配置项可能包括项目的各类计划和报告等。
所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是:基线配置
项向开发人员开放读取的权限;非基线配置项向PM, CCB及相关人员开放。(掌握)
配置管理员为每个项目成员分配对配置库的操作权限。一般地，项目成员拥有
Add, Checkin/Checkout, Download等权限，但是不能拥有“删除”权限。配置管
理员的权限最高。具体操作视所采用的配置管理软件而定。
6、配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置
审计、发布和交付等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能
最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定
比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项
的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任
何版本。(掌握)
7、配置基线(常简称为基线)由一组配置项组成，这些配置项构成一个相对稳定的逻
辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须
遵循正式的变更控制程序。
8、一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文
卷和用户文档构成一条基线。产品的一个测试版本(可能包括需求分析说明书、概要设
计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等)
是基线的一个例子。(掌握)
9、基线通常对应于开发过程中的里程碑(Milestone)，一个产品可以有多个基线，
也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release)，内部开
发使用的基线一般称为构造基线(Build)。(掌握)
10、每一个基线，定义的内容:
建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。(掌握)
11、配置库可以分开发库、受控库、产品库3种:(掌握)
①开发库
也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的
配置实体，动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能
有较为频繁的修改。(可以任意的修改)
②受控库
也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置
于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品
存入受控库。(可以修改，需要走变更流程)
③产品库
也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，
被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产
品存入产品库内，等待交付用户或现场安装。(一般不再修改，真要修改的话需要走变更流程)
12、配置库的建库模式有两种:
按配置项类型建库和按任务建库(掌握)
①按配置项的类型分类建库，适用于通用软件的开发组织。
在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。
使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
②按开发任务建立相应的配置库，适用于专业软件的开发组织。
在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有
必要把配置项严格地分类存储，人为增加目录的复杂性。
对于研发性的软件组织来说，采用这种设置策略比较灵活。
用于建立配置库的工具:VSS, CVS;也可以通过手工方式进行建库;
14、配置控制委员会(CCB)，负责对配置变更做出评估、审批以及监督已批准变更的实施。
其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。
CCB不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的
不同，组成不同的CCB。小的项目CCB可以只有一个人，甚至只是兼职人员。
通常，CCB不只是控制配置变更，而是负有更多的配置管理任务，例如:配置管理计
划审批、基线设立审批、产品发布审批等。(掌握)
15、配置管理员负责在整个项目生命周期中进行配置管理活动，具体有:
①编写配置管理计划
②建立和维护配置管理系统
③建立和维护配置库
④配置项识别
⑤建立和管理基线
⑥版本管理和配置控制
⑦配置状态报告
⑧配置审计
⑨发布管理和交付
⑩对项目成员进行配置管理培训。(掌握)
16、软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。(掌握)
17、软件配置的整体性在整个项目生命周期中得到控制。软件质量保证人员应该定期审
核各类软件基准以及软件配置管理工作。使软件基准的状态和内容能够及时通知给相关
组别和个人
18、配置管理计划由配置管理员制定，配置控制委员会负责审批。(掌握)
19、配置管理计划的主要内容为:(掌握)
①配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、
发布管理与交付。
②实施这些活动的规范和流程。
③实施这些活动的进度安排。
④负责实施这些活动的人员或组织，以及他们和其他组织的关系。
20、配置标识是配置管理员的职能，基本步骤如下:(掌握)
①识别需要受控的配置项。
②为每个配置项指定唯一性的标识号。
③定义每个配置项的重要特征。
④确定每个配置项的所有者及其责任。
⑤确定配置项进入配置管理的时间和条件。
⑥建立和控制基线。
⑦维护文档和组件的修订与产品版本之间的关系。
21、配置控制即配置项和基线的变更控制，包括下述任务:
标识和记录变更申请，分析和评价变更，批准或否决申请，实现、验证和发布已修改的配置项。(掌握)
变更流程:
①变更申请
②变更评估
③通告评估结果
④变更实施
⑤变更验证与确认
⑥变更的发布
⑦基于配置库的变更控制(掌握)
24、配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别
用以验证当前配置项的一致性和完整性。(掌握)
25、配置审计的作用:(掌握)
①防止向用户提交不适合的产品，如交付了用户手册的不正确版本。
②发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
③找出各配置项间不匹配或不相容的现象。
④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。
⑤确认记录和文档保持着可追溯性。
26、功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致)
验证:(了解)
①配置项的开发已圆满完成。
②配置项已达到
③配置标识中规定的性能和功能特征。
④配置项的操作和支持文档己完成并且是符合要求的。
27、物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致)，
验证:
①要交付的配置项是否存在。
②配置项中是否包含了所有必需的项目。
28、发布管理和交付:
①存储
②复制
③打包
④交付
⑤重建(了解)
1、常用付费软件配置管理工具有:(了解)
①RationaI CIearCase
②Perforce
③CACCC
④HavestMerantPVCS
⑤ MicrosoftVSS, CVS
2、常用的开源免费的软件配置管理工具有:
①SVN
②GIT
③CVS(了解)
