软件质量模型

简介:

关于软件质量模型,业界已经有很多成熟的模型定义,比较常见的质量模型有 McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO9126 模型。

Jim McCall 软件质量模型(1977 年)

Jim McCall 的软件质量模型,也被称为 GE 模型(General Electrics Model)。其最初起源于美国空军,主要面向的是系统开发人员和系统开发过程。McCall 试图通过一系列的软件质量属性指标来弥补开发人员与最终用户之间的沟壑。

McCall 质量模型使用 3 中视角来定义和识别软件产品的质量:

  1. Product revision (ability to change).
  2. Product transition (adaptability to new environments).
  3. Product operations (basic operational characteristics).

McCall 模型通过层级的要素、标准和指标来详述这 3 个视角定义(产品修改、产品转移、产品运行)。

  • 11 Factors (To specify):描述软件的外部视角,也就是客户或使用者的视角。
  • 23 Criterias (To build):描述软件的内部视角,也就是开发人员的视角。
  • Metrics (To control):定义衡量指标和方法

下图中,左侧为 11 个质量要素,右侧为 23 个质量标准。

Barry W. Boehm 软件质量模型(1978 年)

Boehm 软件质量模型试图通过一系列的属性的指标来量化软件质量。Boehm 的质量模型包含了 McCall 模型中没有的硬件属性。Boehm 模型也类似于 McCall 的质量模型,采用层级的质量模型结构,包括高层属性、中层属性和原始属性。

高层属性主要关注 3 个问题:

  • As-is utility
  • Maintainability
  • Portability

中层属性包含了 7 个质量要素:

  • Portability (General utility characteristics)
  • Reliability (As-is utility characteristics)
  • Efficiency (As-is utility characteristics)
  • Usability (As-is utility characteristics, Human Engineering)
  • Testability (Maintainability characteristics)
  • Understandability (Maintainability characteristics)
  • Flexibility (Maintainability characteristics, Modifiability)

可以看出,Boehm 模型和 McCall 模型有些相似,区别在于 McCall 模型主要关注于高层属性("As-is utility")的精确度量上,而 Boehm 模型则基于更广泛的属性,并且对可维护性做了更多的关注。

FURPS/FURPS+ 软件质量模型

FURPS 模型最初由 Robert Grady 提出,后来由 Rational Software 进行扩展至 FURPS+。

FURPS 模型包括:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

FURPS 包括两种不同的类型:功能性和非功能性。

R. Geoff Dromey 软件质量模型

Dromey 软件质量模型由 3 个主要元素组成:

  1. Product properties that influence quality
  2. High level quality attributes
  3. Means of linking the product properties with the quality attributes.

构建该质量模型包括以下 5 个步骤:

  1. Chose a set of high-level quality attributes necessary for the evaluation.
  2. List components/modules in your system.
  3. Identify quality-carrying properties for the components/modules (qualities of the component that have the most
  4. impact on the product properties from the list above).
  5. Determine how each property effects the quality attributes.
  6. Evaluate the model and identify weaknesses.

ISO/IEC 9126 软件质量模型(1993 年)

ISO/IEC 9126: Software Product Evaluation: Quality Characteristics and Guidelines for their Use-standard

ISO/IEC 9126 模型是建立在 McCall 和 Boehm 模型之上的,同时加入了功能性要求,还包括识别软件产品的内部和外部质量属性。

软件的 6 个质量特征:

  1. 功能性(Functionality):当软件在指定条件下使用时,软件产品提供满足明确和隐含需要的功能的能力;
  2. 可靠性(Reliability):在指定条件下使用时,软件产品维持规定的性能级别的能力;
  3. 易用性(Usability):在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力;
  4. 效率(Efficiency):在规定条件下,相对于所用资源的数量,软件产品可提供适当性能的能力;
  5. 可维护性(Maintainability):软件产品可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度;
  6. 可移植性(Portability):软件产品从一种环境迁移到另一种环境的能力。

ISO/IEC 9126-1 内部和外部质量特征:

ISO/IEC 9126-1 中的非技术因素:

下面是 ISO/IEC 9126 模型与 McCall 模型 和 Boehm 模型的对比:

ISO/IEC 25010 软件质量模型(2011 年)

ISO/IEC 9126-1:2001 已被 ISO/IEC 25010:2011 代替并废止。

上图阐明了 ISO/IEC 25000 SQuaRE 系列标准的组织,其组成部分均称为分部。 SQuaRE 系列国际标准内的分部有:

  1. ISO/IEC 2500n 质量管理分部。构成这个分部的那些标准定义了由SQuaRE系列标准中的所有其他标准引用的全部公共模型、术语和定义。在针对特定应用情况使用适当标准方面的引用路径和高级的实用建议有助于所有类型的用户。这一分部还提供了用于负责管理软件产品需求和评价的支持功能的要求和指南。
  2. ISO/IEC 2501n 质量模型分部。构成这个分部的标准给出一个包括软件内部质量、 软件外部质量和软件使用质量的特性的详细质量模型。此外, 内部和外部的软件质量特性被分解细化成一些子特性,并且还提供了使用该质量模型的实用指南。
  3. ISO/IEC 2502n 质量测量分部。构成这个分部的标准包括软件产品质量测量参考模型、质量测量的数学定义及其应用的实用指南。给出了应用于软件内部质量、软件外部质量和使用质量的测量。定义并给出了构成后续测量基础的质量测量元素。
  4. ISO/IEC 2503n 质量要求分部。构成这个分部的标准帮助用户规定质量要求。这些质量要求可用在要开发的软件产品的质量需求抽取过程中或用作评价过程的输入。需求定义过程可映射到ISO/IEC 15288 中定义的技术过程。
  5. ISO/IEC 2504n 质量评价分部。构成这个分部的标准给出了无论由评价方、需方还是由开发方执行的软件产品评价的要求、建议和指南。还给出了作为评价模块的测量文档编制支持。
  6. ISO/IEC 25050 到 ISO/IEC 25099 保留用于 SQuaRE 扩展的国际标准和/或技术报告。

 软件质量模型包含 8 个特征,并且被进一步分解为可以度量的内部和外部多个子特征。

 

