? 软件质量概念
? 软件质量保证
? 软件可靠性
? 软件配臵管理
软件质量概念
? 软件质量的定义
? 软件质量特性
? 软件质量模型
? 软件质量的度量和评价
软件质量的定义
? ANSI/IEEE Std 729-1983定义软件
质量为,与软件产品满足规定的和
隐含的需求的能力有关的特征或特
性的全体,。
? M.J,Fisher 定义软件质量为,所
有描述计算机软件优秀程度的特性
的组合,。
质量特性及其组合, 是软件开发
与维护中的重要考虑因素
? 为满足软件的各项精确定义的功能、
性能需求，符合文档化的开发标准，
需要相应地给出或设计一些质量特
性及其组合。
? 如果这些质量特性及其组合都能在
产品中得到满足，则这个软件产品
质量就是高的。
? 软件需求是度量软件质量的基础 。
不符合需求的软件就不具备质量。
? 标准定义了一组开发准则，用来指
导软件人员用工程化的方法来开发
软件 。如果不遵守这些开发准则，
软件质量就得不到保证。
? 软件质量是各种特性的复杂组合。
它随着应用的不同而不同，随着用
户提出的质量要求不同而不同。
软件质量特性
? 软件质量特性，反映了软件的本质 。
讨论一个软件的质量，问题最终要
归结到定义软件的质量特性。
? 定义一个软件的质量，就等价于为
该软件定义一系列质量特性。
? 人们通常把影响软件质量的特性用
软件质量模型来描述 。
软件质量模型
? 软件质量特性定义成 分层模型
? 最基本的叫做 基本质量特性,它可
以由一些子质量特性定义和度量。
? 二次特性 在必要时又可由它的一些
子质量特性定义和度量。
? 1976年 Boehm质量模型
? 1979年 McCall质量模型
? 1985年 ISO质量模型
ISO的软件质量评价模型
? 按照 ISO/TC97/SC7/WG3/1985-1-
30/N382，软件质量度量模型由三
层组成
? 软件质量需求评价准则 （ SQRC）
? 软件质量设计评价准则 （ SQDC）
? 软件质量度量评价准则 （ SQMC）
? 高层和中层建立国际标准，低层可
由各使用单位视实际情况制定
Boehm质量模型
1991年 ISO质量特性国际标准
（ ISO/IEC9126）
? 质量特性,功能性, 可靠性, 可维
护性, 效率, 可使用性, 可移植性
? 推荐 21个子特性：适合性 准确性
互用性 依从性 安全性 成熟性
容错性 可恢复性 可理解性
易学习性 操作性 时间特性
资源特性 可分析性 稳定性 可
变更性 可测试性 可安装性 可替
换性 适应性 一致性
软件质量的度量和评价
? 软件质量特性度量有两类,预测型
和 验收型 。
? 预测度量 是利用定量或定性的方法，
估算软件质量的评价值，以得到软
件质量的比较精确的估算值。
? 验收度量 是在软件开发各阶段的检
查点，对软件的要求质量进行确认
性检查的具体评价值，它是对开发
过程中的预测进行评价。
? 预测度量 有两种。
? 第一种叫做 尺度度量,这是一种 定
量度量 。它适用于一些能够直接度
量的特性,例如，出错率定义为：
错误数／ KLOC／单位时间 。
? 第二种叫做 二元度量,这是一种 定
性度量 。它适用于一些只能间接度
量的特性,例如，可使用性、灵活
性等等 。
尺度度量检查表
二元度量检查表
? 通过对照检查项目，确定一种质量
特性的有无。
? 例如，在设计和编码阶段的复杂性
度量，利用 尺度度量方法 来做。对
模块复杂性的度量采用 McCabe 环
路度量。
? 对于 二元度量,可针对检查表中每
一项都应给以记分，指定信息存在
时记, 1”，否则记, 0”。表中所
有各项的分数相加，即得度量结果。
软件的质量保证
? 质量保证的概念
? 软件质量保证的主要任务
? 质量保证与检验
? 软件质量保证体系
? 质量保证的实施
? 软件的质量设计
质量保证的概念
? 什么是质量保证，它是 为保证产品
和服务充分满足消费者要求的质量
而进行的有计划、有组织的活动 。
? 质量保证是 面向消费者的活动,是
为了使产品实现用户要求的功能，
站在用户立场上来掌握产品质量的。
? 软件的质量保证就是向用户及社会
提供满意的高质量的产品。
? 软件的质量保证活动也和一般的质
量保证活动一样，是 确保软件产品
从诞生到消亡为止的所有阶段的质
量的活动 。即 为了确定、达到和维
护需要的软件质量而进行的所有有
计划、有系统的管理活动 。
软件质量保证的主要任务
? 为了提高软件的质量和软件的生
产率，软件质量保证的主要任务
大致可归结为 8点。
1.用户要求定义
? 熟练掌握 正确定义用户要求的技
术
? 熟练使用和指导他人使用 定义软
件需求的支持工具
? 重视 领导全体开发人员收集和积
累有关用户业务领域的各种业务
的资料和技术 技能 。
2,力争不重复劳动
? 考虑哪些 既有软件可以复用
? 在开发过程中，随时 考虑所生产
软件的复用性 。
3,掌握开发新软件的方法
? 在开发新软件的过程中大力使用和
推行软件工程学中所介绍的开发方
法和工具。
? 使用先进的开发技术：如 结构化
技术, 面向对象技术
? 使用数据库技术或网络化技术
? 应用开发工具或环境
? 改进开发过程
4,组织外部力量协作的方法
? 一个软件自始至终由同一个软件开
发单位来开发，也许是最理想的。
但在现实中常常难以做到。
? 改善对外部协作部门的开发管理。
必须 明确规定 进度管理, 质量管理,
交接检查, 维护体制 等各方面的要
求, 建立 跟踪检查 的体制 。
5,排除无效劳动
? 最大的无效劳动就是 因需求规格说
明有误, 设计有误 而造成的 返工 。
定量记录返工工作量, 收集和分析
返工劳动花费数据
? 较大的无效劳动是 重复劳动,即相
似的软件在几个地方同时开发
? 建立互相交流、信息往来通畅、具
横向交流特征的信息流通网
6,发挥每个开发者的能力
? 软件生产是人的智能生产活动，它
依赖于人的能力 和 开发组织团队的
能力 。
? 开发者 必须有 学习各专业业务知识,
生产技术 和 管理技术 的能动性。
? 管理者 或 产品服务者 要 制定技术培
训计划, 技术水平标准,以及 适用
于将来需要的中长期技术培训计划 。
7,提高软件开发的工程能力
? 要想生产出高质量的软件产品必
须有高水平的 软件工程能力 。
? 在软件开发环境或软件工具箱的
支持下, 运用先进的开发技术,
工具和管理方法开发软件的能力 。
8,提高计划和管理质量能力
? 项目开发初期 计划阶段的项目计划
评价
? 计划执行过程中及计划完成报告的
评价
? 将评价、评审工作在工程实施之前
就列入整个开发工程的工程计划中
? 提高软件开发项目管理的精确度
质量保证与检验
? 其一是 切实搞好开发阶段的管理,
检查各开发阶段的质量保证活动开
展得如何；
? 其二是 预先防止软件差错给用户造
成损失 。
? 为了 确保每个开发过程的质量,防
止把软件差错传递到下一个过程，
必须进行质量检验。
质量检验的原则
? 用户要求的是产品所具有的功能，
这是“真质量”。 靠质量检验，一
般检查的是“真质量”的质量特性 。
? 能靠质量检验的质量特性,即使全
数检验，也只是代表产品的部分质
量特性 。
? 必须 在各开发阶段对影响产品质量
的因素进行切实的管理,认真检查
实施落实情况。
? 当开发阶段出现异常时,要从质量
特性方面进行检验，看是否会给后
续阶段带来影响 。
? 虽然各开发阶段进展稳定，但由于
工程能力不足，软件产品不能满足
用户要求的质量。这时 可通过检验
对该产品做出评价，判断是否能向
用户提供该产品 。
? 要以一定的标准检验产品，根据产
品的质量特性，检查各个过程的管
理状态。
软件质量保证体系
? 软件的质量保证活动，是涉及各个
部门的部门间的活动。
? 例如，如果在用户处发现了软件故
障,产品服务部门 就应听取用户的
意见，再由 检查部门 调查该产品的
检验结果，进而还要调查软件实现
过程的状况，并根据情况检查设计
是否有误，不当之处加以改进，防
止再次发生问题。
? 为了顺利开展以上活动,事先明确
部门间的质量保证业务, 确立部门
间的联合与协作的机构 十分重要，
这个机构就是质量保证体系 。
? 必须 明确反馈途径 。
? 必须 明确各部门的职责 。
? 必须 确定保证系统运行的方法,
工具, 有关文档资料,以及 系统
管理的规程和标准 。
? 必须 明确决定是否可向下一阶段
进展的评价项目和评价准则 。
? 必须 不断地总结系统管理的经验
教训, 能够修改系统 。
? 制定质量保证计划,在计划中
? 确定 质量目标
? 确定 在每个阶段为达到总目标
所应达到的要求
? 确定 进度安排
? 确定 所需人力、资源和成本等 。
软件质量保证规程和技术准则
? 规定 在项目的哪个阶段进行评审及
如何评审 ；
? 规定 在项目的哪个阶段应当产生哪
些报告和计划 ；
? 规定 产品各方面测试应达到的水平 。
? 在 每次评审和测试中发现的错误如
何修正 ；
? 描述 希望得到的质量度量 ；
? 说明 各种软件人员的职责,规定
为了达到质量目标他们必须进行
哪些活动。
? 建立
? 在各阶段中执行质量评价的 质量
评价和质量检查系统
? 有效运用质量信息的 质量信息系
统,并使其运行。
质量保证的实施
? 软件质量保证的实施需要从纵向
和横向两个方面展开。
? 要求所有与软件生存期有关的
人员都要参加
? 要求对产品形成的全过程进行
质量管理
? 这要求整个软件部门齐心协力，
不断完善软件的开发环境。此外
还需要与用户共同合作。
质量目标与度量
? 为了开发高质量的软件，需要 明确
软件的功能, 明确软件应达到什么
样的质量标准,即 质量目标 。
? 为了达到这个目标,在开发过程中
的各个阶段进行检查和评价 。
? 在做质量评价时,需要有对质量进
行度量的准则和方法 。
? 需要有在软件生存期中如何使用这
些准则和方法的 质量保证步骤,以
及提高该项作业效率的 工具
软件质量度量和保证的条件
? 适应性,适应各种用户、软件类型
? 易学性,不需要特殊技术，易掌握
? 可靠性,同个软件的评价结果一致
? 针对性,设计阶段就确立质量目标，
在各个阶段实施落实。
? 客观性：
? 经济性：
质量保证活动的实施步骤：
? Target：以用户要求和开发方针为
依据，对质量需求准则、质量设计
准则的各质量特性设定质量目标。
? Plan：设定适合于被开发软件的评
测检查项目 (质量评价准则 )。研讨
实现质量目标的方法或手段。
? Do：制作高质量的规格说明和程序。
在接受质量检查前先做自我检查 。
? Check,以 Plan阶段设定的质量评
价准则进行评价。 计算结果用质量
图的形式表示 出来。比较评价结果
的质量得分和质量目标，看其是否
合格。
? Action,对 评价发现的问题进行改
进活动,如果实现并达到了质量目
标就转入下一个工程阶段。 这样重
复,Plan”到,Action”的过程,直
到整个开发项目完成。
软件的质量设计
? 质量特性转换为软件的内部结构
? 在 软件定义阶段, 必须定义对软件
的质量需求 。即确定软件的质量特
性及必需的评价准则，并定量地设
定其必须达到的质量水平
? 在以后软件开发的每一阶段结束时，
要算出评价的分数,然后与 目标值
加以对照,以评估在这一阶段开发
的软件质量是否达到要求。
? 为了实现规定的质量特性，就需要
把这些 质量特性转换为软件的内部
结构的特性 。
? 例如，软件质量需求中的,性能,，
可以转换成软件内部结构中的构成
元素，即 每一个程序模块和物理数
据各自应具有的性能特性 。 这些性
能特性的累积就形成外部规格中的
性能特性 。
软件的结构特性与评价标准
? 结构特性 逻辑数据层次
? 评价标准
? 全部数据元素定义完毕
? 所有层次的操作符定义完毕
? 结构特性 功能层次
? 评价标准
? 全部功能元素定义完毕
? 所有层次的操作符定义完毕
? 结构特性 逻辑数据与功能的对应
关系
? 评价准则
? 所有数据都与功能对应
? 所有功能元素都与数据对应
? 逻辑数据与功能的相互关系个数
（局部）
? 结构特性 物理数据层次
? 评价准则
? 全部数据元素定义完毕
? 物理数据之间的所有指针定义完
毕
? 上述指针都具有层次性
? 结构特性 模块层次
? 评价准则
? 所有模块定义完毕
? 模块之间所有控制关系定义完毕
? 上述关系都是标准过程调用形式
? 各层次上的模块大小适当
? 结构特性
物理数据与模块的对应关系
? 评价准则
? 所有物理数据都与模块对应
? 所有模块都与物理数据对应
? 对应于一个物理数据的模块数
（以一对一为好）
? 结构特性
逻辑数据与物理数据的对应关系
? 评价准则
? 所有逻辑数据都与物理数据对应
? 对应于一个物理数据的逻辑数据
数（以一对一为好）
? 结构特性
功能与模块的对应关系
? 评价准则
? 所有功能都与模块对应
? 对应模块的功能个数（以一对
一为好）
软件可靠性
? 软件生存期与软件寿命的关系
? 在软件工程中常用的定义
? 软件可靠性定义
? 测试中的可靠性分析
? 测试精确度和测试覆盖度的评价
软件生存期与软件寿命的关系
? 一切有生命的东西都有一个,寿命,
? 这个概念也可以延伸到对非生命产
品的质量评价上来。例如一个电子
产品的寿命就是指该产品从出厂直
到丧失使用价值的持续时间。
? 从软件工程的角度来说,软件产品
的寿命是指软件的整个生存期 。
? 从软件用户的角度来看，更关心的
是 软件在交付使用后的情况如何 。
? 希望用一个指标 平均失效间隔时间
MTBF(MeanTime Between Failure)
来表明，在规定的要求和条件下，
能在多大的程度上依赖这个软件来
完成任务。
? 我们把 在使用期间软件能够正常工
作的持续时间叫做软件的使用寿命 。
? 软件的 使用寿命与输入环境有关 。
? 例如，有一个存在缺陷的编译程序，
当用于学生做简单练习时,MTBF
可能很长。而做一个大的课题时，
由于程序连续出错,MTBF就会变
得很短。
? MTBF可以看做是对软件可靠性做
估计的样本数据，但不能看做是依
据。
?,错误”这一术语。在没有特别加
以说明的情况下，这是一个泛用的、
模糊的概念。
? 它指的可能是 bug(设计中的差错 )、
fault(故障 ),error(错误 )、
failure(失效 ),crash(重大事故 )、
problem(疑问 )等。
? 在汉译中，这些术语的使用更加混
乱。
在软件工程中常用的定义
? 故障 (fault),软件的内在缺陷 。这
些缺陷可在生存期各个阶段被引入。
? 错误 (error),故障在一定的环境条
件下的暴露,导致系统在运行中出
现了不正常、不正确、不按规范执
行的状态，称为软件出错。
? 失效 (failure),对错误不做任何修正
和恢复,导致系统的输出不满足用
户要求,称为软件的一次失效。
? 以上定义的故障、错误和失效，分
别代表了 广义的“错误” 在不同的
条件下 所对应的术语。
? 它们可以理解为：设计者的失误 ─
导致系统中留有错误的设计 ──缺
陷或,故障, (fault)，这些 故障 导
致系统的错误执行 ──错误 (error)，
由于 错误 导致系统的错误输出 ──
失效 (failure)。
? 故障是物理地或静态地存在的
? 失误、错误和失效都是系统的一种
动态的转瞬即逝的现象
? 软件发生失效标志着软件一次使用
寿命的结束
? 发生过失效的软件通常仍然是可用
的。只有当软件频繁失效，或者公
认已经“过时”了的时侯，软件才
被废弃,意味着当前这一版本软件
使用寿命的终结。
软件故障产生原因
? 支持软件工作的基本条件 (除硬件
外的操作系统、数据库管理系统、
编译程序、微代码等 )的缺陷
? 软件设计不当
? 加入了允许范围之外的输入
软件可靠性的定义
? 软件可靠性是软件在 给定的时间间
隔 及 给定的环境条件 下,按设计要
求, 成功地运行程序 的概率。
? 环境条件 ─指的是 软件的使用环境 。
无论是什么软件，如果不对它的使
用环境加以限制，都是会失效的。
这种失效的数据，不能用来度量软
件的可靠性。
? 规定的时间 ─在定义中，一般采用
“运行时间” t 作为时间的尺度。
因
? 具体要处理的问题是多种多样的
? 其对应的输入环境是随机
? 程序中相应程序路径的选取也是随
机的
? 软件的失效也是随机的
? 应当把运行时间 t当作随机变量来考
虑。
? 规定的功能 ─在考虑软件可靠性时，
首先应当明确 软件的功能是什么,
哪些功能是主要的, 哪些功能是次
要的 。一般从软件需求分析说明书
和设计说明书中可以了解这些情况。
? 由于功能不同，失效带来的损失
就不一样。因此，还要明确 哪些失
效是致命的, 哪些失效是非致命的,
哪些又是容易修复的 。此外，还要
明确,怎样才算是完成了一个规定
的功能 。
? 成功地运行程序 ─是指不仅程序能
正确地运行，满足用户对它的功能
要求,而且当程序一旦受到意外
的伤害，或系统故障时，能尽快恢
复，仍能正常地运行。
测试中的可靠性分析
? 在软件开发的过程中,利用测试的
统计数据，估算软件的可靠性,以
控制软件的质量是至关重要的。
? 推测错误的产生频度，即推测错误
产生的时间间隔
? 推测残留在程序中的错误数
? 评价测试的精确度和覆盖率
推测错误的产生频度
? 估算错误产生频度的一种方法是
估算平均失效等待时间 MTTF
(Mean Time To Failure)
? MTTF估算公式 (Shooman模型 )
M T T F =
I
K E E t
T
T C( ( ))?
E t E eT K t( ) ( )? ? ? ?1
故障累积指数曲线模型
估算软件中故障总数 ET的方法
利用 Shooman模型 估算程序中原
来错误总量 ET —瞬间估算
E t
t
K
E
I
E t
I
E t
t
K
E
I
E t
I
C T
T
C
T
C T
T
C
T
( ) ( )
( ) ( )
1
1
1
2
2
2
1
1
? ? ?
?
?
?
?
?
?
? ? ?
?
?
?
?
?
?
M T T F
M T T F
1
2
解此方程组
?
( ) ( )
( ) ( )E
t t
t E t t E t
E t E tT
C C
C C?
?
? ? ?
? ?2 1
2 1 1 2
1 2
? ( )
( ( ))
K
I E t
t E E t
T C
T C
?
?
? ?
1
1 1
利用最小二乘法进行程序原有错
误数 ET及 K的估算
? 由失效率
? 整理得
? 若对程序进行若干次不同的功能测试，
可得到一系列实验数据
? ? ?
?
?
?
?
?
?K
E
I
E t
I
T
T
c
T
( )
E t
I
E
I K
c
T
T
T
( )
? ?
?
Ec ( ti ),? ( ti ),i = 1,2,…,n
? 令
? 有
? ? ?
? ?
1
K
a
E
I
b
E t
I
t
T
T
C i
T
i i i
,,
( )
,( )
? ? ?
? ?i ia b i n? ? ?,,,,1 2 ?
? 用最小二乘法解此方程组，可解出
a,b的估计值
? 最后得到 K,ET 的估计值
?
?
,? ?K
a
E I bT T? ? ? ?
1
利用植入故障法估算程序中原有故
障总数 ET ─ 捕获－再捕获抽样法
? 设 Ns 是 在测试前人为地向程序中植
入的故障数, ns 是 经过一段时间测
试后发现的播种故障数目, n 是 在
测试中又发现的程序原有故障数 。
设 测试用例发现植入故障和原有故
障的能力相同,则 程序中原有故障
总数 N ( =ET )估算值为
N
N
n
ns
s
?
Hyman分别测试法
? 由两个测试员同时互相独立地测试
同一程序的两个副本，用 t 表示 测
试时间,记 t＝ 0时,程序中原有故
障总数是 B0； t＝ t1 时,测试员甲
发现的故障总数是 B1； 测试员乙发
现的故障总数是 B2；其中两人发现
的 相同故障数目是 bc；两人发现的
不同故障数目是 bi。
? 在大程序测试时，头几个月两个测
试员测试的结果应当比较接近,bi
不是很大 。这时有
? 如果 bi比较显著, 应当每隔一段时
间, 由两个测试员再进行分别测试,
分析测试结果，估算 B0。如果 bi减
小，或几次估算值的结果相差不多，
则 B0作为原有错误总数的估算值。
B B B
bc0
1 2? ?
测试精确度和测试覆盖度的评价
? 在软件测试过程中累积发现的故障
数,可用带有平均值函数 m(t) 的非
齐次泊松过程 (NHPP)来描述：
? 其中,N是在测试中可能发现的故
障总数,b是故障发现率。
? 当 N一定时,b越大，在短期内发现
的故障越多。
? ?m t N e bt( ) ? ? ?1
? N 可以认为是 当测试时间无限延长
时 估计可能发现的故障总数 。由于
? 测试的不完全，在某些很难发现的
故障未发现前就可能结束测试
? 若程序中潜在的故障较少，则参数
N的估计误差较大
? 因此，只用测试中累积发现的故障
数来评价测试是不够的。需要从测
试的 量的方面 和 质的方面,全面地
评价测试。
? SPQL (Software Product Quality
Level) 用如下公式度量：
SPQL ＝ Ac× Cv
? 其中,Ac (Test Accuracy) 是 测试
的精确度,它反映了测试的质量；
Cv (Test Coveragy) 是 测试的覆盖
度,它反映了测试的数量。
测试结束时软件产品质量水准
? 测试质量的度量可以靠 测试的故障
捕捉率和遗漏率 来衡量。
? 测试数量的度量指标是 执行的测试
用例数, 确认的程序路径数 等等；
测试精确度 Ac
? 表明在测试的过程中以多大的把握
捕捉了软件中潜在的故障。
? 测定 Ac，需要预先植入播种故障，
然后通过测试，根据播种故障的捕
捉率来推测原有故障的捕获率。
? 用 ns 表示 经过相当长时间测试可能
发现的播种故障数,用 Ns 表示测试
对象软件内 预先埋设的播种故障总
数,用平均值为 m(t)的 NHPP模型 描
述测试时发现播种故障的过程
? m(t)的收敛值 m(?)＝ N
? 测试精确度 Ac的推测值：
A c ? ?
?
?
n
N
m
N
N
N
s
s s s
( )
? 若设测试过程中到时刻 ti 能发现的
累积播种故障总数为 yi,则在测试
期间可得到一连串数据
(t0,0),(t1,y1),……,( tm,ym)
? 可得到一组方程：
? 应用最小二乘法可得到参数 N 与 b
的估计值，并得到测试精确度 Ac。
y N e i ni bt i? ? ??( ),,,1 0 ?
测试覆盖率 Cv
? 表明在整个测试期间发现软件内潜
在故障的可能性有多大。
? 可通过被测试对象软件内潜在的原
有故障的捕捉率来测定的。
? 测试过程中 已发现原有故障总数 为
n0(实测值 )，经过相当长时间测试
后 可能发现的原有故障总数 为 N0，
? 采用平均值函数 m(t)的 NHPP模型
描述测试发现原有故障的过程
? m(t)的收敛值 m(?)＝ Nc
? 测试覆盖率 Cv的推测值,
Cv =
n
N
n
m
n
Nc
0
0
0 0?
?
?
( )
? 测试开始后，由于测试员对程序和
测试环境不熟悉，造成拖期。
? 为描述这种情形，对原来 NHPP的
指数型平均值函数加以改造：
? 它是 把原来的指数型平均值函数在
时间轴上平移而得到的结果, 是具
有时间延迟的 NHPP模型 。
m t N e b t d( ) ( )( )? ? ? ?1
? 测试员从发现错误征兆到确认错误，
需要反复执行程序，以再现错误，
造成时间拖延。
? 因此，在使用测试结果进行软件质
量评价时,只用指数型的 NHPP的
平均值曲线 (A)是不够的 。 实测结果
多是如 (B)所示的 S型曲线 。
m t N bt e bt( ) ( ( ) )? ? ? ?1 1
? 实验表明：
? 对于一般功能单纯的小规模的程
序模块，具有时间延迟的 NHPP
模型比较合适；
? 对于功能比较复杂的程序模块，
S型 NHPP模型比较合适；
? 对于 80000行以上的程序，最基
本的指数型 NHPP模型比较合适。
软件配臵管理
? 在软件建立时 变更是不可避免的,
因为在进行变更前没有仔细分析，
或没有进行变更控制,变更加剧了
项目中软件人员之间的混乱 。
? 协调软件开发使得混乱减到最小的
技术叫做配臵管理 。
? 配臵管理是一组标识、组织和控制
修改的活动，目的是使错误达到最
小并最有效地提高生产率。
软件配臵管理的概念
? 软件配臵管理，简称 SCM，是一种
“保护伞”活动，它 应用于整个软
件工程过程 。
? SCM活动的目标是为了
(1) 标识变更；
(2) 控制变更；
(3) 确保变更正确地实现；
(4) 向其他有关的人报告变更。
? 在软件工程过程中产生的所有信息
项（文档、报告、程序、表格、数
据） 构成了软件配臵 。
? 软件配臵是软件的具体形态在某一
时刻的瞬时影像。
? 随着软件工程过程的进展,软件配
臵项 (SCI)数目快速增加。系统规
格说明可繁衍出软件项目实施计划
和软件需求规格说明。它们又依次
繁衍出建立信息层次的其它文档 。
基线 (Baseline)
? 基线是软件生存期中各开发阶段末
尾的特定点，又称里程碑。
? 由正式的技术评审而得到的 SCI协
议和软件配臵的正式文本才能成为
基线。
? 基线的 作用是把各阶段工作的划分
更加明确化,以便于检验和肯定阶
段成果。
软件开发各阶段的基线
项目数据库
? 一旦 一个 SCI成为基线, 就把它存
放到项目数据库中 。
? 当软件组织成员想要 对基线 SCI进
行修改时, 把它从项目数据库中复
制到该工程师的专用工作区中 。
? 例如，把一个 名为 B的 SCI从项目
数据库复制到工程师的专用工作区
中 。 工程师在 B'（ B的副本）上完
成要求的变更, 再用 B'来更新 B。
? 有些系统中把这个基线 SCI锁定。
? 在变更完成、评审和批准之前，不
许对它做任何操作。
基线 SCI和项目数据库
软件配臵项 SCI
? 软件配臵管理的对象就是 SCI—软
件配臵项 。
? 系统规格说明
? 软件项目实施计划
? 软件需求说明
? 可执行的原型
? 初步的用户手册
? 设计规格说明
? 源代码清单
? 测试计划和过程、测试用例和测
试结果记录
? 操作和安装手册
? 可执行程序（可执行程序模块、
连接模块）
? 数据库描述（模式和文件结构、
初始内容）
? 正式的用户手册
? 维护文档（软件问题报告、维护
请求、工程变更次序）
? 软件工程标准
? 项目开发总结
? 除以上所列 SCI以外，许多软件工
程组织还把 配臵控制之下的软件工
具 列入其中，即 编辑程序, 编译程
序, 其它 CASE工具的特定版本 。
因为要使用这些工具来生成文档、
程序和数据，如果编译程序的版本
不同，可能产生的结果也不同。
配臵对象
? 在实现 SCM时，把 SCI组织成配臵
对象,在项目数据库中用一个 单一
的名字来组织它们 。
? 一个配臵对象有一个 名字 和一组 属
性,并通过某些联系“连接”到其
它对象。
? 每个对象与其它对象的联系用箭头
表示。箭头指明了一种构造关系。
配臵对象
? 双向箭头则表明一种相互关系 。如
果对“源代码”对象作了一个变更，
软件工程师就可以根据这种相互关
系确定，其它哪些对象（和 SCI）
可能受到影响。
软件配臵管理的任务
? 软件配臵管理（ SCM）的任务是：
? 标识单个的 SCI
? 标识和管理软件各种版本
? 控制变更
? 审查软件配臵
? 报告所有加在配臵上的变更。
配臵标识
? 一方面随着软件生存期的向前推进，
SCI的数量不断增多 。
? 整个软件生存期的 软件配臵就象一
部不断演变的电影,而某一时刻的
配臵就是这部电影的一个片段。
? 为了方便 对软件配臵的各个片段
（ SCI） 进行控制和管理,不致造
成混乱，首先应给它们 命名 。
对象类型
? 基本对象, 是由软件工程师在分析、
设计、编码和测试时所建立的 文本
单元 。例如，基本对象可能是需求
规格说明中的一节，一个模块的源
程序清单、一组用来测试一个等价
类的测试用例。
? 复合对象, 是基本对象或其它复合
对象的 一个收集 。
? 对象标识：
（名字、描述、资源、实现）
? 对象的 名字 明确地标识对象。
? 对象 描述 包括,SCI类型 （如文档、
程序、数据）,项目标识, 变更 和
／或 版本信息 。
? 资源 包括由对象 产生的, 处理的,
引用的 或 其它需要 的 一些实体 。
? 基本对象的实现 是 指向 文本单元 的
指针,复合对象的实现为 null。
命名对象之间的联系
? 对象的层次关系,一个对象可以
是一个复合对象的一个组成部分，
用联系 < is part of >标识 。
E-R diagram 1.4 < is part of >
data model;
data model < is part of > Design
Specification;
? 就可以建立 SCI的一个层次。
? 对象的相互关联关系,对象跨越对
象层次的分支相互关联。这些交叉
的结构联系表达方式如下：
data model <interrelated> data flow
model;
(两个复合对象之间的相互联系 )
data model <interrelated> test case
class m;
(一个复合对象与一个特定的基本
对象之间的相互联系）
演变图
? 整个软件工程过程中所涉及的软件
对象都必须加以标识。
? 在对象成为基线以前可能要做多次
变更，在成为基线之后也可能需要
频繁地变更。
? 对于每一配臵对象都可以建立一个
演变图,用演变图记叙对象的 变更
历史 。
演变图
? 在某些工具中，当前保持的 只是最
后版本的完全副本 。
? 为了得到较早时期 (文档或程序 )的
版本，可以从最后版本中,提取”
出 (由工具编目的 )变更,使得 当前
配臵直接可用,并使得 其它版本也
可用 。
版本控制
? 版本控制是 SCM的基础，它管理并
保护开发者的软件资源。
? 版本控制管理在软件工程过程中建
立起 配臵对象的不同版本 。
? 版本管理可以把 一些属性结合到各
个软件版本 上。
? 通过 描述所希望的属性集合 来 确定
（或 构造 ） 所想要的配臵 。
? 使用 演变图 来表示系统的不同版本。
? 图中的各个结点都是 聚合对象,是
一个 完全的软件版本 。
? 软件的每一版本都是 SCI（源代码、
文档、数据） 的一个收集,且各个
版本都可能由不同的变种组成。
? 例如，一个简单的程序版本由 1,2、
3,4和 5等部件组成。其中 部件 4在
软件 使用彩色显示器 时使用,部件 5
在软件 使用单色显示器 时使用。因
此，可以定义版本的两个变种。
版本管理的主要任务
? 集中管理档案，安全授权机制,
? 版本管理的操作 将开发组的档案
集中地存放在服务器上, 经系统
管理员授权给各个用户 。
? 用户通过登入（ check in）和检
出（ check out）的方式访问服务
器上的文件，未经授权的用户无
法访问服务器上的文件。
? 软件版本升级管理,
? 每次登入时，在服务器上都会生
成新的版本。
? 任何版本都可以随时检出编辑，
同一应用的不同版本可以像树枝一
样向上增长。
? 加锁功能,
? 目的是 在文件更新时保护文件,
避免不同用户更改同一文件时发
生冲突 。
? 某一文件一旦被 登入, 锁即被解
除,该文件可被其它用户使用。
? 在 更新一个文件之前锁定它,避
免变更没有锁定的项目源文件。
? 在文件登入和检出时，需要注意登
入和检出的使用,
? 当需要修改某个小缺陷时，应 只
检出完成工作必需的最少文件 ；
? 需要对文件变更时，应登入它并
加锁, 保留对每个变更的记录 ；
? 应避免长时间地锁定文件。如果
需要长时间工作于某个文件，最
好能 创建一个分支,并在分支上
做工作。
? 如果需要做较大的变更，可有两
种选择：
a.将需要的所有文件检出并加锁，
然后正常处理 ；
b.为需要修改的所有分支创建分
支，把变更与主干,脱机,，然后
把结果合并回去。
变更控制
? 软件生存期内全部的软件配臵是软
件产品的真正代表,必须使其保持
精确 。
? 软件工程过程中 某一阶段的变更,
均要 引起软件配臵的变更,这种变
更必须严格加以 控制 和 管理,保持
修改信息。
? 变更控制包括 建立控制点 和 建立报
告与审查制度 。
变更控制
过程
软件变更有两类不同情况：
? 为改正小错误需要的变更 。它是必
须进行的，通常不需要从管理角度
对这类变更进行审查和批准。但是，
如果发现错误的阶段在造成错误的
阶段的后面，例如在实现阶段发现
了设计错误，则必须遵照标准的变
更控制过程，把这个变更正式记入
文档，把所有受这个变更影响的文
档都做相应的修改。
? 为了增加或者删掉某些功能、或者
为了改变完成某个功能的方法而需
要的变更 。这类变更必须经过某种
正式的变更评价过程，以估计变更
需要的成本和它对软件系统其它部
分的影响。
? 如果变更的代价比较小且对软件
系统其它部分没有影响，或影响
很小，通常应批准这个变更。
? 如果变更的代价比较高，或者影
响比较大，则必须权衡利弊，以
决定是否进行这种变更。
? 如果同意这种变更,需要进一步
确定由谁来支付变更所需要的费
用。 如果是用户要求的变更，则
用户应支付这笔费用；否则，必
须完成某种成本／效益分析，以
确定是否值得做这种变更。
? 这种变更报告和审查制度，对变更
控制来说起了一个安全保证作用。
? 在一个 SCI成为基线之前，可以对所
有合理的项目和技术申请进行非正
式的变更；
? 一旦某个 SCI经过正式的技术评审并
得到批准，它就成了基线。以后如
果需要对它变更，就必须得到项目
负责人的批准，或者必须得到变更
控制负责人的批准。
配臵状态报告
? 为了清楚、及时地记载软件配臵的
变化，需要 对开发的过程做出系统
的记录,以反映开发活动的历史情
况。这就是配臵状态登录的任务。
? 登录主要 根据变更控制小组会议的
记录,并产生 配臵状态报告 。
? 对于每一项变更，记录：发生了什
么？为什么会发生？谁做的？什么
时侯发生的？会有什么影响？
配臵状态报告信息流
? 每次 新分配一个 SCI，或 更新一个
已有 SCI的标识,或 一项变更申请
被变更控制负责人批准, 并给出了
一个工程变更顺序 时,在配臵状态
报告中就要增加一条变更记录条目。
? 一旦进行了配臵审计，其结果也应
该写入报告之中。
? 配臵状态报告可以放在一个联机数
据库中，以便软件开发人员或者软
件维护人员可以对它进行查询或修
改。此外在软件配臵报告中新登录
的变更应当及时通知给管理人员和
软件工程师。
? 配臵状态报告对于大型软件开发项
目的成功起着至关重要的作用。避
免了可能出现的不一致和冲突。
配臵审计
? 软件的完整性,是指开发后期的 软
件产品能够正确地反映用户要求 。
? 软件配臵审计的目的就是要
? 证实整个软件生存期中各项产品
在技术上和管理上的完整性。
? 确保所有文档的内容变动不超出
当初确定的软件要求范围。使得软
件配臵具有良好的可跟踪性。
? 软件配臵审计是软件变更控制人员
掌握配臵情况, 进行审批的依据 。
? 软件的变更控制机制通常只能跟踪
到工程变更顺序产生为止。为确认
变更是否正确完成? 一般可以用以
下两种方法去审查：
? 正式技术评审
? 软件配臵审计
? 正式的技术评审 着重 检查已完成修
改的软件配臵对象的技术正确性,
? 评审者 评价 SCI，决定它与其它
SCI的一致性，是否有遗漏或可能
引起的副作用。
? 正式技术评审应对所有的变更进行，
除了那些最无价值的变更之外。
? 软件配臵审计 作为正式技术评审的
补充,评价在评审期间通常没有被
考虑的 SCI的特性 。
? 软件质量保证
? 软件可靠性
? 软件配臵管理
软件质量概念
? 软件质量的定义
? 软件质量特性
? 软件质量模型
? 软件质量的度量和评价
软件质量的定义
? ANSI/IEEE Std 729-1983定义软件
质量为,与软件产品满足规定的和
隐含的需求的能力有关的特征或特
性的全体,。
? M.J,Fisher 定义软件质量为,所
有描述计算机软件优秀程度的特性
的组合,。
质量特性及其组合, 是软件开发
与维护中的重要考虑因素
? 为满足软件的各项精确定义的功能、
性能需求，符合文档化的开发标准，
需要相应地给出或设计一些质量特
性及其组合。
? 如果这些质量特性及其组合都能在
产品中得到满足，则这个软件产品
质量就是高的。
? 软件需求是度量软件质量的基础 。
不符合需求的软件就不具备质量。
? 标准定义了一组开发准则，用来指
导软件人员用工程化的方法来开发
软件 。如果不遵守这些开发准则，
软件质量就得不到保证。
? 软件质量是各种特性的复杂组合。
它随着应用的不同而不同，随着用
户提出的质量要求不同而不同。
软件质量特性
? 软件质量特性，反映了软件的本质 。
讨论一个软件的质量，问题最终要
归结到定义软件的质量特性。
? 定义一个软件的质量，就等价于为
该软件定义一系列质量特性。
? 人们通常把影响软件质量的特性用
软件质量模型来描述 。
软件质量模型
? 软件质量特性定义成 分层模型
? 最基本的叫做 基本质量特性,它可
以由一些子质量特性定义和度量。
? 二次特性 在必要时又可由它的一些
子质量特性定义和度量。
? 1976年 Boehm质量模型
? 1979年 McCall质量模型
? 1985年 ISO质量模型
ISO的软件质量评价模型
? 按照 ISO/TC97/SC7/WG3/1985-1-
30/N382，软件质量度量模型由三
层组成
? 软件质量需求评价准则 （ SQRC）
? 软件质量设计评价准则 （ SQDC）
? 软件质量度量评价准则 （ SQMC）
? 高层和中层建立国际标准，低层可
由各使用单位视实际情况制定
Boehm质量模型
1991年 ISO质量特性国际标准
（ ISO/IEC9126）
? 质量特性,功能性, 可靠性, 可维
护性, 效率, 可使用性, 可移植性
? 推荐 21个子特性：适合性 准确性
互用性 依从性 安全性 成熟性
容错性 可恢复性 可理解性
易学习性 操作性 时间特性
资源特性 可分析性 稳定性 可
变更性 可测试性 可安装性 可替
换性 适应性 一致性
软件质量的度量和评价
? 软件质量特性度量有两类,预测型
和 验收型 。
? 预测度量 是利用定量或定性的方法，
估算软件质量的评价值，以得到软
件质量的比较精确的估算值。
? 验收度量 是在软件开发各阶段的检
查点，对软件的要求质量进行确认
性检查的具体评价值，它是对开发
过程中的预测进行评价。
? 预测度量 有两种。
? 第一种叫做 尺度度量,这是一种 定
量度量 。它适用于一些能够直接度
量的特性,例如，出错率定义为：
错误数／ KLOC／单位时间 。
? 第二种叫做 二元度量,这是一种 定
性度量 。它适用于一些只能间接度
量的特性,例如，可使用性、灵活
性等等 。
尺度度量检查表
二元度量检查表
? 通过对照检查项目，确定一种质量
特性的有无。
? 例如，在设计和编码阶段的复杂性
度量，利用 尺度度量方法 来做。对
模块复杂性的度量采用 McCabe 环
路度量。
? 对于 二元度量,可针对检查表中每
一项都应给以记分，指定信息存在
时记, 1”，否则记, 0”。表中所
有各项的分数相加，即得度量结果。
软件的质量保证
? 质量保证的概念
? 软件质量保证的主要任务
? 质量保证与检验
? 软件质量保证体系
? 质量保证的实施
? 软件的质量设计
质量保证的概念
? 什么是质量保证，它是 为保证产品
和服务充分满足消费者要求的质量
而进行的有计划、有组织的活动 。
? 质量保证是 面向消费者的活动,是
为了使产品实现用户要求的功能，
站在用户立场上来掌握产品质量的。
? 软件的质量保证就是向用户及社会
提供满意的高质量的产品。
? 软件的质量保证活动也和一般的质
量保证活动一样，是 确保软件产品
从诞生到消亡为止的所有阶段的质
量的活动 。即 为了确定、达到和维
护需要的软件质量而进行的所有有
计划、有系统的管理活动 。
软件质量保证的主要任务
? 为了提高软件的质量和软件的生
产率，软件质量保证的主要任务
大致可归结为 8点。
1.用户要求定义
? 熟练掌握 正确定义用户要求的技
术
? 熟练使用和指导他人使用 定义软
件需求的支持工具
? 重视 领导全体开发人员收集和积
累有关用户业务领域的各种业务
的资料和技术 技能 。
2,力争不重复劳动
? 考虑哪些 既有软件可以复用
? 在开发过程中，随时 考虑所生产
软件的复用性 。
3,掌握开发新软件的方法
? 在开发新软件的过程中大力使用和
推行软件工程学中所介绍的开发方
法和工具。
? 使用先进的开发技术：如 结构化
技术, 面向对象技术
? 使用数据库技术或网络化技术
? 应用开发工具或环境
? 改进开发过程
4,组织外部力量协作的方法
? 一个软件自始至终由同一个软件开
发单位来开发，也许是最理想的。
但在现实中常常难以做到。
? 改善对外部协作部门的开发管理。
必须 明确规定 进度管理, 质量管理,
交接检查, 维护体制 等各方面的要
求, 建立 跟踪检查 的体制 。
5,排除无效劳动
? 最大的无效劳动就是 因需求规格说
明有误, 设计有误 而造成的 返工 。
定量记录返工工作量, 收集和分析
返工劳动花费数据
? 较大的无效劳动是 重复劳动,即相
似的软件在几个地方同时开发
? 建立互相交流、信息往来通畅、具
横向交流特征的信息流通网
6,发挥每个开发者的能力
? 软件生产是人的智能生产活动，它
依赖于人的能力 和 开发组织团队的
能力 。
? 开发者 必须有 学习各专业业务知识,
生产技术 和 管理技术 的能动性。
? 管理者 或 产品服务者 要 制定技术培
训计划, 技术水平标准,以及 适用
于将来需要的中长期技术培训计划 。
7,提高软件开发的工程能力
? 要想生产出高质量的软件产品必
须有高水平的 软件工程能力 。
? 在软件开发环境或软件工具箱的
支持下, 运用先进的开发技术,
工具和管理方法开发软件的能力 。
8,提高计划和管理质量能力
? 项目开发初期 计划阶段的项目计划
评价
? 计划执行过程中及计划完成报告的
评价
? 将评价、评审工作在工程实施之前
就列入整个开发工程的工程计划中
? 提高软件开发项目管理的精确度
质量保证与检验
? 其一是 切实搞好开发阶段的管理,
检查各开发阶段的质量保证活动开
展得如何；
? 其二是 预先防止软件差错给用户造
成损失 。
? 为了 确保每个开发过程的质量,防
止把软件差错传递到下一个过程，
必须进行质量检验。
质量检验的原则
? 用户要求的是产品所具有的功能，
这是“真质量”。 靠质量检验，一
般检查的是“真质量”的质量特性 。
? 能靠质量检验的质量特性,即使全
数检验，也只是代表产品的部分质
量特性 。
? 必须 在各开发阶段对影响产品质量
的因素进行切实的管理,认真检查
实施落实情况。
? 当开发阶段出现异常时,要从质量
特性方面进行检验，看是否会给后
续阶段带来影响 。
? 虽然各开发阶段进展稳定，但由于
工程能力不足，软件产品不能满足
用户要求的质量。这时 可通过检验
对该产品做出评价，判断是否能向
用户提供该产品 。
? 要以一定的标准检验产品，根据产
品的质量特性，检查各个过程的管
理状态。
软件质量保证体系
? 软件的质量保证活动，是涉及各个
部门的部门间的活动。
? 例如，如果在用户处发现了软件故
障,产品服务部门 就应听取用户的
意见，再由 检查部门 调查该产品的
检验结果，进而还要调查软件实现
过程的状况，并根据情况检查设计
是否有误，不当之处加以改进，防
止再次发生问题。
? 为了顺利开展以上活动,事先明确
部门间的质量保证业务, 确立部门
间的联合与协作的机构 十分重要，
这个机构就是质量保证体系 。
? 必须 明确反馈途径 。
? 必须 明确各部门的职责 。
? 必须 确定保证系统运行的方法,
工具, 有关文档资料,以及 系统
管理的规程和标准 。
? 必须 明确决定是否可向下一阶段
进展的评价项目和评价准则 。
? 必须 不断地总结系统管理的经验
教训, 能够修改系统 。
? 制定质量保证计划,在计划中
? 确定 质量目标
? 确定 在每个阶段为达到总目标
所应达到的要求
? 确定 进度安排
? 确定 所需人力、资源和成本等 。
软件质量保证规程和技术准则
? 规定 在项目的哪个阶段进行评审及
如何评审 ；
? 规定 在项目的哪个阶段应当产生哪
些报告和计划 ；
? 规定 产品各方面测试应达到的水平 。
? 在 每次评审和测试中发现的错误如
何修正 ；
? 描述 希望得到的质量度量 ；
? 说明 各种软件人员的职责,规定
为了达到质量目标他们必须进行
哪些活动。
? 建立
? 在各阶段中执行质量评价的 质量
评价和质量检查系统
? 有效运用质量信息的 质量信息系
统,并使其运行。
质量保证的实施
? 软件质量保证的实施需要从纵向
和横向两个方面展开。
? 要求所有与软件生存期有关的
人员都要参加
? 要求对产品形成的全过程进行
质量管理
? 这要求整个软件部门齐心协力，
不断完善软件的开发环境。此外
还需要与用户共同合作。
质量目标与度量
? 为了开发高质量的软件，需要 明确
软件的功能, 明确软件应达到什么
样的质量标准,即 质量目标 。
? 为了达到这个目标,在开发过程中
的各个阶段进行检查和评价 。
? 在做质量评价时,需要有对质量进
行度量的准则和方法 。
? 需要有在软件生存期中如何使用这
些准则和方法的 质量保证步骤,以
及提高该项作业效率的 工具
软件质量度量和保证的条件
? 适应性,适应各种用户、软件类型
? 易学性,不需要特殊技术，易掌握
? 可靠性,同个软件的评价结果一致
? 针对性,设计阶段就确立质量目标，
在各个阶段实施落实。
? 客观性：
? 经济性：
质量保证活动的实施步骤：
? Target：以用户要求和开发方针为
依据，对质量需求准则、质量设计
准则的各质量特性设定质量目标。
? Plan：设定适合于被开发软件的评
测检查项目 (质量评价准则 )。研讨
实现质量目标的方法或手段。
? Do：制作高质量的规格说明和程序。
在接受质量检查前先做自我检查 。
? Check,以 Plan阶段设定的质量评
价准则进行评价。 计算结果用质量
图的形式表示 出来。比较评价结果
的质量得分和质量目标，看其是否
合格。
? Action,对 评价发现的问题进行改
进活动,如果实现并达到了质量目
标就转入下一个工程阶段。 这样重
复,Plan”到,Action”的过程,直
到整个开发项目完成。
软件的质量设计
? 质量特性转换为软件的内部结构
? 在 软件定义阶段, 必须定义对软件
的质量需求 。即确定软件的质量特
性及必需的评价准则，并定量地设
定其必须达到的质量水平
? 在以后软件开发的每一阶段结束时，
要算出评价的分数,然后与 目标值
加以对照,以评估在这一阶段开发
的软件质量是否达到要求。
? 为了实现规定的质量特性，就需要
把这些 质量特性转换为软件的内部
结构的特性 。
? 例如，软件质量需求中的,性能,，
可以转换成软件内部结构中的构成
元素，即 每一个程序模块和物理数
据各自应具有的性能特性 。 这些性
能特性的累积就形成外部规格中的
性能特性 。
软件的结构特性与评价标准
? 结构特性 逻辑数据层次
? 评价标准
? 全部数据元素定义完毕
? 所有层次的操作符定义完毕
? 结构特性 功能层次
? 评价标准
? 全部功能元素定义完毕
? 所有层次的操作符定义完毕
? 结构特性 逻辑数据与功能的对应
关系
? 评价准则
? 所有数据都与功能对应
? 所有功能元素都与数据对应
? 逻辑数据与功能的相互关系个数
（局部）
? 结构特性 物理数据层次
? 评价准则
? 全部数据元素定义完毕
? 物理数据之间的所有指针定义完
毕
? 上述指针都具有层次性
? 结构特性 模块层次
? 评价准则
? 所有模块定义完毕
? 模块之间所有控制关系定义完毕
? 上述关系都是标准过程调用形式
? 各层次上的模块大小适当
? 结构特性
物理数据与模块的对应关系
? 评价准则
? 所有物理数据都与模块对应
? 所有模块都与物理数据对应
? 对应于一个物理数据的模块数
（以一对一为好）
? 结构特性
逻辑数据与物理数据的对应关系
? 评价准则
? 所有逻辑数据都与物理数据对应
? 对应于一个物理数据的逻辑数据
数（以一对一为好）
? 结构特性
功能与模块的对应关系
? 评价准则
? 所有功能都与模块对应
? 对应模块的功能个数（以一对
一为好）
软件可靠性
? 软件生存期与软件寿命的关系
? 在软件工程中常用的定义
? 软件可靠性定义
? 测试中的可靠性分析
? 测试精确度和测试覆盖度的评价
软件生存期与软件寿命的关系
? 一切有生命的东西都有一个,寿命,
? 这个概念也可以延伸到对非生命产
品的质量评价上来。例如一个电子
产品的寿命就是指该产品从出厂直
到丧失使用价值的持续时间。
? 从软件工程的角度来说,软件产品
的寿命是指软件的整个生存期 。
? 从软件用户的角度来看，更关心的
是 软件在交付使用后的情况如何 。
? 希望用一个指标 平均失效间隔时间
MTBF(MeanTime Between Failure)
来表明，在规定的要求和条件下，
能在多大的程度上依赖这个软件来
完成任务。
? 我们把 在使用期间软件能够正常工
作的持续时间叫做软件的使用寿命 。
? 软件的 使用寿命与输入环境有关 。
? 例如，有一个存在缺陷的编译程序，
当用于学生做简单练习时,MTBF
可能很长。而做一个大的课题时，
由于程序连续出错,MTBF就会变
得很短。
? MTBF可以看做是对软件可靠性做
估计的样本数据，但不能看做是依
据。
?,错误”这一术语。在没有特别加
以说明的情况下，这是一个泛用的、
模糊的概念。
? 它指的可能是 bug(设计中的差错 )、
fault(故障 ),error(错误 )、
failure(失效 ),crash(重大事故 )、
problem(疑问 )等。
? 在汉译中，这些术语的使用更加混
乱。
在软件工程中常用的定义
? 故障 (fault),软件的内在缺陷 。这
些缺陷可在生存期各个阶段被引入。
? 错误 (error),故障在一定的环境条
件下的暴露,导致系统在运行中出
现了不正常、不正确、不按规范执
行的状态，称为软件出错。
? 失效 (failure),对错误不做任何修正
和恢复,导致系统的输出不满足用
户要求,称为软件的一次失效。
? 以上定义的故障、错误和失效，分
别代表了 广义的“错误” 在不同的
条件下 所对应的术语。
? 它们可以理解为：设计者的失误 ─
导致系统中留有错误的设计 ──缺
陷或,故障, (fault)，这些 故障 导
致系统的错误执行 ──错误 (error)，
由于 错误 导致系统的错误输出 ──
失效 (failure)。
? 故障是物理地或静态地存在的
? 失误、错误和失效都是系统的一种
动态的转瞬即逝的现象
? 软件发生失效标志着软件一次使用
寿命的结束
? 发生过失效的软件通常仍然是可用
的。只有当软件频繁失效，或者公
认已经“过时”了的时侯，软件才
被废弃,意味着当前这一版本软件
使用寿命的终结。
软件故障产生原因
? 支持软件工作的基本条件 (除硬件
外的操作系统、数据库管理系统、
编译程序、微代码等 )的缺陷
? 软件设计不当
? 加入了允许范围之外的输入
软件可靠性的定义
? 软件可靠性是软件在 给定的时间间
隔 及 给定的环境条件 下,按设计要
求, 成功地运行程序 的概率。
? 环境条件 ─指的是 软件的使用环境 。
无论是什么软件，如果不对它的使
用环境加以限制，都是会失效的。
这种失效的数据，不能用来度量软
件的可靠性。
? 规定的时间 ─在定义中，一般采用
“运行时间” t 作为时间的尺度。
因
? 具体要处理的问题是多种多样的
? 其对应的输入环境是随机
? 程序中相应程序路径的选取也是随
机的
? 软件的失效也是随机的
? 应当把运行时间 t当作随机变量来考
虑。
? 规定的功能 ─在考虑软件可靠性时，
首先应当明确 软件的功能是什么,
哪些功能是主要的, 哪些功能是次
要的 。一般从软件需求分析说明书
和设计说明书中可以了解这些情况。
? 由于功能不同，失效带来的损失
就不一样。因此，还要明确 哪些失
效是致命的, 哪些失效是非致命的,
哪些又是容易修复的 。此外，还要
明确,怎样才算是完成了一个规定
的功能 。
? 成功地运行程序 ─是指不仅程序能
正确地运行，满足用户对它的功能
要求,而且当程序一旦受到意外
的伤害，或系统故障时，能尽快恢
复，仍能正常地运行。
测试中的可靠性分析
? 在软件开发的过程中,利用测试的
统计数据，估算软件的可靠性,以
控制软件的质量是至关重要的。
? 推测错误的产生频度，即推测错误
产生的时间间隔
? 推测残留在程序中的错误数
? 评价测试的精确度和覆盖率
推测错误的产生频度
? 估算错误产生频度的一种方法是
估算平均失效等待时间 MTTF
(Mean Time To Failure)
? MTTF估算公式 (Shooman模型 )
M T T F =
I
K E E t
T
T C( ( ))?
E t E eT K t( ) ( )? ? ? ?1
故障累积指数曲线模型
估算软件中故障总数 ET的方法
利用 Shooman模型 估算程序中原
来错误总量 ET —瞬间估算
E t
t
K
E
I
E t
I
E t
t
K
E
I
E t
I
C T
T
C
T
C T
T
C
T
( ) ( )
( ) ( )
1
1
1
2
2
2
1
1
? ? ?
?
?
?
?
?
?
? ? ?
?
?
?
?
?
?
M T T F
M T T F
1
2
解此方程组
?
( ) ( )
( ) ( )E
t t
t E t t E t
E t E tT
C C
C C?
?
? ? ?
? ?2 1
2 1 1 2
1 2
? ( )
( ( ))
K
I E t
t E E t
T C
T C
?
?
? ?
1
1 1
利用最小二乘法进行程序原有错
误数 ET及 K的估算
? 由失效率
? 整理得
? 若对程序进行若干次不同的功能测试，
可得到一系列实验数据
? ? ?
?
?
?
?
?
?K
E
I
E t
I
T
T
c
T
( )
E t
I
E
I K
c
T
T
T
( )
? ?
?
Ec ( ti ),? ( ti ),i = 1,2,…,n
? 令
? 有
? ? ?
? ?
1
K
a
E
I
b
E t
I
t
T
T
C i
T
i i i
,,
( )
,( )
? ? ?
? ?i ia b i n? ? ?,,,,1 2 ?
? 用最小二乘法解此方程组，可解出
a,b的估计值
? 最后得到 K,ET 的估计值
?
?
,? ?K
a
E I bT T? ? ? ?
1
利用植入故障法估算程序中原有故
障总数 ET ─ 捕获－再捕获抽样法
? 设 Ns 是 在测试前人为地向程序中植
入的故障数, ns 是 经过一段时间测
试后发现的播种故障数目, n 是 在
测试中又发现的程序原有故障数 。
设 测试用例发现植入故障和原有故
障的能力相同,则 程序中原有故障
总数 N ( =ET )估算值为
N
N
n
ns
s
?
Hyman分别测试法
? 由两个测试员同时互相独立地测试
同一程序的两个副本，用 t 表示 测
试时间,记 t＝ 0时,程序中原有故
障总数是 B0； t＝ t1 时,测试员甲
发现的故障总数是 B1； 测试员乙发
现的故障总数是 B2；其中两人发现
的 相同故障数目是 bc；两人发现的
不同故障数目是 bi。
? 在大程序测试时，头几个月两个测
试员测试的结果应当比较接近,bi
不是很大 。这时有
? 如果 bi比较显著, 应当每隔一段时
间, 由两个测试员再进行分别测试,
分析测试结果，估算 B0。如果 bi减
小，或几次估算值的结果相差不多，
则 B0作为原有错误总数的估算值。
B B B
bc0
1 2? ?
测试精确度和测试覆盖度的评价
? 在软件测试过程中累积发现的故障
数,可用带有平均值函数 m(t) 的非
齐次泊松过程 (NHPP)来描述：
? 其中,N是在测试中可能发现的故
障总数,b是故障发现率。
? 当 N一定时,b越大，在短期内发现
的故障越多。
? ?m t N e bt( ) ? ? ?1
? N 可以认为是 当测试时间无限延长
时 估计可能发现的故障总数 。由于
? 测试的不完全，在某些很难发现的
故障未发现前就可能结束测试
? 若程序中潜在的故障较少，则参数
N的估计误差较大
? 因此，只用测试中累积发现的故障
数来评价测试是不够的。需要从测
试的 量的方面 和 质的方面,全面地
评价测试。
? SPQL (Software Product Quality
Level) 用如下公式度量：
SPQL ＝ Ac× Cv
? 其中,Ac (Test Accuracy) 是 测试
的精确度,它反映了测试的质量；
Cv (Test Coveragy) 是 测试的覆盖
度,它反映了测试的数量。
测试结束时软件产品质量水准
? 测试质量的度量可以靠 测试的故障
捕捉率和遗漏率 来衡量。
? 测试数量的度量指标是 执行的测试
用例数, 确认的程序路径数 等等；
测试精确度 Ac
? 表明在测试的过程中以多大的把握
捕捉了软件中潜在的故障。
? 测定 Ac，需要预先植入播种故障，
然后通过测试，根据播种故障的捕
捉率来推测原有故障的捕获率。
? 用 ns 表示 经过相当长时间测试可能
发现的播种故障数,用 Ns 表示测试
对象软件内 预先埋设的播种故障总
数,用平均值为 m(t)的 NHPP模型 描
述测试时发现播种故障的过程
? m(t)的收敛值 m(?)＝ N
? 测试精确度 Ac的推测值：
A c ? ?
?
?
n
N
m
N
N
N
s
s s s
( )
? 若设测试过程中到时刻 ti 能发现的
累积播种故障总数为 yi,则在测试
期间可得到一连串数据
(t0,0),(t1,y1),……,( tm,ym)
? 可得到一组方程：
? 应用最小二乘法可得到参数 N 与 b
的估计值，并得到测试精确度 Ac。
y N e i ni bt i? ? ??( ),,,1 0 ?
测试覆盖率 Cv
? 表明在整个测试期间发现软件内潜
在故障的可能性有多大。
? 可通过被测试对象软件内潜在的原
有故障的捕捉率来测定的。
? 测试过程中 已发现原有故障总数 为
n0(实测值 )，经过相当长时间测试
后 可能发现的原有故障总数 为 N0，
? 采用平均值函数 m(t)的 NHPP模型
描述测试发现原有故障的过程
? m(t)的收敛值 m(?)＝ Nc
? 测试覆盖率 Cv的推测值,
Cv =
n
N
n
m
n
Nc
0
0
0 0?
?
?
( )
? 测试开始后，由于测试员对程序和
测试环境不熟悉，造成拖期。
? 为描述这种情形，对原来 NHPP的
指数型平均值函数加以改造：
? 它是 把原来的指数型平均值函数在
时间轴上平移而得到的结果, 是具
有时间延迟的 NHPP模型 。
m t N e b t d( ) ( )( )? ? ? ?1
? 测试员从发现错误征兆到确认错误，
需要反复执行程序，以再现错误，
造成时间拖延。
? 因此，在使用测试结果进行软件质
量评价时,只用指数型的 NHPP的
平均值曲线 (A)是不够的 。 实测结果
多是如 (B)所示的 S型曲线 。
m t N bt e bt( ) ( ( ) )? ? ? ?1 1
? 实验表明：
? 对于一般功能单纯的小规模的程
序模块，具有时间延迟的 NHPP
模型比较合适；
? 对于功能比较复杂的程序模块，
S型 NHPP模型比较合适；
? 对于 80000行以上的程序，最基
本的指数型 NHPP模型比较合适。
软件配臵管理
? 在软件建立时 变更是不可避免的,
因为在进行变更前没有仔细分析，
或没有进行变更控制,变更加剧了
项目中软件人员之间的混乱 。
? 协调软件开发使得混乱减到最小的
技术叫做配臵管理 。
? 配臵管理是一组标识、组织和控制
修改的活动，目的是使错误达到最
小并最有效地提高生产率。
软件配臵管理的概念
? 软件配臵管理，简称 SCM，是一种
“保护伞”活动，它 应用于整个软
件工程过程 。
? SCM活动的目标是为了
(1) 标识变更；
(2) 控制变更；
(3) 确保变更正确地实现；
(4) 向其他有关的人报告变更。
? 在软件工程过程中产生的所有信息
项（文档、报告、程序、表格、数
据） 构成了软件配臵 。
? 软件配臵是软件的具体形态在某一
时刻的瞬时影像。
? 随着软件工程过程的进展,软件配
臵项 (SCI)数目快速增加。系统规
格说明可繁衍出软件项目实施计划
和软件需求规格说明。它们又依次
繁衍出建立信息层次的其它文档 。
基线 (Baseline)
? 基线是软件生存期中各开发阶段末
尾的特定点，又称里程碑。
? 由正式的技术评审而得到的 SCI协
议和软件配臵的正式文本才能成为
基线。
? 基线的 作用是把各阶段工作的划分
更加明确化,以便于检验和肯定阶
段成果。
软件开发各阶段的基线
项目数据库
? 一旦 一个 SCI成为基线, 就把它存
放到项目数据库中 。
? 当软件组织成员想要 对基线 SCI进
行修改时, 把它从项目数据库中复
制到该工程师的专用工作区中 。
? 例如，把一个 名为 B的 SCI从项目
数据库复制到工程师的专用工作区
中 。 工程师在 B'（ B的副本）上完
成要求的变更, 再用 B'来更新 B。
? 有些系统中把这个基线 SCI锁定。
? 在变更完成、评审和批准之前，不
许对它做任何操作。
基线 SCI和项目数据库
软件配臵项 SCI
? 软件配臵管理的对象就是 SCI—软
件配臵项 。
? 系统规格说明
? 软件项目实施计划
? 软件需求说明
? 可执行的原型
? 初步的用户手册
? 设计规格说明
? 源代码清单
? 测试计划和过程、测试用例和测
试结果记录
? 操作和安装手册
? 可执行程序（可执行程序模块、
连接模块）
? 数据库描述（模式和文件结构、
初始内容）
? 正式的用户手册
? 维护文档（软件问题报告、维护
请求、工程变更次序）
? 软件工程标准
? 项目开发总结
? 除以上所列 SCI以外，许多软件工
程组织还把 配臵控制之下的软件工
具 列入其中，即 编辑程序, 编译程
序, 其它 CASE工具的特定版本 。
因为要使用这些工具来生成文档、
程序和数据，如果编译程序的版本
不同，可能产生的结果也不同。
配臵对象
? 在实现 SCM时，把 SCI组织成配臵
对象,在项目数据库中用一个 单一
的名字来组织它们 。
? 一个配臵对象有一个 名字 和一组 属
性,并通过某些联系“连接”到其
它对象。
? 每个对象与其它对象的联系用箭头
表示。箭头指明了一种构造关系。
配臵对象
? 双向箭头则表明一种相互关系 。如
果对“源代码”对象作了一个变更，
软件工程师就可以根据这种相互关
系确定，其它哪些对象（和 SCI）
可能受到影响。
软件配臵管理的任务
? 软件配臵管理（ SCM）的任务是：
? 标识单个的 SCI
? 标识和管理软件各种版本
? 控制变更
? 审查软件配臵
? 报告所有加在配臵上的变更。
配臵标识
? 一方面随着软件生存期的向前推进，
SCI的数量不断增多 。
? 整个软件生存期的 软件配臵就象一
部不断演变的电影,而某一时刻的
配臵就是这部电影的一个片段。
? 为了方便 对软件配臵的各个片段
（ SCI） 进行控制和管理,不致造
成混乱，首先应给它们 命名 。
对象类型
? 基本对象, 是由软件工程师在分析、
设计、编码和测试时所建立的 文本
单元 。例如，基本对象可能是需求
规格说明中的一节，一个模块的源
程序清单、一组用来测试一个等价
类的测试用例。
? 复合对象, 是基本对象或其它复合
对象的 一个收集 。
? 对象标识：
（名字、描述、资源、实现）
? 对象的 名字 明确地标识对象。
? 对象 描述 包括,SCI类型 （如文档、
程序、数据）,项目标识, 变更 和
／或 版本信息 。
? 资源 包括由对象 产生的, 处理的,
引用的 或 其它需要 的 一些实体 。
? 基本对象的实现 是 指向 文本单元 的
指针,复合对象的实现为 null。
命名对象之间的联系
? 对象的层次关系,一个对象可以
是一个复合对象的一个组成部分，
用联系 < is part of >标识 。
E-R diagram 1.4 < is part of >
data model;
data model < is part of > Design
Specification;
? 就可以建立 SCI的一个层次。
? 对象的相互关联关系,对象跨越对
象层次的分支相互关联。这些交叉
的结构联系表达方式如下：
data model <interrelated> data flow
model;
(两个复合对象之间的相互联系 )
data model <interrelated> test case
class m;
(一个复合对象与一个特定的基本
对象之间的相互联系）
演变图
? 整个软件工程过程中所涉及的软件
对象都必须加以标识。
? 在对象成为基线以前可能要做多次
变更，在成为基线之后也可能需要
频繁地变更。
? 对于每一配臵对象都可以建立一个
演变图,用演变图记叙对象的 变更
历史 。
演变图
? 在某些工具中，当前保持的 只是最
后版本的完全副本 。
? 为了得到较早时期 (文档或程序 )的
版本，可以从最后版本中,提取”
出 (由工具编目的 )变更,使得 当前
配臵直接可用,并使得 其它版本也
可用 。
版本控制
? 版本控制是 SCM的基础，它管理并
保护开发者的软件资源。
? 版本控制管理在软件工程过程中建
立起 配臵对象的不同版本 。
? 版本管理可以把 一些属性结合到各
个软件版本 上。
? 通过 描述所希望的属性集合 来 确定
（或 构造 ） 所想要的配臵 。
? 使用 演变图 来表示系统的不同版本。
? 图中的各个结点都是 聚合对象,是
一个 完全的软件版本 。
? 软件的每一版本都是 SCI（源代码、
文档、数据） 的一个收集,且各个
版本都可能由不同的变种组成。
? 例如，一个简单的程序版本由 1,2、
3,4和 5等部件组成。其中 部件 4在
软件 使用彩色显示器 时使用,部件 5
在软件 使用单色显示器 时使用。因
此，可以定义版本的两个变种。
版本管理的主要任务
? 集中管理档案，安全授权机制,
? 版本管理的操作 将开发组的档案
集中地存放在服务器上, 经系统
管理员授权给各个用户 。
? 用户通过登入（ check in）和检
出（ check out）的方式访问服务
器上的文件，未经授权的用户无
法访问服务器上的文件。
? 软件版本升级管理,
? 每次登入时，在服务器上都会生
成新的版本。
? 任何版本都可以随时检出编辑，
同一应用的不同版本可以像树枝一
样向上增长。
? 加锁功能,
? 目的是 在文件更新时保护文件,
避免不同用户更改同一文件时发
生冲突 。
? 某一文件一旦被 登入, 锁即被解
除,该文件可被其它用户使用。
? 在 更新一个文件之前锁定它,避
免变更没有锁定的项目源文件。
? 在文件登入和检出时，需要注意登
入和检出的使用,
? 当需要修改某个小缺陷时，应 只
检出完成工作必需的最少文件 ；
? 需要对文件变更时，应登入它并
加锁, 保留对每个变更的记录 ；
? 应避免长时间地锁定文件。如果
需要长时间工作于某个文件，最
好能 创建一个分支,并在分支上
做工作。
? 如果需要做较大的变更，可有两
种选择：
a.将需要的所有文件检出并加锁，
然后正常处理 ；
b.为需要修改的所有分支创建分
支，把变更与主干,脱机,，然后
把结果合并回去。
变更控制
? 软件生存期内全部的软件配臵是软
件产品的真正代表,必须使其保持
精确 。
? 软件工程过程中 某一阶段的变更,
均要 引起软件配臵的变更,这种变
更必须严格加以 控制 和 管理,保持
修改信息。
? 变更控制包括 建立控制点 和 建立报
告与审查制度 。
变更控制
过程
软件变更有两类不同情况：
? 为改正小错误需要的变更 。它是必
须进行的，通常不需要从管理角度
对这类变更进行审查和批准。但是，
如果发现错误的阶段在造成错误的
阶段的后面，例如在实现阶段发现
了设计错误，则必须遵照标准的变
更控制过程，把这个变更正式记入
文档，把所有受这个变更影响的文
档都做相应的修改。
? 为了增加或者删掉某些功能、或者
为了改变完成某个功能的方法而需
要的变更 。这类变更必须经过某种
正式的变更评价过程，以估计变更
需要的成本和它对软件系统其它部
分的影响。
? 如果变更的代价比较小且对软件
系统其它部分没有影响，或影响
很小，通常应批准这个变更。
? 如果变更的代价比较高，或者影
响比较大，则必须权衡利弊，以
决定是否进行这种变更。
? 如果同意这种变更,需要进一步
确定由谁来支付变更所需要的费
用。 如果是用户要求的变更，则
用户应支付这笔费用；否则，必
须完成某种成本／效益分析，以
确定是否值得做这种变更。
? 这种变更报告和审查制度，对变更
控制来说起了一个安全保证作用。
? 在一个 SCI成为基线之前，可以对所
有合理的项目和技术申请进行非正
式的变更；
? 一旦某个 SCI经过正式的技术评审并
得到批准，它就成了基线。以后如
果需要对它变更，就必须得到项目
负责人的批准，或者必须得到变更
控制负责人的批准。
配臵状态报告
? 为了清楚、及时地记载软件配臵的
变化，需要 对开发的过程做出系统
的记录,以反映开发活动的历史情
况。这就是配臵状态登录的任务。
? 登录主要 根据变更控制小组会议的
记录,并产生 配臵状态报告 。
? 对于每一项变更，记录：发生了什
么？为什么会发生？谁做的？什么
时侯发生的？会有什么影响？
配臵状态报告信息流
? 每次 新分配一个 SCI，或 更新一个
已有 SCI的标识,或 一项变更申请
被变更控制负责人批准, 并给出了
一个工程变更顺序 时,在配臵状态
报告中就要增加一条变更记录条目。
? 一旦进行了配臵审计，其结果也应
该写入报告之中。
? 配臵状态报告可以放在一个联机数
据库中，以便软件开发人员或者软
件维护人员可以对它进行查询或修
改。此外在软件配臵报告中新登录
的变更应当及时通知给管理人员和
软件工程师。
? 配臵状态报告对于大型软件开发项
目的成功起着至关重要的作用。避
免了可能出现的不一致和冲突。
配臵审计
? 软件的完整性,是指开发后期的 软
件产品能够正确地反映用户要求 。
? 软件配臵审计的目的就是要
? 证实整个软件生存期中各项产品
在技术上和管理上的完整性。
? 确保所有文档的内容变动不超出
当初确定的软件要求范围。使得软
件配臵具有良好的可跟踪性。
? 软件配臵审计是软件变更控制人员
掌握配臵情况, 进行审批的依据 。
? 软件的变更控制机制通常只能跟踪
到工程变更顺序产生为止。为确认
变更是否正确完成? 一般可以用以
下两种方法去审查：
? 正式技术评审
? 软件配臵审计
? 正式的技术评审 着重 检查已完成修
改的软件配臵对象的技术正确性,
? 评审者 评价 SCI，决定它与其它
SCI的一致性，是否有遗漏或可能
引起的副作用。
? 正式技术评审应对所有的变更进行，
除了那些最无价值的变更之外。
? 软件配臵审计 作为正式技术评审的
补充,评价在评审期间通常没有被
考虑的 SCI的特性 。
