开源软件版本发布与开源社区贡献评估的关系实证研究

1 .第３７卷第 ４期 计算机应用与软件 Ｖｏ ｌ３７ Ｎｏ ．４ ２０２０年 ４月 Ｃｏ ｍｐｕｔ ｅｒＡｐｐ ｌｉｃ ａｔｉ ｏｎｓａ ｎｄＳｏ ｆｔ ｗａｒ ｅ Ａｐｒ ．２０２０ 开源软件版本发布与开源社区贡献评估的关系实证研究 董 晨１ 尹 刚 ２ １ （天津理工大学计算机科学与工程学院天津市智能计算及软件新技术重点实验室 天津 ３ ００３ ８４） ２ （国防科技大学计算机学院复杂系统软件工程湖南省重点实验室 湖南 长沙 ４ １００ ７３） 摘 要 软件版本发布这一软件管理活动不仅直接影响开源软件用户的使用体验，同时也会在一定程度上影 响着开源社区的贡献评估过程。针对此问题，对开源软件版本发布与开源社区贡献评估的关系展开实证研究，着 重分析软件版本发布对贡献的第一次评估反馈以及接受概率的影响。根据实验结果，对目前的开源社区提出相 应的实践建议，以促进开源社区更加有效地管理软件版本发布与贡献评估之间的关系，使得开源社区能够更加良 性发展。 关键词 开源软件 版本发布 贡献评估 实证研究 中图分类号 ＴＰ３１１． ５ 文献标志码 Ａ ＤＯＩ ：１０． ３９６９／ ｊ．ｉ ｓｓｎ． １０００ ３８６ｘ ．２０２０． ０４． ００３ ＡＮＥＭＰＩ ＲＩＣＡＬＳＴＵＤＹＯＮＯＰＥＮＳＯＵＲＣＥＳＯＦＴＷＡＲＥＲＥＬＥＡＳＥ ＡＮＤＥＶＡＬＵＡＴＩ ＯＮＯＦＣＯＭＭＵＮＩ ＴＹＣＯＮＴＲＩ ＢＵＴＩ ＯＮ Ｄｏ ｎｇＣｈ ｅｎ１ Ｙｉ ｎＧａ ｎｇ２ １ （Ｔｉ ａｎｊ ｉ ｎＫｅ ｙＬａ ｂｏｒ ａｔｏ ｒｙｏ ｆＩｎ ｔｅｌ ｌｉ ｇｅｎ ｃｅＣｏ ｍｐｕ ｔｅｒａ ｎｄＮｏ ｖｅｌＳ ｏｆｔ ｗａｒ ｅＴｅ ｃｈｎ ｏｌｏ ｇｙ，Ｓ ｃｈｏ ｏｌｏ ｆＣｏ ｍｐｕ ｔｅｒＳ ｃｉｅ ｎｃｅａ ｎｄＥｎ ｇｉｎ ｅｅｒ ｉｎｇ， Ｔｉ ａｎｊ ｉ ｎＵｎ ｉｖｅ ｒｓｉ ｔｙｏ ｆＴｅ ｃｈｎ ｏｌｏ ｇｙ，Ｔｉ ａｎｊ ｉ ｎ３０ ０３８ ４，Ｃｈ ｉｎａ） ２ （Ｌ ａｂｏ ｒａｔ ｏｒｙｏ ｆＳｏ ｆｔ ｗａｒ ｅＥｎ ｇｉｎ ｅｅｒ ｉｎｇｆ ｏｒＣｏ ｍｐｌ ｅｘＳ ｙｓｔ ｅｍｓ ，Ｃｏ ｌｌ ｅｇｅｏ ｆＣｏ ｍｐｕ ｔｅｒ ，Ｎａ ｔｉｏ ｎａｌＵｎ ｉｖｅ ｒｓｉ ｔｙｏ ｆＤｅ ｆｅｎ ｓｅＴｅ ｃｈｎ ｏｌｏ ｇｙ， Ｃｈ ａｎｇ ｓｈａ４ １００ ７３，Ｈｕ ｎａｎ，Ｃｈ ｉｎａ） Ａｂｓ ｔｒａ ｃｔ Ｓｏ ｆｔ ｗａｒ ｅｒｅ ｌｅａ ｓｅ，ａｓ ｏｆｔ ｗａｒ ｅｍａ ｎａｇ ｅｍｅ ｎｔａ ｃｔｉ ｖｉ ｔｙｎｏ ｔｏｎｌ ｙｄｉ ｒｅｃ ｔｌ ｙｉｎｆ ｌｕｅ ｎｃｅ ｓｔｈｅｕｓ ｅｒｅ ｘｐｅ ｒｉｅ ｎｃｅｏ ｆｏｐｅ ｎ ｓ ｏｕｒ ｃｅｓ ｏｆｔ ｗａｒ ｅ，ｂｕｔａ ｌｓｏａ ｆｆ ｅｃｔ ｓｔｈｅｃ ｏｎｔ ｒｉ ｂｕｔ ｉｏ ｎｅｖ ａｌｕａ ｔｉ ｏｎｐｒ ｏｃｅ ｓｓｏ ｆｏｐｅ ｎｓｏ ｕｒｃ ｅｃｏ ｍｍｕｎｉ ｔｙｔ ｏａｃ ｅｒｔ ａｉ ｎｅｘ ｔｅｎｔ ．Ｉｎｖ ｉｅｗ ｏ ｆｔｈｉ ｓｐｒ ｏｂｌ ｅｍ，ｔ ｈｉｓｐａ ｐｅｒｃ ｏｎｄ ｕｃｔ ｓａｎｅ ｍｐｉ ｒｉ ｃａｌｓ ｔｕｄｙｏ ｎｔｈｅｒ ｅｌａ ｔｉ ｏｎｓ ｈｉｐｂｅ ｔｗｅ ｅｎｔ ｈｅｒ ｅｌｅ ａｓｅｏ ｆｏｐｅ ｎｓｏ ｕｒｃ ｅｓｏ ｆｔ ｗａｒ ｅ ａ ｎｄｔ ｈｅｅ ｖａｌ ｕａｔ ｉｏ ｎｏｆｔ ｈｅｃ ｏｎｔ ｒｉ ｂｕｔ ｉｏ ｎｏｆｔ ｈｅｏ ｐｅｎｓ ｏｕｒ ｃｅｃ ｏｍｍｕｎｉ ｔｙ．Ｗｅｆ ｏｃｕｓ ｅｄｏ ｎａｎａ ｌｙｚ ｉｎｇｔ ｈｅｉ ｍｐａ ｃｔｏ ｆｓｏ ｆｔ ｗａｒ ｅ ｒ ｅｌｅ ａｓｅｏ ｎｔｈｅｆ ｉｒ ｓｔｅ ｖａｌ ｕａｔ ｉｏ ｎｏｆｆ ｅｅｄｂ ａｃｋａ ｎｄｔ ｈｅｐ ｒｏｂａ ｂｉｌ ｉｔ ｙｏｆａ ｃｃｅ ｐｔａ ｎｃｅ ．Ｂａ ｓｅｄｏ ｎｔｈｅｅ ｘｐｅ ｒｉｍｅ ｎｔａ ｌｒｅ ｓｕｌ ｔｓ ，ｓｏ ｍｅ ｐｒ ａｃｔ ｉｃ ａｌｓ ｕｇｇ ｅｓｔ ｉｏ ｎｓａ ｒｅｐｕｔｆ ｏｒｗａ ｒｄｆ ｏｒｔ ｈｅｃ ｕｒｒ ｅｎｔｏ ｐｅｎｓ ｏｕｒ ｃｅｃ ｏｍｍｕｎｉ ｔｙｔ ｏｐｒ ｏｍｏ ｔｅｍｏ ｒｅｅ ｆｆ ｅｃｔ ｉｖ ｅｍａ ｎａｇ ｅｍｅ ｎｔｏ ｆｔｈ ｅ ｒ ｅｌａ ｔｉ ｏｎｓ ｈｉｐｂｅ ｔｗｅ ｅｎｓ ｏｆｔ ｗａｒ ｅｒｅ ｌｅａ ｓｅａ ｎｄｃ ｏｎｔ ｒｉ ｂｕｔ ｉｏ ｎｅｖ ａｌｕａ ｔｉ ｏｎ，ｓ ｏｔｈａ ｔｔｈｅｏ ｐｅｎｓ ｏｕｒ ｃｅｃ ｏｍｍｕｎｉ ｔｙｃ ａｎｄｅ ｖｅｌ ｏｐｂｅ ｔｔ ｅｒ． Ｋｅ ｙｗｏｒ ｄｓ Ｏｐｅ ｎｓｏ ｕｒｃ ｅｓｏ ｆｔ ｗａｒ ｅ Ｓｏ ｆｔ ｗａｒ ｅｒｅ ｌｅａ ｓｅ Ｅｖ ａｌｕａ ｔｉ ｏｎｏ ｆｔｈｅｃ ｏｎｔ ｒｉ ｂｕｔ ｉｏ ｎ Ｅｍｐｉ ｒｉ ｃａｌｓ ｔｕｄｙ 如今互联网高效运转的重要基础设施。开源软件的成 ０ 引 言 功来自于开源社区的开源开发者 ［３－４］，这些开源开发 者分布在世界各地，他们通过网络进行沟通和合作，并 开源软件是一种源代码可以自由获取、修改、再分 在一定的协同 机 制 下 为 开 源 软 件 贡 献 代 码 ［５］。 据 发的软件 ［１－２］，其所展现出的强大创新力和生命力给 Ｌｉ ｎｕｘ基金会 ２０１７年的 官 方 数 据 统 计，已 经 有 来 自 软件产业带来了巨大的变革，开源软件正在被越来越 １３００多个公司的 １４０００多个开发者为 Ｌｉ ｎｕｘ内核提 多的领域所应用。例如著名的开源软件 Ｌｉ ｎｕｘ正在被 交了代码贡献。由此可见，开源开发者是开发软件得 大量的企业和机构用作服务器操作系统，成为支撑起 以生存和发展的重要推动力。 收稿日期： ２０１ ９－０ ６－１ ０。国家级大学生创新创业训练计划平台项目（２ ０１８ １００ ６００ ０８）；天津市大学生创新创业训练计划平台项 目（２ ０１９ １００ ６００ ８０）。董晨，讲师，主研领域：数据挖掘，图像处理。尹刚，副研究员。 

