基于版本更新日志的移动应用演化趋势自动分析

钟仁毅 王 翀 梁 鹏 罗 忠

1(武汉大学计算机学院 武汉 430072)2(海军工程大学舰船与海洋学院 武汉 430033)

近年来，移动应用程序数量的增长越来越快.截至2020年第1季度，Android应用商店Google Play为用户提供的移动应用数量已达256万个，苹果应用商店Apple App Store也为iOS用户提供了185万个应用供其下载和使用[1].为了满足用户不断变化的新需求并在激烈的市场竞争中保持优势，无论新开发的移动应用还是已有移动应用的新版本，其发布数量均在不断增长，为开发者及时了解移动应用的重要更新、探索移动应用的演化趋势以及把握移动应用的市场动态带来了挑战.

移动应用的版本更新日志是由移动应用开发者在移动应用商店中以标准格式提供的短文本，其发布时间和周期与移动应用的新版本完全一致，描述了移动应用当前版本的主要或重要更新，表征了移动应用演化的部分特点.目前，许多研究者已将移动应用的用户评论[2-4]或不同版本的移动应用源码[5]用于移动应用的维护和演化分析.尽管用户评论和版本更新记录都是移动应用商店中公开可爬取的文本信息，但后者所包含的无用信息更少，使用的词汇和术语相对规范且无二义性，更易于通过人工或自动的方式处理和分析.与移动应用历史版本的安装包或源码相比，版本更新记录中提供的更新内容更加直观且易于获取，更便于开发人员快速了解移动应用的发展趋势和市场动态.因此，移动应用的版本更新记录作为一种公开的数据源，可用于快速分析移动应用的演化特点，了解移动应用的发展趋势.

目前，已有部分研究将移动应用的版本更新记录用于移动应用的分析.例如，文献[6]使用移动应用的版本更新日志来识别和确定应用评论中提出的问题.Hassan等人[7]对主流安卓应用的紧急更新(emergency updates)进行了实证研究，而该研究对版本更新记录的分析仅用于确定它们是否为安卓应用的紧急更新提供了有用信息.与该研究的不同之处在于，本文的探索性研究仅将移动应用的版本更新记录作为研究对象和实验数据，拟从需求工程的角度探索移动应用更新的特点和趋势.本文的前期研究已对3 000条人工标注的版本更新条目进行了初步分析，从功能和非功能需求的角度探索了移动应用的演化特点[8].然而，前期研究仅基于有限数量的版本更新日志及其人工分类标签.在前期研究基础上，本文将从2个方面设计并完成基于版本更新日志的移动应用演化趋势分析研究：1)探讨使用监督式机器学习算法从版本更新日志中自动识别不同类型的需求的可行性；2)使用规模更大的数据集对移动应用的演化趋势进行分析.具体来说，本文的主要贡献有3个方面：

1) 为了减少从版本更新日志中识别出不同类型需求所需的时间和人力成本，引入监督式机器学习算法，用以在数量庞大的移动应用版本更新日志中自动预测特定类型的需求.

2) 选择朴素贝叶斯(Naïve Bayes, NB)、随机森林(random forest, RF)和J48这3种监督式机器学习算法作为候选的版本更新日志自动分类算法，并设计了一系列实验对上述3种算法的性能进行评估，找出最适合对版本更新记录进行自动分类的机器学习算法.

3) 使用最适合对版本更新记录进行自动分类的监督式机器学习算法，完成版本更新日志中特定需求类型的自动预测和版本更新条目的自动分类，并基于自动分类结果分析移动应用的演化趋势.

1 相关工作

在发布工程(release engineering)领域，Web及桌面软件的发布规划研究和工程设计已较为成熟，而面向移动应用的发布工程研究则在近几年才受到软件工程和移动应用领域的关注[9-10].

目前，许多研究主要使用软件的用户评论和源码作为实验和分析的数据源.例如，通过对移动应用的用户评论进行分析以探索其对需求获取和软件演化的重要性[3-4,11]，或者对用户评论进行语义分析进行项目推荐[12].特别是，在移动应用领域，仅有少量实证研究从开发人员的角度使用并分析软件的版本更新日志.其中，Nayebi等人开展的调查研究探索了移动应用开发人员采用何种方法对版本进行组织，以及在此过程中应用了哪些发布策略[10].文献[10]的作者发现，50%参与该调查研究的开发人员为移动应用制定了明确的发布策略.Mcilroy等人[13]对30个移动应用类别中排名前10 713个移动应用的更新频率进行了实证分析.其研究结果指出，14%更新频繁的移动应用排名较高，但其中45%的移动应用未向用户提供关于更新的任何有效信息.Hassan等人在文献[7]中分析了Google Play中1 000个移动应用的紧急更新，用于确定应用的更新模式及其对用户体验的影响.研究结果表明，移动应用的大部分紧急更新都是由简单错误造成的，开发人员应避免这类紧急更新以改善用户体验.Nayebi等人[14]在2018年进行的另一项实证研究对开发人员如何考虑在移动应用中删除和添加功能进行了探索.这一研究主要基于Lehman的软件演化定律，即：程序的功能必须随时间的推移而增加，以保持用户满意度.然而，Nayebi的这项研究发现，在移动应用领域中，开发人员认为“删除已有功能与增加新功能同样重要，或比增加新功能更加重要”[14].

