软件配置管理 吕共欣 2002年7月

软件配置管理 内容 SCM介绍 SCM在CMM中的定义与基本内容 SCM实施

什么是软件配置管理 软件配置管理主要是对软件生存期过程中的各种阶段产品和最终产品演化和变更的管理，它是软件质量管理的重要组成部分。 软件配置管理(SCM)介绍 什么是软件配置管理 软件配置管理主要是对软件生存期过程中的各种阶段产品和最终产品演化和变更的管理，它是软件质量管理的重要组成部分。

软件配置管理(SCM)介绍 软件配置管理概念 软件配置项（software configuration item ） 软件配置

软件配置管理(SCM)介绍 软件配置项 软件开发的过程中，会得到许多工作产品或阶段产品，还会用到许多工具软件，这可能是外购软件，也可能是用户提供的软件。所有这些独立的信息项都要得到妥善的管理，绝不能出现混乱，以便在提出某些特定的要求时，能将其进行约定的组合来满足使用的目的。 　 这些信息项是配置管理的对象，称为软件配置项。

软件配置管理(SCM)介绍 软件配置 软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。

软件配置管理(SCM)介绍 软件配置举例 以交付给不同用户的某一软件产品为例，开发的软件产品是具有一定功能和性能的初始系统，经调查，了解到“用户1”代表了一些用户，这个用户群使用的计算机为“机型1”，所用的操作系统是“操作系统1”；而“用户2”所代表的用户群使用着“机型2”和“操作系统2” 。

软件配置管理(SCM)介绍 软件配置举例（续1） 操作系统1 用户1 机型1 操作系统2 用户2 机型2 初始系统 … 机型n

软件配置管理(SCM)介绍 软件配置举例（续2） F C 用户1 A B E D B A C D E 用户2 G H

软件配置举例（续3） 软件配置管理(SCM)介绍 F C A B E G D H 用户1 用户2 A B C D E F A B C D E 产品1 产品2

软件配置管理意义 软件配置管理(SCM)介绍 软件项目的特点 忽视软件配置管理可能导致的混乱现象 软件产品是逻辑实体，是不可见的、抽象的智力产品 软件项目的规模日益庞大和复杂 参与项目人员数量增加，人员间的沟通渠道数量也倍增 软件产品易于被拷贝 软件时时处在演化和变更状态 开发人员的离去对项目有较大的影响 忽视软件配置管理可能导致的混乱现象

软件配置管理(SCM)介绍 软件配置管理功能 配置标识 配置控制 配置状态报告 配置审核

软件配置标识 软件配置管理(SCM)介绍 确定配置项 配置命名及其相关信息 技术性文档 管理性文档 唯一性 可追溯性 一个典型的实例是采用层次式命名规则来反映树状结构。例如CODE是根结点为PCL_TOOLS的树结构第六层结点，对其命名为：　PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE

软件配置管理(SCM)介绍 配置控制 软件变更 配置库 配置基线 变更请求与变更控制

配置控制——软件变更 软件配置管理(SCM)介绍 软件变更的不可避免性 软件变更的复杂性 变更管理的任务 用户 软件开发人员或项目管理人员 软件在一处变更，可能要涉及一些相关部件和文档，需要将这一变更通知到受影响的相关人员 变更管理的任务 分析变更：必要性、经济可行性、技术可行性 记录和追踪变更 采取措施保证变更在受授状态下进行

配置控制——配置库 软件配置管理(SCM)介绍 配置库的作用 三类库 记录与配置相关的所有信息 利用库中的信息评价变更的后果 从库中提取各种配置管理过程的管理信息 （如版本信息） 三类库 开发库 受控库 产品库

配置控制——配置基线 软件配置管理(SCM)介绍 基线是软件生存期各开发阶段末尾的特定点，也称为里程碑 如果把软件看作是系统的一个组成部分，以下三种基线是最受人们关注的 功能基线 分配基线 产品基线

配置控制——变更请求与变更控制 软件配置管理(SCM)介绍 利用配置库实现变更控制 变更请求 工作状态 评审状态 受控状态 未通过评审 Check in 工作状态 评审状态 受控状态 开发人员满意 通过评审 Check out

配置审核 软件配置管理(SCM)介绍 配置审核的任务是验证配置项对配置标识的一致性 配置审核内容 对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象 配置标识的准则是否得到了遵循 变更控制规程是否已遵循，变更记录是否可供使用 在规格说明、软件产品和变更请求之间是否保持了可追溯性 配置审核内容 功能配置审核 物理配置审核

