美文网首页论文研读
为众包软件开发者的个性化团队推荐

为众包软件开发者的个性化团队推荐

作者: SpareNoEfforts | 来源:发表于2018-09-10 11:25 被阅读31次

摘要

  大部分软件开发平台采取比赛范式来征求来自团队的贡献。为了在复杂任务中获取竞赛力,众包软件开发者通常选择与他人协作。然而,已存在的众包平台通常承担开发者的独立贡献,并且不为他们提供团队组建的有效支持。之前关于团队推荐的研究旨在通过为一个任务推荐最合适的团队来优化任务结果,而不是为特定人员找到合适的合作者。在这项工作中,我们关注的是为众包开发者提供团队推荐。首先我们展示了Kaggle实证研究的结果:这表明开发人员的个人队友偏好主要受三个因素的影响。 第二,我们提供了一个协作意愿模型来表征开发人员的队友偏好,并将队友推荐问题制定为优化问题。 然后我们设计一个近似算法来为开发人员找到合适的队友。 最后,我们对Kaggle数据集进行了一系列实验,以评估我们方法的有效性。

CSS概念

软件及其工程→编程团队;软件开发协作,软件创建和管理

摘要

众包 协作意愿 团队推荐

1. 介绍

  作为一个流行的分布式的问题解决模型,众包已经广泛应用于软件开发[1]。近几年来,许多众包软件开发(CSD)平台(例如:Kaggle[2]和Topcoder[3])旨在征求软件开发任务的解决方案。在CSD平台中,任务请求者发布具有详细描述和一定金额奖励的任务。然后开发人员可以选择单独或协作参与,只有少数顶级开发人员可以根据预先设定的规则获得奖励。与众包中的微任务不同,例如数据标签,软件开发任务对于个人而言通常过于复杂,因此开发人员更愿意加入团队以确保软件开发的生产力和质量。

  与众包中的微任务不同,例如数据标注,软件开发任务对于个人而言通常过于复杂,因此开发人员更愿意加入团队以确保软件开发的生产力和质量[4]。我们对Kaggle的实证研究揭示了团队协作的好处。然而,如今的像Kaggle这样的CSD平台没有为团队的组建提供有效的支持。据我们所知,很少有人为众包开发者推荐队友。

  团队推荐问题已在各个领域得到广泛研究。 在合作学习中,大量研究集中于将学生分配到合适的团队,并基于专业知识 - 不相似性目标和专业知识 - 获得目标来提升他们的技能[5][6]。 在项目开发中,一些研究旨在通过推荐合适的任务团队来优化任务结果[7][8][9][10]。 在员工培训中,一些工作试图将员工分配到具有员工培训和项目成就的目标的项目中[11]。在这些研究中,任务请求者将任务分配给推荐的团队,这不能满足想要找队友的开发人员的需求。 也有一些研究致力于挖掘人们的队友偏好。 一些人对促使研究人员与各种合作伙伴合作的因素进行了实证研究,发现个体特征和研究领域是合作的最强预测因子[12]。 然而,很少有研究涉及开发人员的队友喜好。

  在我们的工作中,我们的目标是为众包开发人员研究个性化的队友推荐方法。 首先,为了验证队友推荐的重要性,我们对Kaggle进行了实证研究。 我们的结果表明,开发人员可以从团队合作中受益,他们对CSD平台中的队友推荐支持有很大的需求。 我们的分析还表明,开发者的队友偏好很大程度上受到三个因素的影响,包括与队友的亲密关系与队友的专业差异通过协作获得的专业知识。 其次,我们将开发者的协作意愿定义为上述三个因素的加权总和,其中权重定义了开发者的队友偏好。 然后,个性化的队友推荐问题被制定为优化团队的协作意愿的问题。 第三,我们进一步提供了量化这三个因素的方法,然后提出了一种基于线性规划的方法,用他们的协作历史来计算开发人员的队友偏好。 最后,根据开发人员的个人队友偏好,我们设计了一个带有近似算法的队友推荐方法,以最大化候选团队的协作意愿。

这项工作的主要贡献如下:

  • 通过对Kaggle的实证研究,我们为了实现众包软件开发的问题,确定了个性化的队友推荐。据我们所知,在CSD中研究这个问题的很少。
  • 我们提出了一个称为团队协作意愿的度量标准,通过考虑开发人员的个人队友偏好来衡量团队成功的可能性,并提供获取偏好和计算协作意愿的方法。
  • 我们进一步根据个人队友的偏好,为众包开发者提供个性化的队友推荐方法,并进行一系列的实验,通过与其他方法比较来评估我们的方法的性能。