2 .第 ４期 董晨，等：开源软件版本发布与开源社区贡献评估的关系实证研究 １３ 另一方面，开源软件在不断发展的过程中会经历 列功能和服务，目前已经托管了超过一千多万的开源 ［６］ 一个个的里程碑，并在恰当时机发布新的软件版本 。 软件项目。鉴于 Ｇｉ ｔＨｕｂ平台是极具代表性的开源社 每一个软件版本可能包含了对上一个版本所包含的 区平台，我们选取它作为我们的调研平台，并在该平台 ｂｕｇ （软件缺陷）的修复，也可能包含了新添加的功能。 上进一步选取了要具体分析的开源软件。我们设定的 在每次发布新的软件版本时，软件项目的管理团队需 软件筛选标准为： 要在综合考虑软件的稳定性以及任务的紧迫性的前提  软件版本发布频繁。 下，决定是否需要把某些特定改动加入到本次发布计  软件比较流行，参与的开源开发者数量大。 ［７］ 划中 。 最终，我们选取了 Ｇｉ ｔＨｕｂ平台上三个流行开源软 软件版本发布规划不仅仅会直接影响到软件用户 件：ｂｏ ｏｔｓ ｔｒ ａｐ、ｓ ｃｉｋｉ ｔ ｌｅａ ｒｎ以及 ｅ ｌａｓ ｔｉ ｃｓｅ ａｒｃ ｈ，三个开源软 群体的使用体验，还有可能会影响到开源开发者的参 件具有不同的编程语言和应用领域，其基本信息如表 与体验。然而正如前所述，开源开发者是促进开源软 １所示。如表 ２所示，其社区关注数量和开发者群体 件不断发展的核心力量。因此，为了更好地分析开源 以及其代码提交数量都是位于社区前列水平，表明其 社区对开源开发者贡献的接受现状，本文从开源软件 是具有一定流行度的软件。 版本发布的角度出发，对开源开发者的贡献评估进行 表 １ 调研项目的基本信息 了实证研究，并试图回答以下两个研究问题： 项目名称 编程语言 应用领域 研究问题 １：开源软件版本发布对开源社区贡献 Ｅｌ ａｓｔ ｉｃ ｓｅａ ｒｃｈ Ｊ ａｖａ 搜索引擎 第一次评估反馈延迟的影响。 Ｓ ｃｉｋ ｉｔ ｌｅａ ｒｎ Ｐｙ ｔｈｏ ｎ 机器学习 研究问题 ２：开源软件版本发布对开源社区贡献 Ｂｏ ｏｔｓ ｔｒ ａｐ Ｊ ａｖａ Ｓｃｒ ｉｐｔ 前端框架 接受概率的影响。 通过这些研究，我们深入分析了开源软件版本发 表 ２ 调研项目的流行度指标 布与开源社区开发者贡献评估的关联关系。与此同 项目名称 关注数量 提交数量 开发者数量 时，我们也对开源社区提出了相应的实践建议，以促进 Ｅｌ ａｓｔ ｉｃ ｓｅａ ｒｃｈ ４ ０１４ １ ４ ５５６ ２ １１ ８９ 开源社区的健康持续发展。 Ｓ ｃｉｋ ｉｔ ｌｅａ ｒｎ ３ ４４８ ２ ２ ３８７ ３ １２ ９１ Ｂｏ ｏｔｓ ｔｒ ａｐ １ ３２５ ４２ １ ８６３ ７ １０ ７２ １ 研究方法 （２）原始数据采集。如图 ２所示，我们通过 Ｇｉ ｔｈｕ ｂ 如图 １所示，我们首先构建开源软件版本发布与 网站提供的数据服务接口采集实验所需的原始数据。 社区贡献数据集，然后基于此数据集分别开展两方面 Ｇｉ ｔｈｕｂ提供了丰富的接口以获取其网站的各种数据， 的研究： １）软件版本发布与第一次评估反馈延迟的关 其中 社 区 贡 献 数 据 通 过 接 口 “／ ｒｅｐｏ ｓ／：ｏ ｗｎｅ ｒ／：ｒ ｅｐｏ／ 联分析；２）软 件 版 本 发 布 与 贡 献 接 受 概 率 的 关 联 ｐｕｌ ｌｓ ”采集，版本发布数据通过接口“／ ｒｅｐｏ ｓ／：ｏ ｗｎｅ ｒ／： 分析。 ｒ ｅｐｏ／ ｒｅｌ ｅａｓ ｅｓ”采集。采集到的数据存储于关系型数据 库 Ｍｙ ＳＱＬ中。 图 １ 研究方法概览 图 ２ 数据采集方案 １． １ 数据集构建 （３）数据清洗。为保证实验的准确性和有效性， （１）调研项目。Ｇｉ ｔＨｕｂ是目前最火的开源社区， 消除其他干扰因素的影响，我们对采集到的原始数据 它为开源软件提供源代码托管、开发任务管理等一系 进一步清洗，其中包括以下操作： 

