软件工程中的系统文献映射研究-设计和执行过程的第三步

接着上一篇(“软件工程中的系统文献映射研究-设计和执行过程的第二步”),继续讲软件工程中的系统文献映射研究。

上一篇给出了文献的正式检索和筛选过程的图,这里把整个流程梳理一遍。

文献的正式检索和筛选过程一般包括7个步骤:  

步骤1:在数据库中检索文献。  

收录文献的数据库非常多,怎么选择非常重要。例如在我前面对软件开发中的假设条件及其管理的研究中,选择的标准一个是根据我们自身的经验,另一个就是根据其他类似文献的选择情况。在该研究中我们最终定下了7个数据库。选取的数据库未包括Google Scholar,因为针对软件工程的文献,该数据库的精度存在问题,且可能与其他数据库的检索结果大量重复[1]。

选取的数据库描述如下。

(1)ACM Digital Library  

(2)IEEE Explore  

(3)Science Direct  

(4)Springer Link  

(5)Wiley InterScience  

(6)EI Compendex  

(7)ISI Web of Science 

其次就是检索词的问题,因这七个数据库采用不同的检索引擎和策略,因此在各数据库中的检索范围也不同。例如在Springer Link数据库中,其检索引擎支持用户检索 “with all of the words”、“with the exact phase”、“with at least one of the words”、“without the words”、“where the title contains”、“where the authors / editor is”、“show documents published”。但是该引擎并不支持基于关键字或摘要的检索。所以针对Springer Link数据库,本研究设定其检索范围为标题。

再次是检索时间的范围。时间范围是影响研究的一个关键因素。目前软件工程中的系统文献映射研究还无法做到自动化,基本上还是依赖于大量的人工参与。如果不控制时间范围,往往会检索到海量的结果,光靠人工很难在合理的时间内筛选完。但如果控制时间范围,那就涉及到怎么选择开始时间和截止时间的问题。截止时间很好确定,比如可以是我们开始这项研究的时间。但是开始时间往往需要一些策略。

(1)这个领域是否有里程碑?里程碑可以是该领域内的某个著名事件(比如敏捷开发领域中敏捷宣言的提出),也可以是某篇具有重要意义文章的发表(比如软件架构领域Perry and Wolf发表的文章被认为是该领域的奠基成果)。如果有,则可以考虑选择里程碑的时间节点作为开始时间。

(2)如果实在找不到里程碑,那就要考虑以一个固定年限做检索(如10年、15年、20年)。但到底是10年、15年,还是多少年,应综合判断:a. 检索筛选过程是否能在合理时间内完成。b. 是否能得到足够数量的入选文献以形成有意义的结论。不可否认,这里面主观性较大。

例如在我前面对软件开发中的假设条件及其管理的研究中,检索的时间范围为2001年1月到2015年12月(系统文献映射研究的开始时间)。该研究中,若采用不设定时间范围的检索与筛选过程,会导致需要极高的成本以及并不能在合理的时间内完成。然而因为软件开发中假设条件及其管理的主题广度较大,我们并未发现任何文献可以充当此主题的里程碑。考虑到对此系统文献映射研究而言,十五年是一个合理的时间范围,因此该研究设定2001年1月为起始时间点。

最后是检索表达式的问题。在“软件工程中的系统文献映射研究-设计和执行过程的第二步”中,已经提过在文献的试验性检索和筛选过程中会尝试不同组合的检索表达式,所以在这只需要直接采用前面得到的结论即可。例如在我前面对软件开发中的假设条件及其管理的研究中,我们在这一步采用的检索表达式为:(software) AND (assumption OR assume OR assuming)。

步骤2:基于数据库的检索结果进行第一轮筛选(标题和摘要)。

从数据库检索出一定数量的文献后,就转入了第一轮筛选。这一轮筛选中我们会阅读每一篇从数据库中检索出的文献的标题和摘要,结合事先拟定好的筛选标准,以判断某文献是否可以进入下一轮筛选。在这一步中可以淘汰大部分的文献。

注意:也有研究将标题和摘要分为两轮筛选,所以文献的正式检索和筛选过程也可能有8个步骤。 

所有的软件工程中的系统文献映射研究都必须有文献的筛选标准,这些标准同样需要在文献的试验性检索和筛选过程中进行设计、精化、验证。例如在我前面对软件开发中的假设条件及其管理的研究中,我们采用的标准如下所述。

入选标准:  

I1:该文献关注软件开发中的假设条件(如需求的假设条件)。  

排除标准:  

E1:该文献关注方法或工具的假设条件。  

E2:该文献未经同行评审(如技术报告)[2]。  

E3:如果同一工作在多篇文献中出现,排除较不成熟的文献。  

E4:该文献的语言不是英语。  

E5:该文献仅有摘要而无全文。  

E6:该文献仅仅提到假设条件的术语。  

E7:该文献没有用于回答研究问题的有效数据。  

采用E1的原因是现存两种类型的假设条件:(1)在软件开发中制定的假设条件(例如假设某软件的用户多为老年人)以及(2)为特定方法和工具制定的假设条件(例如对方法或工具的设计做出假设)。因为此系统文献映射研究的主题为软件开发中的假设条件及其管理,所以采用E1来排除那些关注方法或工具的假设条件的文献。

步骤3:基于步骤2的结果进行第二轮筛选(全文)。  

