软件分析的未来

软件分析的未来2015-03-07 infoq 译:李中杰本文最初发表在IEEE Software杂志上，现在由InfoQ和IEEE计算机学会联合呈献于此。

这一期我们请到了一个六人专家团，由软件分析领域的知名专家组成，讲述他们心目中这个领域那些最重要的、或者是被严重忽视的问题。他们都认为当前实践的视野还不够开阔：软件分析的受众应该超越开发者（Ahmed Hassan），软件分析的结果应该超越单纯的数字（Per Runeson）。分析应该证明其实用性（Abram Hindle, Martin Shepperd）。基于统计自然语言处理的“自然”软件分析正面临很大的机会（Prem Devanbu）。最后，软件分析需要像《反恐24小时》这部电视剧里的Chloe O’Brian 和 Jack Bauer那样的信息分析师和特工（Sunghun Kim）。希望你们喜欢！——特邀编辑Tim Menzies 和 Tom Zimmermann

软件分析：超越开发者

Ahmed E. Hassan

软件分析（SA）通过基于事实的决策支持系统将商业智能的概念带到软件产业。今天，SA主要聚焦于帮助开发者个人解决日常编码和缺陷修复活动中的决策问题，这是通过挖掘开发者相关的资源库（例如版本控制系统和缺陷跟踪系统）来实现的。例如，通过挖掘历史变更的实际风险，我们可以自动地确定当前一个代码变更的风险——或者叫出错可能（bugginess）1。

为了能成为一种强大的、战略性的决策制定工具，未来的SA研究必须超越这些平庸的任务。SA要能帮助到一个项目的各种利益相关者——营销、销售、支持以及法务团队——而不仅仅是开发者。SA必须挖掘除了开发者相关的资源库以外的、项目各个方面的资源和知识。传统方法挖掘的代码库应当与其他面向客户的资源库，例如运行日志、客户支持通话记录、博客和视频讨论等内容结合起来。

只有采取这样一种多方面的视角， SA才能支持更加有影响力的业务层次的决策，而不是那些太过普通的决策，象“这个文件缺陷多吗？哪个程序员能修复它”之类的问题。只有那样，我们才能帮助开发者和他们的经理就一段代码的重要性及其对用户满意度和收入等问题开展更加战略性的讨论，帮助支持人员借助错误日志和视频帮助的关联来更好的回答客户的咨询，帮助市场营销人员基于实际使用数据来更好的为他们的广告活动锁定目标群体，帮助销售人员通过理解每个特性对于客户的内在价值而进行更好的定价。

证明其对实践者的价值

Abram Hindle

软件分析最容易实现的目标——度量和报告——取得的成功反响很大。象GitHub、BitBucket、Ohlol、Jira、FogBugz等这样的现代软件服务已普遍使用可视化甚至是缺陷成本估计。从这件事看，即使那些开发者从没读过我们的一篇论文，我们也可以拍拍自己的背表示自我表扬了。

然而，软件分析更加甜蜜的果实却令人扫兴：数据挖掘技术在软件领域被遗忘了。我认为未来的软件分析将会考虑各种层次的上下文：软件开发域（非功能需求、环境、工具、风格，等等），软件本身（数据库、应用，等等），以及总体的软件项目上下文（需求、术语表、架构、社区，等等）。例如，自然语言处理采用的n-grams模型忽略了源代码的嵌套结构，而我们应当将这一知识考虑进来。因此，我们应当停止盲目地使用最新的数据挖掘工具，而应该加以修改和定制，以使其适合于软件分析。

我能看到缺陷重复识别或提交分类的准确率或召回率的提高，但却看不到这些提高对于实践者的意义所在。要证明其意义，软件分析必须显示出它的成本-价值比是否合理。相比之下，什么都不做有时候反而非常有效。我们得围绕实践者的真实需求来评估这些技术。我们不应该去评估10%的准确率的提高对于缺陷分类或经理而言是否有意义——我们必须评价其经济性，这决定了实践者是否用得起我们的技术。

软件分析的未来取决于证明其对实践者的价值，证明其经济适用性，提供必要的工具和技术，通过有效的利用我们在软件工程领域的知识，来打造多一些意义、少一些表面化的软件分析。

单纯的数字还不够

Per Runeson

近年来，在软件工程社区，对软件分析的兴趣与日俱增。这代表了一种朝着“系统的、有组织的、可以量化的软件开发方法”前进的良好的趋势，就像ISO610.12软件工程定义中所说的那样。然而，数字还不够。软件工程所提出的问题极少能被象“4”或者“y = 3.1x + 2”这样的答案所回答。数字和等式对于表示数据之间的关系很重要，但对于实际使用来说，数字和等式必须伴以解释和可视化。

这里的“解释”指的是将数字运算带来的发现融入到真实的、活生生的软件工程世界里去，融入到组织和公司文化里去，融入到商务和市场里去。这主要是一种从定量到定性的转移。举个例子，假设软件分析发现在项目经理的经验和项目的失败之间存在一种负相关（即：项目经理的经验越高，项目失败的可能性越大），这是否意味着我们应该雇佣缺乏经验的经理呢？不，别忘了第三个因素——项目复杂度。有经验的经理往往负责更复杂的项目，而这些项目失败的可能性更大。正是这种解释性的工作，才使得软件分析真正发挥作用。

另外一种将软件分析的数字运用到经理们的日常管理中去的方法是可视化。虽然绝大多数的软件经理的技术和分析能力都不错，但是他们往往没有时间去探究细节，他们需要可视化的方法来理解数字所代表的发现。统计和电子表格工具产生的图表是一个好的开端，但是，如何将软件分析的输出真正传递到决策者手里，还需要更多的研究工作。可视化是使软件分析展示出强大威力的利器。总之，我们应该继续推进软件分析的研究，但请不要忘记解释和可视化。

分析的三个问题

Martin Sheppard

使用高级机器学习和统计学方法，对各种软件工程产物（例如源代码和变更数据）进行数据挖掘，正成为一个迅速发展的行业。许多有趣的、有用的模型和发现正在涌现，但是，这些方法并非毫无危险。作为研究人员，我们应当问自己三个问题：

第一，我的模型与傻瓜策略（例如猜测或使用众数组）相比好多少？这看似一个没有必要的问题，但如果分析本身的目标就是要超过另一个模型或结果，那么我们的模型最终还抵不过一个坏模型的危险还是存在的。如果这显得耸人听闻了，让我来举个例子：Stephen MacDonell 和我最近证明，一些之前发布的结合趋均数回归和案例推理的预测性模型实际上还不如基于枚举的简单猜测。看似幼稚的基准方法却有着简单易用的优点。

第二，实际效果显著到什么程度？这一般用效应量（effect sizes3）来判断。然而，一种危险在于，如果像惯常一样的只关注零假设显著性检验及报告p值，那么当n很大的时候（对数据分析来说经常如此），即使非常小的效果在统计学意义上也是非常显著的（而在实效上却并非如此）。因为我们的目标在于发现具有实用价值的结果，确保不被p值所迷惑是非常重要的。

第三，当一个或多个输入条件发生一点变化时，结果会发生多大变化，即分析对输入条件按的敏感度有多大？我们务必提醒自己，我们所面对的是充满噪音和不确定的数据，因此，必须意识到输入中微小的度量错误可能会对模型产生一些影响，这是非常重要的。敏感性分析是分析这种弱点的一种系统性方法4。有了它，用户就知道一种模型是多么严重的依赖于某个特定的输入，这样，他们至少知道应该在哪里投入额外的工作来保证其精度。