how to write abstracts
TRANSCRIPT
![Page 1: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/1.jpg)
For writing technical reports, white papers, research papers, …
How to write abstracts?
Ganesh SamarthyamCo-founder (CodeOps Tech.)Author, writer, conference speaker [email protected]
![Page 2: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/2.jpg)
If you can write, you're an author!
Just like Nike’s mission statement - every one is an author!
![Page 3: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/3.jpg)
If she can, you can
If she can write, you can write
too!
![Page 4: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/4.jpg)
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
![Page 5: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/5.jpg)
Some of my publications
https://scholar.google.co.in/citations?user=3Zksd94AAAAJ
![Page 6: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/6.jpg)
Translations in other languages
https://books.google.co.in/books?id=x--MCwAAQBAJ
Korean!
![Page 7: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/7.jpg)
Writing => Influence => Leadership
Grady Booch
Martin Fowler Kent Beck
Robert C. Martin
![Page 8: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/8.jpg)
But I am a techie, not a writer!
![Page 9: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/9.jpg)
You don't need a Ph.D to write papers !
![Page 10: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/10.jpg)
Techie + Don't have a Ph.D
Grady Booch
Martin Fowler Kent Beck
Robert C. Martin
![Page 11: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/11.jpg)
Writing abstracts
![Page 12: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/12.jpg)
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
![Page 13: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/13.jpg)
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
![Page 14: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/14.jpg)
Title should reflect the paper’s content
![Page 15: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/15.jpg)
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
![Page 16: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/16.jpg)
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
![Page 17: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/17.jpg)
Abstract: a must for any kind of technical writing
Tool demos
Technical briefings
Posters
White papers
Articles
Research papers Experience reports
Case studies
![Page 18: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/18.jpg)
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
![Page 19: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/19.jpg)
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
![Page 20: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/20.jpg)
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.
Why care about this topic?
![Page 21: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/21.jpg)
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.
What “gap” or “whitespace” does this
work fill or address?
![Page 22: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/22.jpg)
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.
What is the “contribution” of the work?
![Page 23: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/23.jpg)
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.
What is the evidence that this approach works? How can you
substantiate your claims?
![Page 24: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/24.jpg)
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.
What exactly does this paper cover?
![Page 25: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/25.jpg)
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
![Page 26: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/26.jpg)
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
![Page 27: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/27.jpg)
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.
What is the context of this paper?
Why this work is important in this
context?
![Page 28: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/28.jpg)
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.
What “gap” or “whitespace”
does this work fill or address?
![Page 29: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/29.jpg)
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”?
![Page 30: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/30.jpg)
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.
What does this paper (not the overall work)
cover?
![Page 31: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/31.jpg)
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.
Why should you care?
Who should read this?
![Page 32: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/32.jpg)
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.
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.
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)
![Page 33: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/33.jpg)
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
![Page 34: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/34.jpg)
Writing abstracts: tips & best practices
![Page 35: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/35.jpg)
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]
![Page 36: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/36.jpg)
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]
![Page 37: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/37.jpg)
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]
![Page 38: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/38.jpg)
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!]
![Page 39: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/39.jpg)
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.]
![Page 40: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/40.jpg)
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.]
![Page 41: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/41.jpg)
You can write too!
![Page 42: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/42.jpg)
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)
![Page 43: How to Write Abstracts](https://reader037.vdocuments.us/reader037/viewer/2022092803/58d0f9a91a28abc00b8b5c67/html5/thumbnails/43.jpg)
[email protected] @GSamarthyam
www.codeops.tech slideshare.net/sgganesh
+91 98801 64463 bit.ly/ganeshsg