语言 Chinese, Simplified

SEO Title

在软件工程的背景下，软件质量是指两个相关但不同的概念：

基于功能需求或规范，软件功能质量反映了它在多大程度上符合或符合给定的设计。这个属性也可以被描述为一个软件的适用性，或者它作为一个有价值的产品如何与市场上的竞争对手进行比较。
软件结构质量是指它如何满足支持功能需求交付的非功能需求，如健壮性或可维护性。这与软件按需工作的程度有很大关系。

只有通过对软件内部结构、源代码、单元级、技术级和系统级的分析，才能对结构质量的许多方面进行静态评估，这实际上就是它的体系结构如何遵循OMG在一篇关于这个主题的论文中概述的软件体系结构的合理原则。[2]但是一些结构质量，例如可用性，只能动态地评估（用户或其他代表他们的人与软件交互，或者至少是一些原型或部分实现；甚至与纸板制作的模拟版本的交互也代表了一个动态测试，因为这样的版本可以被视为一个原型）。其他方面，如可靠性，可能不仅涉及软件，还涉及底层硬件，因此，可以静态和动态评估（压力测试）。

功能质量通常是动态评估的，但也可以使用静态测试（如软件评审）。

历史上，适用于软件质量管理的属性和度量的结构、分类和术语是从ISO 9126-3和随后的ISO 25000:2005[3]质量模型（也称为SQuaRE[4]）中派生或提取的，IT软件质量联盟（CISQ）定义了一个软件提供业务价值所需的五个主要理想结构特征：可靠性、效率、安全性、可维护性和（足够的）规模。

软件质量度量量化了软件程序或系统在这五个维度中的每一个维度上的评分。软件质量的综合度量可以通过一个定性或定量的评分方案或两者的混合，然后通过一个反映优先级的加权系统来计算。这种将软件质量定位在线性连续统上的观点得到了对“关键编程错误”的分析的补充，在特定情况下，这些错误可能导致灾难性的中断或性能下降，从而使给定的系统不适合使用，而不管基于聚合测量的评级如何。在系统级发现的此类编程错误最多代表90%的生产问题，而在单元级，即使数量更多，编程错误也只占不到10%的生产问题。因此，正如W.Edwards-Deming所描述的，没有整个系统上下文的代码质量具有有限的价值。

为了查看、探索、分析和交流软件质量度量，信息可视化的概念和技术提供了可视化的、交互式的有用方法，特别是当几个软件质量度量必须相互关联或与软件或系统的组件相关时。例如，软件地图代表了一种专门的方法，它“可以表达和组合关于软件开发、软件质量和系统动力学的信息”

动机

“科学和它的测量工具一样成熟”（路易斯·巴斯德在《埃伯特与杜姆克》中，第91页）。衡量软件质量的动机至少有两个：

风险管理：软件故障给我们带来的不仅仅是不便。软件错误已导致人员死亡。原因从设计不良的用户界面到直接的编程错误都有。Leveson博士的论文中讨论了导致多人死亡的编程错误的一个例子。[6]这导致了对某些类型软件的开发需求，特别是在历史上，对于嵌入在医疗和其他设备中的软件，用于管理关键基础设施：“[编写嵌入式软件的工程师]参见Java程序暂停三分之一秒以执行垃圾收集和更新用户界面，他们设想飞机从天上掉下来。”[7]在美国，联邦航空管理局（FAA）内，FAA飞机认证服务提供软件程序、政策、指导和培训，关注对机载产品有影响的软件和复杂的电子硬件（“产品”是飞机、发动机或螺旋桨）
成本管理：与其他工程领域一样，具有良好结构软件质量的应用程序维护成本较低，更容易理解并根据紧迫的业务需求进行更改。行业数据表明，核心业务应用程序（如企业资源规划（ERP）中的应用程序结构质量较差，客户关系管理（CRM）或金融服务中的大型交易处理系统）会导致成本和进度超支，并以返工的形式造成浪费（某些组织的开发时间高达45%[9]）。此外，由于数据损坏、应用程序中断、安全漏洞和性能问题，较差的结构质量与高影响的业务中断密切相关。

然而，衡量和提高嵌入式系统中的软件质量（强调风险管理）和商业软件中的软件质量（强调成本和可维护性管理）之间的区别变得有些无关紧要。嵌入式系统现在通常包括一个用户界面，他们的设计师和专注于商业应用的同行一样，都非常关注影响可用性和用户生产力的问题。后者则将ERP或CRM系统视为一个企业神经系统，其正常运行时间和性能对企业的福祉至关重要。这种融合在移动计算中最为明显：在智能手机上访问ERP应用程序的用户取决于跨所有类型软件层的软件质量。