3 . １４ 计算机应用与软件 ２０２０年  剔除起始阶段的数据：由于在软件发展的起始 响，我们首先定义了如下变量（发布后评估相对间隔）： 阶段，软件的开发和维护还未进入稳定状态，其版本发 Ｔｉ ｍｅＤ（Ｐ）－Ｔｉ （Ｒｉ） ｍｅ ＲＩ Ｄ（ｉ ，Ｐ）＝ （４） 布还未处于正常状态，因此我们对这一部分数据不予 ＲＣ（ｉ ） 考虑，而从 软 件 管 理 团 队 开 始 有 规 律 性 地 发 布 版 本 式中：Ｔｉ ｍｅＤ函数用于返回开源贡献 Ｐ的评估结果时 开始。 间点。因此 ＲＩ Ｄ（ｉ ，Ｐ）的含义类似于式（２）中 ＲＩ （ｉ，Ｐ）  只保留正式版本：在发布正式版本前，项目管 的含义，只是 Ｐ的分析时间发生了变化。 理管理团队还会发布一些测试版本，而测试版本的发 接着，我们统计了以下两组数据。 布较为随意一些，同时也过于频繁。因此，我们在实验 （１）被合并的贡献分布数据： 中只保留了正式发布的版本而去掉了测试版本。过滤 ＜ＲＩ Ｄ，Ｃｏ ｕｎｔ ａｃ ｃｅｐｔ ｅｄ＞ 方式是使用文本分析的技术，判断每一个版本发布的 （２）被关闭的贡献分布数据： 后缀名是否以数字结尾，并且不包含“ｂ ｅｔａ ”字样。 ＜ＲＩ Ｄ，Ｃｏ ｕｎｔ ｒｅ ｊｅｃ ｔｅｄ＞  只保留有效版本间的贡献数据：在确定了有效 在上面两组数据中，ＲＩ Ｄ表示发布后相对间隔的 的正式版本后，我们定位出最老版本和最新版本，并只 取值分布，而 Ｃｏ ｕｎｔ ａｃ ｃｅｐｔ ｅｄ和 Ｃｏｕｎｔ ｒｅ ｊｅｃ ｔｅｄ分别表示被接受 保留这两个版本之间的贡献数据。 的和被关闭的开源贡献在 ＲＩ Ｄ下的数量分布。进而， 最终，我们共收集了 １ ７４个软件版本发布数据以 我们对这两组数据进行对比统计，分析软件版本发布 及 １０３８９２个贡献数据。 是如何影响开源贡献的接受概率的。 １． ２ 软件版本发布与第一次评估反馈延迟的 关联分析 ２ 研究结果 为评估软件版本发布对开源社区贡献第一次评估 反馈延迟的影响，我们首先定义了以下三个变量。 ２． １ 研究问题 １ （１）版本发布周期： 发布后提交相对间隔和评估延迟的关联关系如图 ＲＣ（ｉ ）＝Ｔｉ ｍｅ（Ｒｉ＋１）－Ｔｉ ｍｅ（Ｒｉ） （１） ３所示。可以看出，当发布后相对间隔取值在 ０．５左 式中：Ｒｉ表示按照时间顺序排列的第 ｉ个版本，而 Ｔｉ ｍｅ 右或者 １． ０左右时，开源贡献的第一次评估反馈延迟 函数用于返回所传递参数的创建时间点。因此，发布 较小；而当发布后提交相对间隔取其他值时，反馈延迟 周期 ＲＣ表示两个相邻版本的时间间隔差。 具有波动性，不过在 ０． ０附近时反馈延迟相对稳定地 （２）发布后提交相对间隔： 维持在一个较高水平上。 Ｔｉ ｍｅ（Ｐ）－Ｔｉｍｅ （Ｒｉ） ＲＩ （ｉ，Ｐ）＝ （２） ＲＣ（ｉ ） 式中：Ｐ表示处于版本 Ｒｉ和 Ｒｉ＋１这时间段时，开源社 区开发者所提交的某次贡献。因此，发布后提交相对 间隔 ＲＩ （ｉ，Ｒ）表示的是：以上一个版本为基准点，贡献 Ｐ在本次周期内是哪个阶段提交的。当 ＲＩ取值为 ０ 时，表明贡献 Ｐ是在上一个版本发布时被提交的；而 当 ＲＩ取值为 １时，表明贡献 Ｐ是在本次发布周期的结 尾，也就是下一个版本发布时被提交的。 （３）评估延迟： ＥＤ（Ｐ）＝Ｔｉ ｍｅ（ＣＭＴｆｉｒｓｔ（Ｐ））－Ｔｉ ｍｅ（Ｐ） （３） 图 ３ 软件版本发布与第一次评估反馈的关系 式中：ＣＭＴｆｉｒｓｔ函数用于返回某次开源贡献所接受到的 由以上实验观察我们可以得到初步的结论：在一 第一个反馈，因此评估延迟 ＥＤ表示从贡献 Ｐ被提交 个软件版本发布周期内，在后半期提交的开源贡献更 开始，到它接收到第一个评估的时间延迟。对于每一 有可能得到及时的反馈，而在前半周期提交的开源贡 条开源贡献数据，我们计算它的发布后相对间隔和评 献的反馈延迟则更长一些。对于这种现象，一种可能 估延迟，然后分析它们之间的关联关系。 的解释是在软件版本发布前，项目管理团队需要对项 １． ３ 软件版本发布与贡献接受概率的关联分析 目整体的动态进行全局把握，并且由于筹划版本发布 为评估软件版本发布对开源贡献接受概率的影 的事务，管理团队可能会有更多的时间关注项目，从而 

