基于竞争的众包软件开发：从客户角度的多方法研

​引用：Stol K J，Caglayan B，Fitzgerald B.基于竞争的众包软件开发：从客户角度的多方法研究[J]。信息与通信技术软件工程，IEEE Transactions，2017年。

摘要

众包正在作为一种替代性外包策略出现，并且在软件工程界引起了越来越多的关注。但是，众包软件开发涉及复杂的任务，这些任务与在诸如Amazon Mechanical Turk之类的众包平台上可以找到的微任务明显不同。这些微任务的持续时间短得多，通常非常简单，并且不涉及任务之间的任何相互依赖性。为了在软件开发环境中实现众包的潜在利益，公司需要了解该策略如何工作以及可能影响众包参与的因素。我们提出了一种多方法的定性和定量的理论建构调查研究。首先，我们从众包文献中得出了一系列关键问题，作为《财富》 500强公司探索性案例研究的初始分析框架。我们通过分析十分流行的Topcoder众包平台上的13,602个众包竞赛来补充案例研究结果。从我们的经验发现和众包文献中，我们提出了一种众包兴趣和实际参与众包竞赛的理论模型。我们使用结构方程建模来评估模型。事实证明，由于奖品的级别和游戏的持续时间，观众不会对游戏更加感兴趣。

1引言

软件工程不再仅出现在孤立的小型开发人员小组中，而是越来越多地出现在涉及许多人的组织和社区中。全球化趋势正在增长，并且重点放在协作方法和基础结构上。众包作为完成工作的一种新兴方法，允许客户或请求者在众包平台上发布有关工作或任务的广告，而供应商（即单个工人）在平台上执行满足其兴趣和能力的任务。

众包已广泛应用于各个领域，并且有许多众包平台，客户和供应商可以通过该平台相互查找。软件开发任务通常是相互依赖的，复杂的，异构的，并且可能需要大量的时间，认知上的努力和各种专业知识。但是，有一些将复杂的任务众包的例子。

一般而言，众包的使用有许多潜在的好处，它们也将应用于软件开发。大量作者认为，众包可能成为软件开发的一种常见方法。众包吸引了研究人员对诸如人机交互和信息系统之类的兴趣，以及最近对软件工程的兴趣。到目前为止，大多数研究都提出了对开发人员和平台的分析，包括AMT和Topcoder。但是，很少有研究从客户的角度研究众包作为外包软件开发的实用替代方案。为了更好地了解组织如何与这种新兴的“未知劳动力”互动，从这个角度研究众包非常重要。因此，我们的研究目标如下：

研究目标：将众包作为一种软件开发策略来更好地理解它。

出于这个目标，我们首先在一家使用Topcoder进行大型项目众包的公司中进行了行业案例研究，并基于ICSE'14论文，通过以下方式对其进行了扩展：

• 我们通过对Topcoder平台的大规模定量分析来扩展案例研究分析。由于案例研究固有地范围有限，因此这种定量分析有助于透视案例研究的结果。

• 基于案例研究的具体发现和现有文献，我们开发了一种理论模型，该模型代表了一些影响人群兴趣并参与众包竞争的关键因素。

• 使用Topcoder平台上举行的13,600多个比赛的数据集，我们使用结构方程建模对模型进行了评估。

2背景

2.1定位和定义众包软件开发

在我们的早期工作中，我们将众包定位为与外包和开源分开的战略。表1扩展了这种定位，清楚地将众包描述为一种独特的外包形式。我们以自己的定义结束本节。

术语“众包”具有许多定义。众包参与的性质不同于开源和外包。尽管参与方式不同，但是许多众包平台的典型特征是基于竞争的参与性质。 Topcoder是用于众包软件开发的最大平台，并使用竞争机制。客户使用该平台来促进一项任务，然后由人群成员来执行。收视率最高的人群成员将赢得比赛并获得付款。因此，竞争因素和经济诱因经常阻碍合作。豪将众包描述为“类固醇外包”，这表明众包只是一种外包形式。但是，并行执行的重复性工作不适合外包。劳动力的性质也将众包作为一种外包策略加以区分，通常客户不了解这种人群。 “传统的”外包方案的特征是，在一段时间内完成工作之前，先与特定的（因此是已知的）供应商签订合同协议，可以在两方之间建立关系。在众包场景中，人群扮演着“供应商”的角色，但事先不知道将由谁提交，因此将向人群中的哪个成员付款。