在对从移动应用商店收集的数据进行自动分类方面，许多研究已经成功地将监督机器学习算法应用于应用评论中的需求识别和分类[7,15-18].特别是，文献[15]和文献[17]从需求工程的角度对用户评论进行了处理，致力于将移动应用的评论自动分类为功能需求(functional requirements, FR)和特定类型的非功能需求(non-functional requirements, NFR).与移动应用的用户评论相比，版本更新日志由开发人员提供，所包含的无用信息相对较少.这一差异使得在用户评论自动分类上表现最优的分类器[7-8]可能在版本更新记录自动分类上无法表现出最优的性能.因此，需要在移动应用版本更新日志的数据集上评估监督式机器学习算法的分类效果，便于以半自动的方式为移动应用的演化趋势分析提供服务.

2 研究设计

2.1 研究问题

本文设计了2个研究问题(research question， RQ)，从移动应用版本更新日志所属的需求类型这一角度，探索如何根据版本更新日志对移动应用的更新趋势进行分析.

问题1.哪些技术或方法可有效用于移动应用版本更新日志的自动分类？

问题1原理.在文献[15，19]中，多种监督式机器学习算法已被有效用于对移动应用的用户评论进行自动分类.故理论上，同属于短文本的移动应用更新日志也可使用监督式学习算法进行自动分类，以减少人工分类的时间开销.该研究问题旨在对已有研究中分类效果较优的机器学习算法进行性能评估，探索哪种算法能更准确地对移动应用的版本更新日志进行自动分类，进而为基于版本更新日志的移动应用演化趋势自动分析提供具有优势的技术支持.

问题2.从需求类型的角度对移动应用的版本更新日志进行分析，其结果揭示了移动应用演化的哪些特点？

作为移动应用演化的表现形态之一，版本更新日志是由开发人员在移动应用库中发布的一组短文本，通常描述了移动应用当前版本中最重要的变化.为了保持并进一步增大移动应用的市场占有率，开发人员往往对版本更新日志中的内容进行了精挑细选，以有效表征该应用的重要和关键改进.本文将通过2个子研究问题对移动应用的演化特点进行分析：

问题2.1.根据版本更新日志，开发者在更新移动应用时着重考虑的是哪种类型的需求？

问题2.1原理.该研究问题有助于分析哪种需求类型(功能需求、非功能需求或某种特定的非功能需求)主导了移动应用的更新，进而探索这类需求类型在不同移动应用类别中的关注度差异及其随时间的变化趋势.

问题2.2.从版本更新日志所属需求类型的角度来看，移动应用演化的热点有哪些？这些更新热点随时间有何变化？

问题2.2原理.该研究问题进一步从不同需求类型的角度抽取移动应用更新的热点，有助于分析移动应用更新热点的变化趋势.

2.2 数据采集

本文所使用的数据来源于本文作者在前期研究[8]中收集和使用的移动应用版本更新日志，数据采集时间为2019年3月.在数据采集任务正式开始前，作者对主流的移动应用商店中不同类别移动应用的版本更新记录进行了预调研，并根据预调研的结果制定了2个数据采集策略：1)考虑移动应用版本更新记录采集的便捷性与可行性，选择苹果App Store作为数据采集源；2)选择社交(Social Networking)、旅游(Travel)和阅读(Books)这3个类别移动应用的版本更新记录作为待收集和分析的对象.第2个采集策略选择3个移动应用的原因为：1)根据苹果App Store应用市场中各类别应用数量排行[20]，游戏类应用占比最多(21.86%)，新闻类占比最少(1.83%).过高或过低的样本占比可能对移动应用演化趋势分析产生较大影响，故选择移动应用数量占比在2%～6%这个区间范围的应用类别较为合适.2)所选类别的移动应用版本更新频次不能过低，版本更新日志的内容应较为丰富且有价值，有助于基于版本更新日志对移动应用演化趋势开展探索性分析.需要说明的是，匹配上述2个采集策略的移动应用类别较多，作者为开展本文的探索性研究随机选择出的3个类别为社交(Social Networking)、旅游(Travel)和阅读(Books)，样本数据有一定的多样性，但仅能用于部分探索移动应用演化的特点和趋势，不能代表整个移动应用市场的发展动态.

