The notes below affect technical papers in information technology and electrical engineering, with focus on papers in systems and systems.

Provide the paper to someone else to see. If you’re able to, find a couple: one individual acquainted with the technical matter, another only generally acquainted with the region.

Papers could be divided roughly into two groups, namely original research papers and survey papers. You will find papers that combine the 2 elements, but many publication venues either only accept either type or require author to recognize if the paper ought to be evaluated like a research contribution or perhaps a survey paper. (Most research papers have a “related work” section that may be considered market research, but it’s usually brief when compared with all of those other paper and just addresses a significantly narrower slice from the field.)

Research Papers

A great research paper includes a obvious statement from the problem the paper is addressing, the suggested solution(s), and results achieved. It describes clearly what’s been done before around the problem, and what’s new.

The aim of a paper would be to describe novel technical results. You will find four kinds of technical results:

1. An formula
2. A method construct: for example hardware design, software system, protocol, etc. One objective of the paper is to make sure that the next one who designs a method like yours does not result in the same mistakes and uses a number of your very best solutions. So make certain the hard problems (as well as their solutions) are discussed and also the non-apparent mistakes (and the way to prevent them) are discussed. (Craig Partridge)
3. A performance evaluation: acquired through analyses, simulation or measurements
4. A theory: composed of an accumulation of theorems.

A paper should concentrate on

• describing the outcomes in sufficient details to determine their validity
• identifying the novel facets of the outcomes, i.e. what new understanding is reported and important non-apparent
• identifying the value of the outcomes: what enhancements and impact will they suggest.

Paper Structure

• Typical outline of the paper is:
  • Abstract, typically only 100-150 words
  • Introduction (brief!): introduce problem, outline solution the statement from the problem will include a obvious statement why the issue is important (or interesting).
  • Related Work (or before summary). Hint: Within the situation of the conference, make certain to cite the job from the PC co-chairs so that as a number of other PC people much like remotely plausible, in addition to from anything relevant in the previous two proceedings. Within the situation of the journal or magazine, cite anything relevant from last 2-three years approximately volumes.
  • Outline of all of those other paper: “The rest of the paper is organized the following. In Section 2, we introduce. Section 3 describes. Finally, we describe future operate in Section 5.” [Observe that Section is capitalized. Also, vary your expression between “section” being the topic of the sentence, as with “Section 2 discusses. ” and “In Section, we discuss. “.]
  • Body of paper
    • problem
    • approach, architecture
    • results

    Your body should contain sufficient motivation, with a minumum of one example scenario, preferably two, with illustrating figures, adopted with a crisp generic problem statement model, i.e.

    

    functionality, particularly emphasizing “new” functionality. The paper might include formalisms. General evaluations of the formula or architecture, e.g. material showing the formula is O(log N), click here, away from the evaluation section.

    

    Architecture of suggested system(s) to do this model ought to be more generic than your personal peculiar implementation. Always include a minumum of one figure.

    Realization. contains actual implementation details when applying architecture is not totally straightforward. Mention briefly implementation language, platform, location, dependencies on other packages and minimum resource usage if pertinent.

    Evaluation. So how exactly does it truly operate in practice? Provide real or simulated performance metrics, finish-user studies, mention exterior technology adoptors, or no, etc.

  • Related work, otherwise done at the start
  • Summary and Future Work
    • frequently repeats the primary result

  • Acknowledgements
  • Bibliography
  • Appendix (to become cut first if made to):
    • detailed protocol descriptions
    • proofs using more than two lines
    • other low-level but important details

It’s suggested that you simply write the approach and results sections first, which are together. Then problem section, if it’s outside of the introduction. Then your conclusions, then your intro. Write the intro last because it glosses the conclusions within the last sentences. Finally, write the abstract. Last, provide your paper a title.

Title

• Avoid basically probably the most readily understood abbreviations.
• Avoid common phrases like “novel”, “performance evaluation” and “architecture”, since nearly every paper will a performance look at some architecture also it had better be novel. Unless of course somebody really wants to see 10,000 Google results, nobody looks for these kinds of words.

Use adjectives that describe the distinctive options that come with your projects, e.g. reliable, scalable, high-performance, robust, low-complexity, or low-cost. (You will find clearly exceptions, e.g. once the performance evaluation may be the core from the paper. Even just in that situation, some thing specific is more suitable, as with “Delay measurements of X” or “The caliber of service for FedEx deliveries”.)

Abstract

• The abstract must not contain references, as it might be utilized with no primary article. It’s acceptable, while not common, to recognize work by author, abbreviation or RFC number. (For instance, “Our formula relies upon the job by Cruz and Wesson.”)
• Avoid utilization of “within this paper” within the abstract. The other paper will you be speaking about here?
• Avoid general motivation within the abstract. You don’t have to warrant the significance of the web or explain what QoS is.
• Highlight not only the issue, but the principal results. Lots of people read abstracts after which decide whether to concern yourself with all of those other paper.
• Because the abstract will be utilised by search engines like google, make sure that terms that identify your projects are located there. Particularly, the any protocol or system developed and also the general area (“service qualityInch, “protocol verification”, “service creation atmosphere”) ought to be within the abstract.
• Avoid equations and math. Exceptions: Your paper proposes E = m c 2 .

