Software Size Estimation by Integrating Functional Size and Functional Complexity Measures
本研究提出了一种通过回归分析将功能规模度量（UFP 和 CFP）与功能复杂度度量（CC 和 YC）相结合的软件规模估算模型，证明了结合这些指标——特别是将 UFP 与复杂度度量相结合——能够显著降低估算误差，并提高诸如 COCOMO II 等应用的预测准确性。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
开发软件是一项复杂的工程，就像建造建筑物一样，只不过其材料不是砖块和砂浆，而是代码行和功能需求。几十年来，项目经理一直依赖统计这些代码行数来估算一个项目需要多少时间和资金。然而，这种方法是有缺陷的，因为两段程序可以实现完全相同的功能，但根据程序员编写方式的不同，所需的代码量可能大相径庭。为了解决这个问题，业界开发出一种通过衡量软件对用户实际“做了什么”——即统计输入、输出和数据文件——而非如何编写代码的方法来衡量软件规模的方法。这被称为功能规模。然而，即使是这种功能计数也存在盲点：它衡量的是功能的数量，却往往忽略了构建这些功能的难度。一个简单的功能可能很容易构建，而一个拥有许多分支路径和条件的复杂功能可能在编码时成为一场噩梦，即便两者在传统意义上都只被计为一个“功能”。
功能规模与构建复杂度之间的这种差距，正是来自印度尼西亚的一个研究小组试图解决的核心难题。他们致力于研究，将功能规模的度量与结构复杂度的度量相结合，是否能更准确地预测软件项目的真实规模。他们的工作重点在于完善如何估算构建软件所需的投入，这是一项至关重要的任务，决定了一个项目是能保持在预算内，还是会失控。通过同时观察软件的“内容”以及“构建难度”，他们旨在为这些数字系统的规划者和管理者描绘出一幅更清晰的图景。
研究人员首先从两个真实的软件项目中收集了数据：一个是为员工合作社设计的，另一个是为零售店设计的。他们没有使用公共数据集，因为那些数据集往往缺乏其分析所需的特定细节。相反，他们将这些应用程序的文本需求转化为视觉流程图，即 BPMN 图。这些图表充当了桥梁，使团队能够为系统的每个部分提取两种不同类型的测量值。首先，他们计算了功能规模，即统计用户交互和数据文件的数量。他们使用了两种既定的方法进行计算：一种是计算未调整的功能点，基于输入和输出等标准类别；另一种是计算 COSMIC 功能点，通过追踪数据在系统中的流入和流出。
接着，他们测量了这些相同部分的结构复杂度。这涉及分析流程图内的逻辑，以查看存在多少决策点、循环和分支路径。他们使用了两种不同的复杂度指标：一种统计代码中的独立路径数量，另一种则权衡不同类型分支和循环的认知难度。最后，他们将这些组合测量值与实际编写的代码行数进行了对比。这个最终计数作为“地面真值”（ground truth），即研究人员试图预测的已完成软件的实际规模。
结果显示，根据所使用的功能规模方法不同，呈现出截然不同的模式。当研究人员使用第一种功能规模方法时，加入复杂度测量显著提高了预测的准确性。具体而言，其估算误差率从 24% 下降到了 22%。这表明，对于这类功能计数，了解逻辑的复杂度有助于修正估算，使其更接近现实。然而，对于第二种功能规模方法，情况则有所不同。当他们使用 COSMIC 功能点时，加入复杂度测量并未降低误差率，误差率稳定在 15%。在这种情况下，功能规模度量本身已经非常精确，以至于额外的复杂度数据并没有让最终数值变得更准确。
尽管在第二种方法中误差率没有改善，但复杂度数据仍然证明了其价值。当研究人员将复杂度度量添加到 COSMIC 功能点中时，他们预测的质量以另一种方式得到了提升。落在极小误差范围内的估算百分比从 76% 增加到了 80%。这意味着，虽然平均误差没有变化，但团队在获得非常接近正确答案方面变得更加可靠。研究得出结论，整合复杂度度量并非“一刀切”的解决方案；其价值取决于正在使用的功能规模方法。对于一种方法，它提升了准确性；而对于另一种方法，它提升了稳定性。这些发现为向既有的投入估算模型输入数据提供了一种更细致的新方法，有望帮助软件团队对其项目真正所需的时间和资源做出更明智的决策。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。