前期研究[8]在进行正式的数据采集时，首先浏览了苹果App Store六个地区(亚洲、北美洲、欧洲、南美洲、非洲和大洋洲)的移动应用商店中社交、旅游和阅读这3个类别移动应用的版本更新日志[8].其次，分别爬取了在每个地区3个类别中排名前10的免费移动应用的版本更新日志；接着，排除了重复、更新日志的数量低于30以及近3年无版本更新日志的移动应用；最终，保留了120个移动应用(社交类40个、旅游类50个、阅读类30个)的8 647个版本更新日志.由于一个版本更新日志通常包含多条更新条目，上述120个移动应用发布的更新条目共计17 024条.

在已收集的版本更新日志中，“本次更新”和“近期更新”的内容往往有较大程度的重复.为消除冗余，本文制定了筛选原则：若本次更新中的版本更新条目与“近期更新”中的更新条目相同，则保留“本次更新”中的更新条目.将这一筛选原则应用于120个移动应用的17 024条版本更新条目，可得到8 325条不重复的版本更新条目组成的初始数据集.

为了平衡不同类别移动应用所提供的版本更新条目的数量，作者从初始数据集中选择了60个移动应用(在社交、旅游、阅读类别中分别随机选择20个移动应用)的版本更新条目，构建了本文研究所需的数据集.同时，考虑版本更新日志的稀疏性和部分缺失，剔除了2013年之前和2019年之后发布的版本更新条目.最终，得到的数据集由60个应用的6 527条版本更新条目组成，其发布时间区间为2014年至2018年.其中，旅游类的版本更新条目为2 782条，社交类的为2 666条，阅读类的为1 079条.

2.3 数据集划分

根据前期研究的经验，在有限的时间内人工标记和分析6 527条版本更新条目是一项非常耗时的任务.因此，我们从6 527条版本更新条目中选择了3 000条(社交、旅游、阅读类分别随机选择1 000条)进行人工标注和分类，用以训练和评估监督式分类算法；而其余的3 527条将用评估结果中最有效的监督式分类算法进行自动分类.

2.4 数据标注

为提高人工标注的准确性，本文采用了Kripp-endorff等人[21]提出的先验编码(priori coding)方法进行人工标注，使定性分析的结果更加丰富[22].本文的人工标注过程由2名计算机专业的本科生(含第1作者)完成；标注结果的一致性校验由标注者与第2作者和第3作者共同完成，标注结果的正确性校验由第2作者和第3作者共同完成.具体的标注过程如下：

首先，作者与2位标注者一起对拟采用的分类标准(ISO 25010[23])进行了解释与讨论.接着，2名标注者对120条(社交、旅游、阅读类分别随机选择40条)版本更新条目进行了独立的人工预标注，分别耗时30 min和35 min，2人标注结果的内部一致性[17]为63%.2名标注者与第2作者和第3作者对37%不一致的标注结果进行了讨论并达成一致后，制定了一个人工标注指南，以帮助标注者提高人工分类的准确性.之后，重新选择了500条更新条目进行第2轮试标注.经统计，第2轮试标注的内部一致性为73.8%.2名标注者与第2作者和第3作者对第2轮中不一致的人工分类结果进行讨论并达成一致后，对人工标注指南进行了更新.最终，2位标注者依据该指南对3 000条更新条目进行了标注并达成一致意见.为降低人工标注的准确性对后续版本更新日志自动分类结果准确性的影响，第2作者和第3作者分别从数据集中随机抽取了5%进行标注结果的正确性校验，以确保人工标注的质量.

在人工标注的过程中，绝大多数移动应用的版本更新条目只提及1种需求类型，但仍有少量(343 000)更新条目的内容涉及多种需求类型.为确保1条更新条目仅包含1种需求类型的标签以便对监督式分类器进行训练，作者将这34条更新条目进行了手动拆分，故人工标注的数据集最终由3 034条移动应用的版本更新条目构成.

本文采用的分类标准ISO 25010定义了8种类型的NFR：功能适用性(Functional Suitability)、性能效率(Performance Efficiency)、兼容性(Compati-bility)、可用性(Usability)、可靠性(Reliability)、安全性(Security)、可维护性(Maintainability)和可移植性(Portability).在对3 034条版本更新条目进行人工标注时，未发现提及“功能适用性”和“可维护性”这2类非功能需求的更新条目.因此，本文仅考虑ISO 25010中定义的其余6种NFR类型和FR共7种与需求类型相关的类别.此外，本文还定义了类别“其他”以归类不能分为以上7种类型的更新条目.例如，对用户支持的感谢以及与需求无关的更新条目(“keep the good work”或“please continue to pay attention”)，或是未指明具体缺陷仅声明“对部分问题进行了修复”(“Bug fixed”)的版本更新条目.表1列举了本文考虑的8种类型(即“性能效率”“兼容性”“可用性”“可靠性”“安全性”“可移植性”“功能需求”和“其他”)及其相应示例.

