质量度量模型

软件的质量由一系列质量要素组成，每一个质量要素又由一些衡量标准组成，每个衡量
标准又由一些量度标准加以定量刻画。质量度量贯穿于软件工程的全过程以及软件交付之
后，在软件交付之前的度量（内部属性）主要包括程序复杂性、模块的有效性和总的程序规
模。在软件交付之后的度量（外部属性）则主要包括残存的缺陷数和系统的可维护性方面。
ISO 9126 称为“软件产品评价：质量特性及使用指南”。在这个标准中，把软件质量定
义为“与软件产品满足声明的或隐含的需求能力有关的特性和特性的总和”，可以分为 6 个
特性，即：功能性、可靠性、效率、可使用性、可维护性以及可移植性。这 6 大特性，每个
特性包括一系列副特性，其中各质量特性和质量子特性的含义如下：
特性 副特性
1 功能性(functionality)：与一组功能
及其指定的性质的存在有关的一组属
性。功能是指满足规定或隐含需求的那
些功能。
适合性(suitability)：与对规定任务能否提供一组功能
以及这组功能是否适合有相关的软件属性。
准确性(accurateness)：与能够得到正确或相符的结果
或效果有关的软件属性。
互用性(interoperability)：与同其他指定系统进行交
互操作的能力相关的软件属性。
依从性(compli ance)：使软件服从有关的标准、约定、
法规及类似规定的软件属性。
安全性(security)：与避免对程序及数据的非授权故意
或意外访问的能力有关的软件属性。
2 可靠性(reliability)：与在规定的一
段时间内和和规定的条件下，软件维持
其性能的有关能力。
成熟性(maturity)：与由软件故障引起实效的频度有关
的软件属性。
容错性(fauIt tolerance)：与在软件错误或违反指定接
口的情况下，维持指定的性能水平的能力有关的软件属
性。
易恢复性(recoverability)：与在故障发生后，重新建
立其性能水平并恢复直接受影响数据的能力，以及为达
到此目的所需的时间和努力有关的软件属性。
3 易使用性(usability)：与为使用所需
的努力和由一组规定或隐含的用户对
这样所作的个别评价有关的一组属性。
易理解性(understandability)：与用户为理解逻辑概念
及其应用所付出的劳动有关的软件属性。
易学性(1earnability)：与用户为学习其应用(例如操作
控制、输入、输出)所付出的努力相关的软件属性。
易操作性(Operability)：与用户为进行操作和操作控制
所付出的努力有关的软件属性。
4 效率(efficiency)：在规定条件下，
软件的性能水平与所用资源量之间的
关系有软件属性
资源特性(resource behavior)：与软件执行其功能时，
所使用的资源量以及使用资源的持续时间有关的软件属
性。
5 可维护性
(maintaina bility)：与进行规定的
修改所需要的努力有关的一组属性。
易分析性(analyzability)：与为诊断缺陷、失效原因或
判定待修改的部分所需努力有关的软件属性。
易改变性(changeability)：与进行修改、排错或适应环
境变换所需努力有关的软件属性。
稳定性(sta、bility)：与修改造成未预料效果的风险有
关的软件属性。
易测试性(testability)：为确认经修改软件所需努力有
关的软件属性。
6 可移植性(portability)：与软件可从
某一缓建转移到另一环境的能力有关
的一属性。
适应性(adaptability)：与一软件无需采用有别于为关
软件准备的处理或手段就能适应不同的规定环境有关的
软件属性。
易安装性(installability)：与在指定环境下安装软件
所需努力有关的软件属性。
一致性(conformance)：使软件服从与可移植性有关的标
准或约定的软件属性。
易替换性(replaceability)：与一软件在该软件环境中
用来替代指定的其他软件的


把软件的质量度量引申到架构设计，就衍生出了架构的质量属性和其实现的问题。我们
可以通过下面的检查表来描述和构造自己的质量度量模型。
软件架构的质量属性
编
号
名称 内容
1 性能 每个用例的预期响应时间是多少。
平均/最慢/最快的预期响应时间是多少。
需要使用哪些资源（CPU,局域网等）。
需要消耗多少资源。
使用什么样的资源分配策略。
预期的并行进程有多少个。
有没有特别耗时的计算过程。
服务器是单线程还是多线程。
有没有多个线程同时访问共享资源的问题，如果有，如何来管理。
不好的性能会在多大程度上影响易用性。
响应时间是同步的还是异步的。
系统在一天、一周或者一个月，系统性能变化是怎样的。
预期系统负载增长是怎样的。
2 可用性 系统故障有多大的影响。
如何识别是硬件故障还是软件故障。
系统发生故障后，能多快恢复。
在故障情况下，有没有备用系统可以接管。
如何才能知道，所有的关键功能已经被复制了呢。
如何进行备份，备份和恢复系统需要多长时间。
预期的正常工作时间是多少小时。
每个月预期的正常工作时间是多少。
3 可靠性 软件或者硬件故障的影响是什么。
软件性能不好会影响可靠性吗。
不可靠的性能对业务有多大影响。
数据完整性会受到影响吗。
4 功能 系统满足用户提出的所有功能需求了吗。
系统如何应付和适应非预期的需求。
5 易用性 用户界面容易理解吗。
界面需要满足残疾人的需求吗。
开发人员觉得用来开发的工具是易用的和易理解的吗。
6 可移植性 如果使用专用开发平台的话，用它的优点真的比缺点多吗。
建立一个独立层次的开销值得吗。
系统的可移植性应该在哪一级别来提供呢（应用程序、应用服务器、操
作系统还是硬件级别）。

7 可重用性 该系统是一系列的产品线的开始吗。
其它建造的系统有多少和现有系统有关呢？如果有，其他系统能重用吗。
哪些现有构件是可以重用的。
现有的框架和其它代码能够被重用吗。
其它应用程序可以使用这个系统的基础设施吗。
建立可重用的构件，代价、风险、好处是什么。
8 集成性 于其它系统进行通信的技术是基于现行的标准吗。
构件的接口是一致的和容易理解的吗。
有解释构件接口的过程吗。
9 可测试性 有可以测试语言类、构件和服务的工具、过程和技术吗。
框架中有可以进行单元测试的接口吗。
有自动测试工具可以用吗。
系统可以在测试器中运行吗。
10 可分解性 系统是模块化的吗。
系统之间有序多依赖关系吗。
对一个模块的修改会影响其它模块吗。
11 概念完整性 人们理解这个架构吗。是不是有人问很多很基本的问题呢。
架构中有没有自相矛盾的决策。
新的需求很容易加到架构中来吗。
12 可完成性 有足够的时间、金钱和资源来建立架构基准和整个项目吗。
架构是不是太复杂。
架构足够的模块化来支持并行开发吗。
是不是有太多的技术风险呢。