解释软件熵：原因，影响和补救措施

本文概述

• 什么是软件熵？
• 软件熵的影响
• 软件熵的来源
• 如何计算熵：为C, S和I分配值
• 减少E的增长
• 本文总结

本文针对的是软件开发人员或项目经理, 他们对什么是软件熵, 对其工作的实际影响以及促进其增长的潜在因素感到好奇。

主要目的是建立对软件熵的认识, 因为它是所有形式的软件开发中的一个因素。此外, 我们探索了一种可以为软件熵分配具体值的方法。只有量化软件熵并观察其在后续发行版中的增长, 我们才能真正了解它对我们当前目标和未来计划构成的风险。

什么是软件熵？

软件熵是从现实世界中熵的主要特征中得名的：它是一种混沌的度量, 它可以保持不变或随着时间的推移而增加。换句话说, 它是衡量软件系统固有的内在不稳定性的变化量。

不幸的是, 软件熵很少得到应有的重视。

从开发团队撤离某人, 过早开始开发周期或实施”快速修复”时(在实际上最有可能增长的时刻), 都不会考虑。

软件开发是一门艺术和一种行业, 其核心构建模块定义不清。尽管构建人员使用水泥和指甲, 但是软件开发人员使用逻辑断言和一组假设。无法将它们握在手中并进行检查, 也不能在八分之一英寸处订购。尽管偶然的观察者可能会想将软件开发与构建进行比较, 但除了一些表面上的相似之处, 这样做反而适得其反。

尽管存在这些困难, 我们仍然可以制定指导方针, 使我们能够理解软件熵的来源, 衡量其对我们的目标构成的风险的程度, 以及(如有必要)可以采取哪些步骤来限制其增长。

建议的软件熵定义如下：

E = I´C / S

其中I´是从上次开发迭代中引入的意外问题的数量得出的, C是对系统实施更改现在导致新的I´> 0的感知概率, S是下一次开发迭代的范围。通常, 低于0.1的E值被认为是良好的。 E值为0.5被认为是很高的, 高于1.0的值是压倒性的。

开发迭代的概念是我们对软件熵的理解所不可或缺的。这些是从系统的一种行为导致另一种行为的活动周期。我们在软件迭代期间为自己设定的目标称为其范围。在软件开发中, 此类周期涉及修改或扩展软件的基础代码。

即使对代码进行的所有修改都不会在开发迭代中发生, 即使执行代码的人们对此并不这么认为。也就是说, 以使用”快速而肮脏”的方法来构建系统而自豪的小型组织(很少或根本没有需求或分析的收集)仍然使用开发迭代来实现其目标。他们根本就没有计划。同样, 即使修改后的系统的行为与我们的意图有所不同, 它仍然可以通过开发迭代来实现。

实际上, 发生这种风险的原因恰恰是我们对软件熵的了解旨在加以解释, 而我们对其进行度量的愿望却旨在加以限制。实际上, 我们可以如下定义软件熵。

任何给定的系统都有一组有限的已知未解决问题I0。在下一个开发迭代的末尾, 将有一组有限的已知未解决问题I1。系统的固有熵指定了我们对I1的期望可能与其实际值相差多少, 以及在随后的迭代中相差可能会增大多少。

软件熵的影响

我们对软件熵影响的实践经验取决于我们如何与所讨论的系统进行交互。

用户具有软件的静态视图；他们关心的是它现在的行为方式, 而不关心系统的内部结构。通过执行预定义的动作, 用户假定软件将以相应的预定义行为做出响应。但是, 用户最不愿意推论他们正在使用的软件中的熵水平。

软件熵与变化的概念联系在一起, 在静态系统中没有意义。如果没有改变系统的意图, 我们就不能说它的熵。同样, 尚不存在的系统(即, 下一次迭代实际上是它的第一个迭代)没有熵。

从用户的角度来看, 软件可能被认为是”笨拙的”, 但是如果在随后的迭代中, 软件开发人员和管理人员按计划达到了他们的目标, 我们必须得出结论, 系统中的熵实际上非常低！因此, 用户的经验几乎没有告诉我们有关软件熵的信息：

• 软件开发人员对软件的看法不明确。他们关注的是系统当前仅在必须更改的情况下才能运行, 并且关注系统如何设计适当策略的细节。

• 管理人员可能对软件最复杂的看法, 包括静态的和流畅的。他们必须在短期需求与进一步延伸至未来的业务计划需求之间取得平衡。

扮演这两个角色的人都有期望。只要这些期望被破坏, 软件熵就会显现出来。也就是说, 软件开发人员和管理人员会尽最大的努力评估风险并为风险做出计划, 但是-除了外部干扰之外-如果他们的期望仍然令人失望, 那么只有这样才能说到软件熵。它是一只看不见的手, 它破坏了范围之外的组件交互, 导致生产服务器莫名其妙地崩溃, 并保留了及时且具有成本效益的修补程序。

