网志

烤架,第2部分:未知的虫子和爆米花

杰森·萨克斯(Jason Sachs)2020年4月5日2条评论

这是一篇有关在软件版本中降低收益的简短文章。

Those of you who have been working professionally on software or firmware have probably faced this dilemma 之前. The Scrum大师 世界上可能会像 完成的定义最低可行产品。等等等等等等。简单来说, 您如何知道何时可以发布产品? 这是一个容易回答的难题。

使得容易达成共识的是必须包含哪些功能。 Magic Happy Mobile Blender必须具有三种速度。按下向上箭头应提高速度。按下向下箭头应降低速度。如果未按下安全互锁开关,则搅拌机应停止。如果检测到的电机温度达到105 °C,搅拌机应停止。等等。这些是要求。完成的定义。最低可行产品。等等等等等等。您可以对此进行测试,发布完成或未完成。

本文以PDF格式提供,便于打印

使得上市时间和质量之间不可避免的紧张关系成为难题。我们可以包括这些功能或解决这些错误,但是将花费更长的时间。因此,利益相关者聚在一起,决定,好吧,我们不’不必担心自动清洁周期,因此我们可以忘记该功能,’如果电容开关检测不正确’如果一个人同时按下两个搅拌机上的BLEND(混合)按钮,则大多数情况下都无法工作,每只手的一根手指— ignore that bug, we’ll close it as Won’t修复。这些是判断力。他们可能会引起争议。我不’享受那种会议。决定删除某个功能可能会使人沮丧,特别是如果您’我花了很多时间来解决这个问题。

但是目前,我’我对这些错误更感兴趣,还有几年前唐纳德·拉姆斯菲尔德(Donald Rumsfeld)所说的话:

报道说有些事没有’发生的事情对我来说总是很有趣的,因为据我们所知,已知的东西很多。有些事情我们知道我们知道。我们也知道有未知的事物。就是说我们知道有些事情我们不知道。但也有未知的未知数—the ones we 做n’t know we 做n’不知道。如果纵观整个国家和其他自由国家的历史,那一类往往是困难的。

What 做es this have to 做 with software releases? 那里 is a stage in the product cycle when we’重新发现并修复错误,我们所知道的就是我们已经发现的错误。我们不’不知道是否有虫子’还没有被确定!我们赢了’不知道直到有人举报他们:如果你不这样做’t find the bugs, your customers will. 那里 are various studies that say

