高质量的软件是一个重要目标,即使最疲倦的软件开发人员也会同意这一点。但是,如何定义软件质量呢?在最一般的意义上,软件质量可以这样定义:在一定程度上应用有效的软件过程,创造有用的产品,为生产者和使用者提供明显的价值。
毫无疑问,对上述定义可以进行修改、扩展以及无休止的讨论。针对本书的论题来说,该定义强调了以下三个重要的方面:
1.有效的软件过程为生产高质量的软件产品奠定了基础。过程的管理方面所做的工作是检验和平衡,以避免项目混乱(低质量的关键因素)。软件工程实践允许开发人员分析问题、设计可靠的解决方案,这些都是生产高质量软件的关键所在。最后,诸如变更管理和技术评审等普适性活动与其他部分的软件工程活动密切相关。
提问
如何为软件质量下一个最好的定义?
引述
作为卓越的代名词,一些人并不能适应需要杰出素质的环境。
—— Steve Jobs
2.有用的产品是指交付最终用户要求的内容、功能和特征,但最重要的是,以可靠、无误的方式交付这些东西。有用的产品总是满足利益相关者明确提出的那些需求,另外,也要满足一些高质量软件应有的隐性需求(例如易用性)。
3.通过为软件产品的生产者和使用者增值,高质量软件为软件组织和最终用户群体带来了收益。软件组织获益是因为高质量的软件在维护、改错及客户支持方面的工作量都降低了,从而使软件工程师减少了返工,将更多的时间花费在开发新的应用上,软件组织因此而获得增值。用户群体也得到增值,因为应用所提供的有用的能力在某种程度上加快了一些业务流程。最后的结果是:(1)软件产品的收入增加;(2)当应用可支持业务流程时,收益更好;(3)提高了信息可获得性,这对商业来讲是至关重要的。
1 Garvin的质量维度
David Garvin[Gar87]建议采取多维的观点考虑质量,包括从符合性评估到抽象的(美学)观点。尽管Garvin的8个质量维度没有专门为软件制定,但考虑软件质量时依然可以使用。
性能质量。软件是否交付了所有的内容、功能和特性?这些内容、功能和特性在某种程度上是需求模型所规定的一部分,可以为最终用户提供价值。
特性质量。软件是否提供了使第一次使用的最终用户感到惊喜的特性?
可靠性。软件是否无误地提供了所有的特性和能力,当需要使用该软件时,它是否是可用的,是否无错地提供了功能?
建议
当应用采用了Garvin的质量维度时,可以使用雷达图提供每个Garvin质量维度的可视化表现形式。
符合性。软件是否遵从本地的和外部的与应用领域相关的软件标准,是否遵循了事实存在的设计惯例和编码惯例?例如,对于菜单选择和数据输入等用户界面的设计是否符合人们已接受的设计规则?
耐久性。是否能够对软件进行维护(变更)或改正(改错),而不会粗心大意地产生意想不到的副作用?随着时间的推移,变更会使错误率或可靠性变得更糟吗?
适用性。软件能在可接受的短时期内完成维护(变更)和改正(改错)吗?技术支持人员能得到所需的所有信息以进行变更和修正缺陷吗?Douglas Adams[Ada93]挖苦地评论道:“可能发生故障的东西与不可能发生故障的东西之间的差别是,当前者发生了故障时,通常是不可能发现和补救的”。
审美。毫无疑问,关于什么是美的,我们每个人有着不同的、非常主观的看法。可是,我们中的大多数都同意美的东西具有某种优雅、特有的流畅和醒目的外在,这些都是很难量化的,但显然是不可缺少的,美的软件具有这些特征。
感知。在某些情况下,一些偏见将影响人们对质量的感知。例如,有人给你介绍了一款软件产品,该软件产品是由过去曾经生产过低质产品的厂家生产的,你的自我保护意识将会增加,你对于当前软件产品质量的感知力可能受到负面影响。类似地,如果厂家有极好的声誉,你将能感觉到好的质量,甚至在实际质量并不真的如此时,你也会这样想。
Garvin 的质量维度提供了对软件质量的“软”评判。这些维度中的多数(不是所有)只能主观地考虑。正因如此,也需要一套“硬”的质量因素,这些因素可以宽泛地分成两组:(1)可以直接测量的因素(例如,测试时发现的缺陷数);(2)只能间接测量的因素(例如,可用性或可维护性)。在任何情况下,必须进行测量,应把软件和一些基准数据进行比较来确定质量。
2 McCall的质量因素
McCall、Richards和Walters[McC77] 提出了影响软件质量因素的一种有用的分类。这
些软件质量因素侧重于软件产品的三个重要方面:操作特性、承受变更的能力以及对新环境
的适应能力,如图15-1所示。
针对图15-1中所提到的因素,McCall 及他的同事提供了如下描述:
正确性。程序满足其需求规格说明和完成用户任务目标的程度。
可靠性。期望程序以所要求的精度完成其预期功能的程度。需要提醒大家注意的是,还有更完整的可靠性定义。
效率。程序完成其功能所需的计算资源和代码的数量。
完整性。对未授权的人员访问软件或数据的可控程度。
易用性。对程序进行学习、操作、准备输入和解释输出所需要的工作量。
可维护性。查出和修复程序中的一个错误所需要的工作量。(这是一个非常受限的定义。)
引述
满足进度计划的喜悦已经被遗忘很久之后,低质量所带来的痛苦依然挥之不去。
—— Karl Weigers
灵活性。修改一个运行的程序所需的工作量。
易测试性。测试程序以确保它能完成预期功能所需要的工作量。
可移植性。将程序从一个硬件和软件系统环境移植到另一个环境所需要的工作量。
可复用性。程序(或程序的一部分)可以在另一个应用中使用的程度。这与程序所执行
功能的封装和范围有关。
互操作性。将一个系统连接到另一系统所需要的工作量。
要想求得这些质量因素的直接测度【直接测度意味着存在一个简单可计算的值。该值为被考察的属性提供直接的指标。例如,程序的“规模”可以通过计算代码的行数直接测量。】是困难的,且在有些情况下是不可能的。事实上,由McCall等人定义的度量仅能间接地测量。不过,使用这些因素评估应用的质量可以真实地反映软件的质量。
3 ISO 9126质量因素
ISO 9126国际标准的制定是试图标识计算机软件的质量属性。这个标准标识了6个关键的质量属性。
功能性。软件满足已确定要求的程度,由以下子属性表征:适合性、准确性、互操作性、依从性和安全性。
可靠性。软件可用的时间长度,由以下子属性表征:成熟性、容错性和易恢复性。
易用性。软件容易使用的程度,由以下子属性表征:易理解性、易学习性和易操作性。
效率。软件优化使用系统资源的程度,由以下子属性表征:时间特性和资源利用特性。
可维护性。软件易于修复的程度,由以下子属性表征:易分析性、易改变性、稳定性和易测试性。
可移植性。软件可以从一个环境移植到另一个环境的容易程度,由以下子属性表征:适应性、易安装性、符合性和易替换性。
ISO9126中的质量因素不一定有助于直接测量。然而,它们确实为间接测量提供了有价值的基础,并为评估系统质量提供了一个优秀的检查单。
建议
尽管为这里提到的质量因素制定量化测量是很诱人的,但你也可以创建一个简单的属性清
单来提供显示质量因素的可靠指标。
4 定向质量因素
质量维度和因素关注软件的整体,可以用其作为表征应用质量的一般性指标。软件团队可以提出一套质量特征和相关的问题以调查软件满足每个质量因素的程度。例如:McCall把易用性看作重要的质量因素。当要求评审用户界面和评估易用性时,该如何进行?可能要从McCall提出的子属性一易理解性、易学习性和易操作性开始,但是在实用的意义上,这些子属性表示什么意思呢?
引述
当从业人员想将事情做正确或做得更好时,任何活动都将变得富有创造性。
—— John Updike
为了进行评价,需要说清楚界面具体的、可测量的(或至少是可识别的)属性。例如下面这些属性[Bro03]。
直觉。界面遵照预期使用模式的程度,使得即使是新手也能不经过专门培训而开始使用。
- 界面布局易于理解吗?
- 界面操作容易找到和上手吗?
- 界面使用了可识别的隐喻吗?
- 输入的安排可尽量少敲击键盘和点击鼠标吗?
- 界面符合三个重要原则吗(第14章)?
- 美学的运用有助于理解和使用吗?
效率。定位或初步了解操作和信息的程度。
- 界面的布局和风格可以使用户有效地找到操作和信息吗?
- 一连串的操作(或数据输入)可以用简单动作实现吗?
- 输出的数据和显示的内容是否能立即被理解?
- 分层操作是否组织得能使用户完成某项工作所需导航的深度最小?
健壮性。软件处理有错的输入数据或不恰当的用户交互的程度。
- 如果输入了规定边界上的数据或恰好在规定边界外的数据,软件能识别出错误吗?更为重要的是,软件还能继续运行而不出错或性能不下降吗?
- 界面能识别出常见的可识别错误或操作错误,并能清晰地指导用户回到正确的轨道上来吗?
- 若发现了错误的情况(与软件功能有关),界面是否提供了有用的诊断和指导?
丰富性。界面提供丰富特征集的程度。
- 界面是否能按照用户的特定要求进行定制?
- 界面是否提供宏操作以使用户将单个的行为或命令当作一连串的常用操作?
当界面设计展开后,软件团队将评审设计原型,询问他们所关注的问题。如果对这些问题的大多数回答是“肯定的”,用户界面就具备了高质量。应该为每个待评估的质量因素开发出类似的一组问题。
5 过渡到量化观点
软件界也力图开发软件质量的精确的测度,但有时又会为活动的主观性而受挫。Cavano和McCall[Cav78]讨论了这种情形:
质量评定是日常事件(葡萄酒品尝比赛、运动赛事(如体操)、智力竞赛等)中的一个关键因素。在这些情况下,质量是以最基本、最直接的方式来判断的:在相同的条件和预先决定的概念下将对象进行并列对比。葡萄酒的质量可以根据清澈度、颜色、酒花和味道等来判断。然而,这种类型的判断是很主观的,最终的结果必须由专家给出。
主观性和特殊性也适用于软件质量的评定。为了帮助解决这个问题,需要对软件质量有一个更精确的定义,同样,为了客观分析,需要产生软件质量的定量测量方法……既然没有这种事物的绝对知识,就不要期望精确测量软件质量,因为每一种测量都是部分地不完美的。Jacob Bronkowski这样描述知识的自相矛盾现象:“年复一年,我们设计更精准的仪器用以更精细地观察自然界,可是当我们留心这些观察数据,却很不愉快地发现这些数据依然模糊时,我们感到它们还和过去一样不确定。”
建议
当面临质量困境时(每个人都会在某个时期面对它),尽力得平衡——用足够的工作量去开发质量可接受的产品,而不是将项目葬送掉。
软件度量可应用于软件质量的定量评估。在所有的情况下,这些度量都表示间接的测度。也就是说,我们从不真正测量质量,而是测量质量的一些表现。复杂因素在于所测量的变量和软件质量间的精确关系。