软件质量

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

  • 软件的功能质量反映了基于功能要求或规格符合或符合给定设计的程度。该属性也可以描述为适合一项软件的目的,或者它与市场上的竞争对手进行比较为有价值的产品。这是制作正确软件的程度。
  • 软件结构质量是指它如何满足支持功能要求(例如鲁棒性或可维护性)的非功能要求。它与软件根据需要的工作程度有关。

结构质量的许多方面只能通过分析软件内部结构,其源代码(请参见软件指标),单位级别和系统级别(有时称为端到端测试)来静态评估。 ,这实际上是其架构如何遵守对像管理组(OMG)在有关该主题的论文中概述的软件体系结构原理。

但是,某些结构性质量(例如可用性)只能进行动态评估(用户或代表其作用的用户或其他与软件相互作用,或者至少是某些原型或部分实现;即使是与纸板中制作的模拟版本的相互作用也代表动态测试是因为可以将其视为原型)。其他方面,例如可靠性,不仅涉及软件,而且还涉及基础硬件,因此可以在静态和动态上对其进行评估(压力测试)。

通常会动态评估功能质量,但也可以使用静态测试(例如软件评论)。

从历史上看,适用于软件质量管理的属性和指标的结构,分类和术语是从ISO 9126和随后的ISO/IEC 25000标准中得出或提取的。基于这些模型(请参阅模型), IT软件质量的财团(CISQ)定义了一块软件提供业务价值所需的五个主要理想的结构特征:可靠性,效率,安全性,可维护性和(适当)尺寸。

软件质量测量可以在这五个维度中的每个维度中量化软件程序或系统速率的多大程度。可以通过定性或定量评分方案或两者的组合,然后是反映优先级的加权系统来计算软件质量的汇总度量。对“关键编程错误”的分析可以补充这种软件质量位置在线性连续体上的观点,这些分析在特定情况下可能会导致灾难性的中断或性能降解,从而使给定系统不适合使用,无论基于汇总测量值的评级如何。在系统级别上发现的这种编程错误占生产问题的90%,而在单位级别,即使越来越多的编程错误占生产问题的10%(另请参见90九十规则)。结果,如W. Edwards Deming所描述的那样,没有整个系统上下文的代码质量的价值有限。

查看,探索,分析和交流软件质量测量值,信息可视化的概念和技术可提供视觉上的交互式手段,尤其是有用的,如果必须使用多种软件质量措施相互关联或与软件或系统的组件相关。例如,软件地图代表了一种专门的方法,该方法“可以表达和结合有关软件开发,软件质量和系统动态的信息”。

软件质量在软件项目的发行阶段也起著作用。具体而言,发行过程的质量和建立(也是补丁程序),配置管理是整体软件工程过程的重要组成部分。

动机