表1众包特征

使众包不同于开放式外包和外包的其他方面包括参与的持续时间，客户和“供应商”（即从事这项工作的开发商）的动机（参见表1）。根据表中的特征，我们对众包软件开发的定义如下：

通过具有外部激励作用的公开电话，具有必要的专业知识的潜在的，通常是不确定的外部人员将代表组织完成指定的软件开发任务。

2.2众包软件开发中的关键问题

2.2.1任务分解

众包中的一个关键问题是将工作分解为一系列较小的任务。将模块定义为“职责分配而不是子例程”。一个关键的挑战是找到合适的软件产品，以分解为可以有效地众包的任务，这被称为“工作流程设计问题”。更有效的分解将导致并行性提高。分解软件项目时，一方面，有必要为众包任务提供足够详细的规范，另一方面，在优化任务之间要有一个良好的平衡。

2.2.2协调与沟通

在将复杂任务众包时（例如在软件开发中），需要协调。协调的重点是引导个人朝着共同的目标和明确的目标迈进，并将组织的不同部分联系起来以实现一系列任务。尽管与上面讨论的任务分解有关，但是协调尤其涉及到沟通，相互依存以及各个部分整合为一个整体。这种协调特性似乎假定活动是在组织内进行的。众包平台的成员无法分配任务。相反，开发人员可以选择他们要处理的任务。参加人数越多，通信开销越大。是否适合于众包环境取决于工作是以协作还是竞争的方式完成的。

2.2.3规划与计划

在众包的情况下，将任务分配给未知的劳动力以完成任务，结果，组织放弃了对该特定工作的控制。这可以加快开发速度，因为任务可以并行完成，并且可以独立于组织内的员工完成，尤其是在付款取决于及时交付的情况下。众包的承诺之一就是缩短产品开发周期。为了实现这一点，重要的是人群可以遵循众包组织的预期时间表。

 

 

1两阶段研究的设计

2.2.4质量保证

众包的另一个建议的好处是高质量提交的潜力。同时，如果大多数提交的质量较低，则存在“噪声”的风险，这使得评估提交的质量的任务更加繁琐。无论软件是内部开发还是由外部各方开发，质量保证都是软件开发中的关键问题。众包中的一个特殊问题是，客户对交付软件的开发人员及其所遵循的流程知之甚少，因此他们无法控制这些方面。人群开发人员可以“满足并最大程度地减少工作量”。同样，在解决方案上可能会有分歧。

2.2.5知识和知识产权

软件开发是一项知识密集型活动，因此，知识管理是软件工程领域中的重要主题。与传统外包的主要区别在于，没有供应商对众包项目的问题领域有深入的了解。相反，工人的持续流动是众包的固有特征。较高的周转率可能导致进度安排和成本超支，从而危及竞争的成功结果。

 

表2研究策略的主要利弊

表2总结了这两个阶段使用的研究策略的优缺点（请注意，该表并不详尽）。

2.2.6动机与奖励

众包的最终考虑因素是动力和回报。对某些众包任务的补偿应取决于任务的预期持续时间和复杂性。任务的复杂性可能会有所不同。显然，软件开发任务是复杂且耗时的，参赛者将获得丰厚的回报。众包的优势之一是它可以大大降低成本。但是，确定合适的价格是一般和软件开发众包的关键挑战。

3研究设计

3.1阶段1：案例研究的设计

3.1.1设置

TechPlatform Inc.（TPI，化名）是一家财富500强公司，在云中提供服务和解决方案。在2012年，TPI在一名高级经理的鼓励下，试图调查众包在其软件开发功能中的使用情况。

