/
A guide to writing good software engineering papers A guide to writing good software engineering papers

A guide to writing good software engineering papers - PowerPoint Presentation

pasty-toler
pasty-toler . @pasty-toler
Follow
387 views
Uploaded On 2017-11-03

A guide to writing good software engineering papers - PPT Presentation

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

paper results software papers results paper papers software research section writing engineering problem work don

Share:

Link:

Embed:

Download Presentation from below link

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.


Presentation Transcript

Slide1

A guide to writing good software engineering papersTracy Hall

Brunel Software Engineering Lab (BSEL)Slide2

The lifecycle of a research paper…Slide3
Slide4
Slide5
Slide6
Slide7
Slide8
Slide9

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.