配置审核——实施 软件配置管理(SCM)介绍 配置审核时机 实施配置审核的责任人 软件产品交付或是软件产品正式发行前 软件开发的阶段工作结束之后 在维护工作中，定期地进行 实施配置审核的责任人 项目组成员 非项目组成员 其他项目的配置管理人员 内部审核员 配置管理人员

配置审核——实施(续) 软件配置管理(SCM)介绍 配置审核工作开展 由项目经理决定何时进行配置审核工作 质量保证组或软件组的配置管理组指定该项目的配置审核人员 项目经理和配置审核员决定审核范围 配置审核员准备配置审核检查单 配置审核员安排时间审核文档和记录，审核活动可能涉及到： 项目范围 配置项的入库及出库 评审记录 配置项的变更历史 测试记录 文件的命名 变更请求 版本的编号

配置审核——实施(续) 软件配置管理(SCM)介绍 配置审核工作开展 配置审核员在审核中发现不符合现象，并做记录 由项目经理负责消除不符合现象 配置审核员验证所有发现的不符合现象确已得到解决

配置状态报告 软件配置管理(SCM)介绍 任务 有效地记录和报告管理配置所需要的信息 目的 及时、准确地给出软件配置的当前状况 需要跟踪捕捉的状态报告信息 配置项的当前标识 已交付软件的配置 变更请求或问题报告的状态 已获准变更的状态

CMM介绍 SCM在CMM中的定义与基本内容

CMM介绍 CMM软件过程成熟度的五个等级

CMM介绍 软件过程成熟度关键过程区域

CMM介绍 软件过程成熟度结构

关键过程区域组织的共同特点 执行约定 执行能力 CMM介绍 执行的活动 测量和分析 验证实施 组织方针 高级管理者支持 资源、组织结构、培训 制定计划和规程 工作与工作状态跟踪 测量和分析 确定所执行活动的状态和有效性所采用的测量的例子 验证实施 管理者和质量保证部门的评审和审计

CMM介绍 关键实践举例

目标 等级2的一个关键过程区域——软件配置管理 目标1 软件配置管理活动是有计划的 目标2 所选定的软件工作产品是已标识的、受控的和适用的 目标3 对已标识的软件工作产品的更改是受控的 目标4 受影响的组和个人得到软件基线的状态和内容的通知

执行约定 等级2的一个关键过程区域——软件配置管理 约定1 项目遵循书面的实施软件配置管理的组织方针 这些方针包括： 明确指派每个项目的SCM职责 在项目的整个生命周期内实行SCM 对于对外可交付的软件产品、指定的内部软件工作产品和指定在项目内使用的支持工具都实行SCM 项目建立或利用一个仓库，用来存储配置项/单元和相关联的SCM记录 定期审计软件基线和SCM活动

执行能力 等级2的一个关键过程区域——软件配置管理 能力1 存在或建立一个有权力管理项目软件基线的委员会（即软件配置控制委员会——SCCB） 审定软件基线的建立和配置项/单元的标识 代表项目经理和所有可能受到软件基线更改影响的组的利益 评审和审定对软件基线的更改 审定由软件基线库制造的产品的生成

等级2的一个关键过程区域——软件配置管理 能力1 受到软件基线更改影响的组例子： 硬件质量保证组 硬件技术状态（配置）管理组 硬件工程组 制造工程组 软件工程组（包括所有小组，如设计组） 系统工程组 系统测试组 软件质量保证组 软件配置管理组 合同管理组 文档支持组

执行能力 等级2的一个关键过程区域——软件配置管理 能力2 存在负责协调和实施项目的SCM的组（即SCM组） SCM组协调实现： 项目软件基线库的生成和管理 SCM计划、标准和规程的制定、维护和分发 将置于SCM之下的软件工作产品集合的标识 对存取软件基线库的管理 软件基线的更新 由软件基线库制造的产品的生成 SCM行动的记录 SCM报告的生成和散发

执行能力 等级2的一个关键过程区域——软件配置管理 能力3 为进行SCM活动提供足够的资源和投资 安排一名经理专门负责SCM

执行能力 等级2的一个关键过程区域——软件配置管理 能力4 SCM组的成员在有关进行其SCM活动的对象、规程和方法方面受到培训。

