2021-2022年收藏的精品资料软件工程研究中的效度问题.doc

软件工程研究中的效度问题 摘要 在过去十年中，由于开源项目存档的可利用性，使用软件资源库构件的经验研究已经成为了流行。在本文中，我们调查了过去3年对ICSE和FSE会议记录的研究，并对其按照开源项目与专利项目，以及在这些研究中所使用主题程序的多样性进行分类。我们的调查显示，最近的经验研究中几乎有一半（49）仅仅使用了开源项目。目前的研究或是从这些结果中得出一般性结论，或是明确否定任何超出特定主题软件的领域所得出的结论。我们得出结论，经验性软件工程的研究人员必须考虑到由于只使用几个知名的开源软件项目所引起的外部效度问题，这些对数据源选择的讨论是软件工程研究的一个重要的议题。而且，我们建议，软件资源库基准应有一个共同的研究架构，并共享经验性分析结果，这是为了更好地解决外部效度问题，并促进经验软件工程中分析软件构件的研究。分类和主题描述D 2.0软件工程：通用通用术语 效度关键词 经验研究，外部效度，开源软件1.介绍在过去的几年中，软件工程研究人员充分利用了开源软件项目提供的丰富信息。研究人员已经开发了开源代码库，问题追踪器，邮寄档案列表和其他产品来进行他们的经验研究。从表面上看，这些研究的进行是为了获悉更多的软件开发状态，以及可以如何改善它。 在严格审查开源软件时，这些研究中有许多得出了关于软件工程的一般性的结论。尽管这些研究结果是有用的，这类研究的作者很少就效度面临的威胁发表意见，特别是仅仅在研究现有的开源软件的时候呈现出的外部效度问题。一些研究人员明确否认特定研究项目以外的任何结论，从而在其他方向走得太远。这两种方法都无助于提高目前的技术水准或改进软件工程中的实践。  在本文中，我们探索软件工程研究中效度面临的潜在威胁，这些研究使用软件构件档案作为一个数据集。通常在讨论效度时，我们特别强调关于选择使用开源数据作为主要研究数据源时的外部效度问题。我们调查了过去几年FSE和ICSE的会议记录，以确定被发现问题的普遍性，提出了我们觉得有关改善经验性软件工程研究现状的问题，以及用何种方式可以让这方面知识的研究方法有所改进的建议。2.实验的效度对于任何类型的实验，为了给出有说服力的论据，它们必须具有高度有效性。当对一个实验效度的完整处理被更好地留给了另外的资源，这个部分可以简单应对在软件工程研究中对于内部，外部，以及建构效度的挑战。2.1 建构效度建构效度是指具体的测量值是否真的模拟构成假设定理的自变量和因变量。 换句话说，一个具有高建构效度的经验研究能够确保研究参数与研究问题紧密相关。2.2 内部效度 在经验研究中，干扰因素对内部效度是一个主要的威胁。我们的调查显示，在软件工程研究中，选择性偏差是一个普遍的问题，并且限制了这些研究的效度。内部效度对计算者来说很难处理，因为观察变量的变化可能归因为其他一些变量的存在或者变化度，这些与被控变量有联系，但没有明确地模式化变量。 2.3 外部效度 一般地，外部效度指的是除了那些直接观察结果以外的领域，其研究或实验结果的适用性。如果一个研究的结论支持整个研究领域，那么就说这个研究具有高外部效度。在大多数科学科目中，研究者们非常重视对外部效度的研究，因为研究结果可以广泛适用于其他情况。 一个给定研究的外部效度有几个方面： ·研究是否在领域中推广到了其他学科 ·是否存在足够的根据和论点来支持声明的普遍性 ·研究成果是否能验证预期的理论 减轻建构和内部效度问题常常比应对面向内部效度的威胁更重要，因为解决前两者是先决条件，之后才能考虑研究结果超出进行研究的主题领域之外的普遍性。然而，每个软件工程研究应该争取一个高层次的外部效度，因为软件世界太大，太复杂了，无法全面地研究。研究人员选择研究代表性的项目，然后对其总体概括出结论是很重要的。3.研究中的开源数据 随着最近的开源软件开发和数据的激增，研究人员已经转向这些容易取得开发数据和构件的资源。尽管有困难，不管是否能够被理解，这样做的情况已经发生。有一段时间在开源研究领域，从开源资料库中获得一套平衡的数据已经成为一个难题，一些数据集合已经尝试着去解决这个问题。然而，开源数据在一些方面要区分于专利软件数据。首先，当使用开源数据集时，研究人员们经常可以使用软件工程过程中的产品，而当审查专利软件时，研究人员们通常可以得到一个关于软件系统以及软件系统构建和维护环境的更为完整的视图。其次，进一步偏置源数据是开源软件的领域。许多最成熟的开源项目是系统领域软件，这可能会引起它自己特有的一系列发展倾向。以其他领域方向为发展目标的软件工程可能会有特殊的问题，并且不能被系统特有的软件偏置精准地捕获到。第三，大量存在的工作决定了开源项目的社会结构。与此同时，专利项目已经建立了组织结构，通过研究它们，研究人员们可能放弃探索社会关系的时间密集型过程。此外，考恩威法则指出软件的设计和构建是否开放或私化，可能会被组织结构深远影响。由于开源项目的组织结构通常是自发形成的，能够使用开源项目数据解答的关于通信和组织结构的研究问题类型，不能推广到结构明确定义的封闭源项目。 最后，使用开源项目数据进一步使研究方法的验证变得复杂，因为很难找到合适的工作人员（开发者，管理者，测试者），让他们验证自动化软件分析的结果，因为贡献者的角色常常是隐蔽的，他们的工作都基于自愿的原则。3.1 在研究中开源数据的调查一个关于过去会议的简单调查有助于说明我们的观点。这样一个调查，尽管不能完全代表所有的软件工程研究，却可以表明目前在主要的软件工程会议上的普遍观点。在这个调查中，我们研究了相对于使用合适的源软件构件，仅仅使用开源软件构件进行经验研究的范围。虽然可操作的开源定义可能是不固定的，但是我们决定用这样一个定义去区分开源项目和封闭性项目，那就是“现成的源代码和开发工具”。此外，开源项目存在于一个开放的发展实践和授权的连续统一体，所以分类必然是主观的。在分类文章的过程中，我们寻找那些使用开源数据的文章，而不仅仅是那些构造了一个开源工具，或者是在一个开源授权下提供他们的工具的文章。当作者使用他们的工具作为开源框架的一部分，以按照各种其他作用或者不同文章讨论中提及到的开源项目将数据源区分开，我们也不会把这些文章分类为开放性的。表1说明了我们关于使用OSS对比PSS的研究结果。我们的调查结果很有启发性。在最近的ICSE或FSE中使用软件项目作为研究对象的文章中，几乎一半仅仅使用了OSS数据，而其他23%的使用了PSS数据。只有15%的文章使用了若干OSS,PSS或常规数据（包括生产实例和基准）的结合。我们希望OSS与PSS之间的区别不会像我们认为的那么巨大，以免使大量软件工程研究的效度问题引起争议。在做这个调查的时候，我们注意到了一些有趣的现象。每当提到开源项目时，总会用到很多“生产阶段代码”或“现实世界应用”这类时期。许多文章愿意承认使用来自SourceForge的项目作为他们唯一的输入数据源，然而轻易忽视了这种做法所带来的问题。我们也注意到很多作者选择在他们制造的数据中测试算法或程序，例如样本程序和基准。然而这些测试在研究过程中是一个重要的步骤，因此获得的结果不会使他们的外部效度更可信（见第5节标记处的讨论）。有趣的是，主题数据源的实现语言似乎也很容易被曲解。例如，许多用研究工具是用JAVA编写的，因此作者选择JAVA程序作为他们的数据源。找不到标准化的“产业”语言，例如Visual Basic或Cobol.这些语言虽然过时了，也许不能处在软件工程研究的最前沿，大量现有系统仍然在这类平台上运作，在一定规格基础上，软件工程实践者们仍然在接触和使用这些语言。对改进软件工程实践状态感兴趣的研究者们，可以考虑将使用这些语言进行编写的项目作为候选的研究对象，将会做得更好。会议文章总量用到数据的文章数据源开放封闭常规合并ICSE07ESEC/FSE07ICSE08FSE08ICSE09ESEC/FSE09494256315038392136193820181217722109595751025232247563总量数据占比例266175100%8649%4023%2414%2715%表1：在研究文章中开放性源作为数据源4.开放式问题 上面所给的背景资料，我们相信经验软件工程领域必须解决下面的问题，以增加主要使用开源数据进行的研究的外部效度。 ·高度依赖开源数据对效度有什么威胁？ ·开源开发与专利开发实践在意义方面有不同之处吗？ ·是否有足够多种类的开源数据使结果具有普遍性？· 即使当效度问题存在，作者可以识别出这些问题，并解决它们吗？ 项目委员会，评审员和研究人员可以并应该共同工作，解决这些问题并增加软件工程研究的效度。通过认识各种数据源的优点和偏差，作者可以在考虑到专利软件与开源软件开发差异性的基础上，更好地提高他们研究的质量，解决那些关于效度的问题。例如，从历史来看，开源团队在工作方式上与专利软件团队有根本性的不同。成员们频繁来去，他们在地理位置上分布广泛，根据需要他们留下了如电子邮件存档这类长期使用的交流工具的信息。这些特征尤其和软件工程研究人员研究的大型项目有关。相比之下，专利的团队工作方式有所不同，他们可能留给研究人员更少的有用信息。闲聊、会议以及其他的通讯往往没有记录。在某些情况下，这样的相互交流可以占用一个标准工作日的75分钟。专利软件开发拥有而开源开发没有的一类资源，是参与人员的使用权。当有大量数据供给时，专利软件收集信息相比简单地将自动挖掘技术应用到大型开源数据库更加费时，代价更大。此外，开源软件的成功对专利软件厂商并没有很大的影响。许多公司利用不断深入的全球化，在地理上广泛分布团队以期达到最大限度的工作效率。虽然源代码不能在开源许可证条件下使用，但是实际的开发实践已经开始借鉴这些开放资源。同时，成功的开放资源项目往往获得商业公司的赞助、使用和夺标购买。在这种情况下，许可证或许会保持开放，但是开发构架开始变得严格，渐渐回到传统的开发过程。5.基准 最后值得注意的一点是软件工程研究中基准的使用。我们不是第一个建议在软件工程中使用基准的，但是我们的调查数据显示先前的请求往往被忽视。对于软件效度的威胁正在增加，对于经验基准的正确设置连同其他措施一起将加强软件工程领域效度问题的研究。虽然软件测试领域已经开始使用软件构件基础设施库（SIR）评估各种测试方法，我们研究的许多论文都引用了这个资源库的构件，但是这些论文很少对整个程序组有一个综合全面的考虑，因为SIR资源库会因为用回归测试和错误数据覆盖软件历史而受到限制。SIR是一个很好的开始，但是为了增强实验的有效性，研究人员需要一个更为完整的数据集。构建一个具有代表性的基准数据集是很不容易的，但是其他领域的结果是令人鼓舞的。例如，为编译器优化的研究建的Dacapo基准已经在学术界和产业界采用并继续发展。虽然基准的制定有很多的困难(研究者会优化研究以适应基准的特点)，我们相信这些基准带来的好处远远超过了研究成本。鉴于软件的发展变化非常迅速，维持这一套基准可能非常耗时间。尽管有这些困难，一套恰当的基准应该被认为是软件工程研究中效度实验的先决条件。而且，这些基准将促进研究方法的比较性评估。目前，由于缺乏共同的基准和对这些基准的分析结果，研究者经常被迫重复他人用过的方法，并经常和相同主题的软件比较，承担了不必要的高昂的验证研究方法费用。6.结论 自从ICSE和FSE的初期，软件工程研究取得了很大的进展，而且使用真实软件系统进行经验验证的限制有很大程度的提高。考虑最近的ICSE和FSE会议中我们已经表达了我们的担忧，即被检验数据不足以保证隐含要求的结果普遍性，而作者不能充分承认这个事实。因此，我们概述了一系列问题，希望会鼓励研究人员更好地解决外部效度问题。 此外，展望未来，我们提出为什么我们相信一套合适的执行基准和这套基准共享的分析结果会改善软件工程研究中的效度测量。最后，在软件工程领域中，评审员和项目委员会成员承担监控效度问题的责任。这些研究界的突出贡献者在他们审查出版的论文中必须坚持关于效度的讨论。大家在这个领域的一致努力将会掀起将效度研究向更高标准发展的高潮。