这两种类型的软件现在都使用多层技术栈和复杂的体系结构，因此软件质量分析和度量必须以全面和一致的方式进行管理，与软件的最终目的或用途分离。在这两种情况下，工程师和管理层都需要能够根据测量和基于事实的分析，遵循“上帝（我们）信任”的原则，做出合理的决策。所有其他人都带来了数据”。（（mis-）归于W.Edwards Deming等人）。

定义

质量有许多不同的定义。对于某些人来说，它是“软件产品符合要求的能力”（ISO/IEC 9001，[10]由[11]评论），而对于其他人来说，它可以是“客户价值”（Highsmith，2002）甚至是缺陷级别的同义词。

质量历史记忆的第一个定义来自20世纪初的休哈特：质量有两个共同的方面：一是把事物的质量看作独立于人的存在的客观现实。另一种则与客观现实的结果是我们的思想、感觉或感觉有关。换句话说，质量有主观的一面。（休哈特[12]）

Kitchenham、Pfleeger和Garvin对质量的五种观点

Kitchenham和Pfleeger，[13]进一步报道了David Garvin的教导，[14]确定了质量的五种不同观点：

超验的观点涉及质的形而上学方面。在这种质量观中，它是“我们作为一种理想而努力追求的东西，但可能永远不会完全实现”。[13]它很难定义，但类似于一位联邦法官对淫秽行为的评论：“我看到它就知道了”。[15]
用户视角关注的是产品在给定的使用环境中的适当性。超越的观点是虚幻的，而用户的观点则更具体，基于满足用户需求的产品特性
制造视角表示质量符合要求。质量的这一方面受到诸如ISO 9001等标准的强调，该标准将质量定义为“一组固有特性满足要求的程度”（ISO/iec9001[10]）。
从产品的角度看，质量可以通过测量产品的固有特性来获得。
质量的最终观点是基于价值的。这种观点认识到，不同的质量观点对不同的利益相关者可能具有不同的重要性或价值。

根据Deming的软件质量

沃尔特·a·休哈特大师指出了试图定义产品（几乎是任何产品）质量所固有的问题。定义质量的困难在于将用户的未来需求转化为可测量的特性，从而设计和生产出满足用户需求的产品。这并不容易，只要一个人觉得这项努力相当成功，他就会发现消费者的需求已经改变，竞争对手已经进入，等等

- W.爱德华兹·德明

根据Feigenbaum的软件质量

质量是顾客的决定，不是工程师的决定，不是市场的决定，也不是一般管理的决定。它是基于顾客对产品或服务的实际经验，根据顾客的要求来衡量的——陈述的或未陈述的、有意识的或仅仅感觉到的、技术上可操作的或完全主观的——并且总是代表竞争市场中的一个移动目标

根据Juran的软件质量

质量这个词有多种含义。这两个意思支配着这个词的用法：1。质量是指满足顾客需求，从而提供产品满意度的产品特性。2。质量包括没有缺陷。然而，在这样一本手册中，将质量一词的简短定义标准化为“适合使用”是很方便的

CISQ质量模型

尽管“质量是一个感性的、有条件的和有点主观的属性，不同的人可能会有不同的理解”（正如在关于商业质量的文章中所指出的），软件结构质量特性已经由IT软件质量联盟（CISQ）明确定义。在能力成熟度模型框架（Capability Maturity Model framework）的合著者、CISQ的第一任董事比尔•柯蒂斯（Bill Curtis）和CISQ的杰出顾问卡珀斯•琼斯（Capers Jones）的指导下，CISQ定义了一款提供业务价值所需的软件的五大可取特征。[19]在质量屋模型中，这些是需要实现的“目标”：

可靠性

弹性和结构坚固的特性。可靠性衡量风险水平和潜在应用程序故障的可能性。它还测量由于对软件进行修改而注入的缺陷（ISO称之为“稳定性”）。检查和监视可靠性的目标是减少和防止直接影响用户的应用程序停机、应用程序中断和错误，并增强IT形象及其对公司业务绩效的影响。

效率

源代码和软件架构属性是在应用程序处于运行时模式时确保高性能的元素。对于高执行速度环境（如算法或事务处理）中的应用程序，效率尤其重要，因为在这些环境中，性能和可伸缩性是至关重要的。通过对源代码效率和可伸缩性的分析，可以清楚地了解潜在的业务风险及其由于响应时间降低而对客户满意度造成的危害。

安全

一种度量由于糟糕的编码实践和体系结构而导致潜在安全漏洞的可能性的方法。这将量化遇到损害业务的关键漏洞的风险。[20]

可维护性