TPI众包其软件开发平台是Topcoder，它是最大的软件开发众包平台。在推广他们的服务时，Topcoder建议客户“尝试更多，获得更多成功和减少支出”。 Topcoder提供了一个平台，可促进所谓的数字创作的三个支柱：（1）前端创新； （2）软件开发，以及（3）算法和分析。对于本研究，我们专注于软件开发支柱。

最初，Topcoder聘请项目经理来监督客户项目并作为项目“联系人”协助客户，但几年前，该平台引入了“自助服务”模型以节省成本。这种直接模型涉及Topcoder社区中的“副驾驶员”，充当客户和人群开发人员之间的接口，并帮助选择各种竞赛的获胜者。副驾驶是一位经验丰富的“精英” Topcoder社区成员，他过去在Topcoder平台上得到了证明。他们管理技术和竞赛的技术方面，直到成功交付为止。 Topcoder建议副驾驶员执行技术上繁重的工作和流程管理，以使客户成为“全球人才库的指挥官”。

3.1.2定性数据收集和分析

 

表3案例研究数据来源

我们与参加Topcoder众包计划的TPI的主要信息提供商进行了几次面对面，半结构化的采访。包括所访问位置的部门CTO，软件架构师，软件开发经理，程序经理和项目经理。在研究之前，我们制定了研究计划。在公司内部的三个为期半天的研讨会中进行了面对面的采访。此外，我们进行了两次电话会议采访，每次采访都是由两名TPI工作人员扮演的，他们在众包过程中发挥了关键作用。采访时间每次持续一到两个小时。在研究过程中，我们将本文的一些早期草稿发送给了研究的主要参与者-一种成员资格检查的形式。建议使用成员检查策略以确保研究参与者“发现”或“发现”了发现。这也提供了在必要时寻求分类的机会。表3总结了案例研究的数据来源。

3.1.3定量数据的收集和分析

为了对案例研究的结果提供背景介绍，我们分析了通过Topcoder的公共API收集的数据。定量分析的目的是根据案例研究的结果进行背景分析，以便更好地了解TPI竞争是“非典型的”还是“非典型的”（就TPI竞争中使用的技术，交易的范围和持续时间而言）该奖项。因此，定量分析提供了比较的背景信息。我们在2016年11月收集了所有公开可用的数据。所有数据都存储在SQLite数据库中，并使用Python和R统计软件包进行了分析。

我们根据某些条件过滤了数据。首先，我们用少于$ 100的一等奖消除了挑战。原因是我们认为这些挑战是微不足道的，并不代表公司通常宣布的竞争。我们发现这些挑战通常很少有回报（0.00-1.00美元之间）。在分析过程中，我们确定了一个名为“ Analysis”的用户。该用户总共提交了4,697个提交，是第二大活跃用户的十倍，占提交总数的7.3％。此外，只要用户提交，其他任何人都不会进行其他提交。由于这些游戏不具有代表性，因此我们决定删除这些游戏。最后，我们仅考虑成功完成的比赛，从而进一步减少数据集。我们最终的Topcoder平台样本包含13,602个竞赛数据。在分析过程中，我们在提取的数据中遇到了小的不一致之处。在注册为平台会员之前，约有1.5％（显然）的注册人注册或参加了比赛。我们将注册日期调整为系统中这些注册者的首次活动日期。由于这仅影响了很小的百分比，因此我们将这些条目保留在数据集中。

3.2第二阶段：众包软件开发的理论模型

在第二阶段，众包软件开发：使用结构方程模型（下面详细讨论）来评估模型。 SEM是一种功能强大的统计方法，但到目前为止，在软件工程研究中很少使用。

SEM是第二代统计方法。在包括多元回归和方差分析的所谓第一代统计方法中，通常使用普通最小二乘法（OLS）来估计参数。 OLS的目标是找到使数据点和回归线之间的平均平方距离最小的系数。尽管SEM的总体目标是相似的，也就是说，要使用观察到的数据来确定代表最佳拟合的系数，但是所谓的“观察到的数据”是观察到的变量与其方差之间的协方差。因此，这种类型的SEM有时称为CBSEM（基于协方差的SEM），以将其与偏最小二乘（PLS）SEM区别开来。代替OLS，用于估计SEM中系数的默认算法是最大似然（ML）。在我们的研究中，我们使用了功能强大的ML变体。