Table 1 Exemplary App Changes of Eight Types表1 8种类型的更新记录示例

2.5 数据预处理

本文使用Weka 3.7对原始数据进行预处理，具体流程为：首先，将人工标注的3 034条版本更新条目(.csv格式)导入Weka完成数据的规范化，使用Weka中的NominalToSting函数将初始文件数据类型从Nominal转换为String.其次，使用Weka中的StringToWordVector函数进行文本向量化，生成词向量.其中，使用Snowball进行词干提取，使用MultiStopwords停用词表进行去停用词处理，选择WordTokenizer作为分词器.同时，将TFTransform和IDFTransform设置为True，使用TF-IDF进行特征词提取.

2.6 分类器的选择、训练及评估

基于已有相关研究和前期研究的实验结果，本文拟对比NB,RF和J48这3种监督式机器学习算法在自动分类移动应用版本更新日志上的性能.3种分类器的选择依据为：1)文献[24]指出，NB是一种被广泛应用的机器学习算法.同时，相关研究[15,19,25]的实验结果显示，在对移动应用用户评论这类短文本进行自动分类时，采用NB算法可以得到更准确的分类结果.2)若在文本向量化时采用TF-IDF进行用户评论特征词的提取，使用J48对用户评论进行自动分类的效果略优于NB[15].3)在我们的前期研究中[8,26]，应用RF对版本更新日志进行自动分类可得到最优的分类效果.

为评估3种算法的性能，本文实验采用十折交叉检验以减少分类器对版本更新条目中需求类型进行识别和分类的过拟合.此外，本文采用准确率(Precision)、召回率(Recall)和F值(F1)来评估上述3种分类算法的分类效果.各评估指标加权平均值为

(1)

(2)

(3)

其中，Precisioni，Recalli，F1i分别表示与需求类型i相关的版本更新条目自动分类的准确率、召回率、F值，Numberi表示隶属于该类型的版本更新日志条目数量.

2.7 热词热度计算

针对问题2.2，本文用版本更新条目中的热词表示版本更新的热点，用热词热度来表示版本更新记录中热点的受关注度.热词热度的计算公式为

(4)

其中，DegreeOfConcernsi表示与需求类型i相关的版本更新记录的热词热度，OccurrenceWij表示需求类型为i的版本更新记录中第j个特征词Wij的出现次数，j∈{1,2,…,n}(n为需求类型i的版本更新记录中热词数目)，Numberi表示与需求类型i相关的版本更新条目数.

3 实验与结果

3.1 版本更新日志自动分类的算法评估(问题1)

针对问题1，本节将根据应用3种监督式机器学习算法得到的分类结果的F值，对不同分类算法在版本更新日志自动分类中的性能进行评估，以确定最适合对版本更新日志进行自动分类的算法，探索基于版本更新日志进行移动应用演化趋势自动分析的可行性.

3.1.1 实验准备

首先，根据2.4节定义的人工标注过程完成3 034条版本更新条目的人工标注，其标注结果如图1所示.其中，1 170条(占比约为38.56%)涉及FR，1 519条(占比约为50.07%)涉及NFR，345条(占比约为11.37%)未涉及FR或NFR.进一步，在1 519条标记为NFR的更新条目中，提及“可用性”这一非功能属性的版本更新条目最多(9531 519)，占人工标记总条数的62.74%；提及“安全性”和“兼容性”的版本更新条目最少，分别为13条和40条，占人工标记总条数的0.40%和1.32%.

考虑监督式自动分类方法，如果待分类样本集的数量过小，无法对分类器进行有效和准确地训练.鉴于标注需求类别为“兼容性”和“安全性”的版本更新条目数量较少，我们将上述2个类别的更新条目并入“其他”类别，以便更好地训练分类器.也就是说，在本文的版本更新记录自动分类实验中，3种监督式自动分类方法仅用于将移动应用的版本更新条目分为6种类型：“功能需求”“性能效率”“可用性”“可靠性”“可移植性”和“其他”.

本节实验的实验环境配置如下：CPU为Intel 9100f,GPU为AMD RX580,内存为16 GB的便携计算机，操作系统版本为Windows 10 1909，实验软件为Weka3.7.

Fig. 1 Summary of 3 034 manually labeled app changes over eight types of requirements图1 3 034条人工标注更新条目在需求类型中的分布情况