可维护性包括适应性、可移植性和可移植性（从一个开发团队到另一个开发团队）的概念。对于任务关键型应用程序来说，测量和监视可维护性是必须的，因为在这些应用程序中，更改是由紧的上市时间安排驱动的，并且对于it来说，保持对业务驱动的更改的响应非常重要。还必须控制维修费用。

大小

虽然源代码的大小本身不是一个质量属性，但它是一个明显影响可维护性的软件特性。结合上述质量特征，软件规模可用于评估团队生产和完成的工作量，以及通过与时间表数据和其他SDLC相关度量的相关性来评估团队的生产力。

软件功能质量被定义为与明确规定的功能需求的一致性，例如使用客户的声音分析（六西格玛工具包设计的一部分和/或通过用例记录）和最终用户体验到的满意程度来确定。后者被称为可用性，关注用户界面的直观性和响应性，简单和复杂的操作执行的容易程度，以及错误消息的有用程度。通常，软件测试实践和工具确保一个软件的行为符合最初的设计、计划的用户体验和期望的可测试性，即一个支持验收标准的软件配置。

软件质量的双重结构/功能维度与Steve McConnell的完整代码中提出的模型一致，该模型将软件特性分为两部分：内部质量特性和外部质量特性。外部质量特征是产品面向用户的部分，而内部质量特征则是不面向用户的部分。[21]

替代方法

定义质量的一个挑战是“每个人都觉得自己理解它”[22]而软件质量的其他定义可以基于扩展业务中使用的质量概念的各种描述。

Tom DeMarco博士提出，“一个产品的质量是它如何改变世界变得更好的函数。”[23]这可以解释为功能质量和用户满意度在决定软件质量时比结构质量更重要。

Gerald Weinberg在《质量软件管理：系统思维》中提出的另一个定义是“质量对某些人是有价值的。”[24][25]这个定义强调质量本质上是主观的，不同的人对同一个软件的质量会有不同的体验。这个定义的一个优点是它邀请软件团队考虑的问题，例如“谁是我们想要重视我们的软件的人？”还有“什么对他们有价值？”。

测量

尽管本节中提出的概念适用于结构和功能软件质量，但后者的度量基本上是通过测试来执行的[见主要文章：软件测试]。

介绍

软件期望特性（右）和可测量属性（左）之间的关系。

软件质量度量是指量化一个系统或软件在多大程度上具有期望的特性。这可以通过定性或定量的方法或两者的混合来实现。在这两种情况下，对于每个期望的特征，都有一组可测量的属性，这些属性在软件或系统中的存在往往与此特征相关。例如，与可移植性相关联的属性是程序中目标相关语句的数量。更准确地说，使用质量功能部署方法，这些可测量的属性是需要强制执行的“hows”，以启用上面软件质量定义中的“what”。

适用于软件质量管理的属性和度量的结构、分类和术语是从ISO 9126-3和随后的ISO/IEC 25000:2005质量模型中派生或提取的。主要关注内部结构质量。已经创建了子类别来处理特定的领域，如业务应用程序体系结构和技术特性，如数据访问和操作或事务的概念。

软件质量特征与其可度量属性之间的依赖树在右侧的图表中表示，其中对业务系统的用户（右侧）或所有者重要的5个特征中的每一个都依赖于可度量属性（左侧）：

应用架构实践
编码实践
应用程序复杂性
文档
可移植性
技术和功能卷

编程错误和产品缺陷之间的相关性揭示了基本代码错误占源代码中总错误的92%。这些众多的代码级问题最终只占生产中缺陷的10%。体系结构级别的不良软件工程实践仅占缺陷总数的8%，但却花费了一半以上的精力来解决问题，并导致了生产中90%的严重可靠性、安全性和效率问题。[26]

基于代码的分析

许多现有的软件度量都计算应用程序的结构元素，这些元素是为这些单独的指令解析源代码（Park，1992）、[27]令牌（Halstead，1977）、[28]控制结构（McCabe，1976）和对象（Chidamber&Kemerer，1994）而产生的

软件质量度量就是量化一个系统或软件在这些维度上的速率。分析可采用定性或定量方法，或两者结合的方式进行，以提供总体视图[例如使用反映被测因素之间相对重要性的加权平均值]。

线性连续统上软件质量的这种观点必须通过识别离散的关键编程错误来补充。这些漏洞可能不会使测试用例失败，但它们是在特定情况下可能导致灾难性停机、性能下降、安全漏洞、损坏数据和无数其他问题的不良做法的结果（Nygard，2007）[30]，这些问题使得给定的系统事实上不适合使用，而不管其基于聚合度量。一个众所周知的漏洞示例是公共弱点枚举，[31]源代码中的漏洞库，使应用程序暴露于安全漏洞。

