How to Write Abstracts

For writing technical reports, white papers, research papers, …

How to write abstracts?

Ganesh SamarthyamCo-founder (CodeOps Tech.)Author, writer, conference speaker [email protected]

mailto:[email protected]

If you can write, you're an author!

Just like Nike’s mission statement - every one is an author!

If she can, you can

If she can write, you can write

too!

If I can, so you canSuch poor

background where I started from, I see myself

as a success!

I am second from left (wearing glasses)

“Success is relative, individual and personal”

- Wilfred Peterson

Some of my publications

https://scholar.google.co.in/citations?user=3Zksd94AAAAJ

https://scholar.google.co.in/citations?user=3Zksd94AAAAJ

Translations in other languages

https://books.google.co.in/books?id=x--MCwAAQBAJ

Korean!

https://books.google.co.in/books?id=x--MCwAAQBAJ

Writing => Influence => Leadership

Grady Booch

Martin Fowler Kent Beck

Robert C. Martin

But I am a techie, not a writer!

You don't need a Ph.D to write papers !

Techie + Don't have a Ph.D

Grady Booch

Martin Fowler Kent Beck

Robert C. Martin

Writing abstracts

General structure of a paper❖ Title❖ Abstract

❖ Introduction

❖ Motivation & background* ❖ Related work (state of the art)

❖ Methods / main contribution

❖ Results / evaluation ❖ Discussion*

❖ Conclusion & future work

❖ References (bibliography)

* optional parts

Example: MIDAS paper

“MIDAS: A Design Quality Assessment Method for Industrial Software”,

Ganesh Samarthyam, Girish Suryanarayana, Tushar Sharma, Shrinath Gupta,

Proceedings of the International Conference on Software Engineering,

San Francisco, 2013

Title should reflect the paper’s content

Why care about the title?

❖ Title: the “name” of your work

❖ Try to make it “pithy”, “catchy”, “attractive”, or “memorable” ❖ Avoid overly short (~2

words) or excessively long (> 10) words

Why care about the abstract?

❖ Abstract: the “face” of your work

❖ Reviewers and readers read the title and abstract to decide if they want to read it further or not ❖ Publicly available for free

access in sites like dl.acm.org and scholar.google.com

http://dl.acm.org

http://scholar.google.com

Abstract: a must for any kind of technical writing

Tool demos

Technical briefings

Posters

White papers

Articles

Research papers Experience reports

Case studies

Title example: Smells paper

Towards a Principle-based Classification of Structural Design Smells

“Towards” indicates that it is a relatively early work

The paper is about classification of smells that is based on design principles

Download here: www.jot.fm/issues/issue_2013_06/article1.pdf

http://www.jot.fm/issues/issue_2013_06/article1.pdf

Abstract example: Smells paper

Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.

211 words


Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our

study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.

Why care about this topic?


Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and

address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In

order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.

What “gap” or “whitespace” does this

work fill or address?


Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an

effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To

evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.

What is the “contribution” of the work?


Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a

novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for

design smells and also highlight several interesting observations and insights that result from our work.

What is the evidence that this approach works? How can you

substantiate your claims?


Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about

their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.

What exactly does this paper cover?

Title example: MIDAS paper

“MIDAS: A Design Quality Assessment Method for Industrial Software”

Acronym: can refer to it as “MIDAS” paper

Name could imply “MIDAS touch” => transform your software to “gold” quality!

The paper is about a method for assessing design quality of

software developed by IT companies

Abstract example: MIDAS paper

Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.

185 words



What is the context of this paper?

Why this work is important in this

context?


Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software

design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.

What “gap” or “whitespace”

does this work fill or address?

Abstract example: MIDAS paperSiemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA

and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We

believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.

What exactly does this work cover?

What is the “contribution”?


Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-

specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to three projects in CT DC AA. We believe that the

insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.

What does this paper (not the overall work)

cover?


Siemens Corporate Development Center Asia Australia (CT DC AA) develops and maintains software applications for the Industry, Energy, Healthcare, and Infrastructure & Cities sectors of Siemens. The critical nature of these applications necessitates a high level of software design quality. A survey of software architects indicated a low level of satisfaction with existing design assessment practices in CT DC AA and highlighted several shortcomings of existing practices. To address this, we have developed a design assessment method called MIDAS (Method for Intensive Design ASsessments). MIDAS is an expert-based method wherein manual assessment of design quality by experts is directed by the systematic application of design analysis tools through the use of a three view-model consisting of design principles, project-specific constraints, and an “ility”-based quality model. In this paper, we describe the motivation for MIDAS, its design, and its application to