3.1.2 3种算法的分类结果对比

本节将对比NB,RF和J48这3种分类算法在版本更新条目自动分类中的性能.实验数据为3.1.1节中3 034条人工标注的版本更新条目.

表2展示了上述3种算法对3 034条版本更新条目分别进行二分类(binary classifier, BC)和多分类(multi classifier, MC)时的准确率、召回率和F值.综合实验结果表明，对任意一种需求类型而言，3种机器学习算法的二分类效果均明显优于多分类.同时，从分类算法的角度可得出结论：NB和RF分别在二分类和多分类任务中性能最优.

Table 2 Performance of the Three Evaluated Machine Learning Algorithms on App Changes表2 3种监督式机器学习算法的算法性能对比表

Continued (Table 2)

此外，对版本更新日志中FR这一类型进行自动分类时，使用NB(BC)和RF(MC)得到的F值较为接近；而对“性能效率”“可移植性”和“其他”这3种类型而言，使用NB(BC)自动分类的结果明显优于RF(MC).

进一步，图2展示了应用NB(BC)和RF(MC)对版本更新日志进行自动分类时，不同需求类型更新条目的占比对自动分类性能评估指标F值的影响.由图2可知，与FR和“可用性”相比，“性能效率”“可靠性”“可移植性”和“其他”这4种类型的更新条目数占比较低，但使用NB(BC)进行自动分类得到的F值较高.

类似地，对类型为“性能效率”和“可靠性”这2类占比较低的版本更新条目来说，RF(MC)的分类正确率较高.不同的是，“可移植性”和“其他”这2类更新条目数量的低占比，其对应的RF(MC)分类正确性也随之降低.

3.1.3 版本更新条目的自动分类结果

表3和表4展示了应用RF(MC)对数据集中6 527条版本更新条目进行自动分类的结果.

从表3中可以发现，总体上，FR相关(47.0%)的版本更新日志多于与NFR相关(44.4%).但对于阅读类移动应用而言，其版本更新记录中与FR相关(43.6%)的更新条目数略少于与NFR相关(48.1%)的版本更新日志.

Table 3 Distribution of App Changelogs Over App Categories (FR vs NFR) Using RF(MC)

Table 4 Distribution of App Changelogs Over App Categories (4 NFR Types) Using RF(MC)

表4进一步展示了3类移动应用在4个NFR类型的详细分布.其中，“可用性”在NFR中占据主要地位.其次，“可用性”和“可靠性”的占比与3.1.1节中人工分类结果中的占比近似(前者为82%，后者为77%).再者，在社交类移动应用的发布的版本更新记录中，“可靠性”相关版本更新条目的占比明显少于旅行类和阅读类，而“性能效率”相关版本更新日志占比则略多于其他2个移动应用类别.

问题1结论：

1) NB,RF和J48这3种监督式机器学习算法均可用来识别和预测版本更新日志的需求类型.

2) 应用上述3种算法预测版本更新条目的需求类型并进行自动分类时，BC比MC的结果更准确.

3) 在使用BC时，NB的性能优于RF和J48；在使用MC时，RF的性能优于NB和J48.因此，如果仅需对某一特定需求类型进行自动分类和分析，可采用NB(BC)算法，见3.2.2节；否则，则可使用RF(MC)，见3.2.1节.

4) 对于某些需求类型(如“可靠性”)，RF(MC)分类结果的F值与数据集中提及该类型的版本更新条目占比成反比；而对其他的需求类型(如FR)而言，RF(MC)分类结果的F值与数据集中提及该类型的版本更新条目占比成正比.

3.2 移动应用的演化特点(问题2)

3.2.1 需求类型视角下移动应用的演化特点(问题2.1)

基于3.1.3节中应用RF(MC)得到的6 527条移动应用版本更新条目的自动分类结果，本节从更新条目涉及的需求类型这一角度，对移动应用的演化趋势展开如下分析：

从总体上看，6 527条更新条目中的289条发布于2014年，780条发布于2015年，1 305条发布于2016年，1 780条发布于2017年，2 373条发布于2018年.由此可见，近年来，移动应用版本更新日志中更新条目的数量持续增加.进一步，图3展示了旅游、社交和阅读类移动应用的版本更新条目数量随时间的变化趋势，即：旅游类移动应用的版本更新条目数量增长最快，社交类次之，阅读类移动应用更新条目数量的增长则十分缓慢.

Fig. 3 Distribution of app changes over three app categories and years图3 版本更新日志数量随类别及年份的变化

图4展示了FR和4种NFR需求类型相关的移动应用版本更新条目数随时间变化的情况.近5年来，FR和“可用性”相关的更新条目数量增速较快，而“可靠性”“性能效率”和“可移植性”类型的更新条目数量则增速缓慢.

