Cloud Security and Privacy Models
Cloud, Security, Privacy, Models
This document provides you with some tips and some resources to help you write a technical research paper, such as you might write for your required capstone project paper. First, congratulations are in order– you are embarking on an activity that is going to change the way you think and add to the overall body of human knowledge.
The skill of gathering information, deciding what is important, and writing about it for someone else is extremely valuable and will stay with you for the rest of your life. Because we humans have been doing this for quite some time, we have some reasonably standard forms for technical research papers, which you should use for your capstone.
You should do this because your paper will better understand by readers who are familiar with this form. Before you can begin writing your paper, you need to have a sense for what research entails, so I’ll start there. Then I will give you some tips about writing, including connecting with your readers, defining your topic, the format of your paper, and how to include references from the literature. I am a computer scientist, so be aware that parts of this paper are biased toward my discipline.
2 What is Research?
A short definition of research, as given by Booth, Colomb, and Williams (Booth et al., 1995) is “gathering the information you need to answer a question and thereby help you solve a problem” (p. 6). You have all found a problem that you’re interested and are busy gathering information to help you answer questions that you have encountered along the way.
You should be gathering this information from trusted sources, such as articles from refereed journals, articles from edited magazines from professional societies, articles from refereed proceedings of conferences, and books. You should be aware that articles published only on the Internet are not necessarily considered trusted sources and should be used sparingly.
3 Understanding Your Readers
Though you are working closely with your capstone advisor who is primarily reading your drafts, you should be writing for a broader audience. You want to write with your readers in mind. In your case, your readers might be professionals who are familiar with your topic, or they might be a more general audience, who may or may not have differing levels of understanding of your topic area. Booth, Colomb, and Williams (Booth et al., 1995) suggest that you keep the following questions in mind while you are writing:
- Who are your readers?
- What do they expect you to do for them? In your case you are trying to inform them, not entertain them.
- How much do they know?
- Do they already understand your problem/question? You should not assume this in your paper– you should provide some background and explanation of what you have studied.
- How will they respond to your solution/answer? You must try to anticipate questions or misunder- standings that they might have and provide enough explanation to avoid them.
- In what forum will they encounter your report? You should be writing your technical research paper as if it might be published in a journal, professional society magazine, or conference proceedings. Because of this, there are some standards for formatting that you should use, and are discussed later.
4 Define and Narrow Your Topic
Hopefully by now you’ve got a topic selected and you have done most of your literature search and have begun your implementation, if your project has such a component.
One of the things that you might be struggling with is the large amount of information you have and deciding what you should include in your paper. You can make this decision easier by first developing questions that can be answered from what you’ve read so far. This may lead to a few more questions, so this process is cyclical.
Let’s consider some of these questions. They should be of the standard who, what, when, where, why variety. As an example, suppose that you are researching the topic of database visualization tools. You might start with a few very high-level questions that your paper will answer, such as:
- Where is database visualization in the larger topic of information visualization?
- Is it found in any other categories of research? Is it related to any other areas of research?
- What is the history of database visualization?
- Who has made advances in database visualization?
- What was the significance of those advances? Why were their results important?
- What good is database visualization? What can it do for you?
You will find many answers for these questions, and your task is to narrow down what you plan to use to something manageable. The last item above is one that will have both positive and negative answers. Another important aspect of that last item is defining who ’you’ is. It may be your readers, but it may instead be a particular group of users. It may also be that questions like this don’t have answers of practical significance. This does not mean that it is not worthy of research.
You next should try to refine these questions into more specific ones, and start developing answers. You might even decide that database visualization as a topic is too wide and that you will concentrate on “Architectural Support for Database Visualization,” thereby eliminating topics such as novel database visualization methods and concentrating on the computer systems aspects of database visualization. As an example of how to refine the above questions, we could start with the following ideas:
Many databases today are massive, with many dimensions in the data.
People who need to analyze this data have difficulty analyzing it in its native form, which is tabular. Overall characteristics of a data set are difficult to discern when sifting through millions of rows in a table.
A similar problem is faced by scientists with very large computed data sets, such as from fluid flow simulations. In scientific visualization, significant advances were made in graphics hardware and visualization software that enabled these scientists to see the trends and important data points in their data sets.
Database visualization research strives to find mappings from tabular database data to visual displays that will enable analysts of databases other than scientific data to see trends, outliers, anomalies, and patterns in their data.
Ahlberg and Schneiderman (Ahlberg and Schneiderman, 1994) were able to combine methods for defining database queries using GUI elements with 2-dimensional scatterplot displays into a single interactive
Database visualization tool. Their result was important because it was one of the first cases of defining a coupling between database queries and a corresponding interactive visualization that showed many data points at once.
With these statements, you have begun to answer some of the larger questions given above. Notice that you’ve defined who can benefit from research in this area. During the refining process, you will continue describing how individual researchers (and perhaps yourself, if you are that lucky) have developed a technique or described a method that will enable users of database visualization tools or methods to analyze their data in a way that was not possible previously, and you will describe why their advance was important.
Eventually, you are also going to develop some ideas for what still needs to be done and what has not been solved yet. You will also start to define these ideas, which could lead to a research problem you would like to solve. We don’t expect this to occur to any large measure for most capstone projects, but you should be looking out for it. Even if you are unable to implement a new method or complete a proof, you should still be able to articulate what research still needs to be done, and you may even be able to describe possible solutions.
To narrow your topic and what you will report about it, you should find yourself developing answers t hat you deem insignificant or off the main point of the problem that you are trying to address. So it is also important to think about that problem.
5 From Questions to a Problem Statement
Once you begin formulating answers to some of the questions that I mentioned previously, you can then start to formulate an overall problem statement about your topic. Defining the problem that you are addressing can be a struggle, but it is important for several reasons. It should help you stay on course and not stray too far afield.
It should enable you do succinctly describe to your readers and anyone else who asks what you have been studying and why. As you struggle and improve, you will be developing a skill that you will find useful later in life, whether you are conducting research or working for someone who has a problem for you to solve.
The following is a form to follow for developing a problem statement, as suggested by Booth, Colomb, and Williams (Booth et al., 1995). I recommend that you find a copy of this book and look at what they have to say about this in Chapter 4. This book also has some other very useful information about writing a research paper, only some of which I will be able to cover in this document.
- Name your topic:
I am writing about ,
- State your indirect question (and thereby define the condition of your problem):
. . . because I am trying to show you who/how/why
. State how your answer will help your reader understand something more important yet (and thereby define the cost of not knowing the answer):
. . . in order to explain to you how/why.
Of course, you may not be able to make just one sentence out of this, but you should try to make your problem statement as concise as possible. Once you have this, it should keep you grounded as you write. Another added benefit of doing this is that you will have a nice concise and straightforward way to begin your oral presentation on your topic.
6 Supporting Your Position
During your research of current literature, you will develop questions and answers to those questions. You may also develop unanswered questions and devise possible answers to those questions. When you are writing, imagine you are having a conversation with your readers. You wish to make yourself clear by articulating your position– what questions you are studying and why you have answered them the way that you have. You do this throughout your paper by making claims and supporting them with evidence.
Most of what I have talked about so far has to do with developing your claims. It is important that you have these well-articulated. It is your evidence to support your claims that make up the majority of your paper. You must convince your readers that your claim is correct, because your supporting evidence is, according to Booth, Colomb, and Williams, “accurate, precise, sufficient, representative, authoritative, and perspicuous” (Booth et al., 1995).
Perspicuity refers to making certain that users see what you want them to see from a piece of data or other evidence. Chapter seven of this book describes this and these other concepts in detail.
The most important thing to remember about supporting your claims with evidence is that you provide sources for claims of fact that you make. You do this by referring to the literature within your text. For example, I might make the following statement in a paper:
Human interaction and intervention is critical to the effectiveness of visualization of financial data (Lux, 1997) and to the exploration of multi-dimensional data spaces (Ahlberg and Schneiderman, 1994).
While you are writing, you will need to decide how passionate you are about your position. You can take a pretty strong stand and back it up, or you can be an observer who carefully comes to a conclusion after considering many points of view. One way or the other, have an opinion of your own, based on your research.
7 The Paper Format
Once you have gathered your claims and supported them with evidence, you need to organize them into a paper format with which readers of scientific research papers will be familiar. I will describe the parts of most research papers in the order in which they typically appear in a technical research paper.
The title of your paper should communicate clearly what your paper is about. Do not try to be overly clever or witty.
You should not write this until your paper is complete. The abstract should contain the main messages of your paper, in the form of a definition of the problem you researched and what your conclusions were at a very high level. If you have your own accomplishments to report, these should be described at a high level.
Under no circumstances should you copy sentences from your paper into your abstract. You are writing at a much higher level here. To get a sense for this, read over several abstracts from papers that you gathered during your research. The abstract is short – no more than 250-300 words – so you need to be concise.
In this section, you introduce your topic and explain the problem you are investigating. Earlier in this paper, I described how to define your problem and formulate a problem statement. You can use this in your introduction. You explain how this problem fits in a larger context, you provide some motivation for why
This topic is of importance, and you provide some historical context. Some of the example questions I posed earlier can help you with how to explain these. When you write about historical context in terms of who has done what, use first person active voice and refer to the author’s last names. For example repeated from earlier:
Ahlberg and Schneiderman (Ahlberg and Schneiderman, 1994) were able to combine methods for defining database queries using GUI elements with 2-dimensional scatterplot displays into a single interactive database visualization tool.
The introduction is also where you should summarize your findings in some way and tell your reader where all the detail you are about to present will lead them. A technical paper is not a mystery novel. After reading the introduction, your reader should have a good idea of where you are going to take them. You should be providing a framework onto which you will be adding during the subsequent sections of the paper.
Some writers recommend writing the introduction after writing the other subsequent sections of the paper. You will at the very least need to revisit the introduction after the paper is completed.
7.4 Background and Motivation [optional]
If a paper is fairly large and has an extensive amount of background material and/or a long description of your motivation for studying such a problem, you might want to include this in a separate section from the introduction.
7.5 Sections with names of your choice
Following the introduction, you lay out the sections of your paper in some way that helps you organize your main messages that you are trying to get across (your claims and their supporting evidence). You might have an initial section that describes your problem by way of example. If you implemented a method or devised a solution to a problem, you will want to have a section for that. Use sections that break up your presentation of ideas into logical parts.
A formal scientific paper in other disciplines such as Biology contains these sections: Methodology, Results, Discussion. Though we frequently stray from using these section headings in Math and Computer Science, the general concept is still there. You should explain what you did, what resulted, and provide a discussion of those results. This format will pertain for those few of you who might perform some computational experiments (if you tested several algorithms to determine their speed of execution, for example).
7.6 Discussion and Future Work
You should give your readers a sense for where you might go from here with your work, or what questions remain unresolved. Try to tell your reader what work still remains to be done to solve any remaining problems. Or you may be able to speculate what the results you have presented will lead to in the future. The idea here is that with this piece of the puzzle, we will now be able to accomplish something that we could not previously accomplish. You should try to explain that.
Here you summarize your findings. You try to wrap up what you have presented to your reader in a tidy package. You may wish to combine this with the discussion and future work section.
Some people call this section ’References Cited’, ’Literature Cited’, or ’Selected Bibliography’. It is technically incorrect to just call it a bibliography, because that refers to all literature citations on any particular subject. This section will contain only references to works cited within your paper. You should not use footnotes or end notes in place of this section.
There are several formats that are acceptable for this section, and corresponding ways to refer to these entries within the text. You should choose one method and stick to it. The Chicago Manual of Style (University of Chicago Press, 1993) contains examples. There are also other style formats, which are nicely described in a writer’s handbook at the web page of UW-Madison’s Writing Center (University of Wisconsin Writing Center, 2003).
The Macalester Library has developed a web page of online references for style (Macalester College Library Staff, 2003), which I encourage you to refer to for more information. This includes a link to the Columbia Guide to Online Style (Columbia University Press, 2003) and other sites that will help you with how to format your references to online material, such as papers on the web and discussion lists and newsgroups. You’ll see that I have used the styles documented there for web page sources provided in this paper.
This paper uses a style like that documented by the American Psychological Association (APA), in which the author and year are presented in the text, and the references in the references cited section are in alphabetical order by the last name of the first author. An alternative is to number the references and refer to the numbers within brackets in the text. With this style, the references in the references cited section are either in order of their appearance in the text, or in alphabetical order.
If you use software such as latex and bibtex or endnote, the process of organizing your references can be easier. I built this paper using latex and bibtex on a linux machine, and chose the APA style. There are other styles that you could use instead. For example, I could easily reprocess this document with the IEEE style and produce a document with the style that the Institute for Electrical and Electronic Engineers requires for their publications.
8 Books about Writing
The Macalester College Library has several books in the reference section and in the stacks on writing in general and writing technical papers. I particularly like Strunk and White (White et al., 1999) and Williams (Williams, 2000) for general style and Turabian (Turabian, 1996) for information about technical paper writing.
Ahlberg, C. and Schneiderman, B. (1994). Visual information seeking: tight coupling of dynamic query filters with starfield displays. In Proceedings of the ACM CHI9́2 Conference, pages 313–317.
Booth, W. C., Colomb, G. C., and Williams, J. M. (1995). The Craft of Research. The University of Chicago Press. ISBN: 0-226-06584-7.
Columbia University Press (2003). Columbia guide to online style. http://www.columbia.edu/cu/cup/cgos/idx basic.html (2 Feb. 2003.
Lux, M. (1997). Visualization of financial data. In Proceedings of the Workshop on New paradigms in Information Visualization, pages 58–61.
Macalester College Library Staff (2003). Citing resources and preparing publications. http://www.macalester.edu/library/research/general/citing.html (2 Feb. 2003).
Turabian, K. L. (1996). A Manual for Writers of Term Papers, Theses, and Dissertations (Chicago Guides to Writing, Editing, and Publishing). University of Chicago Press. ISBN: 0226816273.
University of Chicago Press (1993). The Chicago Manual of Style. The University of Chicago Press, 14th edition. In Mac Library Reference Section.
University of Wisconsin Writing Center (2003). Writer’s handbook. http://www.wisc.edu/writing/Handbook/Documentation.html (2 Feb. 2003).
White, E., Angell, R., and Strunk, W. (1999). The Elements of Style. Allyn & Bacon, 4th edition. ISBN: 0205313426.