在SEM中，研究人员通过定义一些相互关联的假设来指定理论（假设）模型。基于此，生成方差-协方差矩阵。根据一组样本数据生成第二个方差-协方差矩阵。因此，SEM的目标是测试这两个矩阵是否不同：如果它们不同，则样本数据不支持研究人员的理论模型。因此，两个矩阵之间的非统计显着性差异（使用x2）表明该理论模型适用于经验观察。同时估计结构方程模型中的所有系数。因此，应在整个模型的背景下评估结构方程模型中关系的重要性和强度。仅当模型本身表示良好拟合时，即理论模型与观察模型之间没有显着差异时，对假设关系的评估才有效。

 

表4 Topcoder平台上最流行的十大技术

结构方程模型是通过定义构成我们理论的一组框架和关系而开发的。具体而言，我们重点研究了案例研究中确定的许多重要概念，包括比赛奖励，比赛持续时间和比赛的“并行化”程度。我们使用一个指标来操纵我们的结构。从这个意义上讲，我们的模型是路径模型，它是结构方程模型。路径模型本质上是回归模型；但是，回归仅限于由一个或多个自变量预测或解释的单个因变量。路径模型没有这种约束，因此不需要复杂的模型。

结构方程模型是使用lavaan库为统计软件包R（版本0.5-23）实现的。然后使用一组拟合标准来评估结构方程模型。特别是，使用三种类型的标准对理论模型进行了评估：

• 模型拟合的度量，例如近似均方根误差（RMSEA）；

• 模型路径的单个参数的估计值的统计意义；

• 参数估计的方向和大小，尤其是方向（由参数符号指示）是否有意义。

4个案例研究

TPI选择用于众包的应用程序是Titan（化名），这是TPI现场工程师在与客户进行交互时从一个平台迁移到另一个平台时将使用的Web应用程序。最好将众包部分描述为前端信息系统，该系统必须与遗留组件集成在一起。在TPI中，做出了一项技术决定，即未来的开发应使用HTML5，这是为前端选择的技术，它将替代当前的桌面应用程序。表4列出了Topcoder平台上使用最广泛的10种技术，其中HTML5排名第七。

4.1任务分解

对于TPI，选择产品的哪些部分适合于众包并非完全无关紧要。首先，关于众包工作的决策主要基于内部资源（或缺乏内部资源）。其次，独立的代码和可执行文件（没有相互依赖性）将更易于合并，因此更适合于众包。

为了最大程度地减少交付后对Topcoder代码的修改，TPI为大量开发人员提供了页眉和页脚浏览器代码。对于Titan应用程序，TPI的政策是仅使用HTML5。最初，人们开始期望Topcoder社区将提供一些创新的HTML5代码。但是，TPI要求所有浏览器平台都必须支持HTML5功能，从而导致人群开发人员只能使用所有潜在HTML5功能的一小部分。 TPI规范不包括“人群”的预期创新。

TPI项目包含44个成功的比赛，分为不同类别。表5列出了每个类别中的比赛数量，以及我们整体Topcoder平台示例中的比赛如何分配。

为了最大程度地减少集成工作量，TPI希望人群开发人员使用真正的后端核心而不是存根服务。但是，随着Topcoder的开发开始，内核尚未就绪，并且在大多数开发竞赛中都使用了存根。因此，这种集成工作被推迟到开发过程的后期，这是理想的。

对于传统的内部开发，TPI开发人员已经内部化了许多有关编码标准和模板以及技术规范的信息。但是，许多编码标准和模板都是非正式记录的，没有集中存储在内部Wiki安装中。为了确保在外部人群开发人员的需求声明中阐明此信息，需要进行大量其他工作。 TPI为44个Topcoder竞赛撰写了总计1,061页的规范。相反，如果是内部开发，则几乎不需要编写任何其他文档。与Topcoder联系的架构师描述了以下情况：