顾名思义,这一步中要针对步骤2中过滤出来的文献,进一步阅读其全文,并结合拟定好的筛选标准以判断某文献是否进入下一轮。

步骤4:基于步骤3的结果采用滚雪球技术[3]对其参考文献进行人工筛选。

滚雪球包括对一篇文献的参考文献进行筛选(逆向滚雪球)或者对引用该文献的其他文献进行筛选(正向滚雪球)以识别额外的相关文献[3]。

例如在我前面对软件开发中的假设条件及其管理的研究中,我们首先采用逆向滚雪球技术识别额外的相关文献(即步骤4-1),然后通过标题和摘要筛选识别的文献(即步骤4-2),最后基于步骤4-2的结果通过全文筛选文献(即步骤4-3)。  

步骤5:扩展检索。

在前面检索和筛选的过程中,有可能发现研究设计不完备的地方,那么这个时候就应该加以补救。

例如在我前面对软件开发中的假设条件及其管理的研究中,我们还执行了一步扩展检索,即在七个数据库中检索和筛选关于rely-guarantee和assumption-commitment的方法。执行该步骤的原因是在执行步骤3和步骤4的同时,研究执行过程中发现一些入选文献使用assume-guarantee方法(又名rely-guarantee或者assumption-commitment)在软件开发中管理假设条件。  

以我的经验来说,在这一步结束后得到的文献数量在大部分研究中为50-200。小于50很难形成有意义的结果,而大于200则需要花费大量的时间成本。当然这个50和200的数据非常主观,不能作为绝对标准衡量,仅供参考。

步骤6:数据抽取(包含试验性的数据抽取)。

当筛选出一定数量的文献后,则转入抽取数据的阶段。抽什么数据,怎么抽这些设计上的问题应该预先就已经确定下来。特别值得强调的是,抽取的数据必须覆盖且有能力回答所有的研究问题。 例如在我前面对软件开发中的假设条件及其管理的研究中,抽取的数据如下所述。

#

数据项

描述

研究问题

D1 

ID 

文献的标识

不适用

D2 

标题

文献的标题

不适用

D3 

作者

文献的作者

不适用

D4 

作者类型

学术界、工业界、两者皆有

不适用

D5 

发表类型

书籍、期刊、会议、研讨会

不适用

D6 

发表来源

文献的发表来源(如期刊名)

不适用

D7 

发表年度

文献的发表年度

不适用

D8 

定义

假设条件的定义

研究问题一

D9 

软件开发活动

与假设条件有关的软件开发活动(如需求工程)

研究问题二

D10 

制品

与假设条件有关的软件制品(如需求)

研究问题三

D11 

假设条件管理活动

假设条件管理活动(如制定假设条件)

研究问题四

D12 

方法

假设条件管理方法

研究问题五

D13 

工具

假设条件管理工具

研究问题五

D14 

涉众

与管理假设条件有关的涉众

研究问题六

D15 

收益

软件开发中管理假设条件的收益

研究问题七

D16 

挑战

软件开发中管理假设条件的挑战

研究问题七

D17 

后果

软件开发中未被妥善管理的假设条件造成的后果

研究问题八

D18 

经验

软件开发中管理假设条件有关的经验

研究问题九

步骤7:数据分析。

数据分析包括很多方法,比如描述性的统计分析以及Constant Comparison方法 [4][5]。

这里简单介绍一下Constant Comparison方法。

Constant Comparison为从数据中生成概念提供了系统的方法,并针对生成的概念和分类的验证提供了一个持续的过程[4][5]。本研究遵从Adolph等提出的关于执行Constant Comparison的指南[5]。例如在我前面对软件开发中的假设条件及其管理的研究中,我们将抽取的数据编码为事件;比较这些事件以生成概念;然后继续比较这些事件和概念以生成分类。例如一篇文献提到:“Sometimes changes could be adopted easily; but sometimes even crucial parts of the application had to be rewritten, often because its assumptions did not hold any longer”,先将其编码为:“Consequences caused by not well-managed assumptions”。其中本研究会使用子编码来细化特定的事件。考虑以上的例子,采用的子编码为:“Consequences caused by not well-managed assumptions: Invalid assumptions”。请注意事件的长度可能为一个简单的单词,也可能是几个段落。

参考文献

[1] L. Chen, M.A. Babar, and H. Zhang. Towards an evidence-based understanding of electronic data sources. In: Proceedings of the 14th International Conference on Evaluation and Assessment in Software Engineering (ESEM), Bolzano-Bozen, Italy, pp. 135-138, 2010. 

[2] B. Kitchenham and S. Charters. Guidelines for Performing Systematic Literature Reviews in Software Engineering, Version 2.3. EBSE Technical Report EBSE-2007-01, Keele University and Durham University, 2007.

[3]C. Wohlin. Guidelines for snowballing in systematic literature studies and a replication in software engineering. In: Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering (EASE), London, UK, Article No. 38, 2014.

[4] B.G. Glaser and A.L. Strauss. The Discovery of Grounded Theory: Strategies for Qualitative Research. New York: Aldine Publishing, 1967.

[5] S. Adolph, W. Hall, and P. Kruchten. Using grounded theory to study the experience of software development. Empirical Software Engineering, 16(4): 487-513, 2011.

猜你喜欢

转载自blog.csdn.net/ytomc/article/details/82826738