许多具有高熵水平的系统都依赖于特定的个人, 尤其是在开发团队中有初级成员的情况下。这个人拥有的知识使得其他人没有他的”宝贵”投入就无法执行任务。由于它由异常, 预感和技巧的混合物组成, 因此无法在标准的UML图或技术规范中捕获它。这种知识不依赖于逻辑上一致的框架, 因此很难(即使不是不可能)转移给任何其他人。

让我们假设, 这样的组织可以通过极大的决心和努力来扭转局面并稳定其IT部门。情况似乎有所改善, 因为当软件开发停止时, 任何进展都是令人鼓舞的。但是, 实际上, 与达到预期目标相比, 实现目标的期望值很低, 而在熵值仍然较低的情况下, 可以实现的崇高目标却毫无意义。

当软件熵使项目不堪重负时, 项目将冻结。

没有更多的开发迭代。幸运的是, 这种情况不会立即出现。每个系统都会经历缓慢而陡峭的向悬崖边缘的行进。不管第一个版本的组织性和效率如何, 在进行连续的开发迭代后, 除非采取特定措施来防止它的熵, 否则它的熵就会增加, 并因此会出现意外地出错的风险。

软件熵不能降低。就像现实世界中的熵一样, 它只会增长或保持不变。起初, 它的影响可以忽略不计。当它们开始显现时, 症状就很轻微, 可以掩盖或忽略。但是, 如果组织仅在成为软件项目的主要风险后才尝试与软件熵作斗争, 那么它会遗憾地发现其努力是徒劳的。因此, 当软件熵的程度较低且负面影响最小时, 它最有用。

并非每个组织都应该投入资源来限制其产品中熵的增长。当今正在开发的许多软件(尤其是面向消费者的软件)的预期寿命相对较短, 可能为数年。在这种情况下, 其利益相关者无需考虑软件熵的影响, 因为在丢弃整个系统之前, 它很少会成为严重的障碍。但是, 没有太多明显的理由来考虑软件熵的影响。

考虑运行互联网路由基础结构或将钱从一个银行帐户转移到另一个银行帐户的软件。在任何给定的时间, 都会在生产中使用此软件的一个或多个版本, 并且它们的集体行为可以以相当高的准确性记录下来。

系统的风险容忍度是衡量从一个开发迭代到下一个开发迭代, 我们可以舒适地允许多少和何种类型的意外行为的度量。对于刚才提到的系统类型, 风险承受能力远低于路由电话的软件。反过来, 此软件比驱动许多商业网站的购物车的软件具有较低的风险承受能力。

风险承受能力和软件熵之间存在关联, 因为软件熵必须最小, 以确保在下一次开发迭代中我们将保持在系统的风险承受能力之内。

软件熵的来源

软件熵源于缺乏知识。这是由于我们的公共假设与现有系统的实际行为之间的差异造成的。这个事实解释了为什么软件熵仅在修改现有系统的情况下才有意义。这是我们缺乏了解的唯一机会会产生任何实际影响。软件熵在系统中找到最肥沃的土壤, 其细节无法被一个人理解, 而是散布在开发团队中。时间也是消除知识的有力工具。

代码是一系列逻辑断言的表达。当软件的行为(以及因此的代码)与它要表达的逻辑不符时, 我们可以说它的固有熵。这种情况可能以三种方式出现：逻辑是众所周知的, 并且与它的表达有所不同；对代码打算表达的逻辑有多种理解, 或者对于逻辑不是很了解。

• 第一种情况-逻辑是众所周知的-与当前的表达方式有所不同-最容易解决, 但也最不常见。只有大约两个参与者(一个开发人员和一个负责业务计划的人员)维护的非常小的系统将属于此类别。

• 第二种情况-逻辑不为人所知-是很少见的。出于所有目的和目的, 开发迭代甚至无法开始。如果某个时候所有利益相关者都可以同意, 那么他们很可能会遇到第一种情况。

人的思想会解释其经历, 有效地过滤和修改它们, 以使其适合个人框架。在缺乏有效的开发习惯(基于自由交流思想, 相互尊重和明确的期望)的情况下, 对于系统当前运行方式的解释可能与团队成员一样多。团队当前开发迭代的目标本身可能存在争议。

许多开发人员通过加强自己对自己的需求以及系统”应该”如何组织的独特理解, 来保护自己免受这种情况的影响。另一方面, 管理者和其他利益相关者可能会不经意地试图改变其他团队成员的假设, 这是在使他们自己的生活更轻松的错误尝试中。