“感觉好像我们已经生产了100万个规范文件，但是显然我们没有。规范Topcoder的方式与内部调节的方式完全不同。”

 

表5比赛的类型和频率

4.2协调与沟通

基于Topcoder竞争的方法有效地代表了软件开发的瀑布式方法。但是，TPI正在使用基于Scrum的敏捷开发过程。将这些不同的瀑布与敏捷开发过程结合在一起是有问题的。必须将Topcoder的开发贡献分配给TPI内的Scrum团队，然后将人群贡献注入适当的Sprint中。 TPI架构师将主要问题总结如下：

“我们是一家敏捷商店，我们习惯于改变主意。当我们在一场游戏中告诉他们一件事，而在下一局游戏中改变主意时，Topcoder可能会遇到问题。”

Topcoder和TPI之间的交互模型中也有很多层。首先，在Topcoder方面，一方面，它是一个由人群开发人员组成的社区；另一方面，它是TPI人员之间的共同推动者。此外，Topcoder平台专家还参加了与TPI的联系，监督了副驾驶并建议了该级别的更改。

在TPI内部，选择与Topcoder副驾驶员进行交互的人是一个艰难的决定。在技术方面，TPI指派了一位高级架构师来协调Titan项目的Topcoder开发。在TPI内部，由于需要及时回答问题的压力，Topcoder与Topcoder社区日常联络的角色被认为是有问题的。由于成本高昂，TPI中的某些人担心将这种高级资源分配给该联络角色。软件开发经理从资源分配的角度描述了这种情况：

“为了改善项目中的联系点，联系人需要具备技术技能和项目管理技能，以便能够管理Topcoder技术社区成员的要求，竞争和问题。它使用了非常宝贵的资源。在这个项目，他们一定不能。其他开发人员不需要花一些时间来解决Topcoder提出的所有问题。”

 

图2 Topcoder平台示例的比赛持续时间（天）分布（已修剪X轴以提高可读性）。

在初始阶段，联络角色涉及在Topcoder论坛上回答问题。

“与内部发展相比，还有更多问题。但是，没有非正式的沟通机制。您不能对下一个房间的人大吼大叫，您很快就会得到答案。”

另一个结构协调问题是，TPI将建筑师分配给产品，并且完成Topcoder项目的愿望导致了另外两名建筑师从事该项目。 TPI还拥有一个所谓的“战术” Scrum团队，可以更灵活地分配给不同的任务，因为与TPI的普通Scrum团队相比，它们没有正式分配给项目。但是，在某些情况下，正常的Scrum团队也将被分配到项目中，而战术Scrum团队则不会参与。通常，在项目上有很多额外的协调开销和重复的工作。这两个团队还必须相互交流。为了解决这个问题，TPI放弃了战术团队的使用，而是在项目打印中安排了计划时间。

与涉及同一组织中其他开发人员的分布式开发相比，随着时间的推移趋于建立的唯一关系是与Topcoder共同驱动。由于交互是通过多个级别过滤的，因此没有真正的机会与任何人口统计开发人员建立关系。

4.3计划和安排

Titan项目包括50多个顶级Topcoder竞赛，其中44个已经成功完成。从开发者的角度来看，实际的竞争时间要短得多，因为这是注册截止日期和提交截止日期之间的差额。图2显示了Topcoder平台上比赛持续时间的天数分布。

 

图3注册者与提交Topcoder平台示例之间的相关性

从TPI的角度来看，如果可以实现更灵活的粒度会更好，因为可以接受可交付成果的某些部分，并为这些可接受的部分进行部分付款。由于TPI不想阻止开发人员竞标未来的竞赛，因此有一种趋势是接受所有提交的内容，即使是有缺陷的提交内容。随着主要应用程序的不断发展，TPI必须等待游戏结束，这引发了另一个与计划和调度有关的问题。由于缺乏提交信息，TPI的时间表也受到影响，导致比赛失败。图3显示了样本中注册人数量和竞赛数量之间的散点图。