Fig. 4 Trends of different requirements types in app changelogs图4 不同需求类型的版本更新日志数随年份的变化

进一步，图5显示了旅游、社交和阅读类移动应用中FR相关的版本更新条目数随时间的变化情况.与阅读类移动应用相比，旅游和社交类移动应用在演化更新时，涉及FR的版本更新条目数持续增长，且增速较快.这一现象说明，旅游和社交类移动应用在版本更新时更侧重引入新的功能.

Fig. 5 Trends of FR over the three app categories图5 FR类型版本更新日志数随年份的变化

Fig. 6 Trends of performance requirements over the three app categories图6 “性能效率”类型版本更新日志数随年份的变化

图6显示了3个类别移动应用中与“性能效率”相关的版本更新条目数量随时间的变化情况，即与其他2个类别的移动应用相比，社交类移动应用的版本更新记录中此需求类型被提及的频率更高；而除2016年和2018年外，阅读类和旅游类频率基本一致.

图7显示了3个类别移动应用中，与“可用性”相关的版本更新条目数量随时间的变化情况.与阅读类移动应用中收集到的更新日志相比，旅游类和社交类的移动应用均对“可用性”给予了更为持续的关注.

Fig. 7 Trends of usability requirements over the three app categories图7 “可用性”类型版本更新日志数随年份的变化

图8显示，近5年，这3类移动应用的版本更新日志对“可靠性”的关注度均有所提升.而与其他2个应用类别相比，旅游类应用更注重与可靠性相关的改进.

Fig. 8 Trends of reliability requirements over the three app categories图8 “可靠性”类型版本更新日志数随年份的变化

图9展示了移动应用中“可移植性”类型的版本更新条目数量随时间的变化趋势.自2016年以来，该需求类型在社交类应用中被频繁提及.而在过去3年，旅游类应用在更新时对“可移植性”的关注度基本保持不变.

Fig. 9 Trends of portability requirements over the three app categories图9 “可移植性”类型版本更新数日志随年份的变化

问题2.1结论：

1) 近5年来，移动应用的更新日志数目在不断增加.相较于其他2类应用，阅读类应用更新日志数目增长速度较慢.

2) FR和“可用性”是移动应用版本更新日志中增长最快的2个需求类别.不同类型需求相关的版本更新日志数量在不同应用类别上的增长情况并不相同.例如，对于“可靠性”而言，3个类别移动应用的演化趋势相似；而对于FR和“可用性”来说，旅游和社交类移动应用发布的相关版本更新条目数的增速远快于阅读类.

3.2.2 热词视角下移动应用的演化特点(问题2.2)

从热词的角度对移动应用的演化特点进行分析，需要针对不同的需求类型分别提取出对应版本更新记录中的热词.基于3.1.2节的结论，本节将使用NB(BC)对移动应用的版本更新记录进行自动分类，并基于分类结果对移动应用演化热词的特点进行分析.

表5中比较了FR和4种NFR类型的热词.其中第2列中的特征词包含在2.4节中提及的标注指南中，第3列的热词则是在5类版本更新日志中分别应用Weka中TF-IDF自动生成的特征词的子集，本文抽取了排名前10的特征词并去除部分无意义的词后组成了热词集合.5种需求类型对应的热词之间无重复，即5种需求类型对应的5组热词集合之间没有交集.然而，对任一种需求类型而言，表5第2列中的特征词和第3列中热词集合存在交集，即人工标注指南中75.8%(2533)的特征词与自动分类结果中54.3%(2546)的热词重合.

Table 5 Hot Words for FR and Four Types of NFRs表5 FR和4种NFR相关的热词

接下来，将进一步分析不同需求类型的版本更新记录中所包含热词随时间的变化情况.根据3.1.1节中不同需求类型的版本更新条目在数据集中的占比，本文将以FR和NFR中的“可用性”这2个占比较高的需求类型为例，展示移动应用版本更新记录中热词及其热度的变化，从热词的角度对移动应用的演化特点进行分析.

基于NB(BC)的自动分类结果，2014～2018年，与FR相关的版本更新条目数为2 312条，与“可用性”相关的版本更新条目数为1 249条.据统计，表5行1列3中列出的10个FR相关热词在2 312条FR类型更新条目中出现的总频次为2 889次，FR相关热词的综合热度为1.250,其计算公式见式(2).图10进一步展示了这10个FR相关热词在2 312条FR类型更新条目中的出现频次及其随时间的变化趋势.可以看出，在提及FR的版本更新日志中，出现次数最多的3个热词是“now”(799次)、“can”(672次)和“new”(536次)，且其出现次数逐年增多；而“theme”“enable”和“ability”等热词在版本更新日志中出现次数较少，在某些年份的出现次数甚至为0，故这几个热词随时间的变化趋势无明显规律.