three projects in CT DC AA. We believe that the insights from our MIDAS experience not only provide useful pointers to other organizations and practitioners looking to assess and improve software design quality but also suggest research questions for the software engineering community to explore.

Why should you care?

Who should read this?

Which one is a better abstract?Fred Brooks in his book “The Mythical Man Month” describes how the inherent properties of software (i.e. complexity, conformity, changeability, and invisibility) make its design an “essential” difficulty. Good design practices are fundamental requisites to address this difficulty. One such good practice is that a software designer should be aware of and address “design smells” that can manifest as a result of his design decisions. However, our study of the vast literature on object-oriented design smells reveals the lack of an effective organization of smells that could better guide a designer in understanding and addressing potential issues in his design. In order to address this gap, we have adopted a novel approach to classify and catalog a number of recurring structural design smells based on how they violate key object oriented (OO) design principles. To evaluate the usefulness of our design smell catalog, we first asked Siemens CT DC AA architects to use it to identify design smells in their projects, and later elicited feedback from them about their experience. The feedback received indicates that these architects found the catalog to be very useful. In this paper, we present our catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.


Smells paper MIDAS paper

• Effective motivation and background • Cute acronym (helps cite, recall, or refer)• Mentions who this paper is for and

benefits of reading it (target audience)

Template to get started with1. What is the context of this paper?

2. Why this work is important in this context?

3. What “gap” or “whitespace” does this work fill or address?

4. What exactly does this overall work (not the paper) cover?

5. What exactly is the “contribution” of your paper?

6. What does this paper (not the overall work) cover?

7. What is the evidence that this approach works? (substantiate your claim)

8. Why should someone care about your work or paper?

9. Who should read this? (target audience)

Marked in bold are the key parts of the paper and the abstract

Writing abstracts: tips & best practices

Tip #1

Ensure the title and abstract are free of

“grammatical errors”

Reflects poorly on the quality of the rest of the paper

[Embarrassing to have typos or grammatical errors in the title or abstract]

Tip #2

Write abstract after you have written the paper

Once you completed writing the paper, it is easier to summarise it (abstract is a summary!)

[of course, you can start with a rough abstract but make sure you revisit it after completing the paper]

Tip #3

Write “self-contained” abstracts

Abstract should not refer to tables, figures, or cite other papers

[of course, there are exceptions; consider this as a rule of thumb]

Tip #4

Abstract must be short and effective; try to “arouse

curiosity” to read the full paper

The abstract should be a single paragraph; be creative in encouraging reader to read the whole paper

[most papers are “write-only” papers - try writing a paper that people would like to read!]

Tip #5

Do not copy paste abstract from conclusion section!

Abstract and conclusion have distinct purposes

[Of course there will be some overlaps between abstract and conclusion, but they should not be clones.]

Tip #6

Revise, Revise, ReviseRevise the abstract multiple times to improve it

[Even the best writers revise their writing multiple times to get it to publishable quality text. So, don't hesitate to revise.]

You can write too!

Further reading

❖ Writing Research Papers (Rice University)

❖ How to Write Research Papers? (Tao Xie)

❖ “Writing Good Software Engineering Research Papers” (Mary Shaw)

❖ How to Write a Great Research Paper (Simon Peyton Jones)

http://www.ruf.rice.edu/~bioslabs/tools/report/reportform.html

http://taoxie.cs.illinois.edu/publications/writepapers.pdf

https://www.cs.cmu.edu/~Compose/shaw-icse03.pdf

http://research.microsoft.com/en-us/um/people/simonpj/papers/giving-a-talk/writing-a-paper-slides.pdf

[email protected] @GSamarthyam

www.codeops.tech slideshare.net/sgganesh

+91 98801 64463 bit.ly/ganeshsg

http://www.designsmells.com

mailto:[email protected]

http://twitter.com/GSamarthyam

http://www.codeops.tech

http://slideshare.net/sgganesh

http://bit.ly/ganeshsg

http://www.amazon.com/Oracle-Certified-Professional-Programmer-1Z0-809/dp/1484218353

How to Write Abstracts

Software

Transcript of How to Write Abstracts