2. KAGGLE的实证研究

为了验证我们研究的重要性,我们对Kaggle进行了实证研究。 我们的目标是回答以下三个研究问题(RQ):

  • RQ1:团队协作是否对CSD的开发人员很重要?
  • RQ2:在没有队友推荐的情况下,开发人员在寻求队友方面失败是否常见?
  • RQ3:哪些因素会影响开发人员的合作意愿? 开发人员是否会根据这些因素显示个人喜好选择队友?
    Google文档中提供了详细信息:

2.1 数据准备

  除了对竞赛的基本支持外,Kaggle还提供在线社区,包括讨论社区和内核社区,开发人员可以在这里讨论各种主题的问题并分享想法。

  我们还从Kaggle抓取了一个数据集,涉及275个竞赛和74,354个开发人员,他们从2010年4月到2018年1月完成了191,300个提交。我们还从kaggle的社区中抓取了开发人员的社交数据。

2.2 团队协作的好处

  我们根据参加超过K场竞赛的选定开发者的发展历史,对开发者在不同工作模式下的竞赛排名进行了统计分析。 当K设置为10和20时,选择的开发人员数量为988和327.根据开发人员的工作模式,我们将他们的开发历史划分为个人模式和团队模式。 我们计算了在指定工作模式和他们自己的Top-K排名开发历史下,每个开发人员完成的任务的比例,表示为Prop。结果如图所示 1。 x轴表示Prop,而y轴表示开发者的累积比率。 图 1 显示开发者可以通过团队合作获得更好的排名。 例如,k = 10曲线中的左两点表明,对于988名开发者中约60%的人来说,他们在团队合作模式下参加的竞赛在他们自己的开发史中排名前十,而这一比例仅为14.88%当竞赛单独完成时。

图1 开发人员在两种模式下的表现

  之后,我们研究了与单独工作相比,通过协作是否可以更快地提升开发人员的专业知识。 我们使用Kaggle的评分系统来量化开发者在每场竞赛中获得的专业知识。 617名开发人员被选来进行分析,他们通过团队模式和个人模式参与的次数均大于2。 我们计算了团队合作模式和个人模式下每个开发人员的平均专业知识收益,分别表示为G1和G2。 然后,我们将G1 / G2不同范围内的开发人员数量相加,得到图 2。 x轴表示G1/G2的范围,y轴代表开发人员的比例。 如图 2 所示,与单独工作相比,大多数(超过70%)开发人员可以从团队合作中获益更多,超过20%的开发人员可以获得3倍以上的收益。

图2 617名开发者的G1/G2分布

  从上面给出的分析中,开发人员从团队协作中受益匪浅。

2.3 未能找到队友的现象

  我们浏览了数据集中的讨论表,以选择与其标题中的术语团队(不区分大小写)进行讨论。 我们选择了500个被认为是为寻找队友而发布的讨论。 通过讨论发布者和评论者,我们确定了1987个有意组队的开发人员。 令人惊讶的是,最终只有825名开发人员参加了竞赛,其中只有415名开发人员在团队中工作。 我们可以推断,只有20.9%的开发人员成功合作,58.5%的开发人员放弃参与,这可能是由于缺乏队友。

  通常会看到开发人员在寻找队友方面失败,因此为开发人员提供队友推荐至关重要。

2.3 影响因素和个人队友偏好

  我们对这500个讨论进行了进一步的分析。 事实证明,45%的发布者清楚地表明他们希望通过团队协作获得专业知识的提升,其中77%的发布者要求技能熟练程度与他们相似的队友。 我们可以得出这样的结论:协作所获专业知识的提升和团队成员专业知识的差异会影响开发人员的协作意愿。

  我们根据开始日期对数据集中的275个竞赛进行了排序。 前245个比赛,约90%的数据集,用作历史数据。 我们选择了585名开发人员,他们在历史数据和其余30个竞赛中进行了合作,以分析他们的协作关系,并发现75%的开发人员与他们的前队友合作。 开发人员之间的亲密关系可以通过协作关系来体现,因此它也是影响开发人员协作意愿的重要因素。

  从上面可以看出,开发者对队友提出了不同的要求。 一些讨论发布者要求具有相似技能熟练程度的人组成团队,有些人希望通过团队合作提升他们的专业知识,而其他人则希望与前队友合作。 因此,开发者有自己的队友喜好,这是我们的队友推荐方法需要考虑在内的。