执行能力 等级2的一个关键过程区域——软件配置管理 能力5 软件工程组和其他软件——有关组的成员受到培训以便完成其SCM活动。 其他软件——有关组的例子有： ——软件质量保证组 ——文档支持组 培训的例子包括： ——软件工程组和其他软件——有关组内部进行SCM活动要遵循的标准、规程和方法 ——SCM组的角色、职责和权力

执行活动 等级2的一个关键过程区域——软件配置管理 活动1 按照已文档化的规程对每个软件项目准备一份SCM计划。 这个规程一般规定：

执行活动 等级2的一个关键过程区域——软件配置管理 活动2 用已文档化的经批准的SCM计划作为进行SCM活动的基础。 该计划包括：

执行活动 等级2的一个关键过程区域——软件配置管理 活动3 建立一个配置库管理系统作为软件基线的仓库 该库系统： 支持SCM的多个控制层次 提供对配置项/单元的存储和检索功能 在受影响的组之间和在库内部的层次之间提供配置项/单元的共享和传送 帮助使用配置项/单元的产品标准 对配置项/单元的归档版本提供存储和恢复功能 帮助保证由软件基线库制造的产品的正确生成 对SCM记录提供存储、更新和检索功能 支持SCM报告的编制 提供对库结构和内容的维护

执行活动 等级2的一个关键过程区域——软件配置管理 活动4 标识将置于配置管理之下的软件工作产品 基于已文档化的准则选择配置项/单元 安排给配置项/单元唯一标志符 详细说明每个配置项/单元的特征 详细说明每个配置项/单元所属的软件基线 详细说明在开发中将每个配置项/单元置于配置管理之下的时间点 标识每个配置项/单元的负责人

执行活动 等级2的一个关键过程区域——软件配置管理 活动4 可标识为配置项/单元的软件工作产品例子有： ——过程有关文档（计划、标准或规程） ——软件需求 ——软件设计 ——软件代码单元 ——软件测试规程 ——为软件测试所构造的软件系统 ——为交付给顾客或最终用户所构造的软件系统 ——编译程序 ——其它支持工具

等级2的一个关键过程区域——软件配置管理 执行活动 活动5 按照已文档化的规程，记录、评审、批准和跟踪所有配置项或单元的更改请求和问题报告

执行活动 等级2的一个关键过程区域——软件配置管理 活动6 按照已文档化的规程控制对基线的修改 该规程一般规定： 进行评审和回归测试以保证更改不会造成对基线未料到的影响 仅仅那些经SCCB批准的配置项/单元才能进入软件基线库 以能保证软件基线库的正确性的完整的方式进行配置项单元的登入和退出

执行活动 等级2的一个关键过程区域——软件配置管理 活动6 软件基线库登入和退出步骤： ——验证修改是经审定的 ——建立更改日志 ——保持一份更改拷贝 ——更新软件基线库 ——建立被取代的软件基线的档案

执行活动 等级2的一个关键过程区域——软件配置管理 活动7 按照已文档化的规程生成由软件基线库制造的产品并控制它们的发行。 该规程一般规定： SCCB审定由软件基线库制造的产品的生成 不论为外部使用或内部使用，由软件基线库制造的产品仅仅由软件基线库中的配置项或单元组成

执行活动 等级2的一个关键过程区域——软件配置管理 活动8 按照已文档化的规程记录配置项或单元的状态。 该规程一般规定： 足够详细的记录配置管理行动，使每个配置项/单元的内容和状态，都是清楚地并且能够恢复以前的版本 对每个配置项或单元维护其当前状态并保留其历史

执行活动 等级2的一个关键过程区域——软件配置管理 活动9 编制用文档记载SCM活动和软件基线内容的标准报告，并使受影响的组和个人可以使用它。 报告的例子有： ——SCCB会议记录 ——更改申请的摘要和状态 ——问题报告的摘要和状态 ——软件基线更改的摘要 ——配置项/单元的修改历史 ——软件基线状态 ——软件基线审结果

执行活动 等级2的一个关键过程区域——软件配置管理 活动10 按照已文档化的规程进行软件基线审计。 该规程一般规定： 为审计做好充分准备 评估软件基线的完整性 评审配置库管理系统的结构和设施 验证软件基线库内容的完备性和正确性 验证与适用的SCM标准和规程的符合性 向项目软件经理报告审计结果 跟踪得自审计的措施条款直至结束