现在, 我们得出了软件熵的最常见来源：对系统要表达的逻辑有多种不完整的解释。由于这种逻辑永远只有一个表现形式, 因此从定义上讲这种情况是有问题的。

这种缺乏知识如何产生？无能是一种方法。而且, 正如我们已经看到的, 对下一个开发迭代的目标缺乏共识是另一个原因。但是还有其他因素需要考虑。一个组织可能声称要采用一种开发方法, 但随后随意放弃其某些或全部方面。然后, 软件开发人员的任务是完成模糊的任务, 这些任务通常易于解释。实施变更其开发方法的组织特别容易受到这种现象的影响, 尽管它们绝不是唯一的组织。管理层不知道或无法解决的人际冲突也可能导致期望与结果之间的危险分歧。

我们失去第二种更重要的方法是转移产品的技术知识。即使对于最熟练的作家来说, 在纸上获取技术知识也具有挑战性。原因是转录的内容和方法一样重要。没有适当的纪律, 技术作家可能会记录过多的信息。或者, 他们可能做出使他们忽略要点的假设。在生产之后, 必须精心地更新技术文档, 这对于许多几乎在编写文档后就失去跟踪记录的组织而言, 是一个难题。由于这些困难, 很少将技术知识单独传递到文档中, 而是以配对或其他形式的人与人之间的紧密交互来传递。

每当活跃的参与者离开开发团队时, 软件熵就会突飞猛进。他们正在与他们一起获取宝贵的专业知识。复制该专有技术是不可能的, 并且对其进行近似化需要大量的努力。但是, 只要有足够的注意力和资源, 就可以保留足够的知识, 以使系统熵的增长最小化。

熵还有其他来源, 但是这些来源相对较小。例如, 软件腐烂是系统受其环境变化意外影响的过程。我们可以想到它所依赖的第三方软件(例如库), 但是还有其他更隐蔽的软件腐烂原因, 通常是由于系统所基于的假设发生了变化。例如, 如果在设计某个系统时就对内存的可用性做出了某些假设, 那么如果减少了系统的可用内存, 它可能会在意外的时刻开始发生故障。

如何计算熵：为C, S和I分配值

我是软件系统中未解决的行为问题的数量, 包括缺少承诺的功能。这是一个已知量, 通常会在JIRA之类的系统中进行跟踪。 I´的值直接从中得出。 I´是在上一次开发迭代中被遗弃或不完整的”工作单元”的数量, 以及由于新引入的和意外的行为问题而导致的工作单元的数量。由于I´被视为多个工作单元, 因此我们可以将其与S的值相关联, S的值是同一工作单元中下一个开发迭代的范围。确切地构成”工作单元”的内容取决于开发方法。

C是在实施范围内的工作单元时, 下一次迭代中实际未解决的问题I1的数量将大于其现在的估计的感知概率。该值位于域0 <= C <= 1中。

有人可能会说, 概率C正是软件熵所要衡量的。但是, 该值与我们的软件熵度量之间存在根本差异。出现问题的概率完全是：这不是真正的价值。但是, 这样做很有用, 因为参与项目的人员的感受是有关项目稳定性的宝贵信息来源。

范围S考虑了建议的更改幅度, 必须以与I´相同的单位表示。较大的S值会降低熵, 因为我们正在扩大建议的更改范围。尽管这听起来可能违反直觉, 但我们必须记住, 熵是衡量系统开发可能不符合我们期望的一种度量。仅仅说熵是引入问题的机会的量度是不够的。我们自然会尝试并预测风险, 并在我们的计划中考虑风险(因此在我们对I1的估计中也可能会考虑到这些风险, 这些风险很可能会超过0)。显然, 我们对承担较大的变更范围越有信心, 可以说系统中的熵就越小-除非那些计划变更和/或执行变更的人没有能力。但是, 这种可能性可能反映在I´的当前值中。

注意, 我们不必尝试指定I1的实际值与其期望值之间的差异的大小。如果我们在制定计划时假设我们的计划是正确的, 那么假设我们可以预测结果不能达到我们的预期程度也是不合理的。我们只能指定不会的感知机会C。但是, 实际值I1与期望值的差异程度是导出值I´形式下一次迭代中熵计算的重要输入。

从理论上讲, I´可能为负值。但是实际上, 这种情况永远不会发生。我们通常不会偶然解决问题。 I´的负值不是一个令人欣慰的信号。他们暗示计算熵的方法是有缺陷的。如下所述, 当然可以通过采取特定措施来减少软件熵的增长。但是, 在这种情况下, 我不应该承担负值, 因为我们始终将期望纳入设计中。

