写点什么

理解质量和可靠性

  • 2016-06-13
  • 本文字数:3091 字

    阅读完需:约 10 分钟

质量是软件评估、度量和评价中最重要却也最容易被忽视的一个领域。在所有开发项目的早期规划阶段通常不会仔细考虑它,甚至都不会提到它,但产品准备上线或部署时通常又会把它作为最终的标准。因此,从项目一开始讨论设定预期时就应该把它作为必要内容。

那么,我们如何来讨论产品质量呢?它可以由多种方式来度量,而其中两种特别能深刻地揭示产品的稳定性。它们是:

  1. 测试和实际交付时发现的系统中缺陷和错误的数量,以及
  2. 缺陷平均检测时间(MTTD),或者交付客户前和交付客户后发现缺陷所需的时间。

我们喜欢这两种度量的原因是它们都与产品稳定性相关,随着发布日期的临近这个问题将至关重要。它们是客观的、可度量的,通常可以从大多数组织的当前质量监控体系中得出,不必费太大的气力。

通常,更少的错误和更快的缺陷平均检测时间就会关乎更好的整体质量。虽然拥有最好的质量不一定总是干系人的核心关注点,但在项目交付客户之前可靠性是必须要满足的最低标准。例如,经验表明大约 95% 无缺陷的项目可以运行一天不崩溃。

另一条不错的经验法则是测试人员每月发现的错误少于 20 个通常是可以接受的最低的可靠性。换句话说,产品将可以运行大约一个 8 小时工作日。当然,这个经验法则通常应用于电子商务信息化应用。工业和军事嵌入式应用的可靠性需要达到更高的水平。

Rayleigh 缺陷模型

Rayleigh 缺陷模型是一种获得最佳质量评估的方式,你可以用 Rayleigh 函数作为一个时间函数随传统软件开发过程中预测缺陷发现率。Rayleigh 函数是由英国物理学家 Lord Rayleigh 在声波及电磁波散射的相关工作中发现的。Rayleigh 可靠性模型与从软件开发工作中收集的缺陷数据的实际情况非常接近。

Rayleigh 等式可以用来预测不同时间段发现的缺陷数量。从高层设计评审(HLDR——高层设计已完成)直到已发现 99.9% 的缺陷,在这段持续的时间内它都可以发挥作用。如图 1 所示,这是一个 Rayleigh 缺陷评估示例。

图 1. Rayleigh 缺陷预测示例

注意,曲线峰值更早发生在构建和测试阶段。这意味着大量的缺陷是在项目早期引入和发现的。这些缺陷主要是需求、设计和单元编码缺陷。如果没发现,它们会在项目后期暴露出来,导致大量的返工。

里程碑 10 是声明已经发现 99.9% 的缺陷的时间点。在与质量体系管理(QSM)一起工作的组织中,有不到 5% 的组织记录了详细设计阶段的缺陷。行业研究人员称,缺陷在系统测试时发现比设计或编码时发现的修复成本要高 10 到 100 倍 (Boehm, 1987; McConnell, 2001),这是一个尽早开始度量并采取行动的很有说服力的例子。

模型的简单扩展提供了其他有用的信息。例如,可以以总体曲线占对缺陷优先级予以详细说明。这可以让模型随时间推移按照严重程度来预测缺陷,如图 2 所示。

图 2 通过缺陷严重程度来划分的瑞利缺陷模型

缺陷评估可被认为是一份计划。针对一组特定的条件(规模、复杂度、效率、员工等),应生成一份计划性的曲线。管理者可以把它当作粗略的绩效计量器来用,看项目执行情况是否与计划一致,还可以与历史项目进行比较。如果存在重大偏差,会令管理人员据此进行调查,如果证明确有其事则采取补救措施。

图 3 展示了如何用缺陷检出预估去跟踪并与实际进行比对。很显然,实际测量结果和预估之间有些小偏差,但他们的轨迹大体一致。他们还让我们有信心做到在项目末期每月缺陷检出率在 20 个以内,这是我们建议的最低可接收的交付标准。

图 3 带有实际标绘的缺陷检出率计划

缺陷模型驱动