关键应用程序特性的度量包括度量应用程序架构、编码和联机文档的结构属性，如上图所示。因此，每个特性都受到应用程序中许多抽象层次上的属性的影响，如果要使特性成为影响业务的质量结果的有价值的预测因素，则必须包括计算特性的度量。上图所示的计算特征量的分层方法是由Boehm及其同事在TRW（Boehm，1978）[32]首次提出的，是ISO 9126和25000系列标准中采用的方法。这些属性可以从应用程序源代码的静态分析的解析结果中度量。即使是应用程序的动态特性（如可靠性和性能效率）也有其根源于应用程序的静态结构。

结构质量分析和测量是通过分析源代码、体系结构、软件框架、数据库模式以及共同定义系统概念和逻辑体系结构的原则和标准来进行的。这与通常由开发工具执行的基本的、本地的、组件级代码分析不同，开发工具主要关注实现方面的考虑，并且在调试和测试活动中至关重要。

可靠性

可靠性差的根本原因是不符合良好的体系结构和编码实践。这种不符合性可以通过测量应用程序的静态质量属性来检测。评估应用程序可靠性背后的静态属性，可以估计业务风险的级别，以及应用程序在运行时可能遇到的潜在应用程序故障和缺陷的可能性。

评估可靠性需要至少检查以下软件工程最佳实践和技术属性：

应用架构实践
编码实践
算法的复杂性
编程实践的复杂性
遵守面向对象和结构化编程最佳实践（如适用）
组件或模式再利用率
脏程序设计
错误和异常处理（适用于所有层-图形用户界面、逻辑和数据）
多层设计符合性
资源边界管理
软件避免了会导致意外行为的模式
软件管理数据完整性和一致性
事务复杂性级别

根据应用程序体系结构和使用的第三方组件（如外部库或框架），应按照上述最佳实践列表所画的线定义自定义检查，以确保更好地评估所交付软件的可靠性。

效率

与可靠性一样，性能低效的原因常常出现在违反良好的体系结构和编码实践的情况下，这种情况可以通过测量应用程序的静态质量属性来检测。这些静态属性预测潜在的操作性能瓶颈和未来的可伸缩性问题，特别是对于处理复杂算法或大量数据需要高执行速度的应用程序。

评估性能效率需要至少检查以下软件工程最佳实践和技术属性：

应用架构实践
与昂贵和/或远程资源的适当交互
数据访问性能和数据管理
内存、网络和磁盘空间管理
编码实践
符合面向对象和结构化编程最佳实践（视情况而定）
符合SQL编程最佳实践

安全

大多数安全漏洞都是由糟糕的编码和架构实践（如SQL注入或跨站点脚本）造成的。这些记录在CWE，[33]和卡内基梅隆大学SEI/计算机应急中心（CERT）保存的清单中。

评估安全性至少需要检查以下软件工程最佳实践和技术属性：

应用架构实践
多层设计符合性
安全最佳实践（输入验证、SQL注入、跨站点脚本等[34]）
编程实践（代码级）
错误和异常处理
安全最佳实践（系统功能访问、程序访问控制）

可维护性

可维护性包括模块性、可理解性、可变更性、可测试性、可重用性和从一个开发团队到另一个开发团队的可转移性等概念。在代码级别，这些问题不是关键问题的形式。相反，较差的可维护性通常是由于在文档、复杂度避免策略和基本编程实践方面的最佳实践出现了数千次小的违规行为，这使得干净的代码和易于阅读的代码与无组织的代码和难以阅读的代码之间存在差异。[35]

评估可维护性需要检查以下软件工程最佳实践和技术属性：

应用架构实践
源代码中嵌入的体系结构、程序和代码文档
代码可读性
事务的复杂程度
算法的复杂性
编程实践的复杂性
遵守面向对象和结构化编程最佳实践（如适用）
组件和模式的再利用率
动态编码的控制级
耦合比
脏程序设计
文档
硬件、操作系统、中间件、软件组件和数据库独立性
多层设计符合性
可移植性
编程实践（代码级）
减少重复代码和函数
源代码文件组织清理

维修性与Ward Cunningham的技术债务概念密切相关，技术债务是维修性不足导致的成本的一种表现。可维护性低的原因可以分为鲁莽与谨慎、深思熟虑与疏忽[36]，其根源通常在于开发人员的无能、缺乏时间和目标、粗心大意以及文档（尤其是可维护源代码）在创建成本和收益方面的差异。[37]

大小