Introduction

• Avoid stock and cliche phrases for example “recent advances in XYZ” or anything alluding towards the development of the web.
• Make certain that introduction lets the readers understand what this paper is all about, not only how important your current section of scientific studies are. Readers will not stick to you for 3 pages to discover what you’re speaking about.
• The introduction must motivate your projects by pinpointing the issue you’re addressing after which give an introduction to your approach and/or contributions (and possibly a general description of the results). In this manner, the intro creates my expectations throughout your paper — it offers the context, along with a preview.
• Repeating the abstract within the introduction is a total waste of space.
• Example bad introduction:

At the institute for computer research, me and my colleagues have produced the SUPERGP system and also have applied it to many toy problems. We’d formerly fumbled with earlier versions of SUPERGPSYSTEM for some time. This technique enables the programmer to simply try plenty of parameters, and problems, but contains a special constraint system for parameter settings and LISP S-expression parenthesis counting.

Looking space of GP is big and lots of things we are planning on putting in to the supergpsystem can make this space a lot more colorful.

Body of Paper

Bibliography

• Avoid utilization of et al. inside a bibliography unless of course list is extremely lengthy (five or even more authors). The writer subsumed into et al. might be your consultant or even the reviewer. Note punctuation of et al..
• If covering systems or multimedia, make use of the network bibliography. All records not found there must be delivered to me. All of the frequently-used references for systems can be obtained.
• Internet drafts should be marked “work in progress”.
• Book citations include publication years, but no ISBN number.
• It’s now acceptable to incorporate URLs to material, but it’s most likely bad form to incorporate a URL pointing towards the author’s web site for papers printed in IEEE and ACM publications, because of the situation. Apply it software along with other non-library material. Avoid lengthy URLs it might be sufficient to suggest towards the general page and allow the readers discover the material. General URLs will also be less inclined to change.
• Leave an area between first names and surname, i.e. “J. P. Doe”, not “J.P.Doe”.

Acknowledgements

• Generally, anonymous reviewers do not get acknowledged, unless of course they provided a fantastic degree of feedback or insight. Instead of “We thank X in order to us with Y”, you may vary this as “X contributed to Y.”.

Reporting Statistical Results and Simulations

In basically extended abstracts, statistical results and simulations ought to be reported in enough detail the readers can duplicate the outcomes. This will include all parameters used, warning signs of the amount of samples that led to case study and then any initial conditions, if relevant.

When presenting simulation results, provide understanding of the record confidence. If possible, provide confidence times. Should there be a “strange” behavior within the graph (e.g. a dip, peak or alternation in slope), this behavior either must be described or reasons should be given why this is just because of record aberration. Within the latter situation, gathering more samples is most likely advised.

Figures ought to be selected wisely. You cant ever construct the entire parameter space, so provide understanding of which parameters are significant over what range and which of them are less important. It isn’t very entertaining to provide plenty of flat or straight line lines.

The outline from the graph shouldn’t just repeat the graphically apparent for example “the delay increases using the load”, but explain, for instance, how this increase pertains to the burden increase. Could it be straight line? Will it follow some well-known other system behaviors for example standard queueing systems?

LaTeX Factors

• You don’t need to enclose figures in $$ (math mode).
• Use cite. not cite cite cite.
• Make use of the usepackage choice for LaTeX2e – it comes down out much better on printers with various resolutions. Plus, when compared with cmr, it most likely squeezes an additional 10% of text from your conference allotment.
• Multi-letter subscripts are positioned in roman, not italics. For instance,
• For uniformity, make use of the LaTeX2e graphics set, not the sooner psfigure set:

Items to Avoid

• An excessive amount of motivational material: three reasons are sufficient — and they must be described very briefly.
• Describing the apparent areas of the end result: “Apparent” is understood to be any result that the graduate in our program indicate like a solution should you pose the issue the result solves.
• Describing unnecessary details: a detail is unnecessary, if it is omission won’t harm the reader’s capability to comprehend the important novel facets of the end result.
• Spelling errors: Using the accessibility to spell checkers, there’s pointless to possess spelling errors inside a manuscript. Should you because the author did not take time to spell-look at your paper, why must the editor or reviewer take time to see clearly or trust that the diligence in technical matters is any greater than your diligence in presentation? Note, however, that spell checkers don’t catch all common errors, particularly word duplication (“the the”). If uncertain, consult a dictionary like the (online) Merriam Webster .

Guidelines for Experimental Papers