ISO/IEC 25010 中新增了软件使用质量,其包含 5 个特征,并进一步被划分为可以被度量的多个子特征。

  • 使用质量:在特定的使用周境中,软件产品使得特定用户能达到有效性、生产率、安全性和满意度的特定目标的能力。

质量模型与目标系统的关系:

质量的生命周期:





 

本文转自匠心十年博客园博客,原文链接:http://www.cnblogs.com/gaochundong/p/software_quality_models.html,如需转载请自行联系原作者

目录
相关文章
|
2月前
|
机器学习/深度学习 人工智能 持续交付
利用AI进行代码审查:提升软件质量的新策略
【10月更文挑战第28天】本文探讨了AI在代码审查中的应用,介绍了AI如何通过静态代码分析、代码风格检查和实时反馈提升代码质量。文章还讨论了将AI工具集成到CI/CD流程、定制化规则和结合人工审查等进阶技巧,并推荐了SonarQube和DeepCode等实用工具。未来,AI代码审查工具将更加智能,助力软件开发。
|
3月前
|
安全 数据挖掘 测试技术
提升软件质量:探索高效测试策略
在软件开发过程中,测试是一个关键步骤,它决定了产品能否满足用户需求并保持高性能和安全性。本文将探讨几种有效的测试策略,包括自动化测试、性能测试和安全测试,以帮助开发团队提高软件质量。我们将分析每种方法的优势、实施步骤及面临的挑战,并提供实用的建议。
34 1
|
4月前
|
测试技术 持续交付 云计算
提升软件质量的关键路径:高效测试策略与实践
在当今数字化时代,软件已成为企业运营和产品服务的核心。随着软件开发周期的不断缩短和市场需求的迅速变化,确保软件质量成为开发过程中的首要任务。本文将探讨如何通过高效的测试策略和实践来提升软件质量,包括自动化测试、持续集成、代码审查等关键技术和方法。通过对这些技术的应用和整合,软件开发团队可以在竞争激烈的市场环境中保持领先地位,为用户提供高质量的产品和服务。
|
7月前
|
监控 jenkins 测试技术
软件测试中的敏捷实践:提升效率与质量
【6月更文挑战第7天】在快速迭代的软件开发领域,敏捷测试方法如同精准的瑞士军刀,为团队提供了灵活而高效的质量保证。本文将探讨敏捷测试的核心原则和实践,如何通过持续集成、自动化测试和紧密的跨功能团队合作,实现对软件质量的持续监控和改进。我们将深入理解敏捷测试的价值,并探索它如何帮助开发团队在变化莫测的市场中保持竞争力。
120 0
|
7月前
|
敏捷开发 测试技术
【软件测试】 开发模型和测试模型
【软件测试】 开发模型和测试模型
|
8月前
|
测试技术 API Apache
5个关键问题让单元测试的价值最大化
本文讨论的单元测试策略来自于实践中遇到的真实问题,作者总结出了5个关键策略问题并给出了解决之道。
|
8月前
|
安全 测试技术 持续交付
深入探索白盒测试:提升软件质量的关键步骤
【4月更文挑战第9天】在软件开发的生命周期中,确保代码的质量和性能至关重要。白盒测试,作为软件测试的一个核心分支,提供了一种通过检查内部结构、设计和逻辑来验证程序正确性的方法。本文将深入探讨白盒测试的原理、方法和最佳实践,旨在帮助开发者和测试工程师提高测试效率,从而确保软件产品的可靠性与稳定性。通过对不同白盒测试技术的比较分析,我们将揭示如何更有效地利用这些技术来发现和修复潜在的缺陷。
|
8月前
|
存储 算法 测试技术
深入探索白盒测试:提升软件质量与效率的关键
【4月更文挑战第23天】 随着软件开发的复杂性日益增加,确保代码质量和性能的压力也随之升高。在多种软件测试方法中,白盒测试以其对内部结构和工作原理的透明性而受到重视。本文旨在探讨白盒测试的核心概念、技术及其在提升软件测试效率和质量中的应用。通过分析控制流测试、数据流测试以及静态分析等关键技术,我们将揭示如何有效运用白盒测试以发现潜在的逻辑错误和缺陷。
|
8月前
|
测试技术 程序员
【软件测试学习】—软件测试模型(二)
【软件测试学习】—软件测试模型(二)
|
8月前
|
测试技术 数据库
【软件测试学习】—软件质量需求(四)
【软件测试学习】—软件质量需求(四)

热门文章

最新文章

相关实验场景

更多