测量和分析 等级2的一个关键过程区域——软件配置管理 测量1 进行测量并将测量结果用于确定SCM活动的状态。 测量的例子有： ——每单位时间处理的更改申请数 ——SCM活动的里程碑的完成情况与计划相比较 ——在SCM活动中所完成的工作、花费的工作量和消费 的资金

验证实施 等级2的一个关键过程区域——软件配置管理 验证1 高级管理者定期参与评审SCM活动

验证实施 等级2的一个关键过程区域——软件配置管理 评审和审计至少要检验 以下各组对SCM标准和规程的依照情况 SCM组 SCCB 软件工程组 其它软件——有关组 定期进行软件基线审计的情况

SCM实施需求 SCM实施 任何类型的配置项 唯一标识 对规则的支持 区分与合并 问题关系 历史 日志记录 版本控制 管理关系 报告产生 缺陷生命周期 变更控制 访问控制和安全 发行提示 发行管理 度量搜集 岗位职责 规程依照检验 分发和部署管理 产品制造管理

SCM实施 CM活动演进

SCM实施 关于软件工程管理 软件工程过程的建立和工程度量是软件工程管理的精髓

CMM软件过程财富概念 SCM实施 组织的软件过程财富 组织标准软件过程（包括软件过程体系结构和软件过程元素） 对批准使用的软件生存周期的描述 用于裁剪组织标准软件过程的指南和准则 组织的软件过程数据库 软件过程有关文档库

软件质量与SCM 软件质量与SCM 质量测量方法 Defect density Review rate Development time ratios Defect ratios Yield Defects per hour Defect removal leverage Appraisal to failure ratio (A/FR)

质量测量方法——Defect Density(缺陷密度) 软件质量与SCM 质量测量方法——Defect Density(缺陷密度) 定义：每千行新和修改的源代码中发现的缺陷数量 如果150行代码中有18个缺陷，那么缺陷密度为1000*18/150 = 120 defects/KLOC。 用途： 测量整个开发过程或某个开发阶段的缺陷分布情况

质量测量方法——Defect Density(示例) 软件质量与SCM 质量测量方法——Defect Density(示例) 图中可见，单元测试阶段发现的缺陷越少，代码质量就越高。 在PSP中，单元测试阶段缺陷密度低于5 defects/KLOC，被认为该程序具有很好的质量。 通常，经过PSP培训的软件开发人员，其测试阶段的缺陷密度范围为20 到 40 defects/KLOC。

质量测量方法——Review Rate（复查速度） 软件质量与SCM 质量测量方法——Review Rate（复查速度） 定义：软件工程师自己对所承担程序的设计和代码进行复查的速度。 当开发人员以高于每小时150到200行新增和修改代码速度复查设计和代码时，他们会漏掉很多缺陷。

质量测量方法——Development Time Ratios（开发时间比例） 软件质量与SCM 质量测量方法——Development Time Ratios（开发时间比例） 定义：指软件开发人员在两个开发阶段所化时间比。 PSP中，利用3种开发时间比进行过程控制计算 (1) 设计时间和编码时间比 (2) 设计复查时间和设计时间比 (3) 代码复查时间和编码时间比

软件质量与SCM 开发时间比例——设计时间和编码时间比 PSP的指导原则是软件开发人员应该使详细设计时间和编码时间大致相等。 设计时间和编码时间比用于反映开发工程师的设计工作质量，当软件开发人员花在设计上的时间短而花在编码上的时间特别长时，那么可以断定他在一边编程一边“想”设计，这往往导致没有设计文件，压根不可能对设计进行复查和回溯，更无从谈设计质量。

开发时间比例——设计复查时间和设计时间比 软件质量与SCM 开发时间比例——设计复查时间和设计时间比 从表中可以看出，软件开发人员在详细设计阶段每小时平均导入1.76 缺陷，而在设计复查阶段平均每小时发现2.96 缺陷。因此为了找出设计阶段导入的所有缺陷，花在设计复查上的时间至少是设计时间的59%。 PSP指导原则是软件工程师花在设计复查上的时间至少是设计所花时间的一半。