4 .第 ４期 董晨，等：开源软件版本发布与开源社区贡献评估的关系实证研究 １５ 有更多的机会注意到开源贡献者所提交的工作，从而 演化的必要手段，开源社区的贡献管理是软件能够持 给予及时的反馈。 续发展的重要条件。然而管理团队的时间和精力是有 ２． ２ 研究问题 ２ 限的，因此如何平衡好软件版本发布和社区贡献评估 对于开源软件的发展是至关重要的。 发布后相对间隔与开源贡献的接受概率的对应关 就实际情况而言，软件版本发布管理是一个阶段 系如图 ４所示。可以看出，虽然开源开发者的贡献的 性的集中工作，而社区贡献评估是一个持续性的工作， 接受率大体维持在 ４０％ ～５ ０％之间，但确实也存在着 因此这两类工作的冲突不是一直存在的，只有在需要 一定的变化。尤其是在发布后评估相对间隔取值在 对软件版本发布进行规划和操作时才有可能发生。因 ［０． ９，１． ０］区间时，开源贡献的接受率是最低的；而当 此为了避免两类工作的冲突，开源软件的管理团队可 发布后评估相对间隔在较小区间取值时，开源贡献的 以指派专人负责版本管理，而其他人则更加专注社区 接受率相对是高一些的。 贡献的管理，这样既可以保证版本发布的质量，也可以 保证社区贡献评估的及时反馈。此外，在版本发布期 间，可以把不太确定的社区贡献接受到测试版本中而 不是拒绝该贡献，这样既能保证发布版本的稳定性，又 能吸收社区的贡献。 ３． ２ 面向贡献者 对于贡献者来说，他们所关注的不应该仅仅在提 交的贡献本身，还要对开源软件项目的整体发展和规 划有更进一步的认识。在提交贡献时不干扰项目的版 本发布规划，或者不被项目的版本规划所影响，尽量在 版本发布空窗期提交贡献，提高自己被接纳的概率。 此外，如果自己所提交的贡献没有得到及时的反馈，不 图 ４ 软件版本发布与贡献合并概率的对应关系 要轻易迁怒于项目的管理团队，指责其响应时效低，并 由以上实验观察我们可以得到初步的结论：在软 放弃对贡献的持续关注和必要更新，这会对项目的环 件版本发布前，项目管理团队对开源贡献持谨慎态度， 境建设带来负面的影响，应该要考虑客观情况，积极 更倾向于拒绝而不是接受；而在版本发布后，项目管理 应对。 团队对开源贡献持相对乐观一些的态度，具有更高的 概率去接受开源贡献。对于这种现象，一种可能的解 ４ 相关工作 释是在软件版本发布前，项目管理团队更希望发布一 个稳定的版本，而不是额外接受一个开源贡献，从而承 ４． １ 开源软件 ／ 社区 担更多的不可控的风险。而在版本发布后，项目管理 开源软件的快速发展吸引了大量研究人员的关 的紧张氛围有所缓解，同时又有后续充裕的时间对开 注。杨波等 ［８］对托管在 Ｇｉ ｔＨｕｂ平台中开源软件开发 源贡献和合并效果进行监控，因此管理团队有更高一 过程中产生的数据进行分析并提取了多种类型的指标 些的概率去接受一个开源贡献。 因素，例如问题解决速度和提交增加速度等，他们对这 些因素之间的相关性展开了研究。孙晶等 ［９］提出了开 ３ 实践建议 源软件的可信性模型，定义了开源软件的可信属性及 组件可信性，通过火狐浏览器验证了模型的有效性。 根据实验结果，我们对开源社区的参与者提出了 刘雅新等 ［１０］通过挖掘开源项目邮件列表信息与版本 针对性的 实 践 建 议，以 促 进 开 源 社 区 更 高 效 的 健 康 提交日志信息，构建了开发者的合作网络，基于此网络 发展。 他们分别分析了开发者整体活跃度以及个体开发者活 ３． １ 面向管理者 跃度的变化趋势。Ｏ Ｍａｈｏ ｎｙ等 ［１１］研究了开源社区的 对于开源软件项目的管理者来说，管理项目的版 治理模式。杨彬 ［１２］研究了开源世界的许可证机制的 本发布以及管理开发社区开发者的贡献均为及其重要 发展历史以及应用现状。Ｍｏ ｃｕｓ等 ［１３］选取两个著名 的事务。项目的版本发布管理是软件能够阶段性有序 的开源软件 Ａｐａ ｃｈｅ和 Ｍｏ ｚｉｌ ｌａ为研究对象调研了开源 