3. 问题制定

  受上述实证研究的启发,我们建议为开发人员提供个性化的队友推荐。 在本节中,我们首先介绍几个重要概念,然后提供我们问题的公式表述。
在CSD平台中,开发人员通常具有不同熟练程度的专业知识。 拥有更多经验的开发人员将更加熟练。令{\rm{u = \{ }}{u_{\rm{1}}}{\rm{,}}{u_{\rm{2}}}{\rm{, }}...{\rm{,}}{u_{\rm{n}}}{\rm{ \} }},是开发人员的集合,任务中所需全部技能可以表示为一个集合:{\rm{S = \{ }}{{\rm{s}}_{\rm{1}}}{\rm{, }}{{\rm{s}}_{\rm{2}}}{\rm{, }}...{\rm{, }}{{\rm{s}}_{\rm{m}}}{\rm{\} }}. 我们引入技能熟练度的概念来表示开发人员的技能水平。
定义1(技能熟练度):形式上,开发人员({u_{{\rm{i }}}} \in u)掌握的的技能集合表示为{{\rm{S}}_u}{\rm{(}}{u_{\rm{i}}}{\rm{) }} \subset {\rm{S}},对于{u_{{\rm{i }}}}掌握的每个技能{{\rm{s}}_{\rm{k}}}(即{{\rm{s}}_{\rm{k}}} \subset {{\rm{S}}_u}{\rm{(}}{u_{\rm{i}}}{\rm{) }}),我们定义相应的技能熟练程度为{\rm{Prof(}}{u_{\rm{i}}},{{\rm{s}}_{\rm{k}}}{\rm{) = }}\varepsilon _i^k \in [0,1],来表示{u_{{\rm{i }}}}掌握{{\rm{s}}_{{\rm{k}}}}的能力。
  任务请求者通常预先指定任务所需的技能。因此,我们引出了任务所需技能集的概念。

定义2(任务所需技能集):对于任务v,需要一组技能来保证其完成,这可以表示为集合S(v)。 根据所需技能的数量,任务可分为多技能任务和单技能任务。 特别地,我们的研究目前仅关注单一技能任务,因此我们在本文中将S(v)视为{{\rm{s}}_{\rm{k}}}

  如2.4章节表明,团队协作中与队友的亲密关系,专业知识的差异和专业知识的获得会影响开发人员的协作意愿,开发人员有这三个因素的个人队友偏好。 人格,地理,语言等也会影响开发人员的合作意愿,但本文不考虑这些因素。 给定一个开发者团队 {\rm{T = \{ }}{u_{\rm{1}}}{\rm{, }}{u_{\rm{2}}}{\rm{, }}...{\rm{, }}{u_l}{\rm{\} }},它是所需技能为{{\rm{s}}_{\rm{k}}}的任务v所形成的,对于任何开发者{u_{\rm{i}}}T,让{\rm{C(}}{u_{\rm{i}}}{\rm{ ,T )}} \in [0,1]表示{u_{\rm{i}}}T中成员的亲密度,{\rm{ED(}}{u_{\rm{i}}}{\rm{ ,T ,}}{{\rm{s}}_{\rm{k}}}{\rm{)}} \in [0,1]代表{u_{\rm{i}}}{{\rm{s}}_{\rm{k}}}中与团队成员的专业差异。{\rm{EG(}}{u_{\rm{i}}}{\rm{ ,T ,}}{{\rm{s}}_{\rm{k}}}{\rm{)}} \in [0,1]代表{u_{\rm{i}}}{{\rm{s}}_{\rm{k}}}中通过团队协作的专业获得。 开发人员的协作意愿随着{\rm{C(}}{u_{\rm{i}}}{\rm{ ,T )}}{\rm{EG(}}{u_{\rm{i}}}{\rm{ ,T ,}}{{\rm{s}}_{\rm{k}}}{\rm{)}}的增加而上升,随着{\rm{ED(}}{u_{\rm{i}}}{\rm{ ,T ,}}{{\rm{s}}_{\rm{k}}}{\rm{)}}的增加而下降。\Pr eC = \{ ({\alpha _i},{\beta _i},{\gamma _i})|i \in [1,n]\}用于表示u中开发者的队友的偏好。{u_{\rm{i}}}在团队T中的协作意愿的公式可以形式化为:

\begin{array}{l} W({u_i},T) = {\alpha _i}*C({u_i},T) + {\beta _i}*(1 - ED({u_i},T,{s_k})) + \\ {\rm{ }}{\gamma _i}*EG({u_i},T,{s_k})\\ s.t.{\rm{ }}{u_i} \in T,{\alpha _i} + {\beta _i} + {\gamma _i} = 1{\rm{ }} and\\ {\alpha _i},{\beta _i},{\gamma _i},C({u_i},T),ED({u_i},T,{s_k}),EG({u_i},T,{s_k}) \in [0,1] \end{array}

其中{\alpha _i},{\beta _i},{\gamma _i}表示相应因素对开发商协作意愿的影响程度。 获得PreC值和C({u_i},T),ED({u_i},T,{s_k}),EG({u_i},T,{s_k})的表示的方法将在下面的部分中介绍。

  基于上面介绍的定义,我们将个性化的队友推荐问题定义如下:

定义3(个性化团队推荐问题):假设存在一个开发者集合 {\rm{u = \{ }}{u_{\rm{1}}}{\rm{, }}{u_{\rm{2}}}{\rm{, }}...{\rm{, }}{u_n}{\rm{\} }},任务v的需求技能集合\{ {s_k}\},给定一个开发者{u_i},他要为这个任务寻求N个队友,个性化团队推荐问题研究如何根据每个开发者的个人队友偏好,推荐具有高度协作意愿的最合适的N个队友。

定义4(一个团队的合作意愿)
  团队是否可以组建是基于每个成员的意愿。 我们不仅要考虑到{u_i}的合作意愿,还要考虑所有其他成员的意愿。 因此,我们应该确保每个成员的协作意愿不低于某个阈值threshold,这意味着团队中每个成员应该满足的最小协作意愿。 threshold可以从开发人员的协作历史中获得,并将在章节 4.2中介绍。 同时,我们需要最大化所有成员的协作意愿的平均值,这被定义为团队T的协作意愿:

\psi (T) = \frac{{\sum\nolimits_{{u_j} \in T} {W({u_j},T)} }}{{|T|}}

形式上,针对开发者{u_i}的个性化团队推荐旨在获得最佳团队{T^*}

{T^*} = \arg \mathop {\max }\limits_T \psi (T) = \arg \mathop {\max }\limits_T \frac{{\sum\nolimits_{{u_j} \in T} {W({u_j},T)} }}{{|T|}}    {\rm{ (1)}}

使得 {\rm{T}} \subseteq {\rm{u,|T| = N + 1,}}{u_i} \in T,W({u_j},T) \ge {\rm{threshold}}
{T^*}\backslash \{ {u_i}\}是为{u_i}制定的队友推荐的集合。

4. 建议的方法

  我们在图3中给出了我们的推荐框架。为了量化团队的协作意愿,我们模拟了支配开发人员协作意愿的三个因素,然后通过分析他们的协作历史来表征开发人员的个人队友偏好并获得他们最小的协作意愿。 最后,基于协作意愿,我们提出了一种近似算法来为开发人员提供队友推荐。

图3 推荐框架

4.1 因素模型

  在这一部分中,我们介绍了支配开发人员合作意愿的三个因素的具体表示。

  因素1(与队友的亲密度C({u_i},T) ) : 在CSD平台中,开发人员彼此通常有协作关系和社交互动,我们可以据此衡量开发人员之间的整体亲密度。

  定义5(基于协作关系的亲密度C_1({u_i},T) ):开发人员通常协作完成任务,并经常协作让开发人员更亲密。我们引入基于协作关系的亲密度,即C_1({u_i},T) \in [0,1],来表示在协作关系下u_iu_j有多亲密。我们知道一般情况下:C_1({u_i},{u_j}) \ne C_1({u_j},{u_i})。令加权无向图{{\rm{G}}^{\rm{a}}}{\rm{ = (u, }}{{\rm{R}}^{\rm{a}}}{\rm{ )}}代表开发者的协作关系,这里u是开发者集合,{{\rm{R}}^{\rm{a}}}代表他们的协作关系。\forall {({u _{\rm{i}}},{u _{\rm{j}}})^a} \in {{\rm{R}}^{\rm{a}}},边的权重,\omega ({{\rm{(}}{u _{\rm{i}}}{\rm{,}}{u _{\rm{j}}}{\rm{)}}^{\rm{a}}})代表{u_i}{u_j}之间的协作次数。{u_i}{u_j}多亲密取决于{u_i}{u_j}{u_i}的整体合作关系中的合作关系比例:

{C_1}({u_i},T) = \frac{{\omega ({{{\rm{(}}{u _{\rm{i}}}{\rm{,}}{u _{\rm{j}}}{\rm{)}}}^{\rm{a}}})}}{{\sum\nolimits_{{u_k} \in u} {\omega ({{{\rm{(}}{u _{\rm{i}}}{\rm{,}}{u _{\rm{j}}}{\rm{)}}}^{\rm{a}}})} }}

  定义6(基于社交关系的亲密度C_2({u_i},{u_j})):许多CSD平台提供在线社区,开发人员可以在这里讨论和分享想法。 社交互动越频繁,开发人员关系越亲密。 基于社会关系的亲密度,{{\rm{C}}_{\rm{2}}}{\rm{(}}{u_{\rm{i}}}{\rm{,}}{u_{\rm{j}}}{\rm{)}} \in {\rm{[0,1]}},用于表示{u_{\rm{i}}}在社会关系下与{u_{\rm{j}}}的接近程度。 我们知道一般情况下:C_2({u_i},{u_j}) \ne C_2({u_j},{u_i})。令加权无向图{{\rm{G}}^{\rm{b}}}{\rm{ = (u, }}{{\rm{R}}^{\rm{b}}}{\rm{ )}}代表开发者的社会关系,这里u是开发者集合,{{\rm{R}}^{\rm{b}}}代表他们的社会关系。\forall {({u _{\rm{i}}},{u _{\rm{j}}})^b} \in {{\rm{R}}^{\rm{b}}},边的权重,\omega ({{\rm{(}}{u _{\rm{i}}}{\rm{,}}{u _{\rm{j}}}{\rm{)}}^{\rm{b}}})代表{u_i}{u_j}之间的社会关系次数。{u_i}{u_j}多亲密取决于{u_i}{u_j}{u_i}的整体社会关系中的社会关系比例:

{C_2}({u_i},T) = \frac{{\omega ({{{\rm{(}}{u _{\rm{i}}}{\rm{,}}{u _{\rm{j}}}{\rm{)}}}^{\rm{b}}})}}{{\sum\nolimits_{{u_k} \in u} {\omega ({{{\rm{(}}{u _{\rm{i}}}{\rm{,}}{u _{\rm{j}}}{\rm{)}}}^{\rm{b}}})} }}

  我们将{u_i}{u_j}之间的整体亲密度表示为:

C({u_i},{u _{\rm{j}}}) = \omega *{C_1}({u_i},{u _{\rm{j}}}) + (1 - \omega ){C_2}({u_i},{u _{\rm{j}}})

这里\omega \in [0,1]代表{C_1}({u_i},{u _{\rm{j}}})的权重。注意:C({u_i},{u_j}) \ne C({u_j},{u_i})

{C}({u_i},T)定义为{u_i}T中其他成员的综合亲密度的平均值,表示如下:

{C_2}({u_i},T) = \frac{{\sum\nolimits_{\forall {u _j} \in T \wedge {u _i} \ne {u _j}} {C({u _i},{u _j})} }}{{|T| - 1}}

  因素2(与队友的专业能力差异ED({u_i},T,{s_k}) ) : 专业知识差异削弱了开发人员的团队合作意愿。 不失一般性,{u_i}{u_j}之间的技能{s_k}技能的专业差异定义为:{D^k}({u _i},{u _j}) = |\varepsilon _i^k - \varepsilon _j^k| .

ED({u_i},T,{s_k})定义为{u_i}T中其他成员在{s_k}中的专业差异的平均值,表示如下:

ED({u_i},T,{s_k}) = \frac{{\sum\nolimits_{\forall {u _j} \in T \wedge {u _i} \ne {u _j}} {{D^k}({u _i},{u _j})} }}{{|T| - 1}}

  因素3(团队协作的专业知识获得EG({u_i},T,{s_k}) ) : 许多开发人员希望通过团队合作来提升他们的专业知识。 受Jiawei Zhang等人的启发[11],我们定义一个增益函数来衡量开发人员技能熟练程度的提高。 首先,我们介绍团队T的技能熟练程度,表示为\Pr of(T,{s_k})\,然后表示开发人员从团队获得的专业知识。

  定义7 团队的技能熟练程度(\Pr of(T,{s_k})\):给定一个开发者团队T = \{ {u_1},{u_2}, \cdots ,{u_l}\},以及任务v的所需求的技能s_k的熟练水平{\{ \varepsilon _i^k\} _{{u_i} \in T}},s_k的团队技能熟练程度可以定义为:

\Pr of(T,{s_k}) = 1 - \prod\limits_{{u _{\rm{i}}} \in T} {(1 - \varepsilon _i^k)}

  整体团队熟练程度是团队的一个重要特征,既体现了团队的竞赛力,也体现了团队成员专业知识获得的空间。 形式上,当与团队T合作时,在s_k中的u_i的专业知识获得可以表示为:

EG({u_i},T,{s_k}) = \Pr of(T,{s_k}) - \Pr of({u _{\rm{i}}},{s_k})

4.2 参数估计

  根据章节3,我们需要获得最低协作意愿threshold和开发者队友偏好\Pr eC = \{ ({\alpha _i},{\beta _i},{\gamma _i})|i \in [1,n]\}.
  假设在开发人员的协作历史中,由于他们在自愿的基础上合作,每个团队成员非常愿意合作。 令{R_i} = \{ {T_1},{T_2}, \cdots ,{T_k}\}代表u_i的合作历史,{s^{{T_j}}}代表T_j相应的单一技能任务所需的技能,其中{{\rm{T}}_{\rm{j}}} \in {{\rm{R}}_{\rm{i}}}。 我们在算法1的描述中同时学习thresholdPreC 。当thresholdPreC是相关的,学习过程是迭代的。在给定threshold的情况下,三元组({\alpha _i},{\beta _i},{\gamma _i})是:通过最大化u_i所有协作历史的协作意愿总和,并保证u_i在每个团队中的协作意愿不低于threshold而得到的,如公式(2)所示。 给定threshold,方程式(2)是典型的线性规划问题,我们可以通过典型的线性规划方法得到({\alpha _i},{\beta _i},{\gamma _i})。我们将阈值初始化为0,通过一个指定步长增加阈值,直到\exists {u_i} \in u,此时没有有效的解答,然后我们可以得到threshold的一个近似解,我们根据它获得PreC的值。

({\alpha _i},{\beta _i},{\gamma _i}) = \arg \mathop {\max }\limits_{({\alpha _i},{\beta _i},{\gamma _i})} \sum {W({u_i},T)}

s.t.\forall T \in {R_i},W({u_i},T) \ge threshold,and    (2)

{\alpha _i} + {\beta _i} + {\gamma _i} = 1{\rm{ }},{\alpha _i},{\beta _i},{\gamma _i} \in [0,1]{\rm{ }}

4.3 目标函数和算法

  获得PreC后,开发人员的队友偏好就被定性了。 结合因素1-3,对于任何给定的团队T\forall {u_i} \in T,我们可以计算u_i的协作意愿{W({u_i},T)}。 然后,我们可以得到我们的目标函数的具体表示,表示为公式(1)。 为了向开发人员推荐最合适的队友,一个简单直接的解决方案是遍历所有候选人并找到所需的N个队友,这是不可行的,因为计算复杂度是O({n^N}),其中n代表候选人的数量,N代表所需队友的数量。

         算法1    获得队员偏好 & 阈值
要求: u = \{ {u_1},{u_2}, \cdots ,{u_n}\} ,R = \{ {R_1},{R_2}, \cdots ,{R_n}\}

确保: \Pr eC = \{ ({\alpha _i},{\beta _i},{\gamma _i})|i \in [1,n]\} ,threshold

