软件质量模型

简介:

关于软件质量模型,业界已经有很多成熟的模型定义,比较常见的质量模型有 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,如需转载请自行联系原作者

目录
相关文章
|
24天前
|
监控 数据可视化 数据挖掘
【软件设计师备考 专题 】软件过程评估与能力成熟度评估的基本方法
【软件设计师备考 专题 】软件过程评估与能力成熟度评估的基本方法
55 0
|
3月前
|
容灾 测试技术
如何衡量软件质量好坏?
如何衡量软件质量好坏?
|
8月前
|
敏捷开发 Dubbo Java
需求开发人日评估
随着敏捷开发在国内的风靡,越来越多的团队开始推行敏捷开发,这其中有一个关键事项就是:工时的人日评估。简单来说就是:项目经理会让开发人员自己评估自己负责的模块大概需要的开发周期。 人日,即按照1人几天完成,如1/人日:表示这个需求需要1个人1天完成,如果有2个人一起做,可能就是0.5天(需求开发一般1+1 < 2,因为有代码合并的兼容性要处理)。
400 1
|
10天前
|
安全 测试技术 持续交付
深入探索白盒测试:提升软件质量的关键步骤
【4月更文挑战第9天】在软件开发的生命周期中,确保代码的质量和性能至关重要。白盒测试,作为软件测试的一个核心分支,提供了一种通过检查内部结构、设计和逻辑来验证程序正确性的方法。本文将深入探讨白盒测试的原理、方法和最佳实践,旨在帮助开发者和测试工程师提高测试效率,从而确保软件产品的可靠性与稳定性。通过对不同白盒测试技术的比较分析,我们将揭示如何更有效地利用这些技术来发现和修复潜在的缺陷。
|
10天前
|
机器学习/深度学习 人工智能 算法
深入白盒测试:提升软件质量的策略与实践
【4月更文挑战第9天】在追求软件产品质量的道路上,白盒测试作为一项重要的验证手段,其价值和影响力日益凸显。本文将深入探讨白盒测试的核心概念、实施策略以及面临的挑战,旨在为软件开发和质量保证的专业人士提供一套系统化的白盒测试方法论。通过对代码逻辑结构、执行路径以及内部算法的严密审查,我们揭示了如何有效发现并修复潜在的缺陷,确保软件的稳定性和性能满足用户期待。文章还将分享一系列创新工具和技术,助力测试人员提高测试覆盖率,减少人工干预,最终实现自动化和智能化的软件测试流程。
|
22天前
|
安全 算法 C++
了解C++ 软件开发中的鲁棒性
了解C++ 软件开发中的鲁棒性
36 0
|
8月前
|
敏捷开发 测试技术 持续交付
软件开发过程中的最佳实践和代码质量评估
在软件开发过程中,采用最佳实践和评估代码质量对于确保软件的稳定性和可维护性至关重要。通过明确的需求、合理的开发流程、良好的代码规范以及严格的代码评估,我们可以降低软件开发过程中的风险,并提升开发效率和软件质量。
203 2
|
网络协议 jenkins Devops
自动化测试成熟度模型
我从事软件测试工作以来,第一次知道自动化是15年年底,听大佬说QTP可以录制脚本然后自动化回放,测试效率很高,当时心向往之。不过当时技术比较菜,而且对工作也比较迷茫,听过就忘记了。
自动化测试成熟度模型
|
数据可视化 定位技术 容器
软件系统中的模型
软件系统中的模型
软件系统中的模型
|
测试技术 计算机视觉
MMFewShot训练与测试流程
MMFewShot训练与测试流程
458 0
MMFewShot训练与测试流程