5 . １６ 计算机应用与软件 ２０２０年 软件的实际开发过程。 １）临近软件版本发布时间点前所提交的社区贡 ４． ２ 贡献评估 献的第一次评估延迟更低一些。而在软件版本发布刚 结束后所提交的社区贡献的第一次评估延迟则要高 由于开源开发者群体数量巨大，其编程水平层次 一些。 不齐，为了保证其所提交贡献的质量，开源社区需要对 ２）临近软件版本发布时间点前所提交的社区贡 其贡献进行评估，这其中会涉及到一些任务指派和推 献被接受的概率更低一些。而在版本发布后所提交的 荐等工作。卢松等 ［１４］利用信息检索技术，综合考虑了 社区贡献被接受的概率要高一些。 开发者的影响力因子以及评估的时间衰减的因素，为 另外，根据实验结果我们还对开源软件管理者以 每一个新提交的开源贡献自动推荐最合适的评估者。 及贡献者的行为模式以及协作理念提出了针对性的 张文等 ［１５］提出一种基于 Ｋ最近邻算法的缺陷修复人 建议。 推荐方法 ＯＳＤＲ，该方法首先计算给定的缺陷报告与 在将来的工作中，我们计划进一步研究开源软件 历史缺陷报告之间的文本相似度，然后利用 Ｋ最近邻 版本发布对开源社区贡献类型的接受偏好，即修复软 算法计算相似度最高的 Ｋ个历史缺陷报告及其对应 件缺陷的贡献以及实现新特征的贡献的接受率是如何 的修复人列表。Ｂｏ ｓｕ等 ［１６］研究了开发者的个人声誉 受开源软件版本发布的影响的。 是如何影响贡献评估结果的，发现核心开发者能够得 到更及时的评估反馈，并且核心开发者的评估耗时较 参 考 文 献 ［１ ７］ 短，被接受的概率也更大。Ｂｅ ｌｌ ｅｒ等 对真实开源项 ［１］ Ｌａ ｋｈａ ｎｉＫＲ，Ｗｏ ｌｆＲＧ．Ｗｈ ｙｈａ ｃｋｅ ｒｓｄ ｏｗｈ ａｔｔ ｈｅｙｄ ｏ：Ｕｎ  目的贡献评估记录数据进行了实证研究，深入分析了 ｄ ｅｒｓ ｔａｎ ｄｉｎ ｇｍｏ ｔｉ ｖａｔ ｉｏ ｎａｎ ｄｅｆ ｆｏ ｒｔｉ ｎｆｒ ｅｅ／ ｏｐｅ ｎｓｏ ｕｒｃ ｅｓｏ ｆｔ ｗａｒ ｅ 贡献评估者的实际关注点。Ｈａ ｍａｓ ａｋｉ等 ［１８］基于代码 ｐ ｒｏｊ ｅｃｔ ｓ［Ｍ］．ＭＩ ＴＰｒ ｅｓｓ ，２０ ０３． 仓库和代码审查系统构建了四个开源软件代码评估的 ［２］ Ｌａ ｋｈａ ｎｉＫ Ｒ，Ｖｏ ｎＨｉ ｐｐｅ ｌＥ．Ｈｏ ｗｏｐ ｅｎｓ ｏｕｒ ｃｅｓ ｏｆｔ ｗａｒ ｅ 公开数据库。 ｗｏ ｒｋｓ ：“ｆ ｒｅｅ ”ｕｓ ｅｒ ｔｏ ｕｓｅ ｒａｓ ｓｉｓ ｔａｎ ｃｅ［Ｍ］／／ Ｐｒｏ ｄｕｋ ｔｅｎ ｔｗｉ ｃｋ ４． ３ 软件开发管理 ｌ ｕｎｇｍｉ ｔｖｉ ｒｔ ｕｅｌ ｌｅ ｎＣｏ ｍｍｕ ｎｉｔ ｉｅ ｓ．Ｇａ ｂｌｅ ｒＶｅ ｒｌａ ｇ，２ ００４： ３０３－ ３ ３９． 软件开发往往需要多个开发者一起协同完成某项 ［３］ Ｊ ｅｒｇ ｅｎｓ ｅｎＣ，Ｓ ａｒｍａＡ，Ｗａ ｇｓｔ ｒｏｍ Ｐ．Ｔｈ ｅｏｎ ｉｏｎｐ ａｔｃ ｈ：ｍｉ  任务，同时开发过程中会遇到需求变更、人员流动等问 ｇ ｒａｔ ｉｏ ｎｉｎｏ ｐｅｎｓ ｏｕｒ ｃｅｅ ｃｏｓ ｙｓｔ ｅｍｓ［Ｃ］／／ Ｐｒｏ ｃｅｅ ｄｉｎ ｇｓｏ ｆｔｈ ｅ 题，因此为了保证项目能够有效推进，需要对软件的开 １ ９ｔｈＡＣＭ Ｓ ＩＧＳ ＯＦＴｓ ｙｍｐ ｏｓｉ ｕｍａ ｎｄｔ ｈｅ１ ３ｔｈＥｕ ｒｏｐ ｅａｎｃ ｏｎ 发过程和开发规划进行管理。杨?等 ［１９］调研了软件 ｆ ｅｒｅ ｎｃｅｏ ｎＦｏ ｕｎｄ ａｔｉ ｏｎｓｏ ｆｓｏ ｆｔ ｗａｒ ｅｅｎ ｇｉｎ ｅｅｒ ｉｎｇ ．ＡＣＭ，２ ０１１： 开发过程中开发团队常见的沟通与协调活动，并分析 ７ ０－８ ０． 了能够影响开发团队沟通与协调活动的项目特征以及 ［４］ Ｖｏ ｎＫｒ ｏｇｈＧ，Ｓ ｐａｅ ｔｈＳ，Ｌａ ｋｈａ ｎｉＫ Ｒ．Ｃｏ ｍｍｕ ｎｉｔ ｙ，ｊ ｏｉ ｎ 沟通 协 调 活 动 与 项 目 的 输 出 之 间 的 关 系。 邹 筱 菁 ｉ ｎｇ，ａ ｎｄｓ ｐｅｃ ｉａｌ ｉｚ ａｔｉ ｏｎｉ ｎｏｐ ｅｎｓ ｏｕｒ ｃｅｓ ｏｆｔ ｗａｒ ｅｉｎ ｎｏｖ ａｔｉ ｏｎ：ａ 等 ［２０］深入分析了基于 Ｄｅ ｖＯｐ ｓ开发模式下的软件开发 ｃ ａｓｅｓ ｔｕｄ ｙ［Ｊ ］．Ｒｅ ｓｅａ ｒｃｈｐ ｏｌｉ ｃｙ， ２００ ３，３ ２（７）： １２１ ７－１ ２４１． ［２ １］ 流程，并对相应步骤给出了规范示例。王晓凯 探讨 ［５］ Ｍａ ｄｅｙＧ，Ｆｒ ｅｅｈＶ，Ｔｙ ｎａｎＲ．Ｕｎ ｄｅｒ ｓｔ ａｎｄ ｉｎｇｏ ｓｓａ ｓａｓ ｅｌｆ  了在项目管理过程里出现的常见问题并给出了针对性 ｏ ｒｇａ ｎｉｚ ｉｎｇｐ ｒｏｃ ｅｓｓ ［Ｃ］／／ ２ｎｄＷｏ ｒｋｓ ｈｏｐｏ ｎＯｐ ｅｎＳ ｏｕｒ ｃｅＳ ｏｆｔ  的解决策略。Ｍü ｎｃｈ等 ［２ ２］ 从软件开发过程的基本概念 ｗａ ｒｅＥｎ ｇｉｎ ｅｅｒ ｉｎｇａ ｔｔｈ ｅ２４ｔ ｈＩｎ ｔｅｒ ｎａｔ ｉｏ ｎａｌＣｏ ｎｆｅ ｒｅｎ ｃｅｏ ｎ 入手， 着重介绍了现在具有代表性的集中软件开发过 Ｓ ｏｆｔ ｗａｒ ｅＥｎ ｇｉｎ ｅｅｒ ｉｎｇ （ＩＣＳ Ｅ２０ ０２）．２ ００２：１ ３０－１ ３１． ［６］ Ｓ ａｌｉ ｕＯ，Ｒｕ ｈｅＧ．Ｓ ｏｆｔ ｗａｒ ｅｒｅ ｌｅａ ｓｅｐ ｌａｎ ｎｉｎ ｇｆｏ ｒｅｖ ｏｌｖ ｉｎｇｓ ｙｓ 程模型以及每一种模型所需的执行方法和必要工具。 ｔ ｅｍｓ ［Ｊ］．Ｉ ｎｎｏ ｖａｔ ｉｏ ｎｓｉ ｎＳｙ ｓｔｅ ｍｓａ ｎｄＳ ｏｆｔ ｗａｒ ｅＥｎ ｇｉｎ ｅｅｒ ｉｎｇ ， ２ ００５，１（２）： １８９－２ ０４． ５ 结 语 ［７］ Ｒｕ ｈｅＧ，Ｓ ａｌｉ ｕＭ Ｏ．Ｔｈ ｅａｒ ｔａｎ ｄｓｃ ｉｅｎ ｃｅｏ ｆｓｏ ｆｔ ｗａｒ ｅｒｅ ｌｅａ ｓｅ ｐ ｌａｎ ｎｉｎ ｇ［Ｊ ］．Ｉ ＥＥＥＳ ｏｆｔ ｗａｒ ｅ，２ ００５，２ ２（６）： ４７－５ ３． 本文 选 取 了 Ｇｉ ｔＨｕｂ平 台 上 三 个 流 行 开 源 软 件 ［８］ 杨波，于茜，张伟，等．Ｇｉ ｔＨｕ ｂ开源软件开发过程中影响因 ｂｏ ｏｔｓ ｔｒ ａｐ、ｓ ｃｉｋｉ ｔ ｌｅａ ｒｎ以及 ｅ ｌａｓ ｔｉ ｃｓｅ ａｒｃ ｈ作为实验对象， 素的相关性分析［Ｊ ］．软件学报， ２０１ ７，２ ８（６）： １３３ ０－１ ３４２． 采集了这些项目的软件版本发布数据以及社区贡献数 ［９］ 孙晶，刘丽丽．开源软件可信性评价方法［Ｊ ］．计算机工程 据。基于采集的数据，对开源软件版本发布与开源社 与设计， ２０１ ７（１ ２）： ９０－９ ６． 区贡献的评估展开了实证研究。重点分析了开源软件 ［１０］ 刘雅新，吴高艳，何鹏．开源软件社区中开发者活跃度特 版本发布对开源贡献第一次评估反馈、开源贡献接受 性分析［Ｊ ］．软件导刊， ２０１ ７（９）： １６８－１ ７０， １７３． 概率的影响，我们发现： （下转第 ２４页） 

