软件工程实践
汤铭端
中国航天科工集团公司 706所
第九讲
软件度量
需求管理
软件配置管理
内容和目的
? 了解软件度量的概念和内容
? 掌握需求管理的概念
? 了解需求管理的过程
? 掌握配置管理的概念
? 掌握配置管理的过程
软件度量
软件度量
? 理解软件度量
? 选择软件度量指标
? 度量计划步骤
软件度量的理解
? 项目规划时，需要评估项目规模和进度
等
? 项目跟踪时，需要明确实际的工作量和
时间与计划的对比情况
? 判断软件产品的稳定性时，需要明确发
现和纠正缺陷的速率
? 定量了解项目的进展，需要对当前项目
的绩效进行测量，并与基线进行比较
软件度量的定义
? 软件度量是软件中范围广泛的测度，让
你定量了解进度，工作量，产品规模，
项目状态以及质量性能，用于评估情况，
跟踪进展，评价效率。
度量类型
? 过程
? 项目
? 技术
过程中的度量
? 战略目的
? 进行连续的过程改进
项目中的度量
? 辅助估算
? 质量控制
? 生产率评估
? 项目控制
? 战术目标
技术中的度量
? 评估技术工作产品的质量
? 在项目中进行决策
作用
? 软件度量是为项目估算，计划的基础数
据
? 软件度量提供控制项目的量化信息
? 软件度量为质量管理提供指示
? 软件度量能推动企业的过程改进
度量成本
? 开始度量时设定度量底线：收集度量的
成本应与可获得的潜在利益相平衡
? 防止意外成本（后果）的发生
软件度量的困难
? 不一定认为度量是软件工程的必备要素
? 很难定义和收集度量，常常被忽视。
? 今天的数据是明天的历史数据
选择软件度量
? 开始实施时，选择一组数量少而且平衡
的度量，有助于企业达到目标
GQM:目标 -问题 -度量
? GQM是一个杰出的技术
? 用于选择适当度量来满足需求
GQM:步骤
1,首先选择几个项目或者几个机构的目标，
尽可能将目标叙述的可以量化、可以测
量。
2,对于每个目标，设想一下必须回答的问
题，看看是否达到目标
3,最后，确认必须回答每个问题的度量
目标,
? 一年内降低 50%维护成本
? 将进度估计的准确性实际提高到 10%以
内
? 将下一个项目的系统测试时间减少三个
星期
? 三个月内将消灭一个缺陷的时间减少
40%
问题
? 一年内降低 50%维护成本
? 每个月我们花在维护上的费用是多少?
? 花在我们支持的每个应用软件上的维护成本
是多少?
? 我们花在调整（调整以适应变更的环境）、
完善（增加、提高）和修正（纠正缺陷）上
的费用是多少？
度量
? 我们花在调整、完善和修正上的费用是
多少？
? 每类维护活动所花的时间
? 每类维护活动所花的时间内的总维护成本
平衡的度量组
? 产品规模
? 产品质量
? 过程质量
? 工作量
? 项目状态
? 客户满意度
SEI度量指标
SEI度量指标
? Process
? Effort
? Cost
? Quality
? SQA Audit Results
? Review Results
? Trouble Reports
? Peer Review Results
? Defect Prevention
? Stability
? Requirements
Stability
? Size Stability
? Process Stability
? Computer Resource
Utilization
? Training
项目的常用关键度量
?代码的行数
?及时完成的预定任务
?推迟完成的预定任务
?测试覆盖范围
?资源适合程度
?故障密度
?系统运行的可利用率
?推向市场的时间
?进度、质量和成本之间的折衷
度量对象
? 软件开发人员
? 软件项目组
? 软件机构
软件开发人员
? 工作量分布
? 任务持续时间和工作量的估计值和实际
值
? 单元测试覆盖的代码
? 单元测试发现的缺陷数目
? 代码和设计的复杂性
项目组
? 产品规模
? 工作量分布
? 需求状态 (批准的需求数，实现的需求数，核实的需求 )
? 通过测试的测试用例百分比
? 各主要里程碑之间相隔时间的估计值和实际值
? 人员水平的估计值和实际值
? 集成测试和系统测试中发现的缺陷数
? 检查发现的缺陷数
? 缺陷状态
? 需求的稳定性
? 计划任务数和完成任务数
机构组织
? 发布的缺陷水平
? 产品开发周期
? 估计准确度的进展计划和工作量
? 重新使用的有效性
? 计划成本和实际成本
数据的级别
? 成员级别
? 项目级别
? 机构级别
PSP的度量指标
? 项目计划度量
? 项目质量度量
项目 计划 实际 累计 累计百分比
总结
Minutes/LOC
LOC/Hour
Defects/KLOC
过程效益
A/FR
程序规模（ LOC）
新开发与更改的
最大值
最小值
开发时间
计划
设计
编吗
代码复查
编译
测试
后置处理
总计
最大值
最小值
项目计划总结表
项目计划总结表
项目 计划 实际 累计 累计百分比
引入的缺陷
计划
设计
编码
代码复查
编译
总计
排除的缺陷
计划
设计
编码
代码复查
编译
总计
项目规划度量 --个人统计
任务编号 任务名称 FP LOC 时间 类型
001 通讯模块 3 1000 5 编码
002 总体 10 设计
项目名称：教育信息平台 项目成员：张三 成员级别系数,1.2
项目规划度量 — 项目 统计
? （最好利用工具）统计出所有项目中各
个任务的度量值。
? 统计出项目中某一类任务的工作量值：
FP,LOC
? 统计出项目中某一类任务的规模（人天）
项目规划度量 — 项目 统计例子
? 项目的需求分析时间,50天
? 项目的需求规模,100人天
? 项目中任务 001的设计时间,10天
? 项目中任务 001的设计规模,15人天
? 项目中任务 001的编码时间,5天
? 项目中任务 001的测试时间,6天
? 项目中任务 001的编码规模,5人天
项目质量度量 --个人统计
任务编号 任务名称 类型 阶段 缺陷个数
001 通讯模块 接口 设计 3
002 成绩查询 语法 编码 6
003 招生管理 函数 测试 2
项目名称：教育信息平台 项目成员：李四 成员级别系数,0.8
项目质量度量 — 项 目统计
? 统计出所有项目中各个任务的度量值。
? 统计出某一类型缺陷的个数
? 统计出某一阶段缺陷的个数
? 统计出某一模块缺陷的个数
项目质量度量 — 项目 统计例子
? 项目的需求阶段的缺陷,6
? 项目的编码阶段的缺陷,100
? 项目中任务 001的缺陷数,20
? 项目中接口类缺陷数,20
开发度量计划的步骤
开发度量计划的步骤
1,标识目标
2,选择起步度量
3,明确工作活动
4,汇总历史数据
5,收集并分析度量,
6,决策中使用度量
1、标识目标
? 确定明确的标准目标
? 或者汇总一个基线
标识目标作用
? 让度量计划改善经营成果
? 执行严格定义、目标集中的计划以降低
成本
? 奠定改善软件投资回报的基础
2、选择起步度量
? 进度度量
? 需求度量
? 测试覆盖的百分数
? 软件规模
? 故障密度
? 故障发生解决率
? 项目整体风险度量
2.1进度度量
? 计算按期完成的任务数
? 推迟完成的任务数
? 重订进计划中的任务数
2.2需求度量
? 已经变更需求的百分数
? 新需求百分数
2.3测试覆盖的百分数
? 描述百分之几的代码已经经过测试了；
? 统计表明,
? 没有度量的测试只能测试代码的 50-60%
? 有有度量的测试可以推动代码测试覆盖率
2.4软件规模
? 代码行
? 功能点
? 人月数
2.5故障密度
? 软件质量的基本度量,每 KNCSS未解决的
故障数。
? 例如：产品发行标准,0.25故障 /
KNCSS
? 数据表明,7发现缺陷数 / KNCSS
2.6故障发生解决率
? 在一段固定时间内,发现并解决故障的数
目,是软件可以冻结的一个稳健机制。
? 软件冻结的条件：故障发生率和解决率
为 0
? 故障发生解决率可以判断测试阶段的完
成，有助于测试过多。
2.7项目整体风险度量
? 完成特定进度计划的可能性百分数
3、明确工作活动
? 度量需要的什么特定日期
? 谁负责收集度量数据
? 何时收集、何时报告度量
? 度量如何报告（状态报告、季度会议、
度量报告）
? 必要时可以赋予各种度量相应的优先级
4、汇总历史数据
? 已经完成的项目的度量数据
? 当前项目的历史数据
? 使用度量数据库
? 存储收集的度量数据
度量数据库原则
?数据库应当易于使用,人们才能方便地更新并报
告数据
?数据库应当灵活,
?数据库最好与其他工具有接口界面
?数据库与图形报告工具有接口界面,便于制作图
形和表格
?数据库足够大,以便包含更多的历史信息
?数据库避免重复
?数据库应注意安全
数据库类型
? 电子制表软件
? 商用数据库软件
5、收集并分析度量
? 收据度量数据
? 与既定的目标进行跟踪比较,
? 得出相应的结论
收集并分析度量的自动化
? 知识
? 纸面模板
? 电子数据表
? 预定义报告
? 软件工具
6、决策中使用度量
? 可以判断产品的推出程度
? 了解客户项目的成本和进度
? 在估计成本和进度时考虑多少偶然因素
? 过程改进中投资何处能得到最到的回报
? 何时开始用户培训
度量管理的注意事项
? 软件度量成为习惯
? 从小开始
? 解释为什么
? 分享数据
? 定义数据选项及其规程
? 理解趋势
需求管理
Requirements Management
需求工程
? 定义需求
? 获取需求
? 用户需求
? 系统需求
? 分析需求
? 规格说明
? 文档化需求
? 评审需求
? 管理需求
? 理解需求
? 保管需求
? 实现需求
? 控制需求
? 验证需求
需求管理的目的
? 需求管理 的目的是在顾客和将处理顾客
需求的软件项目之间建立对顾客需求的
共同理解。
需求管理的内容
? 需求管理 包括和顾客一起建立和维护有关软件
项目需求的协议，该协议称作“分配给软件的
系统需求”。
?,顾客”可解释为系统工程组、销售组、另一
个内部组织、或者一个外部顾客。
? 协议既包括技术需求、又包括非技术需求（例
如交付日期）。该协议形成估计、策划和跟踪
整个软件生存周期内软件项目活动的基础。
分配需求的形成
? 将系统需求分配给软件、硬件和其它系
统成分的工作可能由软件工程组之外的
组（例如系统工程组）完成，软件工程
组可能对此分配无直接控制。
? 在项目约束范围内，软件工程组采取恰
当步骤以保证对分配给软件的需求建档、
并加以控制，该组负责处理分配给软件
的系统需求。
需求管理的目标
? 目标 1 分配给软件的系统需求是受控的，
建立供软件工程和管理使用的基线。
? 目标 2 软件计划、产品和活动与分配给
软件的系统需求保持一致。
对分配需求建立文档
? 分配需求包括,
? 1,影响和确定软件项目活动的非技术性需求 （ 即,
协议, 条件, 和 （ 或 ） 合同条款 ）, 如 — 要交付的
产品, 交付日期, 里程碑 。
? 2,对软件的技术需求, 如最终用户, 操作员, 支
持, 或集成功能；性能要求；设计约束；编程语言；
界面需求 。
? 3,用于确认软件产品满足分配需求的验收准则 。
需求管理的过程要求（ 1）
? 活动 1 在分配需求被纳入软件项目之前, 软件
工程组评审它们 。
? 1,鉴别出不完整的和遗漏的分配需求 。
? 2,评审分配需求, 确定它们是否,
? 用软件来实现是可行的和恰当的,
? 被清晰和正确地阐述,
? 是相互一致的, 和
? 是可测试的 。
? 3,负责分析和分配系统需求的组评审任何被识别
出是有潜在问题的分配需求, 并作出必要的更改 。
? 4,和受到影响的组协商由分配需求引起的约定 。
需求管理的过程要求（ 2）
? 活动 2 软件工程组采用分配需求作为软件计划、
工作产品和活动的基础。分配需求,
? 1,被进行管理和控制。
?,进行管理和控制”意味着在给定时间（过去或现在）使
用的工作产品的版本是已知的（即版本控制），而且以受
控的方式引进更改（即更改控制）。
? 2,是软件开发计划的基础。
? 3,是制定软件需求的基础。
需求管理的过程要求（ 3）
? 活动 3 评审对分配需求的更改, 将其纳入软件
项目 。
? 1,评估它对现有约定的影响, 合适时协商更改 。
? 对组织外部的个人和组所作约定的更改由高级管理者参与
评审 。
? 和受到影响的组协商组织内部约定的更改 。
? 2,对由于分配需求的更改所造成的对软件计划,
工作产品和活动必须作的更改要加以,
? 识别, 评价, 风险评估, 文档化, 规划, 传达到受到影响
的组和个人, 跟踪直到结束 。
需求管理过程
? 任何项目都必须存在分配需求类文档
? 合同、任务书、立项报告、招标文件
? Kick Off 会议
? 项目组讨论（评审）分配需求
? 分配需求经批准后纳入配置管理
? 对涉及外部承诺、约定内容的更改严格控制
需求管理的工具,双向追溯矩阵
? 建立需求档案
? 检查需求的完成
? 设计
? 实现
? 检测
? 对相关的更改进行追踪
需求追溯矩阵
部件 1 部件 2 部件 3 部件 4 部件 5
需求 1 *
需求 2 * *
需求 3 * *
需求 4 *
需求 5 *
软件配置管理
SCM
Software Configuration Management
软件开发中存在的一些问题
? 文文不一致
? 文档和文档之间不一致
? 文实不一致
? 文档和程序之间不一致
? 程序版本不一致
? 无法连接、无法安装、无法形成特定产品
? 问题处理的混乱
软件开发中存在的一些问题
? 软件项目进行中面临的一个主要问题是
持续不断的变化
? 有效的项目管理能够控制变化，以最有
效的手段应对变化
? 不断命中移动的目标
配置 (Configuration)
? 一计算机系统或网络按照其功能部件的
特点、数量和主要特征而确定的排列。
具体地讲，配置一词可以指硬件装置或
软件装置。
? 为确定一系统或系统组成部分的特定版
本而提出的需求、设计和实现。
? 在技术文件中制定的并在产品中体现的
硬件、软件的功能和（或）物理特性。
软件配置
? 在软件工程过程中产生的所有信息项（文档、
报告、程序、表格、数据） 构成了软件配臵
? 软件配臵是软件的具体形态在某一时刻的瞬时
影像
? 随着软件工程过程的进展，软件的 配臵项 (CI)
数目快速增加
? 系统规格说明可繁衍出软件项目实施计划和
软件需求规格说明
? 它们又依次繁衍出建立信息层次的其它文档
对配置进行管理
? 对配置进行管理，也称, 技术状态管
理,,就是要在研制和维护阶段保证和
控制整个配置的完整性和一致性。
? 软件配置是软件产品在不同时期的组合。
也可看作是软件的具体形态在某时刻的
瞬时影像。
? 软件的配置项包括程序、文档、数据、
环境、规程等。
定义（ GB/T 11457-1995软件工程术语）
? 配置管理是指,
? 标识和确定系统中配置项的过程, 在系统整个生存
周期内控制这些项的投放和更动, 记录并报告配置
的状态和更动要求, 验证配置项的完整性和正确性
? 对下列工作进行技术和行政指导与监督的一套规范
? 对一配置项的功能和物理特性进行标识和文件编制工作；
? 控制这些特性的更动情况；
? 记录并报告对这些更动进行处理和实现的状态 。
? 软件配置管理既是一项管理工作也是一项技术
工作, 它在软件质量控制中是至关重要的 。
配置管理目标
? 标识变更
? 控制变更
? 确保变更正确实现
? 向其它有关的人报告变更
软件配置管理对需方的作用
? 保证开发, 操作和维护要求的完善；
? 在受控条件下能够作出改变这些要求的
灵活性；
? 建立 SCM活动和任务评价准则的基础；
? 完全和非完全 （ 工程发行 ） 项的补充 。
软件配置管理对开发方的作用
? 查找满足这些要求的项和借助控制改变；
? 通过提供附加在管理阶段的 SCIs（这些
情况中，生存周期过程中的主要软件产
品）的状况，支持联合评审过程；
? 通过集中符合性检查中可度量的结果，
支持审核过程；
? 支持质量保证、验证和确认过程，引伸
到它们在软件生存周期中存在的范围。
软件配置管理对技术人员的作用
? 这些基线能重建的具有保证的稳定基线；
? 状况的一致信息；
? 突出的要求的状况和相互依赖关系；
? 变化的通知、分析和撤消；
? 授权的变化机构；
? 处理、贮存、复制、打包和发行 SCIs的
一致性方法。
软件配置管理的基本术语
? 配置项计算机软件（ CSCI）
? （软件的）配置项（ CI）
? 基线
? 配置库
软件的配臵项 SCI
? 软件配臵管理的对象就是软件的配臵项 —— CI
? CI包括文档、程序、数据等
? 除此以外，还常把 配臵控制之下的软件工具 列
入其中，即 编辑程序, 编译程序, 其它 CASE
工具的特定版本
? 因为要使用这些工具来生成文档、程序和数据，如
果版本不同，可能产生的结果也不同
一般的 CI
? 系统规格说明
? 软件项目实施计划
? 软件需求说明
? 可执行的原型
? 初步的用户手册
? 设计规格说明
? 源代码清单
? 测试计划和过程、测试
用例和测试结果记录
? 操作和安装手册
? 可执行程序（可执行程
序模块、连接模块）
? 数据库描述（模式和文
件结构、初始内容）
? 正式的用户手册
? 维护文档（软件问题报
告、维护请求、工程变
更次序）
? 软件工程标准
? 项目开发总结
配臵对象
? 在实现 SCM时，把 CI组织成配臵对象,在配
臵库（项目数据库）中用一个 单一的名字来组
织它们
? 一个配臵对象有一个 名字 和一组 属性,并通过
某些联系“连接”到其它对象
? 每个对象与其它对象的联系用箭头表示，箭头
指明了一种构造关系
? 双向箭头则表明一种相互关系
? 如果对“源代码”作了一个变更，就可以根据这种
相互关系确定其它哪些 CI可能受到影响
配臵对象
基线 (Baseline)
? 基线是软件生存期中各开发阶段末尾的
特定点，又称里程碑。
? 由正式的技术评审而得到的 CI协议和软
件配臵的正式文本才能成为基线。
? 基线的 作用是把各阶段工作的划分更加
明确化,以便于检验和肯定阶段成果。
软件开发各阶段的基线
项目配臵库（数据库）
? 将 CI和基线存放到项目配臵库中
? 当项目成员想要 对基线中的 CI进行修改时, 把它
从项目配臵库中复制到该工程师的专用工作区中
? 例如把一个 名为 B的 CI从项目配臵库复制到工
程师的专用工作区中
? 工程师在 B'（ B的副本）上完成要求的变更, 再
用 B'来更新 B
? 有些系统中把更改中的这个基线中的 CI锁定
? 在变更完成、评审和批准之前，不许对它做任何
操作
基线 CI和项目配臵（数据）库
配置管理过程 （ ISO12207）
? 配置管理过程是在整个软件生存周期中
实施管理和技术规程的过程，它
? 标识、定义系统中的软件项并指定基线；
? 控制软件项的修改和发行；
? 记录和报告软件项的状态和修改申请；
? 保证软件项的完整性、协调性和正确性；
? 以及控制软件项的储存、处理和交付。
配置管理过程活动
? 软件配置管理主要有以下的基本活动,
? 过程实施
? 配置标识
? 配置控制
? 配置状态统计
? 配置审计
? 发行管理和交付
过程实施
? 编制配置管理计划。描述,
? 配置管理活动；
? 为实施这些活动采用的规程和进度安排；
? 负责实施这些活动的组织，以及它们和
其他组织的关系。
过程实施规程
1 启动和定义范围
1.1 定义 SCM过程的输入
1.2 定义 SCM过程的资源和限制
1.3 分配职责和权利
1.4 SCIs的选择准则
1.5 定义 SCM过程的输出
2 计划
3 控制执行
4 SCM过程的评审和评价
5 结束
软件配置标识
? 应确定一个方案，来标识一个项目需加
控制的软件项及其版本。
? 对于每一软件项及其版本，应标识下述
内容,
? 建立基线的文档；
? 版本引用号；
? 以及其他标识细节。
软件配置标识规程
1 标识 SCIs
2 标识软件配置基线
3 标识软件库
4 进程状态
配臵标识
? 随着软件生存期的向前推进 CI的数
量不断增多
? 整个软件生存期的 软件配臵就象一
部不断演变的电影,而某一时刻的
配臵就是这部电影的一个片段
? 为了方便 对软件配臵的各个片段
（ CI） 进行控制和管理,不致造成
混乱，首先应给它们 命名
对象类型
? 基本对象, 是由软件工程师在分析、设
计、编码和测试时所建立的 文本单元 。
例如，基本对象可能是需求规格说明中
的一节，一个模块的源程序清单、一组
用来测试一个等价类的测试用例
? 复合对象, 是基本对象或其它复合对象
的 一个收集
配臵项标识
? （名字、描述、资源、实现）
? 名字 明确地标识 CI
? 描述 包括,CI类型 （如文档、程序、数
据）,项目标识, 变更 和／或 版本信息
? 资源 包括：由 CI产生的, 处理的, 引用
的 或 其它需要 的 一些实体
? 基本对象的实现 是 指向 文本单元 的指针,
复合对象的实现为 null
命名对象之间的联系
? 对象的层次关系,一个对象可以是一个复合对象的一
个组成部分，用联系 < is part of >标识 以建立 CI的一个
层次,
E-R diagram 1.4 < is part of > data model;
data model < is part of > Design Specification;
? 对象的相互关联关系,对象跨越对象层次的分支相互
关联。这些交叉的结构联系表达方式如下,
data model <interrelated> data flow model;
(两个复合对象之间的相互联系 )
data model <interrelated> test case class m;
(一个复合对象与一个特定的基本对象之间的相互联系）
演变图
? 整个软件工程过程中所涉及的软件对象都必须加
以标识
? 在对象成为基线以前可能要做多次变更，在成为
基线之后也可能需要频繁地变更
? 对于每一配臵对象都可以建立一个演变图,用演
变图记叙对象的 变更历史
? 在某些工具中，当前保持的 只是最后版本的完全
副本
? 为了得到较早时期 (文档或程序 )的版本，可以从最
后版本中,提取”出 (由工具编目的 )变更,使得 当
前配臵直接可用,并使得 其它版本也可用 。
演变图
软件配置控制
? 应标识和记录更改申请；
? 分析和评价更改；
? 批准或不批准申请；
? 实现、验证和发行已修改的软件项。
? 应对每次修改进行审核跟踪、可以跟踪修改的
原因和修改的授权。
? 应对所有访问受控软件项的情况进行控制和审
核，以保证关键功能的安全和保密安全。
软件配置控制规程
1 提议变更
2 评价提议的变更的影响
3 实现变更
4 交流处置
5 结束变更
软件配置控制的主要内容
? 更改控制
? 版本控制
变更控制
? 软件开发中全部的软件配臵是软件产品
的真正代表,必须使其保持 精确
? 软件工程过程中 某一阶段的变更,均要
引起软件配臵的变更,这种变更必须严
格加以 控制 和 管理,保持修改信息
? 变更控制包括 建立控制点 和 建立报告与
审查制度
变
更
控
制
过
程
变更过程
? 首先用户提交书面的变更请求，详细申明变更的理由、变
更方案、变更的影响范围等
? 然后由变更控制机构确定控制变更的机制、评价其技术价
值、潜在的副作用、对其它配臵对象和系统功能的综合影
响以及项目的开销、并把评价的结果以变更报告的形式提
交给变更控制负责人（最终决定变更状态和优先权的某个
人或小组）
? 对批准的变更产生一个工程变更指令（ ECO），描述进行
的变更、必须考虑的约束、评审和审计的准则等
? 要做变更 CI从项目数据库中检出（ check out），对其做出变
更，并实施适当的质量保证活动。然后再把 CI登入（ check
in）到数据库中并使用适当的版本控制机制建立软件的下一
版本
软件变更有两类不同情况
? 为改正小错误需要的变更
? 为了增加或者删掉某些功能、或者为了
改变完成某个功能的方法而需要的变更
改错变更
? 它是必须进行的，通常不需要从管理角
度对这类变更进行审查和批准。
? 但是，如果发现错误的阶段在造成错误
的阶段的后面，例如在实现阶段发现了
设计错误，则必须遵照标准的变更控制
过程，把这个变更正式记入文档，把所
有受这个变更影响的文档都做相应的修
改。
增删功能变更
? 这类变更必须经过某种正式的变更评价过程，以估计
变更需要的成本和它对软件系统其它部分的影响
? 如果变更的代价比较小且对软件系统其它部分没有
影响，或影响很小，通常应批准这个变更。
? 如果变更的代价比较高，或者影响比较大，则必须权衡利弊，
以决定是否进行这种变更。
? 如果同意这种变更,需要进一步确定由谁来支
付变更所需要的费用。 如果是用户要求的变更，
则用户应支付这笔费用；否则，必须完成某种
成本／效益分析，以确定是否值得做这种变更。
变更控制的作用
? 这种变更报告和审查制度，对变更控制
来说起了一个安全保证作用。
? 在一个 CI成为基线之前，可以对所有合
理的项目和技术申请进行非正式的变更；
? 一旦某个 CI经过正式的技术评审并得到
批准，它就成了基线。以后如果需要对
它变更，就必须得到项目负责人的批准，
或者必须得到变更控制负责人的批准。
版本控制
? 版本控制是 SCM的基础，它管理并保护
开发者的软件资源。
? 版本控制管理在软件工程过程中建立起
配臵对象的不同版本 。
? 版本管理可以把 一些属性结合到各个软
件版本 上。
? 通过 描述所希望的属性集合 来 确定 （或
构造 ） 所想要的配臵 。
? 使用 演变图 来表示系统的不同版本。
演变图说明
? 图中的各个结点都是 聚合对象,是一个 完全的
软件版本 。
? 软件的每一版本都是 CI（源代码、文档、数据）
的一个收集,且各个版本都可能由不同的变种
组成。
? 例如，一个简单的程序版本由 1,2,3,4和 5
等部件组成。其中 部件 4在软件 使用彩色显示
器 时使用,部件 5在软件 使用单色显示器 时使
用。因此，可以定义版本的两个变种。
版本管理的主要任务
? 集中管理档案，安全授权机制
? 软件版本升级管理
集中管理档案，安全授权机制
? 版本管理的操作 将开发组的档案集中地
存放在服务器上, 经系统管理员授权给
各个用户 。
? 用户通过登入（ check in）和检出
（ check out）的方式访问服务器上的文
件，未经授权的用户无法访问服务器上
的文件。
软件版本升级管理
? 每次登入时，在服务器上都会生
成新的版本。
? 任何版本都可以随时检出编辑，
同一应用的不同版本可以像树枝
一样向上增长。
加锁功能
? 目的是 在文件更新时保护文件, 避
免不同用户更改同一文件时发生冲
突 。
? 某一文件一旦被 登入, 锁即被解除,
该文件可被其它用户使用。
? 在 更新一个文件之前锁定它,避免
变更没有锁定的项目源文件。
合理使用登入和检出
? 当需要修改某个小缺陷时，应 只检出完成工作必需的
最少文件 ；
? 需要对文件变更时，应登入它并 加锁, 保留对每个变
更的记录 ；
? 应避免长时间地锁定文件。如果需要长时间工作于某
个文件，最好能 创建一个分支,并在分支上做工作。
? 如果需要做较大的变更，可有两种选择,
a.将需要的所有文件检出并加锁，然后正常处理 ；
b.为需要修改的所有分支创建分支，把变更与主干,脱机,，然
后把结果合并回去。
软件配置状态统计
? 应编制管理记录和状态报告，表明受控
软件项的包括基线在内的状态和历史。
? 状态报告应包括某一项目的更改号码，
最新的软件项版本，发行标识，版本号
数，以及各版本的比较。
软件配置状态统计规程
1 记录标识
2 追踪变更
3 汇报状态统计记录
? 软件产品的结构；
? 每个 SCI在接受意义层次的状态；
? 任何被提议的变更的状态；
? 被批准的更改和基线版本；
? 发行的标识。
配臵状态报告
? 为了清楚、及时地记载软件配臵的变化，
需要 对开发的过程做出系统的记录,以
反映开发活动的历史情况。这就是配臵
状态登录的任务。
? 登录主要 根据变更控制小组会议的记录,
并产生 配臵状态报告 。
? 对于每一项变更，记录：发生了什么？
为什么会发生？谁做的？什么时侯发生
的？会有什么影响？
配臵状态报告信息流
配臵状态报告内容
? 每次 新分配一个 CI，或 更新一个已有 CI的标识,或 一
项变更申请被变更控制负责人批准, 并给出了一个工
程变更顺序 时,在配臵状态报告中就要增加一条变更
记录条目。
? 一旦进行了配臵审计，其结果也应该写入报告之中。
? 配臵状态报告可以放在一个联机数据库中，以便软件
开发人员或者软件维护人员可以对它进行查询或修改。
此外在软件配臵报告中新登录的变更应当及时通知给
管理人员和软件工程师。
? 配臵状态报告对于大型软件开发项目的成功起着至关
重要的作用。避免了可能出现的不一致 和冲突。
软件配置评价
? 应确定和保证下述事项,
? 软件项按其要求的功能完整性
? 软件项的物理完整性（不管他们的设计
和编码是否反映最新技术描述）。
软件配置评价要求
? SCM配置评价确定,
? 控制库中贮存的 SCIs符合 SCM记录；
? 就写到的 SCIs和批准的修改的状态（软件产品按此
构造）而言，软件产品是完全的和可利用的；
? 基线 SCIs由相关的 SCIs和相应的批准的修改组成；
? 应支持验证和审核过程以确保被评价的 SCIs、基线和
软件产品的完全性。
? 应执行配置评价以确定组建基线的 SCIs被贮存和保护。
? 应报告配置评价结果。
? 发现异态时，应实施问题解决或过程改进过程。
配臵审计
? 软件配臵审计的目的就是要
? 证实整个软件生存期中各项产品在技
术上和管理上的完整性。
? 确保所有文档的内容变动不超出当初
确定的软件要求范围。使得软件配臵
具有良好的可跟踪性。
? 软件的完整性 是指开发后期的 软件
产品能够正确地反映用户要求
软件配置审计
? 软件配臵审计是软件变更控制人员
掌握配臵情况, 进行审批的依据
? 软件的变更控制机制通常只能跟踪
到工程变更顺序产生为止。为确认
变更是否正确完成,一般可以用以
下两种方法去审查,
? 正式技术评审
? 软件配臵审计
审计内容
? 正式的技术评审 着重 检查已完成修改的软件配
臵对象的技术正确性
? 评审者 评价 CI，决定它与其它 CI的一致性，是
否有遗漏或可能引起的副作用
? 正式技术评审应对所有的变更进行，除了那些
最无价值的变更之外
? 软件配臵审计 作为正式技术评审的补充,评价
在评审期间通常没有被考虑的 CI的特性
软件发行管理和交付
? 应有效控制软件产品和文档的发行和交
付。
? 在软件产品的生存期内应保持代码和文
档的母拷贝。
? 包含安全或保密安全关键功能的代码和
文档按照有关组织的方针加以处理、储
存、包装和交付。
软件发行管理和交付规程
1 处理
? SCM过程应控制所有的发行管理和交付中的输入和输出。
? 保留先期版本确保从基线库中发行的 SCIs 是重新可配置的。
? SCM过程应能重建软件环境。
2 贮存
? 应确保贮存的 SCIs的完整性，与媒体或库的无关,
a)选择贮存的介质使再生错误和变坏最小化；
b)以媒介的贮存期兼容的频次，运行或刷新被存档的 SCIs；
c)在受控环境贮存复制的拷贝以达到损耗风险的最小化；
3 复制
? 应建立规程以确保一致的和完全的复制。
? 应确保发行不含无关项的媒体（如软件病毒）。
? 应使用合适的媒体以确保软件产品复制。
4 打包
5 交付
接口控制
? 应标识和控制接口（如硬件、系统软件、支持软件、一体化的现货产品，
和并行的 /并发开发的软件产品）文档。
? 接口可由相互的协议所调整（例如被软件综合者和子承包软件开发商）
或由一方限定（例如，允许复制产品的现货软件产品的供应商）。
? 应标识,
a)接口用途；
b)接口处要求；
c)受影响的组织；
d)已被控制的接口文档；
e)通知影响接口的提议改变的其他人，以及一起或分别进行接口影响的
评价的规程；
f) 批准、变更和发行的接口文档的规程，包括接口变更机构；
g)把接口文档的变更转换成其他 SCIs的变更的规程；
h)角色和职责。
注意事项
以下几个事项应在进行配置管理工作时给予注意。
1） 配置管理设备应做到专机专用, 以杜绝计算机病
毒 。
2） 存放在磁媒体 （ 如软盘 ） 中的信息, 应每隔一段
时间 （ 如半年 ） 就进行一次拷贝翻新, 以防失效 。
3） 配置项入, 出库应特别注意校验, 以保证一致性 。
4） 软件的运行环境 （ 如操作系统 ）, 开发环境, 支
持软件 （ 如编译软件, 数据库生成系统 ） 都是配
置管理应管理的内容 。
谢谢！
汤铭端
010-68389085（ O） 68215365（ Fax）
mdtang@btamail.net.cn
汤铭端
中国航天科工集团公司 706所
第九讲
软件度量
需求管理
软件配置管理
内容和目的
? 了解软件度量的概念和内容
? 掌握需求管理的概念
? 了解需求管理的过程
? 掌握配置管理的概念
? 掌握配置管理的过程
软件度量
软件度量
? 理解软件度量
? 选择软件度量指标
? 度量计划步骤
软件度量的理解
? 项目规划时，需要评估项目规模和进度
等
? 项目跟踪时，需要明确实际的工作量和
时间与计划的对比情况
? 判断软件产品的稳定性时，需要明确发
现和纠正缺陷的速率
? 定量了解项目的进展，需要对当前项目
的绩效进行测量，并与基线进行比较
软件度量的定义
? 软件度量是软件中范围广泛的测度，让
你定量了解进度，工作量，产品规模，
项目状态以及质量性能，用于评估情况，
跟踪进展，评价效率。
度量类型
? 过程
? 项目
? 技术
过程中的度量
? 战略目的
? 进行连续的过程改进
项目中的度量
? 辅助估算
? 质量控制
? 生产率评估
? 项目控制
? 战术目标
技术中的度量
? 评估技术工作产品的质量
? 在项目中进行决策
作用
? 软件度量是为项目估算，计划的基础数
据
? 软件度量提供控制项目的量化信息
? 软件度量为质量管理提供指示
? 软件度量能推动企业的过程改进
度量成本
? 开始度量时设定度量底线：收集度量的
成本应与可获得的潜在利益相平衡
? 防止意外成本（后果）的发生
软件度量的困难
? 不一定认为度量是软件工程的必备要素
? 很难定义和收集度量，常常被忽视。
? 今天的数据是明天的历史数据
选择软件度量
? 开始实施时，选择一组数量少而且平衡
的度量，有助于企业达到目标
GQM:目标 -问题 -度量
? GQM是一个杰出的技术
? 用于选择适当度量来满足需求
GQM:步骤
1,首先选择几个项目或者几个机构的目标，
尽可能将目标叙述的可以量化、可以测
量。
2,对于每个目标，设想一下必须回答的问
题，看看是否达到目标
3,最后，确认必须回答每个问题的度量
目标,
? 一年内降低 50%维护成本
? 将进度估计的准确性实际提高到 10%以
内
? 将下一个项目的系统测试时间减少三个
星期
? 三个月内将消灭一个缺陷的时间减少
40%
问题
? 一年内降低 50%维护成本
? 每个月我们花在维护上的费用是多少?
? 花在我们支持的每个应用软件上的维护成本
是多少?
? 我们花在调整（调整以适应变更的环境）、
完善（增加、提高）和修正（纠正缺陷）上
的费用是多少？
度量
? 我们花在调整、完善和修正上的费用是
多少？
? 每类维护活动所花的时间
? 每类维护活动所花的时间内的总维护成本
平衡的度量组
? 产品规模
? 产品质量
? 过程质量
? 工作量
? 项目状态
? 客户满意度
SEI度量指标
SEI度量指标
? Process
? Effort
? Cost
? Quality
? SQA Audit Results
? Review Results
? Trouble Reports
? Peer Review Results
? Defect Prevention
? Stability
? Requirements
Stability
? Size Stability
? Process Stability
? Computer Resource
Utilization
? Training
项目的常用关键度量
?代码的行数
?及时完成的预定任务
?推迟完成的预定任务
?测试覆盖范围
?资源适合程度
?故障密度
?系统运行的可利用率
?推向市场的时间
?进度、质量和成本之间的折衷
度量对象
? 软件开发人员
? 软件项目组
? 软件机构
软件开发人员
? 工作量分布
? 任务持续时间和工作量的估计值和实际
值
? 单元测试覆盖的代码
? 单元测试发现的缺陷数目
? 代码和设计的复杂性
项目组
? 产品规模
? 工作量分布
? 需求状态 (批准的需求数，实现的需求数，核实的需求 )
? 通过测试的测试用例百分比
? 各主要里程碑之间相隔时间的估计值和实际值
? 人员水平的估计值和实际值
? 集成测试和系统测试中发现的缺陷数
? 检查发现的缺陷数
? 缺陷状态
? 需求的稳定性
? 计划任务数和完成任务数
机构组织
? 发布的缺陷水平
? 产品开发周期
? 估计准确度的进展计划和工作量
? 重新使用的有效性
? 计划成本和实际成本
数据的级别
? 成员级别
? 项目级别
? 机构级别
PSP的度量指标
? 项目计划度量
? 项目质量度量
项目 计划 实际 累计 累计百分比
总结
Minutes/LOC
LOC/Hour
Defects/KLOC
过程效益
A/FR
程序规模（ LOC）
新开发与更改的
最大值
最小值
开发时间
计划
设计
编吗
代码复查
编译
测试
后置处理
总计
最大值
最小值
项目计划总结表
项目计划总结表
项目 计划 实际 累计 累计百分比
引入的缺陷
计划
设计
编码
代码复查
编译
总计
排除的缺陷
计划
设计
编码
代码复查
编译
总计
项目规划度量 --个人统计
任务编号 任务名称 FP LOC 时间 类型
001 通讯模块 3 1000 5 编码
002 总体 10 设计
项目名称：教育信息平台 项目成员：张三 成员级别系数,1.2
项目规划度量 — 项目 统计
? （最好利用工具）统计出所有项目中各
个任务的度量值。
? 统计出项目中某一类任务的工作量值：
FP,LOC
? 统计出项目中某一类任务的规模（人天）
项目规划度量 — 项目 统计例子
? 项目的需求分析时间,50天
? 项目的需求规模,100人天
? 项目中任务 001的设计时间,10天
? 项目中任务 001的设计规模,15人天
? 项目中任务 001的编码时间,5天
? 项目中任务 001的测试时间,6天
? 项目中任务 001的编码规模,5人天
项目质量度量 --个人统计
任务编号 任务名称 类型 阶段 缺陷个数
001 通讯模块 接口 设计 3
002 成绩查询 语法 编码 6
003 招生管理 函数 测试 2
项目名称：教育信息平台 项目成员：李四 成员级别系数,0.8
项目质量度量 — 项 目统计
? 统计出所有项目中各个任务的度量值。
? 统计出某一类型缺陷的个数
? 统计出某一阶段缺陷的个数
? 统计出某一模块缺陷的个数
项目质量度量 — 项目 统计例子
? 项目的需求阶段的缺陷,6
? 项目的编码阶段的缺陷,100
? 项目中任务 001的缺陷数,20
? 项目中接口类缺陷数,20
开发度量计划的步骤
开发度量计划的步骤
1,标识目标
2,选择起步度量
3,明确工作活动
4,汇总历史数据
5,收集并分析度量,
6,决策中使用度量
1、标识目标
? 确定明确的标准目标
? 或者汇总一个基线
标识目标作用
? 让度量计划改善经营成果
? 执行严格定义、目标集中的计划以降低
成本
? 奠定改善软件投资回报的基础
2、选择起步度量
? 进度度量
? 需求度量
? 测试覆盖的百分数
? 软件规模
? 故障密度
? 故障发生解决率
? 项目整体风险度量
2.1进度度量
? 计算按期完成的任务数
? 推迟完成的任务数
? 重订进计划中的任务数
2.2需求度量
? 已经变更需求的百分数
? 新需求百分数
2.3测试覆盖的百分数
? 描述百分之几的代码已经经过测试了；
? 统计表明,
? 没有度量的测试只能测试代码的 50-60%
? 有有度量的测试可以推动代码测试覆盖率
2.4软件规模
? 代码行
? 功能点
? 人月数
2.5故障密度
? 软件质量的基本度量,每 KNCSS未解决的
故障数。
? 例如：产品发行标准,0.25故障 /
KNCSS
? 数据表明,7发现缺陷数 / KNCSS
2.6故障发生解决率
? 在一段固定时间内,发现并解决故障的数
目,是软件可以冻结的一个稳健机制。
? 软件冻结的条件：故障发生率和解决率
为 0
? 故障发生解决率可以判断测试阶段的完
成，有助于测试过多。
2.7项目整体风险度量
? 完成特定进度计划的可能性百分数
3、明确工作活动
? 度量需要的什么特定日期
? 谁负责收集度量数据
? 何时收集、何时报告度量
? 度量如何报告（状态报告、季度会议、
度量报告）
? 必要时可以赋予各种度量相应的优先级
4、汇总历史数据
? 已经完成的项目的度量数据
? 当前项目的历史数据
? 使用度量数据库
? 存储收集的度量数据
度量数据库原则
?数据库应当易于使用,人们才能方便地更新并报
告数据
?数据库应当灵活,
?数据库最好与其他工具有接口界面
?数据库与图形报告工具有接口界面,便于制作图
形和表格
?数据库足够大,以便包含更多的历史信息
?数据库避免重复
?数据库应注意安全
数据库类型
? 电子制表软件
? 商用数据库软件
5、收集并分析度量
? 收据度量数据
? 与既定的目标进行跟踪比较,
? 得出相应的结论
收集并分析度量的自动化
? 知识
? 纸面模板
? 电子数据表
? 预定义报告
? 软件工具
6、决策中使用度量
? 可以判断产品的推出程度
? 了解客户项目的成本和进度
? 在估计成本和进度时考虑多少偶然因素
? 过程改进中投资何处能得到最到的回报
? 何时开始用户培训
度量管理的注意事项
? 软件度量成为习惯
? 从小开始
? 解释为什么
? 分享数据
? 定义数据选项及其规程
? 理解趋势
需求管理
Requirements Management
需求工程
? 定义需求
? 获取需求
? 用户需求
? 系统需求
? 分析需求
? 规格说明
? 文档化需求
? 评审需求
? 管理需求
? 理解需求
? 保管需求
? 实现需求
? 控制需求
? 验证需求
需求管理的目的
? 需求管理 的目的是在顾客和将处理顾客
需求的软件项目之间建立对顾客需求的
共同理解。
需求管理的内容
? 需求管理 包括和顾客一起建立和维护有关软件
项目需求的协议，该协议称作“分配给软件的
系统需求”。
?,顾客”可解释为系统工程组、销售组、另一
个内部组织、或者一个外部顾客。
? 协议既包括技术需求、又包括非技术需求（例
如交付日期）。该协议形成估计、策划和跟踪
整个软件生存周期内软件项目活动的基础。
分配需求的形成
? 将系统需求分配给软件、硬件和其它系
统成分的工作可能由软件工程组之外的
组（例如系统工程组）完成，软件工程
组可能对此分配无直接控制。
? 在项目约束范围内，软件工程组采取恰
当步骤以保证对分配给软件的需求建档、
并加以控制，该组负责处理分配给软件
的系统需求。
需求管理的目标
? 目标 1 分配给软件的系统需求是受控的，
建立供软件工程和管理使用的基线。
? 目标 2 软件计划、产品和活动与分配给
软件的系统需求保持一致。
对分配需求建立文档
? 分配需求包括,
? 1,影响和确定软件项目活动的非技术性需求 （ 即,
协议, 条件, 和 （ 或 ） 合同条款 ）, 如 — 要交付的
产品, 交付日期, 里程碑 。
? 2,对软件的技术需求, 如最终用户, 操作员, 支
持, 或集成功能；性能要求；设计约束；编程语言；
界面需求 。
? 3,用于确认软件产品满足分配需求的验收准则 。
需求管理的过程要求（ 1）
? 活动 1 在分配需求被纳入软件项目之前, 软件
工程组评审它们 。
? 1,鉴别出不完整的和遗漏的分配需求 。
? 2,评审分配需求, 确定它们是否,
? 用软件来实现是可行的和恰当的,
? 被清晰和正确地阐述,
? 是相互一致的, 和
? 是可测试的 。
? 3,负责分析和分配系统需求的组评审任何被识别
出是有潜在问题的分配需求, 并作出必要的更改 。
? 4,和受到影响的组协商由分配需求引起的约定 。
需求管理的过程要求（ 2）
? 活动 2 软件工程组采用分配需求作为软件计划、
工作产品和活动的基础。分配需求,
? 1,被进行管理和控制。
?,进行管理和控制”意味着在给定时间（过去或现在）使
用的工作产品的版本是已知的（即版本控制），而且以受
控的方式引进更改（即更改控制）。
? 2,是软件开发计划的基础。
? 3,是制定软件需求的基础。
需求管理的过程要求（ 3）
? 活动 3 评审对分配需求的更改, 将其纳入软件
项目 。
? 1,评估它对现有约定的影响, 合适时协商更改 。
? 对组织外部的个人和组所作约定的更改由高级管理者参与
评审 。
? 和受到影响的组协商组织内部约定的更改 。
? 2,对由于分配需求的更改所造成的对软件计划,
工作产品和活动必须作的更改要加以,
? 识别, 评价, 风险评估, 文档化, 规划, 传达到受到影响
的组和个人, 跟踪直到结束 。
需求管理过程
? 任何项目都必须存在分配需求类文档
? 合同、任务书、立项报告、招标文件
? Kick Off 会议
? 项目组讨论（评审）分配需求
? 分配需求经批准后纳入配置管理
? 对涉及外部承诺、约定内容的更改严格控制
需求管理的工具,双向追溯矩阵
? 建立需求档案
? 检查需求的完成
? 设计
? 实现
? 检测
? 对相关的更改进行追踪
需求追溯矩阵
部件 1 部件 2 部件 3 部件 4 部件 5
需求 1 *
需求 2 * *
需求 3 * *
需求 4 *
需求 5 *
软件配置管理
SCM
Software Configuration Management
软件开发中存在的一些问题
? 文文不一致
? 文档和文档之间不一致
? 文实不一致
? 文档和程序之间不一致
? 程序版本不一致
? 无法连接、无法安装、无法形成特定产品
? 问题处理的混乱
软件开发中存在的一些问题
? 软件项目进行中面临的一个主要问题是
持续不断的变化
? 有效的项目管理能够控制变化，以最有
效的手段应对变化
? 不断命中移动的目标
配置 (Configuration)
? 一计算机系统或网络按照其功能部件的
特点、数量和主要特征而确定的排列。
具体地讲，配置一词可以指硬件装置或
软件装置。
? 为确定一系统或系统组成部分的特定版
本而提出的需求、设计和实现。
? 在技术文件中制定的并在产品中体现的
硬件、软件的功能和（或）物理特性。
软件配置
? 在软件工程过程中产生的所有信息项（文档、
报告、程序、表格、数据） 构成了软件配臵
? 软件配臵是软件的具体形态在某一时刻的瞬时
影像
? 随着软件工程过程的进展，软件的 配臵项 (CI)
数目快速增加
? 系统规格说明可繁衍出软件项目实施计划和
软件需求规格说明
? 它们又依次繁衍出建立信息层次的其它文档
对配置进行管理
? 对配置进行管理，也称, 技术状态管
理,,就是要在研制和维护阶段保证和
控制整个配置的完整性和一致性。
? 软件配置是软件产品在不同时期的组合。
也可看作是软件的具体形态在某时刻的
瞬时影像。
? 软件的配置项包括程序、文档、数据、
环境、规程等。
定义（ GB/T 11457-1995软件工程术语）
? 配置管理是指,
? 标识和确定系统中配置项的过程, 在系统整个生存
周期内控制这些项的投放和更动, 记录并报告配置
的状态和更动要求, 验证配置项的完整性和正确性
? 对下列工作进行技术和行政指导与监督的一套规范
? 对一配置项的功能和物理特性进行标识和文件编制工作；
? 控制这些特性的更动情况；
? 记录并报告对这些更动进行处理和实现的状态 。
? 软件配置管理既是一项管理工作也是一项技术
工作, 它在软件质量控制中是至关重要的 。
配置管理目标
? 标识变更
? 控制变更
? 确保变更正确实现
? 向其它有关的人报告变更
软件配置管理对需方的作用
? 保证开发, 操作和维护要求的完善；
? 在受控条件下能够作出改变这些要求的
灵活性；
? 建立 SCM活动和任务评价准则的基础；
? 完全和非完全 （ 工程发行 ） 项的补充 。
软件配置管理对开发方的作用
? 查找满足这些要求的项和借助控制改变；
? 通过提供附加在管理阶段的 SCIs（这些
情况中，生存周期过程中的主要软件产
品）的状况，支持联合评审过程；
? 通过集中符合性检查中可度量的结果，
支持审核过程；
? 支持质量保证、验证和确认过程，引伸
到它们在软件生存周期中存在的范围。
软件配置管理对技术人员的作用
? 这些基线能重建的具有保证的稳定基线；
? 状况的一致信息；
? 突出的要求的状况和相互依赖关系；
? 变化的通知、分析和撤消；
? 授权的变化机构；
? 处理、贮存、复制、打包和发行 SCIs的
一致性方法。
软件配置管理的基本术语
? 配置项计算机软件（ CSCI）
? （软件的）配置项（ CI）
? 基线
? 配置库
软件的配臵项 SCI
? 软件配臵管理的对象就是软件的配臵项 —— CI
? CI包括文档、程序、数据等
? 除此以外，还常把 配臵控制之下的软件工具 列
入其中，即 编辑程序, 编译程序, 其它 CASE
工具的特定版本
? 因为要使用这些工具来生成文档、程序和数据，如
果版本不同，可能产生的结果也不同
一般的 CI
? 系统规格说明
? 软件项目实施计划
? 软件需求说明
? 可执行的原型
? 初步的用户手册
? 设计规格说明
? 源代码清单
? 测试计划和过程、测试
用例和测试结果记录
? 操作和安装手册
? 可执行程序（可执行程
序模块、连接模块）
? 数据库描述（模式和文
件结构、初始内容）
? 正式的用户手册
? 维护文档（软件问题报
告、维护请求、工程变
更次序）
? 软件工程标准
? 项目开发总结
配臵对象
? 在实现 SCM时，把 CI组织成配臵对象,在配
臵库（项目数据库）中用一个 单一的名字来组
织它们
? 一个配臵对象有一个 名字 和一组 属性,并通过
某些联系“连接”到其它对象
? 每个对象与其它对象的联系用箭头表示，箭头
指明了一种构造关系
? 双向箭头则表明一种相互关系
? 如果对“源代码”作了一个变更，就可以根据这种
相互关系确定其它哪些 CI可能受到影响
配臵对象
基线 (Baseline)
? 基线是软件生存期中各开发阶段末尾的
特定点，又称里程碑。
? 由正式的技术评审而得到的 CI协议和软
件配臵的正式文本才能成为基线。
? 基线的 作用是把各阶段工作的划分更加
明确化,以便于检验和肯定阶段成果。
软件开发各阶段的基线
项目配臵库（数据库）
? 将 CI和基线存放到项目配臵库中
? 当项目成员想要 对基线中的 CI进行修改时, 把它
从项目配臵库中复制到该工程师的专用工作区中
? 例如把一个 名为 B的 CI从项目配臵库复制到工
程师的专用工作区中
? 工程师在 B'（ B的副本）上完成要求的变更, 再
用 B'来更新 B
? 有些系统中把更改中的这个基线中的 CI锁定
? 在变更完成、评审和批准之前，不许对它做任何
操作
基线 CI和项目配臵（数据）库
配置管理过程 （ ISO12207）
? 配置管理过程是在整个软件生存周期中
实施管理和技术规程的过程，它
? 标识、定义系统中的软件项并指定基线；
? 控制软件项的修改和发行；
? 记录和报告软件项的状态和修改申请；
? 保证软件项的完整性、协调性和正确性；
? 以及控制软件项的储存、处理和交付。
配置管理过程活动
? 软件配置管理主要有以下的基本活动,
? 过程实施
? 配置标识
? 配置控制
? 配置状态统计
? 配置审计
? 发行管理和交付
过程实施
? 编制配置管理计划。描述,
? 配置管理活动；
? 为实施这些活动采用的规程和进度安排；
? 负责实施这些活动的组织，以及它们和
其他组织的关系。
过程实施规程
1 启动和定义范围
1.1 定义 SCM过程的输入
1.2 定义 SCM过程的资源和限制
1.3 分配职责和权利
1.4 SCIs的选择准则
1.5 定义 SCM过程的输出
2 计划
3 控制执行
4 SCM过程的评审和评价
5 结束
软件配置标识
? 应确定一个方案，来标识一个项目需加
控制的软件项及其版本。
? 对于每一软件项及其版本，应标识下述
内容,
? 建立基线的文档；
? 版本引用号；
? 以及其他标识细节。
软件配置标识规程
1 标识 SCIs
2 标识软件配置基线
3 标识软件库
4 进程状态
配臵标识
? 随着软件生存期的向前推进 CI的数
量不断增多
? 整个软件生存期的 软件配臵就象一
部不断演变的电影,而某一时刻的
配臵就是这部电影的一个片段
? 为了方便 对软件配臵的各个片段
（ CI） 进行控制和管理,不致造成
混乱，首先应给它们 命名
对象类型
? 基本对象, 是由软件工程师在分析、设
计、编码和测试时所建立的 文本单元 。
例如，基本对象可能是需求规格说明中
的一节，一个模块的源程序清单、一组
用来测试一个等价类的测试用例
? 复合对象, 是基本对象或其它复合对象
的 一个收集
配臵项标识
? （名字、描述、资源、实现）
? 名字 明确地标识 CI
? 描述 包括,CI类型 （如文档、程序、数
据）,项目标识, 变更 和／或 版本信息
? 资源 包括：由 CI产生的, 处理的, 引用
的 或 其它需要 的 一些实体
? 基本对象的实现 是 指向 文本单元 的指针,
复合对象的实现为 null
命名对象之间的联系
? 对象的层次关系,一个对象可以是一个复合对象的一
个组成部分，用联系 < is part of >标识 以建立 CI的一个
层次,
E-R diagram 1.4 < is part of > data model;
data model < is part of > Design Specification;
? 对象的相互关联关系,对象跨越对象层次的分支相互
关联。这些交叉的结构联系表达方式如下,
data model <interrelated> data flow model;
(两个复合对象之间的相互联系 )
data model <interrelated> test case class m;
(一个复合对象与一个特定的基本对象之间的相互联系）
演变图
? 整个软件工程过程中所涉及的软件对象都必须加
以标识
? 在对象成为基线以前可能要做多次变更，在成为
基线之后也可能需要频繁地变更
? 对于每一配臵对象都可以建立一个演变图,用演
变图记叙对象的 变更历史
? 在某些工具中，当前保持的 只是最后版本的完全
副本
? 为了得到较早时期 (文档或程序 )的版本，可以从最
后版本中,提取”出 (由工具编目的 )变更,使得 当
前配臵直接可用,并使得 其它版本也可用 。
演变图
软件配置控制
? 应标识和记录更改申请；
? 分析和评价更改；
? 批准或不批准申请；
? 实现、验证和发行已修改的软件项。
? 应对每次修改进行审核跟踪、可以跟踪修改的
原因和修改的授权。
? 应对所有访问受控软件项的情况进行控制和审
核，以保证关键功能的安全和保密安全。
软件配置控制规程
1 提议变更
2 评价提议的变更的影响
3 实现变更
4 交流处置
5 结束变更
软件配置控制的主要内容
? 更改控制
? 版本控制
变更控制
? 软件开发中全部的软件配臵是软件产品
的真正代表,必须使其保持 精确
? 软件工程过程中 某一阶段的变更,均要
引起软件配臵的变更,这种变更必须严
格加以 控制 和 管理,保持修改信息
? 变更控制包括 建立控制点 和 建立报告与
审查制度
变
更
控
制
过
程
变更过程
? 首先用户提交书面的变更请求，详细申明变更的理由、变
更方案、变更的影响范围等
? 然后由变更控制机构确定控制变更的机制、评价其技术价
值、潜在的副作用、对其它配臵对象和系统功能的综合影
响以及项目的开销、并把评价的结果以变更报告的形式提
交给变更控制负责人（最终决定变更状态和优先权的某个
人或小组）
? 对批准的变更产生一个工程变更指令（ ECO），描述进行
的变更、必须考虑的约束、评审和审计的准则等
? 要做变更 CI从项目数据库中检出（ check out），对其做出变
更，并实施适当的质量保证活动。然后再把 CI登入（ check
in）到数据库中并使用适当的版本控制机制建立软件的下一
版本
软件变更有两类不同情况
? 为改正小错误需要的变更
? 为了增加或者删掉某些功能、或者为了
改变完成某个功能的方法而需要的变更
改错变更
? 它是必须进行的，通常不需要从管理角
度对这类变更进行审查和批准。
? 但是，如果发现错误的阶段在造成错误
的阶段的后面，例如在实现阶段发现了
设计错误，则必须遵照标准的变更控制
过程，把这个变更正式记入文档，把所
有受这个变更影响的文档都做相应的修
改。
增删功能变更
? 这类变更必须经过某种正式的变更评价过程，以估计
变更需要的成本和它对软件系统其它部分的影响
? 如果变更的代价比较小且对软件系统其它部分没有
影响，或影响很小，通常应批准这个变更。
? 如果变更的代价比较高，或者影响比较大，则必须权衡利弊，
以决定是否进行这种变更。
? 如果同意这种变更,需要进一步确定由谁来支
付变更所需要的费用。 如果是用户要求的变更，
则用户应支付这笔费用；否则，必须完成某种
成本／效益分析，以确定是否值得做这种变更。
变更控制的作用
? 这种变更报告和审查制度，对变更控制
来说起了一个安全保证作用。
? 在一个 CI成为基线之前，可以对所有合
理的项目和技术申请进行非正式的变更；
? 一旦某个 CI经过正式的技术评审并得到
批准，它就成了基线。以后如果需要对
它变更，就必须得到项目负责人的批准，
或者必须得到变更控制负责人的批准。
版本控制
? 版本控制是 SCM的基础，它管理并保护
开发者的软件资源。
? 版本控制管理在软件工程过程中建立起
配臵对象的不同版本 。
? 版本管理可以把 一些属性结合到各个软
件版本 上。
? 通过 描述所希望的属性集合 来 确定 （或
构造 ） 所想要的配臵 。
? 使用 演变图 来表示系统的不同版本。
演变图说明
? 图中的各个结点都是 聚合对象,是一个 完全的
软件版本 。
? 软件的每一版本都是 CI（源代码、文档、数据）
的一个收集,且各个版本都可能由不同的变种
组成。
? 例如，一个简单的程序版本由 1,2,3,4和 5
等部件组成。其中 部件 4在软件 使用彩色显示
器 时使用,部件 5在软件 使用单色显示器 时使
用。因此，可以定义版本的两个变种。
版本管理的主要任务
? 集中管理档案，安全授权机制
? 软件版本升级管理
集中管理档案，安全授权机制
? 版本管理的操作 将开发组的档案集中地
存放在服务器上, 经系统管理员授权给
各个用户 。
? 用户通过登入（ check in）和检出
（ check out）的方式访问服务器上的文
件，未经授权的用户无法访问服务器上
的文件。
软件版本升级管理
? 每次登入时，在服务器上都会生
成新的版本。
? 任何版本都可以随时检出编辑，
同一应用的不同版本可以像树枝
一样向上增长。
加锁功能
? 目的是 在文件更新时保护文件, 避
免不同用户更改同一文件时发生冲
突 。
? 某一文件一旦被 登入, 锁即被解除,
该文件可被其它用户使用。
? 在 更新一个文件之前锁定它,避免
变更没有锁定的项目源文件。
合理使用登入和检出
? 当需要修改某个小缺陷时，应 只检出完成工作必需的
最少文件 ；
? 需要对文件变更时，应登入它并 加锁, 保留对每个变
更的记录 ；
? 应避免长时间地锁定文件。如果需要长时间工作于某
个文件，最好能 创建一个分支,并在分支上做工作。
? 如果需要做较大的变更，可有两种选择,
a.将需要的所有文件检出并加锁，然后正常处理 ；
b.为需要修改的所有分支创建分支，把变更与主干,脱机,，然
后把结果合并回去。
软件配置状态统计
? 应编制管理记录和状态报告，表明受控
软件项的包括基线在内的状态和历史。
? 状态报告应包括某一项目的更改号码，
最新的软件项版本，发行标识，版本号
数，以及各版本的比较。
软件配置状态统计规程
1 记录标识
2 追踪变更
3 汇报状态统计记录
? 软件产品的结构；
? 每个 SCI在接受意义层次的状态；
? 任何被提议的变更的状态；
? 被批准的更改和基线版本；
? 发行的标识。
配臵状态报告
? 为了清楚、及时地记载软件配臵的变化，
需要 对开发的过程做出系统的记录,以
反映开发活动的历史情况。这就是配臵
状态登录的任务。
? 登录主要 根据变更控制小组会议的记录,
并产生 配臵状态报告 。
? 对于每一项变更，记录：发生了什么？
为什么会发生？谁做的？什么时侯发生
的？会有什么影响？
配臵状态报告信息流
配臵状态报告内容
? 每次 新分配一个 CI，或 更新一个已有 CI的标识,或 一
项变更申请被变更控制负责人批准, 并给出了一个工
程变更顺序 时,在配臵状态报告中就要增加一条变更
记录条目。
? 一旦进行了配臵审计，其结果也应该写入报告之中。
? 配臵状态报告可以放在一个联机数据库中，以便软件
开发人员或者软件维护人员可以对它进行查询或修改。
此外在软件配臵报告中新登录的变更应当及时通知给
管理人员和软件工程师。
? 配臵状态报告对于大型软件开发项目的成功起着至关
重要的作用。避免了可能出现的不一致 和冲突。
软件配置评价
? 应确定和保证下述事项,
? 软件项按其要求的功能完整性
? 软件项的物理完整性（不管他们的设计
和编码是否反映最新技术描述）。
软件配置评价要求
? SCM配置评价确定,
? 控制库中贮存的 SCIs符合 SCM记录；
? 就写到的 SCIs和批准的修改的状态（软件产品按此
构造）而言，软件产品是完全的和可利用的；
? 基线 SCIs由相关的 SCIs和相应的批准的修改组成；
? 应支持验证和审核过程以确保被评价的 SCIs、基线和
软件产品的完全性。
? 应执行配置评价以确定组建基线的 SCIs被贮存和保护。
? 应报告配置评价结果。
? 发现异态时，应实施问题解决或过程改进过程。
配臵审计
? 软件配臵审计的目的就是要
? 证实整个软件生存期中各项产品在技
术上和管理上的完整性。
? 确保所有文档的内容变动不超出当初
确定的软件要求范围。使得软件配臵
具有良好的可跟踪性。
? 软件的完整性 是指开发后期的 软件
产品能够正确地反映用户要求
软件配置审计
? 软件配臵审计是软件变更控制人员
掌握配臵情况, 进行审批的依据
? 软件的变更控制机制通常只能跟踪
到工程变更顺序产生为止。为确认
变更是否正确完成,一般可以用以
下两种方法去审查,
? 正式技术评审
? 软件配臵审计
审计内容
? 正式的技术评审 着重 检查已完成修改的软件配
臵对象的技术正确性
? 评审者 评价 CI，决定它与其它 CI的一致性，是
否有遗漏或可能引起的副作用
? 正式技术评审应对所有的变更进行，除了那些
最无价值的变更之外
? 软件配臵审计 作为正式技术评审的补充,评价
在评审期间通常没有被考虑的 CI的特性
软件发行管理和交付
? 应有效控制软件产品和文档的发行和交
付。
? 在软件产品的生存期内应保持代码和文
档的母拷贝。
? 包含安全或保密安全关键功能的代码和
文档按照有关组织的方针加以处理、储
存、包装和交付。
软件发行管理和交付规程
1 处理
? SCM过程应控制所有的发行管理和交付中的输入和输出。
? 保留先期版本确保从基线库中发行的 SCIs 是重新可配置的。
? SCM过程应能重建软件环境。
2 贮存
? 应确保贮存的 SCIs的完整性，与媒体或库的无关,
a)选择贮存的介质使再生错误和变坏最小化；
b)以媒介的贮存期兼容的频次，运行或刷新被存档的 SCIs；
c)在受控环境贮存复制的拷贝以达到损耗风险的最小化；
3 复制
? 应建立规程以确保一致的和完全的复制。
? 应确保发行不含无关项的媒体（如软件病毒）。
? 应使用合适的媒体以确保软件产品复制。
4 打包
5 交付
接口控制
? 应标识和控制接口（如硬件、系统软件、支持软件、一体化的现货产品，
和并行的 /并发开发的软件产品）文档。
? 接口可由相互的协议所调整（例如被软件综合者和子承包软件开发商）
或由一方限定（例如，允许复制产品的现货软件产品的供应商）。
? 应标识,
a)接口用途；
b)接口处要求；
c)受影响的组织；
d)已被控制的接口文档；
e)通知影响接口的提议改变的其他人，以及一起或分别进行接口影响的
评价的规程；
f) 批准、变更和发行的接口文档的规程，包括接口变更机构；
g)把接口文档的变更转换成其他 SCIs的变更的规程；
h)角色和职责。
注意事项
以下几个事项应在进行配置管理工作时给予注意。
1） 配置管理设备应做到专机专用, 以杜绝计算机病
毒 。
2） 存放在磁媒体 （ 如软盘 ） 中的信息, 应每隔一段
时间 （ 如半年 ） 就进行一次拷贝翻新, 以防失效 。
3） 配置项入, 出库应特别注意校验, 以保证一致性 。
4） 软件的运行环境 （ 如操作系统 ）, 开发环境, 支
持软件 （ 如编译软件, 数据库生成系统 ） 都是配
置管理应管理的内容 。
谢谢！
汤铭端
010-68389085（ O） 68215365（ Fax）
mdtang@btamail.net.cn