Fig. 10 Occurrence of hot words in app changes over years (FR)图10 FR相关热词的频次随年份的变化

类似地，表5行3列3中列出的9个“可用性”相关热词在1 249条版本更新条目中出现的总频次为1 609次，依据式(2)计算得到的相关热词综合热度为1.288.图11展示了这9个“可用性”相关热词在1 938条“可用性”类型更新条目中的出现频次及其随时间的变化趋势.可以看出，在与“可用性”相关的版本更新记录中，出现总次数最多的3个热词是“improve”(515次)、“more”(296次)和“update”(221次).然而，从热词出现次数的增速来看，在2017至2018年间，“improve”和“easier”的增幅较快，而“better”和“update”的增幅较缓.

Fig. 11 Occurrence of hot words in app changes over years (Usability)图11 “可用性”相关热词的频次随年份的变化

图12展示了FR和“可用性”相关热词的综合热度随时间的变化情况.在移动应用的版本更新日志中，与FR相关热词的综合热度在2016年达到峰值后开始下降；相反，与“可用性”相关热词的综合热度在2016年后呈现出上升趋势.

Fig. 12 The degree of concerns of hot words (FR and Usability)图12 FR与“可用性”相关热词的综合热度变化趋势

问题2.2结论：

1) 标注指南中人工定义的特征词与自动提取的特征词重复率较高，且在标注指南中所指定的特征词大部分都包含在采用TF-IDF提取的特征词中.

2) 考虑采用TF-IDF从FR和“可用性”相关更新条目中提取出的热词，其出现频次均逐年增多.此外，不同需求类别的版本更新日志所包含热词的综合热度随时间的变化趋势不尽相同.

4 实验结果分析

4.1 3种监督式分类算法的性能分析(问题1)

3.1节中的问题1的结论1)～3)表明，对版本更新记录的自动分类而言，使用RF(MC)的分类结果最优.这一结论与文献[15,19]中的实验结果并不一致，即对用户评论进行自动分类的最优分类器并不适用于对移动应用版本的更新日志进行自动分类.可能的原因是，用户评论和版本更新记录这2类移动应用数据的数据质量不同，而某些分类器的性能会部分受到数据集质量的影响.此外，在自动分类版本更新日志时，BC明显优于MC，而此结论与文献[15]的结论完全一致.

3.1节的问题1的结论4)表明，不同需求类型在版本更新日志中的百分比并不总是与RF(MC)的F值成正比.例如，“性能效率”类型的版本更新日志在数据集中占比较低，但对该需求类型的更新日志进行自动分类时分类的正确性却较高.究其原因，可能是对“性能效率”这一需求类型来说，分类器从训练集中提取的文本特征词对识别该需求类型的版本更新日志更加敏感.

4.2 移动应用的演化特点及趋势分析(问题2)

移动应用版本更新条目的数量变化揭示，随时间的推移，版本更新条目的数目持续增多.原因可能是，移动应用的用户数量在增加，用户的个性化需求也越来越多，移动应用需要通过更频繁的更新、更丰富的更新内容以快速满足用户需求，以达到维持现有用户和吸引潜在用户的目的.

从移动应用所属类别的角度来探索移动应用的演化趋势时，作者发现：相对于社交和阅读类移动应用，旅游类应用发布的版本更新条目更多.原因可能是旅游类应用通常与其他类别的移动应用关系有更紧密的关联，故需要发布更多数量的版本更新条目以与其他应用进行协调.

根据与各需求类型相关的版本更新条目数量的占比和变化情况可以发现：从整体上看，FR相关的版本更新条目数量比NFR相关的增长更快，原因可能是用户不断地期望有新功能对应用进行扩展.然而，该结论因移动应用的类型不同而有所差异：对于阅读类移动应用而言，NFR类型更新的数量大于FR类型的更新数量；而对于社交类和旅游类移动应用而言，FR类型的版本更新数量略大于NFR类型的更新数量.原因可能是，阅读类应用的功能相对专一，与其他类别应用的交互较少，故更侧重于改善用户体验.

根据不同需求类型版本更新日志中的热词及其出现次数的变换情况可以发现：首先，由于在标注指南中指定的特征词大部分都包含在采用TF-IDF提取的特征词中，基于NB(BC)的半自动方法可极大地减少制定人工标注指南的时间和人力成本.其次，不同类型(如3.3.2节中的FR和“可用性”)的版本更新日志所包含热词的出现频次随时间的变化趋势不同.一方面，同一类型版本更新日志中不同热词出现次数随时间的变化趋势表明了开发者在描述移动应用版本更新内容时的用词偏好，可用于指导版本更新日志内容的撰写以最大程度吸引用户的关注.另一方面，考虑不同类型热词的综合热度，“可用性”类热词热度的攀升以及FR类热词热度的降低说明质量属性正逐渐成为开发者发布版本更新日志的重要关注点.