6 . ２４ 计算机应用与软件 ２０２０年 ［２］ Ｈｕ ａｎｇＹ，Ｋｉ ｎｔａ ｌａＣ，Ｋｏ ｌｅｔ ｔｉ ｓＮ，ｅ ｔａｌ ．Ｓｏ ｆｔ ｗａｒ ｅｒｅ ｊｕｖ ｅ ｏ ｎＥｍｅ ｒｇｉ ｎｇＴｅ ｃｈｎ ｏｌｏ ｇｉｅ ｓｉｎＣｏ ｍｐｕ ｔｉｎ ｇＳｙ ｓｔｅ ｍｓ，２ ０１４，１ ０ ｎ ａｔｉ ｏｎ：ａ ｎａｌ ｙｓｉ ｓ， ｍｏ ｄｕｌ ｅａｎ ｄａｐ ｐｌｉ ｃａｔ ｉｏ ｎｓ［Ｃ］／／ Ｔｗｅ ｎｔｙ  （１）： １－２ ３． Ｆｉ ｆｔ ｈＩｎ ｔｅｒ ｎａｔ ｉｏ ｎａｌＳ ｙｍｐ ｏｓｉ ｕｍｏ ｎＦａ ｕｌｔ Ｔｏ ｌｅｒ ａｎｔＣｏ ｍｐｕ ｔｉｎ ｇ． ［１７］ Ｙｉ ｎＹ Ｃ，Ｃｏ ｏｌｅ ｎＦＰＡ，Ｃｏ ｏｌｅ ｎＭａ ｔｕｒ ｉＴ．Ａｎｉ ｍｐｒ ｅｃｉ ｓｅ Ｄｉ ｇｅｓ ｔｏｆＰａ ｐｅｒ ｓ，１ ９９５：３ ８１－３ ９０． ｓ ｔａｔ ｉｓ ｔｉ ｃａｌｍｅ ｔｈｏ ｄｆｏ ｒａｃ ｃｅｌ ｅｒａ ｔｅｄｌ ｉｆ ｅｔｅ ｓｔｉ ｎｇｕ ｓｉｎ ｇｔｈ ｅｐｏ ｗｅｒ  ［３］ Ｔｏ ｒｑｕ ａｔｏＭ，Ａｒ ａｕｊ ｏＪ，Ｕｍｅ ｓｈＩ ，ｅｔａ ｌ．Ｓ ｗａｒ ｅ：ａｍｅ ｔｈｏ ｄｏｌ ｏ Ｗｅ ｉｂｕ ｌｌｍｏ ｄｅｌ ［Ｊ］．Ｒｅ ｌｉ ａｂｉ ｌｉ ｔｙＥｎ ｇｉｎ ｅｅｒ ｉｎｇ＆Ｓ ｙｓｔ ｅｍＳ ａｆｅ ｔｙ， ｇ ｙｆｏ ｒｓｏ ｆｔ ｗａｒ ｅａｇ ｉｎｇａ ｎｄｒ ｅｊｕ ｖｅｎ ａｔｉ ｏｎｅ ｘｐｅ ｒｉｍｅ ｎｔｓ ［Ｊ］．ＪＩ ｎｆ ２ ０１７，１ ６７：１ ５８－１ ６７． Ｓ ｙｓｔＥｎ ｇＭａ ｎａｇ ，２０ １８，３（２）：１ ５． ［１８］ Ｓ ｒｉｖ ａｓｔ ａｖａＮ，Ｈｉ ｎｔｏ ｎＧ，Ｋｒ ｉｚ ｈｅｖ ｓｋｙＡ，ｅ ｔａｌ ．Ｄｒ ｏｐｏ ｕｔ：ａ ［４］ Ａｒ ａｕｊ ｏＪ，Ｍａ ｔｏｓＲ，Ｍａ ｃｉｅ ｌＰ，ｅ ｔａｌ ．Ｓｏ ｆｔ ｗａｒ ｅｒｅ ｊｕｖ ｅｎａ ｔｉ ｏｎｉ ｎ ｓ ｉｍｐ ｌｅｗａ ｙｔｏｐ ｒｅｖ ｅｎｔｎ ｅｕｔ ａｌｎ ｅｔｗｏ ｒｋｓｆ ｒｏｍｏ ｖｅｒ ｆｉ ｔｔ ｉｎｇ［Ｊ ］． ｅ ｕｃａ ｌｙｐ ｔｕｓｃ ｌｏｕ ｄｃｏ ｍｐｕ ｔｉｎ ｇｉｎ ｆｒａ ｓｔｒ ｕｃｔ ｕｒｅ ：Ａ ｍｅ ｔｈｏ ｄｂａ ｓｅｄ Ｊ ｏｕｒ ｎａｌｏ ｆＭａ ｃｈｉ ｎｅＬｅ ａｒｎ ｉｎｇＲｅ ｓｅａ ｒｃｈ， ２０１ ４，１ ５：１ ９２９－１ ９５８． ｏ ｎｔｉ ｍｅｓ ｅｒｉ ｅｓｆ ｏｒｅ ｃａｓ ｔｉ ｎｇａ ｎｄｍｕ ｌｔｉ ｐｌｅｔ ｈｒｅ ｓｈｏ ｌｄｓ ［Ｃ］／／ ２０１ １  Ｉ ＥＥＥＴｈ ｉｒｄＩ ｎｔｅ ｒｎａ ｔｉ ｏｎａ ｌＷｏ ｒｋｓ ｈｏｐｏ ｎＳｏ ｆｔ ｗａｒ ｅＡｇ ｉｎｇａ ｎｄ （上接第 １６页） Ｒｅ ｊｕｖ ｅｎａ ｔｉ ｏｎ．Ｉ ＥＥＥ，２ ０１１：３ ８－４ ３． ［１１］ Ｏ Ｍａｈ ｏｎｙＳ，Ｆｅ ｒｒａ ｒｏＦ．Ｔｈ ｅｅｍｅ ｒｇｅ ｎｃｅｏ ｆｇｏ ｖｅｒ ｎａｎ ｃｅｉ ｎａｎ ［５］ 梁佩．基于 ＷＥＢ技术的软件老化趋势预测研究［Ｄ］．哈 ｏ ｐｅｎｓ ｏｕｒ ｃｅｃ ｏｍｍｕ ｎｉｔ ｙ［Ｊ ］．Ａｃ ａｄｅ ｍｙｏ ｆＭａ ｎａｇ ｅｍｅ ｎｔＪ ｏｕｒ  尔滨：哈尔滨工程大学， ２０１ ３． ｎ ａｌ，２ ００７，５ ０（５）： １０７ ９－１ １０６． ［６］ Ｊ ｉａＳ，Ｈｏ ｕＣ，Ｗａ ｎｇＪ ．Ｓｏ ｆｔ ｗａｒ ｅａｇ ｉｎｇａ ｎａｌ ｙｓｉ ｓａｎ ｄｐｒ ｅｄｉ ｃ ［１２］ 杨彬．开源软件许可证研究［Ｄ］．济南：山东大学， ２００ ８． ｔ ｉｏ ｎｉｎａｗｅ ｂｓｅ ｒｖｅ ｒｂａ ｓｅｄｏ ｎｍｕ ｌｔｉ ｐｌｅｌ ｉｎｅ ａｒｒ ｅｇｒ ｅｓｓ ｉｏｎａ ｌｇｏ  ［１３］ Ｍｏ ｃｋｕ ｓＡ．Ｔｗｏｃ ａｓｅｓ ｔｕｄ ｉｅｓｏ ｆｏｐ ｅｎｓ ｏｕｒ ｃｅｓ ｏｆｔ ｗａｒ ｅｄｅ ｖｅｌ  ｒ ｉｔ ｈｍ［Ｃ］／／ ＩＥＥＥ Ｉ ｎｔｅ ｒｎａ ｔｉ ｏｎａ ｌＣｏ ｎｆｅ ｒｅｎ ｃｅｏ ｎＣｏ ｍｍｕ ｎｉｃ ａ ｏ ｐｍｅ ｎｔ：Ａｐ ａｃｈ ｅａｎ ｄＭｏ ｚｉｌ ｌａ［Ｊ ］．ＡＣＭ Ｔｒ ａｎｓ ａｃｔ ｉｏ ｎｓｏ ｎＳｏ ｆｔ  ｔ ｉｏ ｎＳｏ ｆｔ ｗａｒ ｅ＆Ｎｅ ｔｗｏ ｒｋｓ ．ＩＥＥＥ，２ ０１７． ｗａ ｒｅＥｎ ｇｉｎ ｅｅｒ ｉｎｇａ ｎｄＭｅ ｔｈｏ ｄｏｌ ｏｇｙ （ＴＯＳ ＥＭ）． ２００ ２，１ １（３）： ［７］ 渊岚．基于人工神经网络的软件系统老化预测研究［Ｄ］． ３ ０９－３ ４６． 西安：西安建筑科技大学， ２０１ ６． ［１４］ 卢松，杨达，胡军，等．基于时间和影响力因子的 Ｇｉ ｔｈｕ ｂ ［８］ 闫永权，郭平．使用混合模型预测 Ｗｅ ｂ服务器中的资源 Ｐｕ ｌｌＲｅ ｑｕｅ ｓｔ评审人推荐［Ｊ ］．计算机系统应用，２ ０１６，２ ５ 消耗［Ｊ ］．计算机科学， ２０１ ６，４ ３（１ ０）： ４７－５ ２． （１ ２）： １５５－１ ６１． ［９］ 梁天新，杨小平，王良，等．记忆神经网络的研究与发展 ［１５］ 张文，李自强，杜宇航，等．ＯＳ ＤＲ：一种开源软件的缺陷修 ［Ｊ ］．软件学报， ２０１ ７，２ ８（１ １）： ２９０ ５－２ ９２４． 复人推荐方法［Ｊ ］．计算机应用与软件， ２０１ ７，３ ４（８）： ７－ ［１０］ Ｌａ ｉＧ，Ｃｈ ａｎｇＷ Ｃ，Ｙａ ｎｇＹ，ｅ ｔａｌ ．Ｍｏ ｄｅｌ ｉｎｇｌ ｏｎｇ ａｎ ｄ １ １，１ ０６． ｓ ｈｏｒ ｔ ｔｅｒ ｍ ｔ ｅｍｐ ｏｒａ ｌｐａ ｔｔ ｅｒｎ ｓ ｗｉ ｔｈｄ ｅｅｐｎ ｅｕｒ ａｌｎ ｅｔｗｏ ｒｋｓ ［１６］ Ｂｏ ｓｕＡ，Ｃａ ｒｖｅ ｒＪＣ．Ｉ ｍｐａ ｃｔｏ ｆｄｅ ｖｅｌ ｏｐｅ ｒｒｅ ｐｕｔ ａｔ ｉｏ ｎｏｎｃ ｏｄｅ ［Ｃ］／／ Ｔｈｅ４ １ｓｔＩ ｎｔｅ ｒｎａ ｔｉ ｏｎａ ｌＡＣＭ Ｓ ＩＧＩ ＲＣｏ ｎｆｅ ｒｅｎ ｃｅｏ ｎＲｅ  ｒ ｅｖｉ ｅｗｏ ｕｔｃ ｏｍｅ ｓｉｎＯＳ Ｓｐｒ ｏｊｅ ｃｔｓ ：ａｎｅ ｍｐｉ ｒｉ ｃａｌｉ ｎｖｅ ｓｔｉ ｇａｔ ｉｏ ｎ ｓ ｅａｒ ｃｈ＆Ｄｅ ｖｅｌ ｏｐｍｅ ｎｔｉ ｎＩｎ ｆｏｒ ｍａｔ ｉｏ ｎＲｅ ｔｒｉ ｅｖａ ｌ．ＡＣＭ， ２０１ ８： ［Ｃ］／／ Ｐｒｏ ｃｅｅ ｄｉｎ ｇｓｏ ｆｔｈ ｅ８ｔ ｈＡＣＭ／ ＩＥＥＥＩ ｎｔｅ ｒｎａ ｔｉ ｏｎａ ｌＳｙ ｍ ９ ５－１ ０４． ［１１］ Ｃｈ ｏｒｏ ｗｓｋ ｉＪＫ，Ｂａ ｈｄａ ｎａｕＤ，Ｓ ｅｒｄ ｙｕｋＤ，ｅ ｔａｌ ．Ａｔ ｔｅ ｎｔｉ ｏｎ ｐ ｏｓｉ ｕｍｏ ｎＥｍｐ ｉｒｉ ｃａｌＳ ｏｆｔ ｗａｒ ｅＥｎ ｇｉｎ ｅｅｒ ｉｎｇａ ｎｄＭｅ ａｓｕ ｒｅｍｅ ｎｔ， ｂ ａｓｅ ｄｍｏ ｄｅｌ ｓｆｏ ｒｓｐ ｅｅｃ ｈｒｅ ｃｏｇ ｎｉｔ ｉｏ ｎ［Ｃ］／／ Ａｄｖ ａｎｃ ｅｓｉ ｎｎｅ ｕ ２ ０１４． ｒ ａｌｉ ｎｆｏ ｒｍａ ｔｉ ｏｎｐ ｒｏｃ ｅｓｓ ｉｎｇｓ ｙｓｔ ｅｍｓ ．２０ １５：５ ７７－５ ８５． ［１７］ Ｂｅ ｌｌ ｅｒＭ，Ｂａ ｃｃｈ ｅｌｌ ｉＡ，Ｚａ ｉｄｍａ ｎＡ，ｅ ｔａｌ ．Ｍｏ ｄｅｒ ｎｃｏ ｄｅｒ ｅ ［１２］ Ｇｏ ｏｄｆ ｅｌ ｌｏ ｗＩ，Ｂｅ ｎｇｉ ｏＹ，Ｃｏ ｕｒｖ ｉｌ ｌｅＡ．Ｄｅ ｅｐｌ ｅａｒ ｎｉｎ ｇ［Ｍ］． ｖ ｉｅｗｓｉ ｎｏｐ ｅｎ ｓｏｕ ｒｃｅｐ ｒｏｊ ｅｃｔ ｓ：Ｗｈ ｉｃｈｐ ｒｏｂ ｌｅｍｓｄ ｏｔｈ ｅｙｆ ｉｘ？ ＭＩ Ｔｐｒ ｅｓｓ ，２０ １６． ［Ｃ］／／ １１ｔ ｈＷｏ ｒｋｉ ｎｇＣｏ ｎｆｅ ｒｅｎ ｃｅｏ ｎＭｉ ｎｉｎ ｇＳｏ ｆｔ ｗａｒ ｅＲｅ ｐｏｓ ｉ ［１３］ Ｓ ａｋＨ，Ｓ ｅｎｉ ｏｒＡ，Ｂｅ ａｕｆ ａｙｓＦ．Ｌｏ ｎｇＳ ｈｏｒ ｔ Ｔｅｒ ｍ Ｍｅ ｍｏｒ ｙ ｔ ｏｒｉ ｅｓ．ＡＣＭ，２ ０１４． Ｂａ ｓｅｄＲｅ ｃｕｒ ｒｅｎ ｔＮｅ ｕｒａ ｌＮｅ ｔｗｏ ｒｋＡｒ ｃｈｉ ｔｅ ｃｔｕ ｒｅｓｆ ｏｒＬａ ｒｇｅＶｏ  ［１８］ Ｈａ ｍａｓ ａｋｉＫ，Ｋｕ ｌａＲＧ，Ｙｏ ｓｈｉ ｄａＮ，ｅ ｔａｌ ．Ｗｈ ｏｄｏ ｅｓｗｈ ａｔ ｃ ａｂｕ ｌａｒ ｙＳｐ ｅｅｃ ｈＲｅ ｃｏｇ ｎｉｔ ｉｏ ｎ［ＥＢ］．ａ ｒＸｉ ｖ：１ ４０２． １１２ ８，２ ０１４： ｄ ｕｒｉ ｎｇａｃ ｏｄｅｒ ｅｖｉ ｅｗ？Ｄａ ｔａｓ ｅｔｓｏ ｆＯＳ Ｓｐｅ ｅｒｒ ｅｖｉ ｅｗｒ ｅｐｏ ｓｉｔ ｏ ３ ３８－３ ４２． ｒ ｉｅｓ ［Ｃ］／／ Ｗｏｒ ｋｉｎ ｇＣｏ ｎｆｅ ｒｅｎ ｃｅｏ ｎＭｉ ｎｉｎ ｇＳｏ ｆｔ ｗａｒ ｅＲｅ ｐｏｓ ｉｔ ｏ ［１４］ Ｃｏ ｒｔｅ ｚＢ，Ｃａ ｒｒｅ ｒａＢ，Ｋｉ ｍＹＪ ，ｅｔａ ｌ．Ａｎａ ｒｃｈ ｉｔｅ ｃｔｕ ｒｅｆ ｏｒｅ  ｒ ｉｅｓ ．２０ １３． ｍｅ ｒｇｅ ｎｃｙｅ ｖｅｎ ｔｐｒ ｅｄｉ ｃｔ ｉｏ ｎｕｓ ｉｎｇＬＳ ＴＭ ｒ ｅｃｕ ｒｒｅ ｎｔｎ ｅｕｒ ａｌｎ ｅｔ ［１９］ 杨?，王二平．软件开发管理中的沟通与协调问题研究 ｗｏ ｒｋｓ ［Ｊ］．Ｅｘ ｐｅｒ ｔＳｙ ｓｔｅ ｍｓｗｉ ｔｈＡｐ ｐｌｉ ｃａｔ ｉｏ ｎｓ，２ ０１８，９ ７：３ １５ ［Ｊ ］．中国管理科学， ２００ ４，１ ２（３）： １４１－１ ４８． －３ ２４． ［２０］ 邹筱菁，柯林．基于 Ｄｅ ｖＯｐ ｓ的软件开发管理模式［Ｊ ］．数 ［１５］ Ｓ ｈｅｎＴ，Ｚｈ ｏｕＴ，Ｌｏ ｎｇＧ，ｅ ｔａｌ ．Ｄｉ ｓａｎ：Ｄｉ ｒｅｃ ｔｉ ｏｎａ ｌｓｅ ｌｆ ａｔ 字技术与应用， ２０１ ６（１ １）： １８４－１ ８７． ｔ ｅｎｔ ｉｏ ｎｎｅ ｔｗｏ ｒｋｆ ｏｒｒ ｎｎ／ ｃｎｎ ｆｒ ｅｅｌ ａｎｇ ｕａｇ ｅｕｎ ｄｅｒ ｓｔ ａｎｄ ｉｎｇ ［２１］ 王 晓 凯．浅 谈 软 件 开 发 管 理 策 略 ［Ｊ ］．科 技 资 讯，２ ００９ ［Ｃ］／／ Ｔｈｉ ｒｔ ｙＳ ｅｃｏ ｎｄＡＡＡＩＣｏ ｎｆｅ ｒｅｎ ｃｅｏ ｎＡｒ ｔｉ ｆｉ ｃｉ ａｌＩ ｎｔｅ ｌｌ ｉ （１ １）： ２０４． ｇ ｅｎｃ ｅ．２ ０１８． ［２２］ Ｍü ｎｃｈＪ ，Ａｒ ｍｂｒ ｕｓｔＯ，Ｋｏ ｗａｌ ｃｚｙ ｋＭ，ｅ ｔａｌ ．Ｓｏ ｆｔ ｗａｒ ｅｐｒ ｏｃｅ ｓｓ ［１６］ Ｚｈ ａｏＪ ，Ｊｉ ｎＹ，Ｔｒ ｉｖｅ ｄｉＫ Ｓ，ｅ ｔａｌ ．Ｓｏ ｆｔ ｗａｒ ｅｒｅ ｊｕｖ ｅｎａ ｔｉ ｏｎ ｄ ｅｆｉ ｎｉｔ ｉｏ ｎａｎ ｄ ｍａ ｎａｇ ｅｍｅ ｎｔ［Ｍ］／／ Ｔｈｅ Ｆｒ ａｕｎ ｈｏｆ ｅｒＩ ＥＳＥ ｓ ｃｈｅ ｄｕｌ ｉｎｇｕ ｓｉｎ ｇａｃ ｃｅｌ ｅｒａ ｔｅｄｌ ｉｆ ｅｔｅ ｓｔｉ ｎｇ［Ｊ ］．ＡＣＭ Ｊ ｏｕｒ ｎａｌ Ｓ ｅｒｉ ｅｓｏ ｎＳｏ ｆｔ ｗａｒ ｅａｎ ｄＳｙ ｓｔｅ ｍｓＥｎ ｇｉｎ ｅｅｒ ｉｎｇ ．Ｓｐ ｒｉｎ ｇｅｒ ，２０ １２．