1: threshold = 0,step = 0
2: while {\rm{ True }} do
3:  {\rm{ }}\forall {\rm{i}} \in {\rm{[1,n],}} 通过公式(2)获得({\alpha _i},{\beta _i},{\gamma _i})
{\rm{4:}}  if{\rm{ }} \exists {\rm{i}} \in {\rm{[1,n],}}({\alpha _i},{\beta _i},{\gamma _i})是无效的, then
5:    break
6:  end if
7:  threshold+=step
8:  Prec=\{({\alpha _i},{\beta _i},{\gamma _i}) | i \in [1,n]\}
9: end while
10:threshold-=step
11:\forall {\rm{i}} \in {\rm{[1,n],}},通过公式(2)获得({\alpha _i},{\beta _i},{\gamma _i})
12:return (PreC,threshold)

  我们提出了一种近似算法PTR来解决这个问题,伪代码在算法2中提出。PTR是一种贪心算法:给定一个队员寻求者u_iPTR遍历候选集合{\rm{u\backslash \{ }}{u_{\rm{i}}}{\rm{\} }}以找到队友u_j,其中\neg \exists {u_l} \in {\rm{u\backslash \{ }}{u_i}{\rm{\} }},\Psi (\{ {u_i},{u_l}\} ) > \Psi (\{ {u_i},{u_j}\} ),根据团队\{ {u_i},{u_j}\}PTR继续遍历候选集合{\rm{u\backslash \{ }}{u_i},{u_j}{\rm{\} }}以找到队友u_k,其中\neg \exists {u_l} \in {\rm{u\backslash \{ }}{u_i},{u_j}{\rm{\} }},\Psi (\{ {u_i},{u_j},{u_l}\} ) > \Psi (\{ {u_i},{u_j},{u_k}\} ),这个过程继续,直到推荐的队友数达到N. PTR的计算复杂度仅为O(n*N)

         算法2    个性化队友推荐
要求: 队友寻求者{u_i},需要找N个队友$
要求: 队友候选者集合:u = \{ {u_1},{u_2}, \cdots ,{u_n}\} \backslash \{ {u_i}\},任务v的需求技能s_k
要求:threshold,\Pr eC = \{ ({\alpha _i},{\beta _i},{\gamma _i})|i \in [1,n]\}
确保: 推荐队友集合 :\{ u_1^,,u_2^,, \cdots ,u_N^ , \}
1:T = \{ {u_i}\} ,teamsize = 1
2:while teamsize < N + 1 do
3:  遍历u寻找 u^,:\neg \exists {u_l} \in {\rm{u\backslash \{ }}{u^,}{\rm{\} }},\Psi (T \cup \{ {u_l}\} ) > \Psi (T \cup \{ {u^,}\} ),
     and \forall {u_k} \in T \cup \{ {u^,}\} ,W({u_k},T \cup \{ {u^,}\} ) > threshold成立
4:  T = T \cup \{ {u^,}\} ,u = u\backslash \{ {u^,}\}
5:  teamsize+=1
6:end while
7:return T\backslash \{ {u^,}\}

5. 实验

  在本节中,我们将介绍数据集和实验设置。 然后给出实验结果并进行分析。

5.1 数据集描述

  我们使用了从Kaggle收集的数据集,其中涉及从2010年4月到2018年1月的275个竞赛和74,354个开发人员。该数据集包含19,300个开发人员的竞赛记录,我们可以从中获得开发人员的技能熟练程度和协作关系。 我们还从Kaggle的讨论社区和内核社区中爬取到他们的社交数据,以挖掘他们的社交关系。488,722对开发人员通过协作或社交关系进行关联。 我们实验中使用的数据集可在GitHub中找到。

5.2 实验设置

  Kaggle中的任务都是数据科学竞赛,所涉及的技能组合是S = \{ {s_1}\},其中s_1表示数据科学。 我们利用Kaggle的评分系统根据开发历史获得开发人员的分数。 通过线性归一化,我们获得了他们的技能熟练程度{\rm{Prof(}}{u_i},{s_i}{\rm{)}} \in {\rm{[0,1]}}.基于协作和社会关系,我们得到了开发人员之间的整体亲密度{\rm{C(}}{u_i},{u_j}{\rm{)}}\omega,基于协作关系的密度的权重,设置为0.7。
  在我们的实验中选择了3,808名合作次数不少于2的开发人员。 我们首先用章节4.2中介绍的方法获取了他们的队友偏好PreCthreshold。 之后,我们将我们的工作与其他方法进行了比较。 比较方法包括:

  • 亲密度优先(CF):CF在推荐过程中考虑了开发人员之间的密切关系,并且该方法在以前的工作中被广泛使用[8]。 CF中不考虑技能熟练程度。
  • 专业知识获得优先(EGF):EGF旨在最大限度地提高团队成员的专业知识,并在协作学习领域采用该方法[6].
  • 专业知识差异优先(EDF):EDF旨在最大限度地减少成员的专业知识差异,同时不考虑开发人员之间的密切关系和专业知识获得。
  • 最佳(Optimal):此方法遍历开发人员集以找到理论上最优的解决方案。

