Tracy Hall Brunel Software Engineering Lab BSEL The lifecycle of a research paper Agenda Introduction Paper content Publication strategies Structure of papers Style of writing Dealing with reviews ID: 602311
Download Presentation The PPT/PDF document "A guide to writing good software enginee..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
A guide to writing good software engineering papersTracy Hall
Brunel Software Engineering Lab (BSEL)Slide2
The lifecycle of a research paper…Slide3Slide4Slide5Slide6Slide7Slide8Slide9
Agenda
Introduction
Paper content
Publication strategiesStructure of papers
Style of writing
Dealing with reviews
Dealing with success!
ReferencesSlide10
Introduction
Papers are important trophies for researchers!
Outputs
CV
H-index
But papers also:
help
move knowledge on
.
convey our new ideas to the
communitySlide11
Publication strategies
Workshop, conference or journal paper?
Short or long paper?
2*, 3* or 4* venue?
Software Engineering Conferences
Software Engineering Journals
FSE, ICSE
TSE, TOSEM
ESEM, ICSME, GEKKO
JSS, IST, ESE
MSR, PROMISE, EASE
SQJ, SEP
ICSE workshops
IETSlide12
Content
So what?????
Must have something valuable to present!
What is your idea?
Why is it important???
What *problem* have you solved. Not just here’s a story of what I’ve done…
Have a very clear message that is maintained in a simple thread throughout – right from the title.Slide13
Structure of papers
Title and authors
Abstract
Introduction
Background
Methods
Results
Threats to validity
Discussion
Conclusions
ReferencesSlide14
Title and authors
Keep the title:
Short
Informative
Engaging
Eg
.
Requirements problems in twelve software companies: an empirical
analysis
T
Hall, S Beecham, A
Rainer, IEE
Proceedings-Software 149 (5), 153-160, 2002
Sort
out author list
asap…
Be aware of publications rules on authors (e.g. IEEE and ACM)Slide15
Abstract
Write first
Use a structured abstract:
Objective
Background
Methods
Results
Conclusions
Or use Kent Beck’s 4 sentence approach:
State
the problem.
State
why the problem is a problem.
A startling
sentence.
The implication
of
the startling
sentence. Slide16
An abstract done in this style would be:
The
rejection rate for OOPSLA papers
is
near 90%. Most papers are rejected not because of a lack of good ideas, but because they are poorly structured. Following four simple steps in writing a paper will dramatically increase your chances of acceptance. If everyone followed these steps, the amount of communication in the object community would increase, improving the rate of progress
.
(Kent Beck)Slide17
Introduction Section
Sell your idea…,
The first sentence is important
Structure:
What, why
and how.
State your explicit contributions
Aims and research questions with motivations
Paragraph describing the structure of the paperSlide18
Background Section
Set the context to your work with the current-state-of-the art:
Describe
the problem, and why it
is important and
interesting. Try to use examples.
Describe
your
solution
Discuss how your solution solves the problem.
Throughout cite *relevant* work.
Make sure that the work you cite is timely.
See
Simon Peyton
Jones’ guideSlide19
Methods Section
Explicitly describe methods that are:
Motivated/justified
Thorough
Rigorous
Validated
Your
methodology must be
repeatable
Replication package (
data/scripts
etc.) should be providedSlide20
Results Section
Be factual
Present plenty of clear demographic data to contextualise your results.
Don’t discuss the results
Use tables/graphs etc.
Clearly explain how to interpret figures presented.
Don’t expect readers to take results on trustSlide21
Discussion Section
Discussion is about squaring the circle
Answer
your research
questions
Discuss the:
Significance
of
your results
,
fit
of results,
use
of results,
future work
Throughout cite relevant referencesSlide22
Threats to validity Section
Address
types
of
threat:
Construct
validity
Internal validity
External
validity
Show how these threats have been mitigated.
Provide reasons why these threats do not negate the results.Slide23
Conclusions Section
Summary of
everything you have said
Emphasise the important:
Contributions of your results
U
ses of your results
Try to end on a strong point about the futureSlide24
Writing style
Don’t
over-claim
. Provide evidence of claims.
Don’t be ‘chatty’, be authoritative.
First person voice?!
Use short sentences.
Use plain English.
Eliminate typos and poor grammar.
Eliminate repetition, but
Include proper signposting.
Take care with references.
Stick to formatting guidelines.
Try to include graphics/tables/diagrams/pictures.
Have a gold standard paper in mind as your personal template.
Please read Norman Fenton’s guide
!Slide25
Dealing with reviews
Dealing with rejection is a core feature of a researcher…
Get as much feedback on your work as possible. Before submission. Believe the feedback…
Try to quickly get over the injustice of what reviewers have said…
Ignore the rudeness of some reviewers.
Believe that there is great value in the reviewers’ comments.
Always
address reviewers’ comments.
DON’T GIVE UP!!!!
Be honest and *kind* as a reviewer yourself!!!Slide26
Dealing with success!
Once accepted:
Consider how to publicise an accepted paper to improve
its exposure
Publish your paper on open-access
Extend conference papers into journal papersSlide27
References
Simon Peyton Jones, How to write a great research paper, Microsoft Research, Cambridge
Norman Fenton, Improving
your Technical Writing
Skills
http
://www.eecs.qmul.ac.uk/~
norman/papers/good_writing/Technical%20writing.pdf
Kent Beck, How
to Get a Paper Accepted at OOPSLA
https://plg.uwaterloo.ca/~
migod/research/beckOOPSLA.html
Mary Shaw. 2003. Writing good software engineering research papers:
minitutorial
. In
Proceedings of the 25th International Conference on Software Engineering
(ICSE '03). IEEE Computer Society, Washington, DC, USA, 726-736.