开发时间比例——代码复查时间和编码时间比 软件质量与SCM 开发时间比例——代码复查时间和编码时间比 编码阶段导入缺陷的平均速率为4.20 defects/小时，代码复查阶段发现缺陷的平均速率为6.52 defects/小时，按照这个数据，软件开发人员应该花在代码复查上的时间应该是编码时间的65%。 PSP的指导原则为50%。

质量测量方法——Defect Ratios（缺陷比） 软件质量与SCM 质量测量方法——Defect Ratios（缺陷比） 定义：开发某阶段缺陷数量和另外一阶段缺陷数量比 。 PSP中使用的缺陷比有： (1) 代码复查缺陷与编译缺陷比 (2) 设计复查缺陷与单元测试缺陷比 经验法则：代码复查缺陷与编译缺陷比=2； 设计复查缺陷与单元测试缺陷比大于2。

质量测量方法——缺陷比 软件质量与SCM 用途： (1) 代码复查缺陷与编译缺陷比反映编码质量 (1) 代码复查缺陷与编译缺陷比反映编码质量 (2) 设计复查缺陷与单元测试缺陷比反映设计质量 经验法则：这两项缺陷比有一项不达标，按照PSP质量标准，这个程序在以后的测试和使用中将带来麻烦。

质量测量方法——Yield（缺陷收益率） 软件质量与SCM 质量测量方法——Yield（缺陷收益率） PSP有两种缺陷收益率，开发阶段缺陷收益率和开发过程缺陷收益率，开发阶段缺陷收益率是指某开发阶段发现并修复的缺陷数与该阶段入口缺陷数百分比。开发过程缺陷收益率为在第一次编译和单元测试前修复的缺陷数百分比。 为了达到高质量程序目标，PSP建议过程缺陷收益率大于70%。

软件质量与SCM 质量测量方法——缺陷收益率 除非程序的使用周期已经结束，否则不可能准确地计算程序的缺陷收益率。但是，当程序具有相当的质量水平时，早期的收益率预测可以被推断出来。

软件质量与SCM 质量测量方法——缺陷收益率 开发过程缺陷收益率为（11+28）/65= 60.0%。

质量测量方法——Defects per Hour（缺陷速率） 软件质量与SCM 质量测量方法——Defects per Hour（缺陷速率） 定义：每小时导入和修复缺陷数量 使用缺陷速率可以指导开发计划的制定。 例如，假设一个软件工程师编码时的缺陷导入速度为4defects/hour，在代码复查阶段缺陷修复速率为8 defects/hour，那么他每花1小时的编码时间就需要花半小时对代码进行复查。

质量测量方法——Defect Removal Leverage (DRL)（缺陷排除杠杆） 软件质量与SCM 质量测量方法——Defect Removal Leverage (DRL)（缺陷排除杠杆） DRL反映的是不同开发阶段排除程序缺陷的效能比。 例如，前例中，设计复查和单元测试排除缺陷效能比为DRL = 2.96/2.21=1.34。 这表明该软件开发人员在排除缺陷方面，在设计复查阶段是单元测试阶段的1.34倍。 DRL有利于软件人员制定最有效的缺陷排除计划。

质量测量方法——A/FR（质量评价成本比） 软件质量与SCM 质量测量方法——A/FR（质量评价成本比） 定义：A代表质量评估成本，或者花在质量评估活动上的开发时间百分比； F代表质量失败成本，指产品失败复原和修复所花时间。 质量评估成本是指设计复查、代码复查以及复查阶段缺陷修复所花的时间； 失败成本是指编译、单元测试，包含差错、修复、重新编译以及对编译和测试中发现的缺陷重新测试所花时间。

软件质量与SCM 质量测量方法——质量评价成本比续 A/FR用途： 1）个人程序以及比较应用于不同程序的开发过程控制程序质量都起到很好的测量作用 2）A/FR指示出软件开发初期阶段软件开发人员在发现和修复缺陷方面所要达到的程度 PSP中，要求软件工程师在做计划时，A/FR值大于2，这就保证了他们在计划中为设计复查和代码复查留出足够的时间。

SCM实施 SCM流程图示例 The modify document process

SCM实施 SCM流程图示例 The identify agents for roles process

SCM实施 SCM流程图示例 The update document process

SCM文档模板 SCM实施 ENGINEERING CHANGE ORDER SOFTWARE CHANGE REPORT SOFTWARE CHANGE REQUEST SOFTWARE CONFIGURATION MANAGEMENT (SCM) PLAN