所有实验均在具有Core i7-6700 3.4GHZ和8GB内存的台式计算机上进行。

5.3 实验结果

  当N = 1,2,3时,我们分别得到了我们的方法和比较方法的推荐结果,并计算了每种方法推荐团队的协作意愿的平均值。 如表??所示
  如表中所示,我们的方法可以推荐具有更高协作意愿的团队,并且优于现有方法(Optimal除外),因为我们的方法考虑了三个因素和个人队友偏好,而CF,EGFEDF只考虑一个因素分别影响协作意愿。 Optimal的结果证明了理论上最大的协作意愿。 然而,Optimal获得推荐结果时,具有最高的计算复杂度(O({n^N}),其中n是候选者的数量,N是所需队友的数量)。 当N = 2时,获得3808开发人员的所有推荐结果需要数小时,而其他方法只需几分钟。 对于所有3,808名开发人员和N = 3Optimal至今已运行30天,但尚未完成。 当N = 1时,Optimal的结果与我们的方法相同,因为我们的方法遍历所有候选者以向开发人员推荐一个队友。 值得注意的是我们的方法可以获得与Optimal类似的结果,计算复杂度仅为O(n * N)

6. 结论

  在本文中,我们通过对Kaggle的实证研究,确定了众包软件开发的个性化队友推荐问题。 然后,我们提出了一种方法,通过根据开发人员的个人队友偏好最大化团队的协作意愿来解决问题。 在Kaggle数据集上进行的实验验证了我们方法的有效性。
  在未来,我们将研究涉及多种开发技能的队友推荐,并在为新手提供推荐时尝试解决冷启动问题。

致谢

  这项工作部分得到了中国国家重点研究发展计划的批准,编号为2016YFB1000804,部分得到了国家自然科学基金项目(61421003,61702024)和部分SKLSDE实验室的批准号SKLSDE-2017ZX-14的支持。 Hailong Sun是本文的通讯作者。

参考文献

相关文章

  • 为众包软件开发者的个性化团队推荐

    摘要   大部分软件开发平台采取比赛范式来征求来自团队的贡献。为了在复杂任务中获取竞赛力,众包软件开发者通常选择与...

  • dmg制作笔记:个性化自己的Mac软件安装包

    原文链接:dmg制作笔记:个性化自己的Mac软件安装包 一、需要材料 .app 文件(以Adobe Zii为例) ...

  • 软件众包和软件众筹的区别

    随着互联网创业热潮的到来以及传统企业升级的加快,越来越多的企业和创业团体需要软件产品。但是对于一个刚刚起步的互联网...

  • 最新 Flutter 团队工程师中文演讲 | Flutter 的

    本视频为 Google Flutter 团队的软件工程师 Xiao Yu 在 2018 谷歌开发者大会做的演讲,演...

  • 软件众包网站有哪些?

    软件众包网站有哪些? 软件众包网站1.大大神 找软件外包公司做软件开发项目首推大大神,严格来说大大神不属于威客平台...

  • 依赖地狱

    通俗而言,“依赖地狱”指开发者安装某个软件包时,发现这个软件包里又依赖不同特定版本的其它软件包。随着系统功能越来越...

  • 一点资讯广告怎么投放?

    媒体概述:一点资讯广告投放是一款为兴趣而生、有机融合搜索和个性化推荐技术的兴趣引擎,团队致力于基于兴趣为用户提供私...

  • 软件众包平台排行最新

    软件众包平台排行 (以下排名不分先后) 软件众包平台排行1.大大神 大大神网严格来说不属于威客网站,它打出的是全球...

  • 随记shp版隐私政策网址

    本软件:随记shp版 开发者:胡冯伟 本软件尊重并保护所有使用服务用户的个人隐私权。为了给您提供更准确、更有个性化...

  • Android开发者软件推荐

    Windows系的 科学上网最牛* lantern本人自己的百度云,破解版链接密码 96pr Android st...

网友评论

    本文标题:为众包软件开发者的个性化团队推荐

    本文链接:https://www.haomeiwen.com/subject/ezpjgftx.html