5 局限性

本文的研究结果由于5个方面的原因存在一定的局限性.

1) 数据集所涉及的移动应用类别仅有3类.作为探索性研究，这3种移动应用类别的选择策略(见2.2节)在一定程度上保证了样本的均衡性，但3.3节的实验结果和结论仅能展现移动应用市场中部分类别的移动应用的演化趋势，不能完整准确地代表移动应用市场的整体特点和变化.文献[16]曾指出，如果选择和收集苹果App Store中其他类别应用的版本更新记录进行实验，其结果或许有所不同，故扩大移动应用数据集的类别将是本文下一步的研究工作之一.此外，所有的版本更新日志均来源于苹果App Store.从其他移动应用市场(如Google Play)中收集移动应用的版本更新记录进行处理和分析，会极大增强本文结论的通用性.

2) 本研究中作为监督式机器学习算法训练集的3 034条版本更新条目是由2位计算机专业本科生分析和标注.为了得到高质量的标注并以此为基础进行分析，作者采取的措施有：在人工标注之前，2位标注者从本科的专业课程中学习了需求工程和软件工程的知识体系.考虑标注的过程，本文进行了2轮预标注，以帮助2位标注者对不同类型需求(特别是NFR)的含义和理解达成共识.如2.4节所述，两轮预标注的一致性分别为第1轮63%，第2轮73%.该过程可以帮助确定并完善人工标注指南，以便进一步对其他版本更新日志进行标注.同时，第2作者和第3作者不仅参与了2轮预标注过程中不一致意见的讨论和决策，还通过随机抽取少量样本的方式对3 034条版本更新条目的人工标注结果进行了正确性检验，以保证分析过程和结论的质量.

3) 本文3.1节的所有实验均在Weka中完成.Weka是用Java语言编写的机器学习工具套件.如果用不同的语言(如Python)对3种分类算法进行实现，则版本更新日志的自动分类结果可能有所不同.因此，如何保证不同语言的算法实现所得到分类结果的一致性还有待进一步研究与分析.

4) 版本更新记录是一种易获取且数据质量较高的公开数据源，从开发者的角度展示了移动应用更新的主要特点.理论上，可以为研究和分析移动应用的演化趋势提供高质量的数据支持.然而在实验数据的收集和分析过程中，作者发现，部分趋于成熟的移动应用在一定时间段内发布的多个版本更新记录不仅具有相同的内容，且其内容多为无意义的信息，这对基于版本更新记录的移动应用演化趋势分析提出了挑战.而对于版本更新记录详尽的移动应用而言，使用本文提供的方法能够在较短时间内了解和掌握其演化的特点和趋势.鉴于此，作者拟进一步研究，在基于版本更新记录分析移动应用演化趋势中移动应用类型、应用综合评分等因素对分析结果的影响.

5) 本文3.2节中对移动应用演化特点的分析和研究分别基于应用RF(MC)和NB(BC)对版本更新条目进行自动分类的结果.鉴于上述人工标注过程存在的问题以及上述2种分类算法准确率(详见表2)，基于该自动分类结果得到的移动应用演化趋势未必能反映出移动应用的真实更新趋势.如果改进分类器以得到更好的分类效果，或对RF(MC)NB(BC)生成的需求类型进行人工复核，移动应用演化趋势分析的准确性将得到进一步提高.

6 总结和展望

本文从需求工程的角度，研究和分析了苹果App Store中3个类别60个移动应用的版本更新日志及其内容，发现与功能需求和非功能需求相关的更新条目数量接近.

本研究涉及旅游、社交和阅读这3个类别的移动应用，探讨了如何利用监督式机器学习算法促进版本更新日志的自动分类，以降低人工标注的成本，帮助移动应用开发者快速了解和分析特定类别的移动应用更新的趋势.

下一步计划扩大研究范围，引入其他类别的移动应用(如苹果App Store和Google Play中健康和教育类应用)并考虑中国移动应用市场(如华为应用市场和小米应用市场)，以提高对整个移动应用市场整体特点和演化趋势分析的准确性以及研究结果的普适性.同时，还计划向本文所分析的移动应用的开发人员进行调研，以探索本研究结果的正确性和有效性及其对移动应用发布工程的影响.再者，除了采用有监督的分类方法外，还将基于人工标注数据所得到的标注指南，探索相应的启发式分类算法，以提高版本更新日志的自动分类效果.