是否有一个指标可以等同于外行术语的复杂性？

Question

很多时候，用户无法理解软件的复杂性。他们认为，因为一个问题很容易描述，那么它就很容易解决。我想将我所构建的“简单程序”的复杂性与具有实际效果的过程的复杂性等同起来。

是否有一个系统能够接受具体的过程并为它们分配一个复杂的过程，例如：

建造厕所=5

建房子= 50

建造帝国大厦= 5000

然后，我可以用一种有意义的方式将其等同于软件：

thisProject =5

项目权重可能是由Cylcomatic复杂性决定的。不管是什么都没那么重要。重要的是这种制度的存在。这样的制度存在吗？

更新

我正在寻找一种方法来比较两个完整系统的复杂性。我不是在找估计方法。我认为使用“金钱和工时”的局限性在于，外行(甚至可能是一些技术人员)可以把这个项目花了这么长时间、花这么多钱的原因归咎于开发商(S)根本就不擅长他们的工作。

想出一个可能性..。

我认为这个问题的解决方案可能类似于迪克斯特拉算法。为System1创建流程图，为System2创建另一个流程图。根据决策包含多少条路线，给每个决策一个权重。每个动作也要有份量。然后，可以使用每个图表的累积权重来比较这两个过程。

1. 对于“有形过程”：如果某个工程师绘制了一个“建造一个厕所”的流程图，那么我们可以使用这样的算法来获得该过程的“总权重”。
2. 对于“无形过程”：假设整个程序可以映射到有限状态机，那么它可以被描述为流程图，并分配一个权重。

因此，厕所过程加权为50，“我的程序”加权为60。所以它就像建造一个厕所一样复杂。

Answer 1

大多数由单个人或小型团队设想的编程项目的特点不是它们的复杂性，它们的更好的特征就是它们的大小。

根据某物的大小来估计：

• 找一个典型的“单位”
• 估计建造一个“单位”的T所需时间
• 将“单位”的数目计算为N
• 乘N
• 如果有多种类型的单位，对每个单元重复并加在一起。
• 添加一些模糊的因素，如集成，复杂性，超支，返工等。

一个基本的小型企业系统可能有20个表单、30个数据库表、10个报表、2个与其他系统的连接。最后的结果可能是10,000行代码。可能需要200页的文件。其中任何一种都可以用作“单位”。

向客户显示“单位”的列表、每个单位的数量和估计数以及总数。然后把它比作一个大房子或一个小公寓楼，有着相似数量的“单位”。

规模比复杂性更重要，但编写编译器或框架库比编写基本业务系统要困难得多，“单元”更难识别。

Answer 2

最近的近似是时间。如果一个系统很小，但需要很长时间，这通常是由于它的复杂性。然而，这是一个很难理解的指标。

我发现有帮助的是估计这个项目。把估计值分解成几个部分。这个想法是把它分解成有意义的最小部分，这通常是敏捷方法中的故事。

没有人能真正理解一个系统需要5000小时的工作才能完成。这个数字太大了。但是，把它分解成个别的故事，每个故事都更容易被理解。如果一个故事是复杂的，需要更多的时间，这将更容易解释在故事层面上，而不是在史诗或系统层面。

说摩天大楼是一座复杂的建筑是一回事:我认为我们作为门外汉可以同意这一事实，但很难解释为什么。更有意义的是说一个子组件是复杂的。例如，电力系统是复杂的，因为大楼内将有5,000个独立的办公室，分别进行计量。污水系统是复杂的，因为在一个垂直的建筑物内将有400个卫生间，必须适当地通风。

当您将一个大问题分解为小问题时，就更容易将估计值附加到它们并解释为什么组件是复杂的。

所以没有，没有银弹号码，你可以用来衡量复杂性。但是，您可以将问题分解为更小、更容易理解的部分，并对其进行解释。

Answer 3

不怎么有意思。

到目前为止，已经提出的每个软件复杂性度量都显示，在来自实际项目的实际数据上，与原始SLOC(源代码行的原始数量)有很强的相关性。McCabe的圈复杂度值得注意的是，它在这一点上的罪恶感，霍斯特德的所有指标都紧跟其后。

你可以做一个花哨的度量，说McWizzBang值为42的程序比McWizzBang = 7的程序更复杂(或者更复杂)，但是你实际上只是说一个有一百万行代码的程序比一个有一千行代码的程序更复杂。嗯，杜赫！

顺便说一句，虽然你没有问它，但软件成本估算也是如此。无论你试图估计什么，为了达到你的成本估计，结果是你可以用更少的钱通过估算原始的SLOC得到同样的结果。