C是一个主观价值。它存在于开发迭代参与者的脑海中, 可以通过对参与者进行投票并取平均结果来推断。这个问题应该以积极的方式提出。例如：”以0到10的比例(最有可能10), 你如何估计团队在此开发迭代中实现其所有目标的机会？”

请注意, 问题是关于团队的整体目标, 而不是一个子集。响应10表示C的值为0, 而响应7则表示C值为3.。在较大的团队中, 每个响应的权重可能取决于相关因素, 例如一个人参与项目多长时间以及他们实际花费了多少时间。然而, 能力不应成为衡量回应权重的因素。不久之后, 即使是团队的初级成员也将了解其在实现目标方面的有效性。足够大的团队可能希望在平均剩余值之前丢弃报告的最高和最低值。

问专业人士团队失败的可能性是一个敏感而挑衅的主张。但是, 这正是任何希望量化熵的组织都需要提出的问题。为了确保得到诚实的答案, 即使参与者报告了很高的价值, 也应匿名提供C的估计值, 而不必担心会受到打击。

必须为S分配与I´相同的”工作单位”中的值, 因此高度依赖于开发方法。对于采用敏捷方法论方面的团队而言, 故事对于S和I´来说似乎是最明显的”工作单位”。在这种情况下, 开发迭代的程度跨越每个定期计划的发布到生产中, 无论是次要的还是主要的。我要量化为发布前每个Sprint期间未成功完成的故事数与发布后出现的意外问题所导致的包含在以后的Sprint中的故事数之和。

请注意, 我们不将修补程序或生产中的其他计划外发行版视为定义开发迭代的程度, 也不应从I´中减去任何关联的故事。

这种方法的困难在于, 必须先进行一段时间的发现和分析, 然后才能将错误分解为故事。因此, 只有在延迟之后才能定义I´的真实值。此外, 在每次冲刺开始时自然会进行C轮询。因此, 必须再次在整个发行版的范围内平均获得的结果。尽管存在这些困难, 但任何采用敏捷方法的方面的团队都可能会发现故事是量化S(因此I´)的最准确单位。

今天还有其他开发方法正在使用。无论采用哪种方法, 度量软件熵的原理都保持不变：应在生产发布之间度量软件熵, 应在相同的”工作单元”中度量S和I´, 并应从直接参与者那里获取C的估计值以非威胁性的方式, 最好是匿名方式。

减少E的增长

一旦失去了有关系统的知识, 就永远无法重获它。因此, 无法降低软件熵。我们所希望做的就是限制其增长。

可以通过在软件开发过程中采取适当的措施来限制熵的增长。在这方面, 敏捷开发的配对编程方面特别有用。由于在编写代码时涉及多个开发人员, 因此分发了基本细节的知识, 并减轻了离职团队成员的影响。

另一个有用的做法是制作结构合理且易于使用的文档, 尤其是在采用瀑布方法的组织内部。此类文档必须以每个人都理解的严格且定义明确的原则为后盾。依靠文档作为沟通和维护技术知识的主要手段的组织非常适合这种方法。只有在没有有关如何编写和使用内部书面文档的指南或培训时(如在采用RAD或敏捷方法的年轻组织中经常发生的情况), 才有价值其价值。

有两种方法可以减少系统中熵的增长：执行旨在减少I´的更改或执行旨在减少C的更改。

第一个涉及重构。旨在减少I´的动作本质上往往是技术性的, 读者可能已经很熟悉了。开发迭代必须发生。此迭代中旨在减少熵的增长的部分将不会带来任何实际的业务收益, 同时会浪费时间和资源。这个事实通常使减少熵的增长成为任何组织中的强力推销。

降低C的值是更有效的策略, 因为效果是长期的。另外, C是检查I´与S之比的重要指标。降低C的措施往往集中在人类的行为和思维上。尽管这些动作本身可能不需要开发迭代, 但随着参与者接受并适应新程序, 它们将减慢后续迭代的速度。就应该进行哪些改进达成共识的看似简单的举动是一条充满自身危险的道路, 因为项目参与者和利益相关者的不同目标突然暴露出来。

本文总结

软件熵是更改现有软件会导致意外问题, 未实现目标或同时导致两者的风险。

尽管在首次创建软件时可以忽略不计, 但是软件熵随每次开发迭代而增长。如果任其发展, 软件熵最终将使进一步的发展停滞。

但是, 并非每个项目都应该考虑软件熵的影响。在熵能产生明显有害影响之前, 许多系统将停产。对于那些寿命足够长以至于熵构成了可信风险的人们, 建立对它的认识并衡量其程度, 虽然仍然很低, 但它们提供了一种确保不会过早中断发展的手段。

一旦系统完全被软件熵的影响所淹没, 就无法进行更多更改, 开发工作基本上就此结束。