软件配置管理
第一章
1，软件配置管理用于控制变化
2，软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则，它是控制软件系统演变的学科。
3，软件配置管理是一种标识、组织和控制修改的技术，软件配置管理应用于整个软件工程过程
4，SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更
5，从某种角度讲，SCM的目的是使错误降为最小并最有效地提高生产效率。
6，软件配置管理定义：
软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计用来：
(1) 标识变化；(2) 控制变化；(3) 保证变化被适当的发现；(4) 向其他可能有兴趣的人员报告变化
7，配置管理是否有成效取决于三个要素：人、规范、工具。
8，软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合
9，软件配置是一个集合，该集合中的每一个元素称为该软件产品软件配置中的一个配置项（Software Configuration Item，SCI）。
10，常见的软件配置项：需求规格说明书、设计规格说明书、源代码、测试计划、测试用例、用户手册等
11，基线(Baseline)是指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线是软件生命周期中各开发阶段的一个特定点，它的作用是把开发各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果
12，基线是已经正式通过复审和批准的某规约和产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程来改变。基线通常标志开发过程一个阶段的结束（里程碑）。
13，里程碑(Milestone)是检查点 (Check Point)，检查点不一定是里程碑，因为检查点还可以是时间、计划和事件
14，功能基线：所规定的对待开发软件系统的规格说明
15，指派基线：又称为分配基线，指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明，指派基线是最初批准的指派配置标识。
16，产品基线：指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明，产品基线是最初批准的产品配置标识
17，软件配置控制委员会(Software Configuration Control Board, SCCB)负责管理软件配置项变更的组织。
具体责任如下：
评估变更；批准变更请求；在生命周期内规范变更申请流程；对变更进行反馈；与项目管理层沟通
18，软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括：
-
目标 1: 软件配置管理的各项工作是有计划进行的。
-
目标 2: 被选择的项目产品得到识别，控制并且可以被相关人员获取。
-
目标 3: 已识别出的项目产品的更改得到控制。
-
目标 4: 使相关组别和个人及时了解软件基准的状态和内容。
第二章
1，软件配置管理角色
PM: 项目经理；CCB: 配置控制委员会；CMO: 配置管理员；SIO: 系统集成员；DEV: 开发人员
2，项目经理（Project Manager，PM）
根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。
职责：制定和修改项目的组织结构和配置管理策略；批准、发布配置管理计划；
决定项目起始基线和开发里程碑；接受并审阅配置控制委员会的报告。
配置控制委员会（Configuration Control Board，CCB）
负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。
职责：定制开发子系统；定制访问控制；制定常用策略；建立、更改基线的设置，审核变更申请；根据配置管理员的报告决定相应的对策。
配置管理员（Configuration Management Officer，CMO）
根据配置管理计划执行各项管理任务，定期向CCB提交报告并列席CCB的例会。
职责：软件配置管理工具的日常管理与维护；提交配置管理计划；各配置项的管理与维护；执行版本控制和变更控制方案；完成配置审计并提交报告；对开发人员进行相关的培训；识别软件开发过程中存在的问题并拟定解决方案。
系统集成员（System Integration Officer，SIO）
系统集成员负责生成和管理项目的内部和外部发布版本。
职责：集成修改；构建系统；完成对版本的日常维护；建立外部发布版本。
开发人员（Developer，DEV）
开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。
3
4，软件配置管理过程包括7项基本活动：
(1) 制定配置管理计划；(2) 识别和标志配置项；(3) 搭建配置管理环境；(4) 配置项的版本控制；(5) 基线变更管理；(6) 配置审核；(7) 配置状态统计
5，制定配置管理计划
-
配置管理计划的主要内容：
配置管理组织及其职责；配置管理工具和配置库的组织结构；配置项标志和基线定义；
变更管理流程；配置审核和配置状态统计
6，识别和标志配置项：
（1）为每一个配置项分配唯一的标志；建立配置项间的对应关系
（2）两类配置项：
-
基本配置项：软件开发者在项目开发过程中所创建的基本工作单元。
-
集成配置项：一个集成配置项是基本配置项或其它集成配置项的集合。
7，搭建配置管理环境
配置管理环境是用于进行软件配置管理的系统环境，其中最重要的是配置管理库，简称配置库
配置库存储配置项 (SCI)、修改请求、变化记录等，并提供对库中所存储文件的版本控制
一般需采用配置管理工具来建立配置库。
8，配置项的版本控制
-
配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题：
-
访问控制：保证具有相应权限的人员才能修改配置项。
-
并行控制：保证不同人员同时对某配置项进行的修改不会互相覆盖。
-
-
对配置项的修改（不同版本间的差别）应被记录下来。
更动者（姓名及其身份）；更动日期和时间；被更动SCI（名及其版本号）；
更动内容及其位置；更动原因；受此更动影响的诸SCI名表。
-
软件产品版本编号方法
-
数字顺序型版本编号
普通版本编号
-
x.y.z，x为主版本号，y为特征版本号，z为缺陷修复版本号，如V3.10.16。
-
主版本号的增加表示提供给客户的主要产品功能的增强。
-
特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
-
缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。
α和β版本编号
-
在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
-
如果存在多次的α发布和β发布，可在A或B后面添加一个数字来说明发布的次数，例如：1.2.5A1，1.3.0B2。
α测试是由公司内部的用户在模拟实际操作环境下进行的测试。
β测试是由软件的多个用户在实际使用环境下进行的测试。
-
属性版本编号：
把版本的重要属性反映在标识中。可以包括的属性有：客户名、开发语言、开发状态、硬件平台、生成日期等。例如： J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
-
包含的信息丰富，方便了查询和管理，版本间的关系易于保持，但由于太复杂，一般只用于软件组织内部的管理
-
-
9，基线变更管理
-
变更批准或拒绝
根据评估结果对变更作出决策：
直接实现变更；挂起或延迟变更；拒绝变更
对于批准的变更，要确定其实现进度：
立即实现变更；在特定的日期实现变更；在软件另外的版本中实现
-
变更实现
10，配置审核
配置管理活动审核：确保所有配置管理活动符合已批准的软件配置管理规程
基线审核：审核基线配置项的完整性和一致性，从而保证基线配置项可被正确地构造。
11，配置状态统计和报告
变更请求的数量。变更管理活动的执行情况。
配置管理系统存储量的变化。配置管理系统和SCCB在运作中发生异常的次数
第三章
1，CMM/CMMI将软件配置管理的活动分为6个方面，每个方面又再进行了细分
SCM过程管理；软件配置标识；软件配置控制；软件配置状态统计；软件配置审计；软件发布管理和交付
2，在CMM和CMMI中，将配置管理的目的定义为"建立和维护产品的完整性"，
3，配置完整性（对标准的理解）
-
产品完整性：项目提交的工作成果是"产品集合完整、子产品正确"的
-
产品集合完整：产品包含的子产品（配置项）是完整的
-
子产品正确：子产品（配置项）达到了需求要求，满足标准、规程的要求
4，三库管理：三库的概念源自CMM/CMMI，即开发库、受控库和产品库。配置项在三库之间迁移，一级比一级的控制更严格。
5，软件开发组日常的工作在开发库中开展，当工作达到里程碑时，再迁移到受控库，在受控库中经过更严格的测试后，再上升到产品库，最后发布。
6，在实践中，三库常常被实现为物理上的三库，而不是通过逻辑的方式来实现，三库物理隔离带来的最大问题是配置项失去了历史可追溯性
7，实现三库的指导思想应该是逻辑上独立，物理上在一起，通过权限与流程的控制来实现配置项在不同库之间的流转，以及相应角色的人员对相应库的访问。
-
CMM2在配置管理方面主要针对于实现部分;CMM3将配置管理扩展到需求、规格说明、设计和工具
-
SCM意义：
记录软件产品的演化过程；
确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置；
最终保证软件产品的完整性、一致性、追朔性、可控性;。
10，每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是"基线管理"的过程
11，建立基线的好处：重现性；可追踪性；版本隔离。
基线管理的步骤：
(1) 在开发前确定基线的"配置"；(2) 基线批准前，根据"配置"检查配置项是否齐备；
(3) 对各个配置项，确认其版本的正确性；(4) 对每个配置项建立基线标志；
(5) 基线变更管理；(6) 基线的各类报告和审计信息。
12，变更管理的流程：
（获得）提出变更请求；由CCB审核并决定是否批准；
为（被接受）修改请求分配人员，提取SCI，进行修改；
提交修改后的SCI，并测试（或者评审）；重建软件的适当版本；
复审（审计）所有SCI的变化；发布新版本。
---可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》
13，配置库管理
(1)设置配置库（即文件夹设置）和设置版本的分支
(2)为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支
私有分支（开发人员的私有开发空间）：开发人员
集成分支（开发团队的公共空间）：由系统集成员及相关指定人员负责：所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。
公共（主干）分支（整个软件开发组织的公共空间）:系统集成员:各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上,对组织内的全体软件人员开放只读权限
上面定义的3类工作空间（分支）由配置管理员统一管理
(3)按配置项类型分类建库和按任务建库。
(4)配置库的日常工作：对配置库的定期备份；清除无用的文件和版本；检测并改进配置库的性能等
14,配置审计：主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现
记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。 （Who、When、Why、What）
-
同时配置审计工作该应当说明如下信息：
(1) 变更要求被完成，并且对附加的修改已经执行了 (2) 采用了正确的正式验证手段
(3) 遵循了标准的要求 (4) 变更的4W信息被完整记录，并和相关配置项关联
-
配置审计有两种:
-
PCA (Physics Configuration Audit)-----非配置管理人员
主要是检查版本是否正确一致。(1) 配置项是否齐备；(2) 版本是否齐全，由非配置管理人员来进行。
-
FCA (Function Configuration Audit) -----CMO
检查配置项是否完整，各种过程文档是否齐备、正确、与需求是否一致，归结为两点，即完全和齐备。
15，配置审计
-
When：软件交付或release时；每个阶段结束时；对于维护性项目，周期性地进行
-
Who：非本项目组成员；其他项目中的配置控制者；内部审计者；SCM小组
-
配置审计步骤（How-审计流程）
-
(1) 由项目经理决定何时进行配置审计工作（识别配置审计的时间[PM]）
-
(2) 质量保证组或项目组的配置管理组制定该项目的配置审计人员（指派审计者[QA/Audit Group]）
-
(3) 项目经理和配置审计员决定审计范围（定义审计范围[PM&Auditors]）
-
(4) 配置审计员准备配置审计检查单（准备配置审计Checklist[Auditor]）
-
(5) 配置审计员安排时间审计文档和记录，审计活动可能涉及到：项目范围，配置项的入库(check in)及出库(check out)，评审记录，配置项的变更历史，测试记录，文件的命名，变更请求和版本的编号等
（通过评审（Review）、文档记录进行审计[Auditor]）
-
(6) 配置审计员在审计中发现不一致现象，并作记录（识别不符合项[Auditor]）
-
(7) 由项目经理负责消除不一致现象（关闭不符合项[PM]）
-
(8) 配置审计员验证所有发现的不一致现象确已得到解决（验证[Auditor]）
16，配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况
应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。
应着重反映当前基线配置项的状态，以作为对开发进度报告的参照
17，软件配置管理最佳实践：
统一标识配置项并存入安全的配置管理系统；控制和审计配置项的变更；合理组织配置项；
在项目的里程碑建立相应的基线；记录和跟踪变更请求；过程驱动的软件配置管理；
维护稳定而一致的工作空间；支持并行开发；尽早和持续集成；
确保有能力重现软件的构建过程；把握好工具、流程和人员三者之间的关系；善用模式和反模式；
18，模式可以指导我们如何成功应用前人的实践，避免犯前人犯过的错误，提高SCM的实施成功率。
反模式是指那些在特定情况下不应该采取的策略和方式。
第4章
1，软件配置管理计划： 人员及职责；配置管理软硬件资源；配置项计划；基线计划；配置库备份计划
2，配置库管理报告： 基本信息；项目成员的操作权限；配置项记录；基线记录；配置库备份记录；配置项交付记录；配置库重要操作日志
3，配置项变更控制报告： 变更申请；审批变更申请；变更配置项；结束变更
4，配置状态报告 (Configuration Status Report)目的：有效记录和报告管理配置所需要的信息，及时、准确地给出软件配置项的当前状态，供相关人员了解，以加强配置管理工作
-
内容
-
各份变更请示概要：变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期
-
基线库状态：库标识、至某日预计库内配置项数、实际配置项数
-
发行信息：发行版本、计划发行时间、实际发行日期、说明
-
备份信息：备份日期、介质、备份存放位置
-
配置管理工具状态
-
配置管理培训状态
-
5，配置审计目的：验证配置项信息与配置标识（需求、标准、流程…）的一致性，4"W"
配置审计报告内容：配置项状态统计；基线库基线统计；变更统计；审计中发现的主要问题
第5章
1，配置管理模式分类： 描述工作区结构的模式； 描述码线结构的模式
2，码线(codeline)--源代码文件与组成某个软件组件的其他人工制品（配置项）随着时间而变更的进展过程。
码线包含沿着一条路径发展的各个配置项的每个版本
3，与码线有关的模式：主线； 活动开发线； 码线策略； 私用版本； 版本线； 版本预备线； 任务分支4，与工作区有关的模式： 私有工作区；储存库； 私有系统构造； 集成构造； 第三方码线；任务级提； 冒烟测试； 单元测试； 回归测试
-
主线——问题： 如何使当前活动码线的数目保持在容易管理的水平，避免项目的版本树长得太宽太密？如何使合并的开销减至最小？
解决方案：简化分支模型：开发单个产品版本时，在主线上进行开发。分支时，先考虑总体战略，然后再创建分支
6，分支是组织文件版本和显示版本历史的手段，是隔离变更的强有力机制。
7，主线既要使码线的并发性达到最大，又要使推迟集成可能造成的问题减至最小
8，私有工作区——问题： 如何跟上不断变化的码线并取得进展，而不会为环境变化而分心？
-
解决方案：以隔离工作的方法控制变更 (Isolate your work to change control)
-
储存库——问题：如何获得填充新工作区的正确组件的正确版本11，
-
冒烟测试(Smoke Test)：如何知道系统在你变更后仍能工作？
描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程；
是确定和修复软件缺陷的最经济有效的方法；缺点在于覆盖面很有限。执行者是开发人员或版本编译人员
12，每次构造都必须进行冒烟测试，以显而易见的方式验证应用未被损坏。
13，单元测试（(Unit Test)）：如何测试模块经你变更后是否仍能像预期一样工作？
14，回归测试（(Regression Test)）：如何确保现有的代码没有因你进行其他改进而变得更糟？
15，每日构建 (Daily Build)
就是把一个软件项目的所有的最新的代码从配置库中取出，然后从头进行编译、链接和运行。通常由工具自动完成（构建自动化）。
daily build 的另一个重要功能就是验证软件中各模块关系是否正确，也可称为"每日集成"。
第9章
1，版本库（Repository）：按照一定格式存储了所有数据，包括文件和目录
经过授权的客户端可以连接到版本库，读写库中的文件
版本库和普通文件服务器的不同：版本库会记录每一次的更改
2，版本控制系统的核心任务：协作编辑和数据共享
3，拷贝-合并模型假定文件是可以通过上下文合并的。通常情况下，文本文件（例如源代码以及用纯文本，HTML，TXT等格式保存的文档）因为其内部结构直观可知，容易理解上下文，所以用拷贝-合并方案较好。而二进制文件（例如用Microsoft Word格式说，PDF等格式保存的文档及图片，声音，可执行文件，库等）内部结构复杂，且不容易理解更改处的上下文，采用锁定-解锁方案较好
4，Subversion主要采用拷贝-修改-合并模型，配合锁定-修改-解锁模型管理数据的共享
5，工作拷贝（Working Copy）是本地机器的一个普通的目录，是私有工作区
6，修订版本（Revision）：每当一次提交完成后，版本库的文件系统就进入了一个新的状态，叫做一次修订（Revision）。在版本库中，最新的一个修订版本称为HEAD
7，CheckOut：从版本库中取出某个目录的拷贝到本机上某个目录的操作
例：svn co svn://192.168.0.1/svnrepos/skizcorp/trunk
-r 1452 会检出1452版，如果存在的话；-N：不递归（仅针对顶层目录），否则目录递归（默认，常用）
8，Update：把版本库的修改同步到本地
-
例1：up 直接把工作拷贝更新到最新版（HEAD版）
-
例2：up -r 2007 更新到2007版
-
例3：up doc/design 只更新doc/design下的文件
9，BASE版：某个文件的BASE版本是指存放在管理目录.svn中的该文件拷贝的版本，Revert会使该文件回到BASE版本
10，Revert，是指放弃对某个文件的修改------revert abc.c 丢弃对abc.c的所有修改
11，当文件发生冲突时，SVN会额外创建3个不受版本控制的文件
12，add：把一个文件加入SVN版本控制系统；delete：从版本控制系统中移除；
move(rename)：移动或者重命名；mkdir：创建目录；copy：拷贝；commit：提交；
status：检查工作拷贝的状态；diff：检查更改的内容
13，分支(Branch)是开发的一条"支线"。它独立于其他开发的线路，并且和其他线路并行开发
-
所有的分支都有共同的历史，有着原先共同的主线(Trunk)
14，创建分支使用copy命令：copy 源目录 目标目录
-
例：先把目录checkout到本地，在本地执行copy命令后提交至版本库
svn co svn://localhost/
svn copy trunk/ branches/mybranch
svn commit –m "My branch created"
-
svn copy svn://localhost/trunk svn://localhost/branches/mybranch –m "My branch"
15，Switch操作可以使工作拷贝在不同的分支之间或者在位于不同服务器上相同的版本库的分支间切换。它的作用是改变工作拷贝对应的URL：switch [--relocate] 目标URL
16,分支的合并是指把修改从分支拷贝到主干或者把主干的修改拷贝到分支的过程。
-
传统方法：diff + patch(只适用于文件内容)
-
例子：取出主干2000版到2007版的修改，然后把它应用到工作拷贝
-
svn diff –r 2000:2007 svn://localhost/trunk > patchfile
patch –p0 < patchfile
-
merge 初始版本树 最终版本树 目标(能够处理目录树的修改，而不限于单个文件内容)
例子
-
merge svn://localhost/trunk@2000 svn://localhost/trunk@2007 my_wc
-
merge –r 2000:2007 svn://localhost/trunk my_wc
17,tag：通常tag对应于milestone，是一个完整可用的版本，不能修改，是只读的
branch：是trunk或tag的分支，可以修改，是可写的，用于做并行开发
18，常用的SVN命令：
| 命令名称 |
功能 |
| svn add |
往版本库中添加新的文件 |
| svn checkout |
将文件checkout到本地目录 |
| svn cleanup |
递归清理工作拷贝 |
| svn commit |
将改动的文件提交到版本库 |
| svn copy |
拷贝文件 |
| svn delete |
删除文件 |
| svn diff |
比较差异 |
| svn export |
导出目录树 |
| svn import |
导入目录树 |
| svn info |
打印作者、时间戳、日志信息大小和日志信息 |
| svn list |
版本库下的文件和目录列表 |
| svn lock |
文件加锁 |
| svn log |
查看日志 |
| svn merge |
将两个版本之间的差异合并到当前文件 |
| svn mkdir |
创建纳入版本控制下的新目录 |
| svn move |
移动一个文件或目录 |
| svn resolved |
移除工作副本的目录或文件的"冲突"状态 |
| svn revert |
恢复本地修改 |
| svn status |
查看文件或者目录状态 |
| svn switch |
代码库URL变更 |
| svn unlock |
文件解锁 |
| svn update |
更新到某个版本 |
第8章
1，两种版本控制模型
-
Lock-Modify-Unlock Model (加锁-修改-解锁)：CVS，SVN，VSS2005
-
Copy-Modify-Merge Model (拷贝-修改-合并)：VSS6.0，PCVS
2，基于"拷贝—修改—合并"的并发控制
-
客户端check out后，有文件的一份独立拷贝。
-
开发者在自己的工作目录中修改文件。
-
若有版本冲突，则使用合并（merge）功能与其它开发者的修改合并，然后提交（check in）。
第6章
1，常用的配置管理工具：Visual SourceSafe（VSS）； CVS； Subversion（SVN）； Borland StarTeam； IBM Rational ClearCase & ClearQuest； Hansky Firefly
ClearCase，Firefly支持异地开发，与开发工具的集成非常好，价格昂贵
VSS仅支持windows,其他支持常见平台，与vs无缝集成，与其他开发工具集成性差
2，软件配置管理工具的主要功能：
版本控制；变更管理；配置审核（配置审计）
配置状态统计（查询和报告）；问题跟踪（跟踪缺陷和变更）；访问控制和安全控制
3，ClearCase主要应用于复杂产品的并行开发、发布和维护，其功能划分为四个范畴：版本控制（Version Control）、工作空间管理（Workspace Management）、构造管理（Build Management）、过程控制（Process Control）。
4，ClearCase把所有版本控制的数据存放在一个永久、安全的存储区中，这个存储区被称为版本对象类（Version Object Bases）
A VIEW selects versions of elements
What is seen is the result of an ordered set of rules called a configuration specification (config spec).
Selected versions appear in a standard directory tree with recognizable file names.
View分为SnapShot View和Dynamic View，Snapshot view是ClearCase在服务器上存储的文件和目录的一个本地镜像，Dynamic View是动态试图，它并不在本地存储任何文件，始终和服务器保持一致。
-
软件配置管理工具选择：功能；是否符合团队特点？性能；费用是；售后服务；易用性
| 序号 |
活动名称 |
角色 |
活动描述 |
参考 |
| 1 |
|
配置管理经理 CCB |
|
《配置管理计划》模板
|
| 2 |
|
配置管理经理 |
|
《VSS使用手册》 《组织管理配置库使用指南》 |
| 3 |
|
配置管理经理 |
|
《软件开发文档命名约定》 |
| 4 |
|
配置管理经理 集成员 |
|
《配置管理计划模板》
《基线策略指南》 |
| 5 |
|
配置管理经理 |
根据配置管理计划，收集配置活动数据， 编写配置状态报告。 |
《配置状态报告》模板 |
| 6 |
|
配置管理经理 |
|
《配置审计报告》模板 |
| 7 |
|
CCB 任意角色 |
|
《文档变更请求》 |