测量软件大小要求正确收集整个源代码，包括数据库结构脚本、数据操作源代码、组件头文件、配置文件等。基本上有两种类型的软件大小需要测量，即技术大小（封装外形）和功能大小：

有几种软件技术尺寸方法已经被广泛描述。最常见的技术调整方法是每项技术的代码行数（LOC）、文件、函数、类、表等的数量，从中可以计算反作用功能点；
测量功能尺寸最常用的方法是功能点分析。功能点分析从用户的角度衡量软件交付的大小。功能点大小调整是根据用户需求完成的，它为开发人员/估计员提供了大小和价值（要交付的功能）的精确表示，并反映了要交付给客户的业务功能。该方法包括对用户可识别的输入、输出和数据存储的识别和加权。然后，可以将大小值与许多量化和评估软件交付和性能的措施（每个功能点的开发成本；每个功能点交付的缺陷；每个员工月的功能点）结合使用。

功能点分析分级标准由国际功能点用户组（IFPUG）支持。它可以在软件开发生命周期的早期应用，并且不依赖于代码行，比如有些不准确的反燃方法。该方法与技术无关，可用于跨组织和跨行业的比较分析。

自从功能点分析开始以来，已经发展出了一些变体，功能尺寸技术的家族已经扩展到包括诸如COSMIC、NESMA、用例点、FP-Lite、早期和快速FPs以及最近的故事点等尺寸测量。然而，功能点具有统计准确性的历史，在许多应用程序开发管理（ADM）或外包业务中被用作通用的工作度量单位，用作交付服务和度量性能的“货币”。

功能点方法的一个常见限制是，它是一个手动过程，因此在应用程序开发或外包业务等大规模计划中可能会耗费大量人力和成本。应用该方法的消极方面可能是促使行业IT领导者组建IT软件质量联盟的原因，该联盟专注于引入一个可计算的度量标准，用于自动化软件规模的测量，而IFPUG则不断推广手动方法，因为其大多数活动都依赖于FP计数器认证。

CISQ宣布在CISQ技术中向CISQ成员提供其第一个度量标准“自动功能点”。这些建议是在OMG的征求意见格式中制定的，并提交给OMG的标准化过程

识别关键编程错误

关键编程错误是特定的体系结构和/或编码不良实践，会导致最高的、即时的或长期的业务中断风险。

它们通常与技术相关，并且在很大程度上依赖于环境、业务目标和风险。有些人可能会考虑尊重命名约定，而另一些人（例如，为知识转移奠定基础的人）则会认为这是绝对关键的。

关键编程错误也可以根据CISQ特性进行分类。基本示例如下：

可靠性

避免会导致意外行为的软件模式（未初始化的变量、空指针等）
执行插入、更新、删除、创建表或选择的方法、过程和函数必须包含错误管理
多线程函数应该是线程安全的，例如servlets或struts操作类不能有实例/非最终静态字段

效率

确保客户机请求（传入和数据）的集中，以减少网络流量
避免对循环中的大型表不使用索引的SQL查询

安全

避免servlet类中不是最终静态的字段
避免在不包括错误管理的情况下访问数据
检查控制返回码并实现错误处理机制
确保输入验证以避免跨站点脚本编写缺陷或SQL注入缺陷

可维护性

应避免深遗传树和筑巢，以提高可理解性
模块应该是松散耦合的（扇出、中介），以避免修改的传播
强制同构命名约定

操作化质量模型

新的质量模型建议，如Squale和Quamoco[38]宣传了质量属性和测量定义的直接集成。通过分解质量属性甚至定义额外的层，复杂抽象的质量属性（如可靠性或可维护性）变得更易于管理和测量。这些质量模型已在工业环境中得到应用，但尚未得到广泛采用。

另见

原文：https://en.wikipedia.org/wiki/Software_quality

本文：http://jiagoushi.pro/node/967

讨论:请加入知识星球或者微信圈子【首席架构师圈】

登录发表评论
163 次浏览

发布日期

星期六, 四月 18, 2020 - 23:07

最后修改

星期四, 一月 5, 2023 - 21:56

热门内容

今日:

总体:

最近浏览：

目录

1动机

2定义

3种替代方法

4测量

5另见

6进一步阅读

7参考文献

8个外部链接

动机

定义

Kitchenham、Pfleeger和Garvin对质量的五种观点

根据Deming的软件质量

根据Feigenbaum的软件质量

根据Juran的软件质量

CISQ质量模型

可靠性

效率

安全

可维护性

大小

替代方法

测量

介绍

基于代码的分析

可靠性

效率

安全

可维护性

大小

识别关键编程错误

可靠性

效率

安全

可维护性

操作化质量模型

另见

最新内容