从 1978 年以来,QSM 已经收集了超过 10000 份完整的软件项目数据。通过对这些数据分析发现,存在着决定瑞利缺陷模型持续时间和量级的特定输入。这些输入能使该模型针对给定情况提供一份精确的预测。以下是 QSM 模型会使用的三个宏参数:

  • 规模(新的和修改的)
  • 产能指数
  • 最高人员配置

这些驱动因子会影响我们在软件项目中看到的缺陷行为模式。下文将深入考究这些驱动因子。除了另行说明之外,这些结果都是基于 QSM 数据分析得出的。

规模

从历史来看,我们发现随着项目规模的增长系统内的缺陷数也会随之增长(如图 4 所示)。简单来说,构建更大的项目使开发人员有了更多导致系统缺陷的可能性,同时也需要去完成更多的测试。缺陷增长率几乎是呈线形的。

同样,随着规模的增长 MTTD 也会随之减少。这是由于系统内的缺陷数增加了,这通常是由于跨大型团队在所难免的交流复杂性所导致的。因为系统中的缺陷更多了,缺陷的时间间隔就减少了。依此类推,因为时间间隔太少,所以大型项目的可靠性往往较低。这是这个行业的典型情况。

图 4 随着规模增长缺陷数随之增长

产能指数(PI)

生产力往往对一个系统的整体质量也有非常大的影响,它可以通过产能指数来测量。它包含软件开发中的许多因素,比如管理人员影响力、开发方法、工具、技术以及开发团队的技能和经验。它还要考虑应用的类型和复杂度、过程因素和复用。它使用一个 0.1 到 40 的标准刻度范围,值低的地方与不良的环境、工具和复杂的系统相关,高值则代表有好的环境、工具和管理,对项目有着充分的理解。

历史数据表明,缺陷检测率会随产能指数的提升呈指数级下降。图 5 展示了相同规模软件应用在不同产能指数(分别为 17 和 21)下的累积的缺陷检出数。有着较高产能指数的项目不仅可以提前九个月交付,大约总计还要少 360 个缺陷。当开发团队变得更少时会更具意义,首先他们更少犯错,从而测试时发现的错误也会降低。在更高的生产力水平上工作可以大幅提升软件质量。

图 5 同样规模的系统在不同产能指数下产生的缺陷对比

人员配置

开发团队的规模也可以影响一个系统的质量,因为较大的团队往往比较小的团队产生更多的错误。如图 6 所示,当在相同项目规模下比较大型团队(红色)和小型团队(灰色)时,在所有项目规模下小型团队都会比大型团队少 50-65 个错误。另外,他们很少制定处罚条例,如果有的话也花不了多少工作量。去识别组织内哪里浪费时这个发现特别有用,因为它说明为项目增加资源未必总能提升质量。

图 6 不论什么项目规模,小型团队产生的错误都比大型团队少

总结

软件可靠性和质量这两个领域应该在预期环境和项目谈判阶段内就予以处理。质量反映了软件遵守或符合给定设计的程度(基于功能性需求或规格说明书),而可靠性是关于在特定环境中指定周期内软件运维的无故障率。

作为一个领导者,这里有几个策略可以让你用于改进可靠性和质量。保持已开发的产品规模尽可能地小,使用较小的团队,定期在环境中投资以改进开发工作室的效率和效果。所有这些措施都将得到可靠性和质量的回报。

参考资料

  • B. Boehm, IEEE Software, Sept. 1987, pp. 84-85
  • S. McConnell, An Ounce of Prevention, IEEE Software, May/June 2001

关于作者

C. Taylor Putnam-Majarian是 QSM 的一名顾问分析师,有超过 7 年的专业的数据分析、测试和研究经验。除了为来自商业和政府部门的客户提供软件评估和基准测试方面的咨询支持之外,Taylor 还撰写了大量敏捷开发、软件评估和过程改进方面的出版物,她还是 QSM 博客的定期撰稿人。最近 Taylor 在华盛顿特区举办的 Agile in Government 会议上展示了题为 Does Agile Scale? A Quantitative Look at Agile Projects 的研究。泰勒拥有迪金森学院的学士学位。

