Vous êtes sur la page 1sur 27

How to Make Research Papers in

Software Engineering

Kai Koskimies
SoSE paper project course
Spring 2009

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 1


Topics

Paper writing as research work


Contributions of a paper
Overall structure of a paper
Focus, focus, focus
Writing style
Reviews
Selecting a conference

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 2


Paper writing as research work

• Writing is a way to elaborate the topic, too


• Especially good for clarifying your own thoughts,
terminology, motivations, contributions
• The text you write is probably not final – write it anyway
• Deadline generator
• Form of research collaboration

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 3


Contributions of a paper
• Concept (e.g. a new kind of architectural modeling
concept)
• Solution (e.g. general architectural solution, algorithm)
• Method, technique (e.g. a method to derive architecture)
• Tool (e.g. a tool concept & implementation to support a
method)
• Evaluation of an approach (often case study)
• Finding & interpreting empirical data
• Combination of existing ideas
• … and any combination of these

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 4


Paper style
• Empirical science style
- contribution: empirical data & its interpretation, empirical
study of known engineering practices etc.
• Engineering style
- contribution: solution to a practical engineering problem
& its evaluation
• Mathematics style
- contribution: algorithm, formal language, correctness,
complexity, coverage etc.
• … or any combination of these

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 5


Antipatterns

• Empirical data as contribution


Present the empirical data (e.g. queries, interviews etc.) you have collected
in a summarizing form
Correction: Decide what is your message, interpret the data, show that your
data supports the message

• Tool as contribution
Present your existing tool and show how it can be used to solve a problem
Correction: Present the problem and solution on an abstract level, and use
your tool only in the implementation part, as part of the evaluation

• Formalism as contribution
Show how a certain aspect of software engineering can be formalized
Correction: Present the formalism as a tool to achieve some advantages or
solve some problem in software engineering

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 6


Overall structure
Template (engineering style):
Introduction
- context and problem statement, approach
Motivating example Background
- concretizing the - needed prerequisites, existing concepts used etc
problem with an Idea
example - beef of the paper, solution on an abstract level
Implementation
- how to realize the idea (e.g. as a tool)
Evaluation
- demonstrate that the idea works, typically a case study
Sometimes related Related work
work can replace - comparison with other existing work, highlights contributions
background Conclusions
(esp. when work is - work seen from bigger perspective, future directions etc.
difficult to compare) Acknowledgements
- funding organizaton, comment providers, programmers etc.
References
Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 7
Title

• Is important for selling the paper


• Should be compact and descriptive (upto 1.5 lines)
• Should allow filtering interested readers
• Can have a catch (e.g. historical: ”… considered harmful”,
playing with words: ”… REST assured”)
• Should not assume special subarea (e.g. ”software
architecture” rather than ”architecture”)
• Technique to find a title: collect all the keywords and find
all possible sensible combinations of them, connected
with auxiliary articles, prepositions etc.

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 8


Author list

• A paper is rarely the result of the work of one person only


• Often there is a person who is mainly responsible (first
author)
• Supervisor, who has at least checked&revised the paper,
can be the last author (typical in Europe & USA)
• Implementing assistants can be included (or at least
mentioned in the acknowledgements)
• Each author category (main author, secondary author,
supervisor) in alphabetical order
• Having several authors does not reduce the merit of
the main author, may even strengthen it

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 9


Roles in a research team

• Manager: provides basic facilities, funding etc.


• Idea generator: provides starting points
• Technology expert: provides technical skills
• Architect: provides general system/tool principles
• Writer: provides paper writing skills
• Presenter: provides convincing demos &
presentations

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 10


Abstract of a paper

• One paragraph (typically 4-6 sentences)


• Template (sentences):
Context
Problem
Solution
Validation
Learned lesson

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 11


Introduction of a paper

• Remember audience: do not use too much text for


painting the scenery
• Introduction is very important for acceptance: hook the
reader (but do not promise too much, either)
• Template (6 paragraphs):
basic context
problem description
deficiencies with previous approaches
basic idea/approach of the paper
contributions of the paper
textual contents description

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 12


Background

• Existing work, basic concepts etc


• Give a descriptive name for this chapter
• Take into account the audience
• The paper should be self-sufficient (with respect to expected
audience)
• Try to be as concise and to the point as possible
• Don’t talk about your contributions here
• Should not take more than 1-2/15 pages
• Often not necessary, if background is general knowledge (or can be
covered in the intro)
• Can be given as ”related work”, if that work is more like starting points
for this work

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 13


Idea

• Don’t overestimate the understanding and guessing


capability of the reader
• Use figures to illustrate the main ideas
• Use examples to concretize the concepts
• Use subsections to structure the presentation
• Avoid your own new terms as much as possible
• Don’t create your own world, but a delta for existing world
• This is the highlight of the paper, keep the focus

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 14


Implementation