4.4质量保证

软件工程领域的许多研究都集中在尽早发现和消除开发过程中的错误上，即在开发周期中发现错误的成本呈指数增长。但是，Topcoder开发过程的结构使其难以保留，因为在编码完成之后，它将QA问题转移到开发过程的后端。正如开发经理所说：

“众包侧重于需求，并在项目开始时放宽了质量流程。因此，现在所有对质量管理的重视都来自项目后期的质量保证周期，而且通常更昂贵。”

也缺乏连续性。人群开发人员不会在游戏结束时保持闲置状态，因此在以后的TPI游戏中可能不会使用它们。实际上，TPI遇到了一个错误，该错误先前已确定并解决，但在返回代码以与人群进行进一步开发后又重新引入。不可避免地，会有不同的开发人员来处理代码，并且通常不组织学习。当他将与开发人员的互动描述为“亲密关系”时，这进一步强化了TPI部门CTO所表达的批评观点：

“结转知识是有限的。我们将有一些参赛者将参加多个比赛，但他们不会像内部人员那样积累领域知识。”

鉴于TPI认为技术与特定领域专业知识的结合非常罕见，因此TPI已采取了一些措施来提高众包贡献的质量。人群开发社区在开发过程中将其用作他们开发的代码的最终测试者或演示者。在此之前，代码测试是通过调用后端存根服务来完成的，但是TPI中存在一个问题，即当完全连接到后端时，众包开发人员交付的代码可能无法顺利运行。当人群为原始HTML5高级面板应用程序生成代码时，出现了一些质量问题。 TPI采纳了此代码，并在TPI要求的级别上将其进一步开发为“黄金标准”。这将作为将来开发的模板传递回Topcoder社区。扩展了该策略，以为Web应用程序准备示例代码，该示例代码可用作Topcoder社区的模板。

4.5知识和知识产权

前述的“竞争关系”也对知识管理和知识产权产生影响。表6列出了每种比赛类型的注册人总数和提交的总数。该表显示有很多潜在的参与者，但是参与者的数量已大大减少。

 

表6每种类型，注册，提交，唯一注册和唯一开发者的竞赛总数以及TPI竞赛的平均提交率

4.6奖励与奖励

鉴于有超过一百万的潜在开发社区成员，Topcoder将声称拥有足够的广泛和深入的专业知识来确保健康的竞争率。但是，TPI由于缺少参赛作品而不得不取消某些比赛。此外，在44项比赛中，有10项仅吸引了一名参与者。 TPI使用别名这一事实可能很重要，因为知名公司似乎更可能吸引人群开发人员。为了调查缺乏提交信息的潜在原因，我们还分析了人口中活跃成员的数量。确定什么是“活跃”成员并不容易。 Topcoder的定价结构非常复杂。 Topcoder估计，通过重新使用目录中的组件，可以解决大约60％的客户项目。但是，TPI无法利用此目录。 “我们已经建立了一个技术栈，并为此编写了许多软件。因此，Topcoder目录对我们来说不是很有用。对于这里的人们来说，价格并不高。”

5理论发展与评估

5.1理论发展与模型

指定SEM的第一步是指定一个理论模型，即定义一组假设。借鉴先前有关众包的文献和我们在第4节中的探索性案例研究，我们提出了许多相互关联的假设（见图11）。

 

图11建议的理论模型

假设1（H1）：项目中的平行竞争与人群对竞争的兴趣负相关。

假设2（H2）：游戏的报酬与人群对游戏兴趣的增加呈正相关。

假设3（H3）：游戏时间与观众对游戏的兴趣成正比

假设4（H4）：人群的兴趣与参加比赛呈正相关。

假设5（H5）：“人群杀手”与游戏参与度呈负相关。