软件质量至少有两个主要观点的动机:

  • 风险管理:软件故障造成的不便。软件错误可能会导致人为死亡(例如:软件错误列表)。这些原因范围从设计不良的用户界面到直接编程错误,例如,请参见波音737案例意外加速案例或Therac-25案例。这导致了开发某些类型软件的要求,尤其是历史上并且历史上嵌入了调节关键基础架构的医疗和其他设备中的软件:“ [[编写嵌入式软件的工程师]请参阅Java程序停滞了三分之一,以执行垃圾的三分之一收集和更新用户界面,并设想飞机从天上掉下来。在美国,在联邦航空管理局(FAA)中,FAA飞机认证服务服务提供软件程序,政策,指导和培训,专注于软件和复杂的电子硬件,对机载产品具有影响(“产品”是“产品”飞机,发动机或螺旋桨)。 DO-178CISO 26262IEC 62304等认证标准提供指导。
  • 成本管理:与任何其他工程领域一样,由良好的软件质量成本降低的软件产品或服务更容易理解,并且可以响应紧迫的业务需求而改变更具成本效益。行业数据表明,核心业务应用程序中的应用结构质量差(例如企业资源计划(ERP),客户关系管理(CRM)或金融服务中的大型交易处理系统)导致成本,安排超越并以以下形式造成浪费。返工(请参阅Muda(日语) )。此外,由于数据损坏,应用中断,安全漏洞和性能问题,结构性质量差与高影响力的业务中断密切相关。
    • CISQ报告质量差的成本估计的影响:
    • IBM的数据泄露报告的成本2020估计数据泄露的全球平均成本:
      • 386万美元

定义

ISO

软件质量是“软件产品符合要求的能力”。对于其他人来说,它可能是客户或价值创造甚至缺陷级别的代名词。软件质量测量可以分为三个部分:过程质量,产品质量,包括内部和外部特性以及使用质量,这是软件的效果。

asq

ASQ使用以下定义:软件质量描述了软件产品的理想属性。存在两种主要方法:缺陷管理和质量属性。

nist

软件保证(SA)涵盖了实现它的属性和过程:

  • [合理]相信软件没有漏洞,即在软件中有意设计或在其生命周期中任何时间插入,并且该软件以预期的方式发挥作用
  • 计划和系统的活动集,以确保软件生命周期过程和产品符合要求,标准和程序

PMI

项目管理学院PMBOK指南“软件扩展”不是定义“软件质量”本身,而是软件质量保证(SQA)为“连续过程,审核其他软件流程以确保遵循这些过程(例如,例如一个软件质量管理计划) 。”而软件质量控制(SCQ)则是指“照顾应用方法,工具和技术,以确保工作产品满足于正在开发或修改的软件的质量要求上满足。”

其他一般和历史性的

质量历史的第一个定义回忆起20世纪初Shewhart: “质量有两个共同的方面:其中之一与将事物的质量作为客观现实的考虑与独立于存在的客观现实有关男人。另一个与我们的想法,感觉或感知有关,换句话说,质量的主观方面。”

Kitchenham和Pfleeger进一步报导了David Garvin的教义,确定了五种不同的质量观点:

  • 先验观点涉及质量的形而上学方面。从这种质量角度来看,它是“我们作为理想努力的东西,但可能永远不会完全实施”。它几乎无法定义,但类似于联邦法官曾经对淫秽评论的评论:“当我看到它时,我知道它”。
  • 用户的观点与给定使用环境有关产品的适当性。尽管先验视图是空灵的,但用户视图更具体,基于满足用户需求的产品特征。
  • 制造观点代表质量符合要求。 ISO 9001等标准强调了质量的这一方面,该标准将质量定义为“一组固有特征满足要求的程度”(ISO/IEC 9001)。
  • 产品的观点意味着可以通过测量产品的固有特征来理解质量。
  • 质量的最终视角是基于价值的。这种观点认识到,质量的不同观点可能对各种利益相关者俱有不同的重视或价值。

试图定义产品质量(几乎所有产品)的固有问题是由沃尔特·A·惠特(Walter A. Shewhart)大师所说的。定义质量的困难是将用户的未来需求转化为可衡量的特征,以便可以设计和实现产品以满足用户将支付的价格满意。这并不容易,一旦人们在努力中感到相当成功,他就会发现消费者的需求已经改变,竞争对手已经搬进来等。

质量是客户的决心,而不是工程师的决心,而不是营销决心,也不是一般管理的确定。它基于客户在产品或服务上的实际经验,该经验是根据其要求衡量的 - 陈述或尚未说明,有意识或仅感知,技术运作或完全主观的,并且始终代表竞争性市场中的移动目标。

质量一词具有多种含义。这些含义中的两种主导了单词的使用:1。质量由满足客户需求的产品功能组成,从而提供了产品满意度。 2.质量包括免于缺陷的自由。然而,在这样的手册中,标准化质量一词的简短定义为“适合使用”很方便。

汤姆·德马科(Tom DeMarco)提出:“产品的质量取决于它使世界变得更好。”这可以解释为意味着功能质量和用户满意度比结构性质量在确定软件质量方面更重要。

杰拉尔德·温伯格(Gerald Weinberg)在质量软件管理中创造的另一个定义:系统思考,是“对某人的质量是有价值的”。该定义强调质量本质上是主观的 - 不同的人会以不同的方式体验同一软件的质量。该定义的一个优势是它邀请软件团队考虑的问题,例如“我们想重视我们的软件的人是谁?”和“什么对他们有价值?”。

其他含义和争议

定义质量的挑战之一是,“每个人都认为自己了解它”,而软件质量的其他定义可能基于扩展业务中质量概念的各种描述。

软件质量通常还与质量保证问题解决方案管理质量控制DevOps混合在一起。它确实与以前提到的领域相比(另请参见PMI定义),但与众不同,因为它不仅专注于测试,还要关注过程,管理,改进,评估等。

测量

尽管本节中提出的概念适用于结构和功能软件质量,但后者的测量基本上是通过测试来执行的[请参见主要文章:软件测试]。但是,测试还不够:根据一项研究,单个程序员在自己的软件中查找错误的效率不到50%。大多数形式的测试效率仅为35%。这使得很难确定[软件]质量。

介绍

软件理想特征(右)和可测量属性(左)之间的关系

软件质量测量是关于量化系统或软件具有理想特征的程度。这可以通过定性或定量手段或两者的混合来执行。在这两种情况下,对于每个理想的特征,都有一组可测量的属性,其中一组软件或系统中的存在倾向于相关并与此特征相关联。例如,与可移植性关联的属性是程序中目标依赖性语句的数量。更确切地说,使用质量函数部署方法,这些可测量的属性是必须强制执行以启用上面软件质量定义中的“ Whats”的“ Hows”。

适用于软件质量管理的属性和指标的结构,分类和术语是从ISO 9126-3和随后的ISO/IEC/IEC 25000:2005质量模型中得出或提取的。主要重点是内部结构质量。已经创建了子类别来处理特定领域,例如业务应用程序体系结构和技术特征,例如数据访问和操纵或交易概念。

右侧的图表表示软件质量特征及其可测量属性之间的依赖树,其中对用户(右)或业务系统所有者的5个特征中的每个特征中的每个特征都取决于可测量的属性(左):

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

编程错误与生产缺陷之间的相关性揭示了基本代码错误占源代码中总错误的92%。这些众多的代码级问题最终仅占生产缺陷的10%。建筑水平的不良软件工程实践仅占总缺陷的8%,但在解决问题上花费的一半以上,导致了严重的可靠性,安全性和生产效率问题的90%。

基于代码的分析

许多现有软件测量了应用程序的结构元素,这些结构元素是由对此类指令的源代码解析代币控制结构(复杂性)和对象所产生的。

软件质量测量是关于量化这些维度的系统或软件速率的量化。可以使用定性或定量方法或两者的混合以提供骨料视图[使用例如加权平均值,以反映所测量因素之间相对重要性]进行分析。

线性连续体上的软件质量观点必须通过识别离散的关键编程错误来补充。这些漏洞可能不会使测试案例失败,但它们是不良做法的结果,在特定情况下可能导致灾难性的中断,绩效降解,安全漏洞,损坏的数据以及无数的其他问题,这些问题实际上不适合使用。无论其基于汇总测量的评级如何。脆弱性的一个众所周知的例子是枚举的常见弱点,这是源代码中漏洞的存储库,该漏洞使应用程序暴露于安全漏洞。

对关键应用特征的测量涉及测量应用程序架构,编码和在线文档的结构属性,如上图所示。因此,每个特征都会受到应用程序中许多抽象级别的属性的影响,如果要成为影响业务的质量成果的有价值的预测指标,则必须包括计算特征的度量。 Boehm及其同事在TRW(Boehm,1978)首先提出了上图中显示的特征度量的分层方法,这是ISO 9126和25000串联标准中采用的方法。这些属性可以从对应用程序源代码的静态分析的分析结果中测量。即使是可靠性和绩效效率等应用的动态特征,它们在应用程序的静态结构中也具有因果根源。

结构质量分析和测量是通过分析源代码体系结构软件框架数据库模式与原理和标准的关系,共同定义了系统的概念和逻辑体系结构。这与通常由开发工具执行的基本,本地,组件级代码分析不同,这些工具主要与实施注意事项有关,并且在调试测试活动中至关重要。

可靠性

可靠性差的根本原因是不合规与良好的建筑和编码实践结合使用的。可以通过测量应用程序的静态质量属性来检测这种不合规。评估应用程序可靠性的基础静态属性提供了对业务风险水平以及潜在应用程序失败的可能性的估计,并且该应用程序在运行时会遇到申请的缺陷。

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

  • 应用架构实践
  • 编码实践
  • 算法的复杂性
  • 编程实践的复杂性
  • 遵守面向对象的和结构化的编程最佳实践(适用)
  • 组件或图案重复使用比
  • 肮脏的编程
  • 错误和异常处理(对于所有层 - GUI,逻辑和数据)
  • 多层设计合规性
  • 资源界限管理
  • 软件避免导致意外行为的模式
  • 软件管理数据完整性和一致性
  • 交易复杂度水平

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

效率

与可靠性一样,效率低下的原因通常是违反良好的建筑和编码实践的行为,可以通过测量应用程序的静态质量属性来检测到。这些静态属性可以预测潜在的操作性性能瓶颈和未来的可扩展性问题,尤其是对于需要高执行速度来处理复杂算法或大量数据的应用程序。

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

  • 应用架构实践
  • 与昂贵和/或远程资源的适当互动
  • 数据访问性能和数据管理
  • 内存,网络和磁盘空间管理
  • 遵守编码实践(最佳编码实践

安全

软件质量包括软件安全性。许多安全漏洞是由于编码和建筑实践(例如SQL注入或跨站点脚本)所致。这些已在CWE和卡内基梅隆大学的SEI/计算机急诊中心(CERT)维护的列表中得到了很好的记录。

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

  • 实施,安全感知和硬化开发过程的管理,例如安全开发生命周期(Microsoft)或IBM的安全工程框架。
  • 安全应用架构实践
  • 多层设计合规性
  • 安全最佳实践(输入验证,SQL注入,跨站点脚本,访问控制等)
  • 安全和良好的编程实践
  • 错误和异常处理

可维护性

可维护性包括模块化,可理解性,可变性,可检验性,可重复性以及从一个开发团队到另一个开发团队的可转移性的概念。这些不会在代码级别上采用关键问题的形式。相反,差的可维护性通常是成千上万的轻微违规行为,具有文档中的最佳实践,复杂性避免策略以及基本的编程实践,从而使清洁和易于阅读的代码与无组织和难以阅读的代码之间有所不同。

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

  • 应用架构实践
  • 嵌入在源代码中的体系结构,程序和代码文档
  • 代码可读性
  • 代码气味
  • 交易的复杂程度
  • 算法的复杂性
  • 编程实践的复杂性
  • 遵守面向对象的和结构化的编程最佳实践(适用)
  • 组件或图案重复使用比
  • 控制的动态编码水平
  • 耦合比
  • 肮脏的编程
  • 文件
  • 硬件,操作系统,中间件,软件组件和数据库独立性
  • 多层设计合规性
  • 可移植性
  • 编程实践(代码级)
  • 减少重复代码和功能
  • 源代码文件组织清洁度

可维护性与沃德·坎宁安(Ward Cunningham)的技术债务概念密切相关,这表明缺乏可维护性导致成本。为什么可维护性较低的原因可以归类为鲁ck,审慎和故意与无意间,并且经常起源于开发人员的无能,缺乏时间和目标,他们的粗心和差异,这些创造成本和从文档和收益中受益,特别是可维护的源代码

尺寸

测量软件大小要求正确收集整个源代码,包括数据库结构脚本,数据操作源代码,组件标头,配置文件等。基本上有两种类型的软件大小要测量,技术尺寸(足迹)和功能大小:

  • 有几种已广泛描述的软件技术大小方法。最常见的技术大小方法是根据技术的数量,文件,功能,类,表等的代码线数(#LOC)数量,可以从中计算起来的功能点;
  • 测量功能大小的最常见是功能点分析。功能点分析从用户的角度来衡量软件的大小。功能点大小是根据用户需求完成的,并为开发人员/估算器和值(要交付的功能)提供了准确表示大小,并反映了要交付给客户的业务功能。该方法包括识别和加权用户可识别的输入,输出和数据存储。然后,尺寸值可与许多措施一起使用,以量化和评估软件交付和性能(每个功能点的开发成本;每个功能点交付的缺陷;每个员工的功能点。)。

功能点分析大小标准由国际功能点用户组( IFPUG )支持。它可以在软件开发生命周期的早期应用,并且不依赖于某种不准确的反击方法等代码行。该方法是技术不可知的,可用于整个组织和整个行业之间的比较分析。

自功能点分析的成立以来,已经发展了几种变化,功能尺寸技术的家族已经扩大到包括宇宙,NESMA,用例,FP Lite,FP Lite,早期和快速FPS以及最近的故事点等尺寸措施。但是,功能点具有统计准确性的历史,并已用作许多应用程序开发管理(ADM)或外包参与的共同工作单位,作为提供服务并衡量绩效的“货币”。

功能点方法的一个普遍局限性是它是一个手动过程,因此在大规模的计划中,诸如应用程序开发或外包参与等大规模计划中可能是劳动密集型且昂贵的。应用该方法的这一负面方面可能是促使行业IT领导者组成IT软件质量联盟的促进行业,专注于引入可计算的度量标准,以自动化软件大小的测量,而IFPUG继续促进手动方法,因为其大多数活动都依赖于手动方法在FP计数器认证上。

CISQ定义了尺寸,以估算软件的大小,以支持成本估算,进度跟踪或其他相关软件项目管理活动。使用了两个标准:自动化功能点以测量软件的功能大小和自动化增强点,以一级测量功能和非功能代码的大小。

确定关键的编程错误

关键的编程错误是特定的建筑和/或编码不良实践,导致最高,直接或长期的业务中断风险。

这些通常与技术有关,并在很大程度上取决于背景,业务目标和风险。有些人可能会考虑尊重命名惯例,而另一些人(例如为知识转移做准备的基础的人)将认为这是绝对至关重要的。

每个CISQ特征也可以对关键编程错误进行分类。下面的基本示例:

  • 可靠性
    • 避免会导致意外行为的软件模式(非初始化的变量,无效指针等)
    • 做插入,更新,删除,创建表或选择的方法,过程和功能必须包括错误管理
    • 多线程函数应确保线程安全,例如,servlet或支柱行动类不得具有实例/非最终静态字段
  • 效率
    • 确保对客户请求的集中化(传入和数据)来减少网络流量
    • 避免在循环中不使用索引的SQL查询
  • 安全
    • 避免在不是最终静态的servlet类中的字段
    • 避免访问数据而不包括错误管理
    • 检查控制返回代码并实施错误处理机制
    • 确保输入验证以避免跨站点脚本缺陷或SQL注射缺陷
  • 可维护性
    • 应避免深层继承树和筑巢以提高可理解性
    • 模块应松散耦合(粉丝,中介),以避免修改的传播
    • 执行同质命名惯例

操作质量模型

关于质量模型和Quamoco等质量模型的较新建议,可以直接整合质量属性和测量的定义。通过分解质量属性甚至定义其他层,复杂的,抽象的质量属性(例如可靠性或可维护性)变得更易于管理和可测量。这些质量模型已应用于工业环境,但尚未获得广泛采用。

琐事

  • “科学与其测量工具一样成熟。”
  • 当我看到它时,我知道。”
  • “您无法控制无法测量的内容。” (汤姆·德马科
  • “您无法将质量检查成产品。” ( W. Edwards Deming
  • “在满足日程安排的甜蜜之后,劣质的痛苦仍然很长时间。” (匿名的)
  • “如果您不从规格开始,那么您编写的每件代码都是补丁。” ( Leslie Lamport

也可以看看

进一步阅读

  • Android OS质量指南,包括UI,安全等清单。
  • 信息技术与通信协会(AMMITEC)的海事经理协会。 海上软件质量指南。 2017年9月
  • Capers Jones和Olivier Bonsignour,“软件质量的经济学”,Addison-Wesley Professional,第一版,2011年12月31日,2011年, ISBN 978-0-13-258220-9
  • 猫实验室 - CNES代码分析工具实验室(在GitHub上)
  • Girish Suryanarayana,软件流程与设计质量:拔河?
  • Ho-Won Jung,Seung-Gweon Kim和Chang-Sin Chung。测量软件产品质量:ISO/IEC 9126的调查IEEE软件,21(5):10-13,2004年9月/10月。
  • 国际标准化组织。软件工程 - 产品质量 - 第1部分:质量模型。 ISO,日内瓦,瑞士,2001年。ISO/IEC 9126-1:2001(e)。
  • 测量软件产品质量:ISO 25000系列和CMMI(SEI站点)
  • MSQF-基于测量的软件质量框架康奈尔大学图书馆
  • Omar Alshathry,Helge Janicke,“优化软件质量保证”,Compsacw,第87-92页,2010年IEEE第34届年度计算机软件和应用程序会议研讨会,2010年。
  • 罗伯特·L·格拉斯(Robert L. Glass)。构建优质软件。新泽西州上萨德尔河Prentice Hall,1992年。
  • Roland Petrasch, “软件质量”的定义:一种实用方法”,ISSRE,1999年
  • 美国质量学会软件质量专业人士(ASQ)
  • Springer Nature的软件质量期刊
  • Spinellis,Diomidis(2006-04-04)。代码质量:开源视角。美国新泽西州的上萨德尔河:艾迪生 - 韦斯利专业人士。 ISBN 978-0-321-16607-4。
  • Stephen H. Kan。软件质量工程中的指标和模型。艾迪生 - 韦斯利(Addison-Wesley),马萨诸塞州波士顿,第二版,2002年。
  • Stefan Wagner。软件产品质量控制。施普林格,2013年。