• Often necessary to show that the idea has been


implemented, part of evaluation
• Architectural descriptions of a new tool
• Generally interesting technical implementation solutions
• Information about the technical environment
• Use screenshots, whenever appropriate (to show that you
really have a tool and to show the GUI)
• Can be rather short

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 15


Evaluation

• Usually in the form of a realistic (industrial) case study


• Example is not a case study
• Make clear what is the thing in the case study you are
interested in
• Recall that a case study never proves anything
• If possible/sensible, characterize results by quantitative
measures (e.g. performance, footprint, lines of code,
working time etc.)
• Even anecdotal experience information can be worth of
mentioning

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 16


Related work
• Comparison of the contribution with existing literature (e.g. one
mentioned in Background)
• If there is very little work to compare, this could be integrated with
Background
• Template: one paragraph per each existing research
direction, with 1-2 statements at the end discussing the differences
• Typically differences are stated in the form ”Unlike our approach, their
method/tool/solution supports X. However, our approach supports Y
which is not considered in their approach.”
• Be careful when discussing about weaknesses of other approaches,
be diplomatic
• Perform systematic literature look-up to find relevant references
(potential conferences & journals, references in other papers, google)

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 17


Conclusions

• Idea: provide a high-level perspective on the work


• Template:
Rephrasing the main contribution (paragraph)
Significance of the work from larger perspective (paragraph)
Future directions of the work (paragraph)
• No new topics for discussions
• Usually no references

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 18


Focus, focus, focus (1)

• Exam answering strategy does not work: you do not get


extra points for extra information
• You should be able to give the main message of your
paper in one sentence, stick to that in the paper structure
• If you are not sure whether a particular ”additional” issue
should be discussed or not, probably it should not be
discussed
• Make the paper a story, with highlights in the middle

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 19


Focus, focus, focus (2)

• Try to write a story: logical line of thought (often top-down)


• Define problem, provide solution, show that it works
• There can be only one beef in one paper
• Summarizing representations are often good (e.g. tables)
• Paper profile:

intro beef

tool, case study


beef intro

bad good

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 20


General writing style

• Do not write for your project team, for your supervisor, for a narrow
community
• Avoid metatext, research process text when not essential, just
concentrate on the result (research methodological issues may be
relevant, though)
• Avoid lists of paragraphs (-> bullet list), still paragraphs are an
important means of structuring
• Beware of the Lemminkäinen effect (”Tiedänpä vielä tämänkin”, I
know this, too. Or: ”There is this additional feature in the tool, too.”)
• The art of removing and compressing text, without affecting the main
message
• Language is a powerful tool – and unreliable. Aim at simple
expressions and sentences (e.g. avoid ”very”)

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 21


Reviews

• There are many kinds of reviewers (w.r.t general experience,


character, specialization area, lazyness); reviews are always
subjective
• In any PC, there is probably always one that likes your paper and one
that dislikes it (and anything between) => you can sometimes just be
unlucky
• The spirit of reviews also reflects the level of the forum
• Try not to take the reviews personally, but merely as input to improve
your paper. Papers can always be improved
• Lack of understanding the paper is not unusual, but that is input for
improving the paper, too
• Often frustrating to react to comments asking for more text, when
space is limited
• Good review is truly valuable for improving the paper

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 22


Selecting a conference (1)
Conference categories

Workshops (e.g. satellite workshops, Nordic workshops,


SPLST)
- good for scientific networking, discussions, initial deadline
generators
- acceptance rate around 50-90%
- publication often as university report
- may provide a journal publication for selected papers (10-
20%)
- PC has some well-known names

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 23


Selecting a conference (2)

Well-known middle-level workshops and conferences (e.g.


GPCE, WICSA, MODELS, ICSM, ICPC, ASWEC,
COMPSAC, TOOLS etc.)
- supported by IEEE or ACM
- good as merit, PhD publication
- acceptance rate around 30-50%
- publication as Springer LNCS, IEEE, ACM, other well-
known publisher
- PC has many well-known names

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 24


Selecting a conference (3)

High-level conferences (e.g. ICSE, ESEC, OOPSLA, ASE, FASE etc.)


- excellent merit, helps you to enter a community
- acceptance rate 10-30%
- publication by Springer LNCS, IEEE, ACM
- good for getting thorough (albeit critical) reviews
- PC mostly consists of well-known persons

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 25


Selecting a conference (4)

Other conferences
- often questionable merit
- some conferences may have special hidden agenda
- acceptance rate unknown (possibly 100%)
- publication as separate proceedings of small publisher
- PC consists of unknown persons
- avoid, if no particular reason to attend

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 26


Check the SE conferences site:
http://www.csc.ncsu.edu/faculty/xie/seconferences.htm

(some personal opinions, too)

Publication in SE research/ KK Spring 2009 TTY Ohjelmistotekniikka 27

Vous aimerez peut-être aussi