在图11中，我们还包括许多控制变量。我们使用需求类型因子（“开发人员的需求”）作为比赛中其他并行活动的数量，因为这会稀释开发人员库（如果有）。这可能会减少单个竞赛的注册和提交总数。最初打算参加给定竞赛的开发人员可能会被其他活跃竞赛分散。

“技术数量”可能是影响注册人数量和提交文件数量的因素。显然，如果不检查每个游戏的规格就无法解释游戏的复杂性，但是所涉及的技术数量却是开发人员所需知识的粗略指标。

我们考虑了注册人已经在进行的比赛数量。发布新比赛（即其注册是公开的）时，成员可能已经提交了其他比赛。这可能会降低他们对新广告竞争的兴趣，但也可能会将他们的注意力从当前竞争转移到新竞争。

5.2估计和评估模型拟合

指定结构方程模型后，下一步是评估模型并评估其拟合度。换句话说，该模型的参数由SEM软件程序估算，并且可以评估生成的模型拟合指数（请参见图10）。在SEM中，有多种替代技术可用于处理非正态分布的数据-在我们的研究中，我们使用了两种此类技术。首先，我们使用鲁棒的ML估计，然后使用Bollen-Stine引导程序来计算标准误差值。

 

图10实施SEM的步骤（改编自Hoyle [115，第7页]）。

 

表7模型拟合指标

已经提出了许多拟合指数来评估结构方程模型。许多研究的批评是它们仅报告适合指数。按照报告SEM的准则，我们讨论了几个常用的拟合指标，还讨论了我们的模型如何在这些指标上评分。重要的是要注意，对于大多数这些指数的关键点尚未达成共识，我们将在下面详细介绍。表7汇总了拟合指数。

根据上面报告的拟合指数，我们得出结论，我们的理论模型得到了数据的支持。但是，应注意，我们的模型不是唯一可行的模型，并且可能存在替代模型。

5.3假设检验和解释

 

表8均值，标准差和相关性（长矛手）

基于各种模型拟合指标，我们确信我们提出的模型是合理的模型。应该注意的是，这种支持并不意味着我们的模型是最优的，它只是一个模型。理论模型非常适合数据，这是可以解释参数估计的前提。根据SEM报告指南，我们在表8中列出了模型的结构，相关性，均值和标准差（由于数据不是正态分布的，因此我们使用非参数Spearman r相关系数）。

6结论与未来研究

众包是外包软件开发的新兴替代策略，近年来引起了相当大的关注。到目前为止，大多数研究都集中在对“人群”（即开发人员）和众包平台的分析上，但是很少关注顾客的意见。为了解决这一差距，本文从客户的角度提出了基于竞争的众包软件开发的多方法研究。

在本文中，我们将基于竞争的众包定位为外包给未知劳动力的独特替代形式。我们相信，众包具有巨大的潜力，尽管正如本文所述，众包客户可能必须克服许多挑战。我们建议一些未来的研究方法：

• 通过“筹款关系”来表征众包客户与众开发人员之间的互动，客户如何以及如何在软件开发环境中有效地进行众包？

• 考虑到强调定期面对面交流（尤其是Scrum）的敏捷软件开发方法已被广泛采用，众包方法（类似于瀑布式软件开发方法，侧重于记录的需求）将如何成为现实。有效地结合和协调？

• 与基于竞争的众包软件开发方法相比，基于竞争的众包方法效果如何？

• 哪些因素使游戏对人群有吸引力？对此有一个清晰的了解可以防止组织参与不太吸引人的广告竞赛，该竞赛可能由于缺乏提交而失败。

• 如何动员人群的“长尾巴”参加众包方法（基于竞争或其他手段）？换句话说，尽管Topcoder拥有超过120万成员，但似乎只有一小部分成员正在积极参与。如何真正实现基于人群的软件开发中的“参与民主化”？

为了回答这些问题，需要从众包系统的所有三个关键角度进行进一步研究，即众包平台，众包和众包客户。我们相信，答案将暗示与人群等未知工人一起工作的新方式。

谢谢

本文由南京大学软件学院2020年硕士王旭翻译和转载