Doug Putnam是数量化软件管理股份有限公司(QSM)的联合首席执行官。他在软件度量领域有 35 年的经验并且被看作是这一行业发展的先驱者。Putnam 先生曾帮助指导业界领先的软件评估和度量工具 SLIM 套件的开发,并且是一个相当出名的国际化作家、演说家和顾问。其主要职责包括管理和交付 QSM 软件度量服务,定义 SLIM 产品套件的需求以及监督从 QSM 基准数据库衍生而来的研究活动。

查看英文原文: Understanding Quality and Reliability

2016-06-13 19:112757

评论

发布
暂无评论
发现更多内容

网络编程六-网络编程相关面试题汇总,nginx运行原理

Java 程序员 后端

系统性能典型案例分析:高性能队列Disruptor,一文深入理解(1)

Java 程序员 后端

系统性能典型案例分析:高性能队列Disruptor,一文深入理解

Java 程序员 后端

绝了!你一直想要的数据库界的里程碑,Alibaba技术官内部私藏MySQL笔记

Java 程序员 后端

网页制作工具之------Dreamweaver界面,springmvc教程下载

Java 程序员 后端

美团二面:聊聊线程池设计与原理,由表及里趣味解析,linux操作系统实用教程课后答案

Java 程序员 后端

老大让我优化数据库,我上来就分库分表,他过来就是一jio

Java 程序员 后端

老生常谈:MySQL高可用,java泛型原理

Java 程序员 后端

精雕细琢!阿里大师53天悉心打磨出来的MyBatis+设计模式架构指南

Java 程序员 后端

线上环境大规模RocketMQ集群不停机优雅升级实践,面试字节跳动Java工程师该怎么准备

Java 程序员 后端

网关性能大PK,Spring Cloud Gateway让人大失所望!,java教程pdf百度云下载

Java 程序员 后端

网络协议从入门到底层原理(11)网络爬虫,线程池底层实现原理

Java 程序员 后端

聊聊MySQL主从复制的几种复制方式,上岸蚂蚁金服

Java 程序员 后端

聊聊RabbitMQ RabbitMQ相关面试题,kafka入门教程步骤

Java 程序员 后端

终于彻底搞清楚了 MySQL spin-lock 之一次CPU问题定位过程总结(1)

Java 程序员 后端

终于等到了!十位Java架构师整理的“阿里P7,看完老板哭着让我留下来

Java 程序员 后端

聊聊多线程(一)线程的基础,linux集群架构师

Java 程序员 后端

系统性能百倍提升典型案例分析:高性能队列Disruptor,linux服务器架构师

Java 程序员 后端

系统性能百倍提升典型案例分析:高性能队列Disruptor(1)

Java 程序员 后端

老夫面试两个月真实经历:面试了20家大厂之后,发现这样介绍项目经验

Java 程序员 后端

聊聊MyBatis的历史,mysql原理详解

Java 程序员 后端

终于彻底搞清楚了 MySQL spin-lock 之一次CPU问题定位过程总结

Java 程序员 后端

绝杀!3位阿里大牛发布这份800页MySQL性能优化法则笔记

Java 程序员 后端

网络协议从入门到底层原理(5)传输层,java编程项目实例教程

Java 程序员 后端

[ CloudWeGo 微服务实践 - 04 ] 尝试操作数据(1)

baiyutang

golang 微服务 10月月更

群晖DS218+做maven私服(nexus3),mysql性能调优

Java 程序员 后端

老板,运维和开发又打起来了!,你连基础的JVM运行时内存布局都忘了

Java 程序员 后端

聊聊多线程(四)线程安全之AtomicInteger类,最全面试考点与面试技巧

Java 程序员 后端

精通springcloud:服务发现,Eureka API,java技术上难以解决的问题

Java 程序员 后端

缓存穿透及解决方案(干货篇),java基础入门第二版第二章答案

Java 程序员 后端

老面试官问我:LRU 和 Innodb Buffer Pool 有什么关系?

Java 程序员 后端

理解质量和可靠性_文化 & 方法_C. Taylor Putnam-Majarian_InfoQ精选文章