一个重要的相关见解是,修复或返工软件的成本为 在软件生命周期的早期阶段要小得多(50到200倍) 周期,而不是后期[Boehm,1976;法根(Fagan),1976年;戴利(1977)。

[勃姆(Boehm),1988年]

查找并解决软件问题 分娩后通常是100倍以上 比在需求和设计阶段查找并修复它昂贵。

正如Boehm在1987年所观察到的,“This 洞察力是将工业软件实践重点放在全面的需求分析和设计上的主要推动力, 进行早期验证和确认,以及 进行前期原型制作和仿真 以避免昂贵的下游修复。”

对于此更新的列表,我们添加了 the word “often”反映更多 关于此观察的见解。一 洞察力显示成本上升因素 对于小型非关键软件系统 比100:1更像5:1。这个比例 揭示了我们可以开发这样的系统 在非正式的,连续的原型模式下更加有效,仍然强调 尽早做好事情,而不要迟到。

[Boehm和Basili,2001年]

测试中发现的缺陷的成本比设计阶段发现的成本高15倍,比实现期间发现的成本高2倍。

[Dawson等,2010]

The Rule of Ten states that 后 每个质量保证级别的成本将增加10倍 纠正和修复缺陷的时间和金钱条款 在前一阶段。如果修复单元缺陷需要\ $ 100 测试,系统测试需要\ 1,000美元,UAT需要10,000美元, 以及\ 100,000的生产成本

[Standish集团,2014年]

等等。不幸的是,其中许多断言都没有提供成本增加的任何解释。一种思考的方法是,在软件开发生命周期中,软件的存在会经历“phase transitions” from “gaseous”在架构/设计期间(尚未编写任何代码),“liquid”在实施过程中,“gelatinous” during testing, to “solid”发布后。在每个步骤中进行代码更改都会产生影响:例如,如果在实施过程中进行了软件更改,则必须更改代码,而如果在测试过程中进行了软件更改,则必须重新进行测试。乔安娜·罗斯曼(Joanna Rothman)举了三个公司的例子:

甲公司没有’t跟踪了在需求,设计和开发阶段检测和修复缺陷的时间,但它确实跟踪了产品出厂后修复缺陷所需的工程时间。发货后,公司A遇到一个常见问题:一些客户对产品质量感到非常失望—最常见的是工程师在发布之前无法修复缺陷的区域。当不满意的非常重要的客户致电高级管理层时,高级管理层随后要求Engineering修复缺陷,作为“emergency” fix.

运输后修复缺陷需要额外的费用。开发人员仍然必须找到缺陷,测试人员必须验证修复程序。另外,对于每个修复程序,编写者都必须开发发行说明,构建工程师必须创建一个单独的分支,测试人员必须进行系统级测试,以验证没有造成其他严重缺陷。因为产品已经发布,所以公司A’的额外系统测试费用包括:

  • 将回归测试添加到测试套件
  • 测试修复程序周围的更多区域
  • 在不同的硬件/软件平台组合上执行广泛的系统测试

During normal system testing, the testers skipped many of these steps because of insufficient time. They could not skip these steps 后 release, though —测试人员必须验证此修复程序不会对其他客户造成问题。

After the fix, the build engineers merged the fix back into the current development branch, 和 testers verified that the fix still worked in the current development branch. Aside from the engineering work, middle management spent significant time tracking the progress of the 紧急情况 fix work 和 reporting that progress to senior management 和 customer.

这些额外的工作加起来。发布后,A公司估计每个修复花费了20个人日。以每人每天500美元的价格计算,每个修复程序的费用为10,000美元。公司A通常有20“emergency” fixes 后 each release, for a total post-release fix cost of about \$200,000.

[罗斯曼,2000年]

So the next time you run across one of these 紧急情况 bugs post-release, 和 one of your team members goes, “Oh, hey, that’s easy to fix, it’我要花几分钟”轻轻提醒他们,实现时间只是完成产品更新版本所需工作的一小部分。

那里 are also additional costs to 做ing this kind of 紧急情况 bug-fixing work:

  • the opportunity cost of staff not working on their normal tasks 之前 the 紧急情况 popped up —这些任务将被延迟,或者可能需要缩小范围

  • 上下文切换和失去焦点的成本—如果我正在复杂的任务A的工作中,这通常需要我5天,而有人打扰我去进行需要2天的高优先级任务B的工作,那么我完成这两项任务的总时间是多长时间和B?答案不会是7天。而是7天

    • whatever time it takes me to wrap things up with Task A so that I can resume it more easily 后 Task B is complete
    • 是时候将我的重点从任务A更改为任务B
    • 加 the time to change my focus back to Task A 后 Task B is 做ne.

    这笔额外费用是’对于短时间的任务来说太糟糕了,但是一个复杂的,为期数周的任务可能需要我整天来处理。那不’t mean I’m sitting there scratching my head for a day 之前 I can resume work on something, but rather, until I get back in the zone 和 focus on Task A in my short- 和 medium-term memory, I’因为工作效率降低,我可能不得不停下来并重新熟悉任务A的各个方面。

好歹— there’解决错误的强烈动机 之前 释放而不是 .

频繁交付的Scrum团队可能会争辩说’s no “before” or “after”释放;而是一系列连续发布,’解决1.04版中的错误要比1.03版中花费更多— well, sure, that’是的,只要客户还可以等待更长的时间。一旦软件的已发布版本中存在错误,开发人员应付出的代价’如果修复被延迟,则不会更改。甚至可能 减少 因为放宽了一些约束,它可以等到开发人员准备好专注于它。但请想象一下以下事件序列:

  • 版本1.02已发布
  • 正在开发1.03版,并且在此过程中意外引入并发现了三个错误:问题1152、1153和1154。
  • 问题1152在开发过程中已修复
  • 小组争论是否应将1.03版的1153和1154固定,并最终决定将其固定为1.03版,而不是将其固定为1.04版。
  • 1.03的开发工作完成
  • 版本1.03.01由自动构建创建
  • 集成测试从1.03.01版开始—团队已经有很多自动化测试,但是他们可以做一些事情’t自动化(也许这是嵌入式系统,而硬件没有’适用于系统级别的自动化测试)
  • 在测试期间,发现了一个新的错误:问题1155
  • XYZ副总裁参加会议,提到问题1153和1155是紧急解决,否则客户R和S会将其业务转移到其他地方,而1154没有’尚待修复,但很重要,应在文档和培训中提及。此外,团队需要尽快发布。
  • 团队修复了1153和1155,并从其通常的最佳软件实践中删除了一些UVW快捷方式(固体, 干燥等);问题1154和1155密切相关,因此针对1155的修复涉及解决问题1154
  • 版本1.03.02由自动构建创建
  • 集成测试在1.03.02版上重新启动
  • 集成测试完成
  • 文档和培训资料已更新,以提及第1154期
  • 版本1.03.02已发布— team celebrates!

现在:我们有几类错误—

  • 解决问题1152的费用:仅实施
  • 解决问题1153的费用:
    • 实施和测试
    • UVW快捷方式以后需要修复
  • 解决问题1155的费用:
    • 实施和测试
    • 解决问题1154的实施成本增加
    • UVW快捷方式以后需要修复
    • 解决方法稍后需要修复
  • 解决问题1154的成本:
    • 1.03.02版:文档和培训材料
    • 未来版本:实施和测试,以及第二次更新文档和培训

错误越深入产品发布周期,就需要花费更多的精力进行修复并应对未修复的后果。

爆米花

臭虫唐’t just reveal themselves; they have to be found. Some are easy to find, some are not. I have a mental model of 爆米花 kernels:

软件错误 爆米花
一个错误 One 爆米花 kernel
存在但尚未找到的错误 未弹出的内核
发现的错误 弹出的内核
发现错误 加热玉米粒

要是我们’re making a bowl of microwaved 爆米花, we have to decide how long to run the microwave. Shorter times = more unpopped kernels; yuck. Longer times = fewer unpopped kernels; hurray. But if we go too long, we start to become impatient, 和 some of the 爆米花 burns.

那里’如果您决定停止时间,这也是一种非常简单的方法’愿意停留在微波炉旁等待:爆米花来了又快又发脾气,然后开始减速,所以当它们变得足够慢时,您就停止该过程并取出爆米花。你不’不必学习数学或物理学就可以了解这一点;它’对于用微波炉制造爆米花的人来说,这几乎是一种直观的策略。

这就是我想要传达的想法:

如果你’重新测试您的软件,并且您仍然经常发现错误,请期待还有更多未发现的错误。

什么时候该停止测试?我不’没有答案;也许如果你’已经一周没有找到错误了,那么这提供了足够的信心,让所有剩余的bug变得晦涩难懂。

I 知道如果我的团队每天持续发现多个错误,那么它’s likely that we’第二天会发现更多错误。

我也知道,如果有一个错误使我们无法使用该软件的某些功能,那么那里’这是一个不错的机会,这些功能中潜藏着未知的错误,因为我们没有’根本无法测试它们。因此,就降低风险而言,应将阻止完全测试的任何错误给予更高的修复优先级。

如果没有时间’我们付出了巨大的代价’d继续测试直到我们不这样做’长时间找不到任何新错误,以增强对我们软件的信心。 (或更系统地说:’d跟踪测试范围并检查我们’在可预见的条件范围内测试了所有功能。在某些行业中,这是一项要求—例如航空航天,汽车和医疗。)

但是时间是一种宝贵的商品。

我希望我可以采用一种更加定量或基于证据的方法来确定正确的权衡。

In the interest of exploring the 爆米花 analogy, I decided to see if there were any articles on 爆米花 that might have some analogous conclusions for software testing. I was surprised by what I found, although most of it was not relevant for my purposes:

One that seemed directly relevant to my 爆米花 analogy was called 爆米花制作:不加内核从Gold Medal Products Company, a manufacturer of food equipment for movie theaters 和 concession stands:

Other factors for 爆米花 popping success are being a good listener 和 爆米花 storage. After the machine gun-like cadence at the height of a popping endeavor, listen carefully for when the popping slows 做wn. Wait until there is a second or two between pops 之前 removing the 爆米花 from the heat source. But 做n’t wait too long, or the 爆米花 will begin to burn.

但是,没有数学,数据或理论。呸。

我发现的其他唯一有用的参考资料来自 保罗·普基特,是BAE Systems的一名工程师,他撰写了有关“GeoEnergy”或寻找碳氢化合物的地质科学。这是2009年10月的博客文章,标题为 爆米花爆破发现:

在寻求与我们的经验世界中可能存在的石油枯竭的完美比喻时,我遇到了迄今为​​止我所遇到的最平凡而实际的例子。由一个提示 Memmel的评论 在TOD任职期间“simulated annealing” in trying to explain the oil discovery process, I began pondering a bit. At the time, I was microwaving some 爆米花 和 it struck me that the dynamics of the popping in some sense captured the idea of 模拟退火, as well as mimiced the envelope of peak oil itself.

所以我建议回复梅梅尔’s comment that we should take a look at 爆米花 popping dynamics. The fundamental question is : 为什么不’所有的内核都同时弹出吗? 我花了一些时间来奠定基础,但最终我提出了一个可行的模型,该模型的复杂性主要涉及反应动力学。毫不奇怪,概率和统计数据很容易得出,因为它与我根据 分散发现模型.

普基特继续引用伯德和佩罗纳’s 2005 study, 爆米花爆破动力学 (很遗憾,它位于付费专栏后面)并使用了“分散发现模型” to fit the data:

$$ \begin{aligned} P(t,T) &= 1-\ frac {e ^ {-\ frac {B} {f(t,T)}}} {1+ \ frac {A} {f(t,T)}} \ cr f(t,T) &= e ^ {R(T,t)}-e ^ {R(T,0)} \ cr R(t,T) &= k(T-T_c)^ 2t-c(T-T_c) \end{aligned} $$

该研究的作者唐’不要使用与我相同的表述,因为理论家没有’倾向于运用我所做的粗尾弥散数学。因此,他们诉诸于使用高斯包络来产生一定随机性的一阶逼近。它们本质上等同于将B项设置为1,将A项设置为0。这确实表现为在爆破初期的低温下更合适。

然后,他继续显示一堆图表,显示它们的拟合程度。

结果是,这个爆米花爆裂实验是分散发现的极好的数学类比。如果我们将最初听到的爆破声视为离散发现的最初搅动,那么当爆破声达到峰值时,随着爆破声逐渐增强,这种类比成立。之后,偶尔出现的流行声便消失了。石油发现也是如此, 偶然发现爆音可能会发生在曲线下方就像我们在1960年初定义的峰值’s.

附录C:色散类比 2018年书“数学地球能:发现,耗竭和更新”由Pukite,Coyne和Challou撰写。

这个想法“dispersive discovery”听起来与软件工程非常相关。发现臭虫的过程是大海捞针的发现之一— the theme of 普凯特的另一个’s articles 展示了一些石油发现的数学模型,以及对其中一些见解的讨论:一些石油更难发现,主要是因为它存在的深度增加。

我发现发现软件错误有很多相似之处。有些很容易找到,而另一些则更困难,因为重现错误所需的一系列情况更加复杂。

因此,假设我们有一个软件项目,并进入测试阶段,每天我们记录寻找错误所花费的时间以及发现的错误数,则可以绘制出错误的累积数量与错误的累积数量之间的关系。数小时的时间来寻找它们,我们可以拟合一条曲线并尝试在未来几天进行推断。

然后我们可以设置某种阈值作为成本权衡—我会要求工程团队将门槛设置得比您想象的要高同样,修复将其投入生产的错误的成本很高。

我从JIRA获得了有关我的项目的数据’我们曾经在工作中使用过,但不幸的是,它仅包括每天发现的错误数量,而不是我们花费了多少小时来寻找它们。

Perhaps some of you have taken such a quantitative approach 之前 —如果有,请告诉我!

至少,请查看您遇到的错误数量’ve been finding. 如果你’仍然找到他们,然后在那里’还有一些东西,例如蟑螂。但是请注意,相反是’t true: 没有证据不是没有证据。测试,测试,测试,并确保已计划好 测试范围.

嵌入式世界的建议

嵌入式系统与联网台式机或移动计算机有些不同。如果我的软件供应商发现并修复了错误,他们可以通知我’那里有更新的版本,甚至自动推送更新。从理论上讲,对于网络嵌入式设备也是如此,但是固件升级是一件罕见的事情,原因有两个:

  • 与Internet连接的嵌入式系统仍然相对不常见。我不’没有任何可靠的统计数据来支持这一点—如果您知道的话,请告诉我—除了检查自己的家庭外,我只有三个联网的嵌入式系统(两个智能恒温器和另一个设备)和一个Roku流视频播放器,但还有许多其他嵌入式系统—电视,DVD播放器,汽车(当今的汽车上有数十个微控制器),咖啡机,冰箱,微波炉,灌溉系统,几个数码相机,GPS接收器,汽车电池充电器,烟雾警报等—没有联网。一世’我什至不确定Roku应该算作嵌入式系统;它’基本上只是一台小型单板计算机,带有电源插孔,红外接收器(用于接收来自遥控器的信号),WiFi接口和HDMI端口。

  • 消费者嵌入式系统的商业模式’致力于支持固件升级。我有一台10岁的松下数码相机DMC-G2, 于2010年3月9日首次宣布。它的最新固件更新仅在8个月后的2010年11月发布:

    松下没有’不想卖给我,甚至不给我新固件;他们想支持和销售最新的相机,这就是他们赚钱的方式。

如果你’在嵌入式固件上工作,在大多数情况下,您可以一次发布;如果您的大批量产品仍在流行曲线上,则可能是两三个。对于固件而言,测试变得比对计算机软件更为重要。我也是这么想“popcorn”建议适用;如果你’仍在查找固件错误,您’re not 做ne yet.

包起来

今天,我们讨论了何时可以发布软件版本,以及该时间与发现错误的频率有何关系。与在设计和实施阶段尽早发现并修复错误相比,在发布周期的后期修复错误的成本很高。’t会产生后期费用,例如测试,文档编制,培训或快速的,可见度较高的紧急修复。爆米花比喻是,未识别的错误就像未爆裂的爆米花一样,您应该等到新的错误报告的速度显着下降后再进行操作’重新完成,否则在发布后,当它们变得更昂贵时,可能会发现更多错误。

感谢您阅读并保持健康!


©2020 Jason M. Sachs,保留所有权利。


[-]
评论者 杰克逊2020年6月14日

The 爆米花 comparison is great!

[-]
评论者 杰里·詹姆斯2020年6月3日

要发布对评论的回复,请单击每个评论所附的“回复”按钮。要发布新评论(而不是回复评论),请查看评论顶部的“写评论”标签。

注册后,您可以参加所有相关网站上的论坛,并获得所有pdf下载的访问权限。

注册

我同意 使用条款隐私政策.

试试我们偶尔但很受欢迎的时事通讯。非常容易退订。
或登录