软件工程研究人员以多种不同的方法来解决问题,因此问题的答案也不尽相同,相应的需要用适当的证据来验证这些结果,文章分析了ICSE2002中提交的论文,对研究内容本身和委员会对文章的评审意见进行分析,给出了如何在软件工程领域做更好的研究工作并能够将这些优秀的工作写出来。
一个研究论文需要向潜在的读者解释他/她完成了什么工作,如何完成的,为什么读者需要关注这个工作,好的研究论文需要回答以下几个问题:
确切的来说,你的贡献到底是什么?
你的新结果是什么
为什么读者要相信你的结果?
如果你能清楚的回答这些问题,你对所得出的结论的交流可能是不错的。如果你的结果对我们软件工程领域的知识给出了了一个有趣的,合理的,重要的贡献。你可能有机会被会议或者期刊接受。
在其他科学和工程领域,有一套成熟的研究方法。比如在物理学中的实验模型和药理学中的双盲法。但是在软件工程领域还没有这类通用的指导法则。(关于这个有大量的讨论,包括从软件工程是否是一个学科,软件工程工程研究的方法论等等)
2.确切的说,你的贡献是什么
2.1 软件工程关注哪类问题
通常来说,软件工程研究人员研究开发和评估软件的方法。开发包括所有涉及建立和修改软件的综合活动,包括代码,设计,文档等等,评估包括所有和对软件系统的功能和非功能属性进行预测,判定和评估相关的分析活动。
软件工程研究回答关于对特定软件进行设计或评估细节相关的开发和分析方法,对整个系统或者技术进行归纳,或者对存在或者合理性进行探索的问题。表1给出了软件工程研究论文给出研究问题和提供的特定的问题模板。
软件工程研究问题的类型 |
|
问题类型 |
例子 |
Method or means of development |
How can we do/create/modify/evolve (or automate doing) X? What is a better way to do/create/modify/evolve X? |
Method for analysis or evaluation |
How can I evaluate the quality/correctness of X? How do I choose between X and Y? |
Design, evaluation, or analysis of a particular instance |
How good is Y? What is property X of artifact/method Y? What is a (better) design, implementation, maintenance, or adaptation for application X? How does X compare to Y? What is the current state of X / practice of Y? |
Generalization or characterization |
Given X, what will Y (necessarily) be? What, exactly, do we mean by X? What are its important characteristics? What is a good formal/empirical model for X? What are the varieties of X, how are they related? |
Feasibility study or exploration |
Does X even exist, and if so what is it like? Is it possible to accomplish X at all? |
前两类研究产生开发或者分析方法,虽然是对作者设定领域的研究方法,但也可以用到其他领域。第三类研究是明确的对特定系统,实践,设计或者其他系统实例,方法进行的研究,研究范围从阐述工业实践到不同设计之间的对比。对这类研究,选择的实例需要有广泛的认知,比如对java发展进化的研究就会比你自己设计的一个玩具语言进行分析更容易接受。由这些案例进行归纳或者进行特征分析。最后,以一种全新的方式处理某个问题会区别于前人工作的提升,所以“合理性”是一个单独的分类(但是ICSE2002中没有这样的文章提交)。
2.2 最常见的有哪些
最常见的ICSE的论文都是关于软件开发,设计,实现,演化,维护或者对软件系统进行操作的其它方法上的提升。还有一类就是软件系统进行推理的方法,包括正确性的分析(测试和验证)。在这个非常挑剔的会议上分析类的文章的接受率不太大。
2.3 程序委员会想要什么样的文章
程序委员会想要一个能对所解决的问题进行清晰的阐述的文章,关于你回答的软件开发中的问题以及解释这个方法如何帮助解决软件工程中的重要问题。你可能会用大量的篇幅描述你的结果,但你应该从解释你所回答的是什么问题以及为什么这个答案很重要开始。
3.你的新结论是什么?
精确的解释你为软件工程的知识库里做了什么贡献以及在除了你自己的项目外,如何使用这个贡献。
3.1 软件工程研究产生了哪类的结果
软件工程研究的结果实际上可能是一些开发或者分析上的过程和技术;他们可能是从特定的案例中建模而来,或者可能是特定的工具,解决方案或者从特定的系统中得到、表3给出了软件工程研究的结果和特定的例子。
3.2 哪些较为常见
大多数ICSE的文章汇报了开发或者分析中的新过程和技术。表4给出了提交论文的分布
Table 4. Types of research results represented in ICSE 2002 submissions and acceptances
Types of software engineering research results |
|
Type of result |
Examples |
Procedure or technique |
|
Qualitative or descriptive model |
|
Empirical model |
|
Analytic model |
|
Tool or notation |
|
Specific solution, prototype, answer, or judgment |
|
Report |
|
Type of result Submitted Accepted Ratio Acc/Sub
Procedure or technique 152(44%) 28 (51%) 18%
Qualitative or descriptive model 50 (14%) 4 (7%) 8%
Empirical model 4 (1%) 1 (2%) 25%
Analytic model 48 (14%) 7 (13%) 15%
Tool or notation 49 (14%) 10 (18%) 20%
Specific solution, prototype, answer, or judgment 34 (10%) 5 (9%) 15%
Report 11 (3%) 0 (0%) 0%
研究项目会产生多种类型结果,但是,会议,包括ICSE通常有页数限制。大多数情况下,这个只能阐述一个idea,或者一或两个支持的idea。很多作者在会议论文里给出其个人的idea,然后将其综合成一篇期刊文章,而期刊文章运行作者将多个idea进行综合并对各个结果之间的复杂关系进行分析
3.3 程序委员会希望看到什么?
涉及到能极大增强我们开发和维护软件能力,能让我们了解我们所开发软件的质量,认识到软的通用准则或者分析软件属性的有趣,创新,令人激动的结果。你需要以能让别人也可以采用你的idea的方式来解释你的结果。一定要解释创新或者原创在什么地方--是idea,还是idea的应用,实现,分析还是什么?
精确定义词汇,并一致性的使用,程序委员会可能会问到:
精确的说,你声称的贡献是什么?
结果能够满足你的声明么?定义是否精确,词汇的使用是否一致?
作者会陷入一些特定的状况,下面是一些例子和建议
有什么新的东西?
程序委员会想要知道有什么新的,令人的激动的发现,并且为什么?就是说这个贡献有什么特别的?相比自己或其他作者之前的工作,这次的工作有什么新的东西,对于一个子学科的通常标准来说,这种进步足够么?
当然,你写了这个工具,实验了,但是你贡献的技术是否嵌入到这个工具里了,或者在使用了你的技术后,原来的工具变得更有效率了?还是你之前文章中所描述的软件可以实际在大规模的问题上使用?作为作者来说,你应该清楚的解释这些,而不是让程序委员会来猜。
对你所声明的内容做清楚的说明。
Awful |
▼ |
我完全一般的解决了... (除非你真的做到了) |
Bad |
▼ |
I worked on galumphing.(or studied, investigated, sought,explored) |
Poor |
▼ |
I worked on improving galumphing.(or contributed to, participated in,helped with) |
Good |
▲ |
l I showed the feasibility of composing blitzing with flitzing. l I significantly improved the accuracy of the standard detector.(or proved, demonstrated, created,established, found, developed) |
Better |
▲ |
l I automated the production of flitz tables from specifications. l With a novel application of the blivet transform, I achieved a 10% increase in speed and a 15% improvement in coverage over the standard method. |
Comments:好的方式,给出解决问题的具体方式,并给出定量的的结论以及验证标准
这个问题之前都有哪些工作?你的工作和其他的有什么不同还是比其他人的更好?
你的研究建立在哪些已经存在的技术上面?你的技术对哪些现存的技术或者之前的研究是一个更好的替代方案?这个和你自己之前的工作相比有什么新的?其他研究人员给出的替代方案有哪些,你的工作和他们的有哪些不同?
作为一个科学和工程领域,软件工程知识也是增量增长的。程序委员会对你对该领域之前工作的解释非常感兴趣。他们希望知道你的工作和之前工作之间的联系,不管你的工作是建立在前人工作的基础上的或者为前人的工作提供一个替代方案。如果你不解释这些,对于程序委员会来说很难理解你的工作如何增进了软件工程领域的知识库,如果程序委员会不能明确的了解你是否知道相关的工作的话,你可能会毁了你自己的信誉。
清楚的解释你的工作和相关工作之间的关系.....
Awful |
▼ |
The galumphing problem has attracted much attention [3,8,10,18,26,32,37] |
Bad |
▼ |
Smith [36] and Jones [27] worked on galumphing. |
Poor |
▼ |
Smith [36] addressed galumphing by blitzing, whereas Jones [27] took a flitzing approach. |
Good |
▲ |
Smith’s blitzing approach to galumphing[36] achieved 60% coverage [39].Jones [27] achieved 80% by flitzing,but only for pointer-free cases [16]. |
Better |
▲ |
Smith’s blitzing approach to galumphing[36] achieved 60% coverage [39].Jones [27] achieved 80% by flitzing,but only for pointer-free cases [16].We modified the blitzing approach to use the kernel representation of flitzing and achieved 90% coverage while relaxing the restriction so that only cyclic data structures are prohibited. |
Comments:好的阐述方式,形式:xxx用了什么方法解决类似问题,达到了什么效果,还存在什么问题,自己的方法解决了什么问题,达到什么效果,避免了什么问题。
精确的说,结果是什么?
解释你的结果是什么,如何运作的,需要详细具体的描述。最好有例子。
4.为什么读者相信你的结论
展示证据证明你的结论是正确的--证明它真的能够帮助之前想要解决的问题。
4.1 软件工程做哪些验证?
软件工程师在支持其研究结果的时候提供多种形式的证据。对于不同的研究结论需要选择合适的验证方式来对研究结果和得到结果的方法进行验证。举个栗子,一个形式化的模型应该由精确推导和证明来进行验证,不能由一两个例子进行验证。另外一方面,验证一个新的开发方法应该从实际系统中抽取的一个简单列子进行验证。表5给出了在软件工程研究中验证的方法并提供了对应的例子。
Types of software engineering research validation |
|
Type of validation |
Examples |
Analysis |
I have analyzed my result and find it satisfactory through rigorous analysis, e.g. … For a formal model … rigorous derivation and proof For an empirical model … data on use in controlled situation For a controlled experiment … carefully designed experiment with statistically significant results |
Evaluation |
Given the stated criteria, my result... For a descriptive model … adequately describes phenomena of interest … For a qualitative model … accounts for the phenomena of interest… For an empirical model … is able to predict … because …, or … generates results that fit actual data … Includes feasibility studies, pilot projects |
Experience |
My result has been used on real examples by someone other than me, and the evidence of its correctness/usefulness/effectiveness is … For a qualitative model … narrative For an empirical model or tool … data, usually statistical, on practice For a notation or technique … comparison of systems in actual use |
Example |
Here’s an example of how it works on For a technique or procedure …a "slice of life" example based on a real system … For a technique or procedure …a system that I have been developing … For a technique or procedure … a toy example, perhaps motivated by reality The "slice of life" example is most likely to be convincing, especially if accompanied by an explanation of why the simplified example retains the essence of the problem being solved. Toy or textbook examples often fail to provide persuasive validation, (except for standard examples used as model problems by the field). |
Persuasion |
I thought hard about this, and I believe passionately that ... For a technique … if you do it the following way, then … For a system … a system constructed like this would … For a model … this example shows how my idea works Validation purely by persuasion is rarely sufficient for a research paper. Note, though, that if the original question was about feasibility, a working system, even without analysis, can suffice |
Blatant assertion |
No serious attempt to evaluate result. This is highly unlikely to be acceptable |
接下来要做的就是把上述的这些整合成一篇论文了^_^!!
如何做好软件工程方面研究--mini教程,Mary shaw(CMU)
原文:http://www.cnblogs.com/helloever/p/5012338.html