how much time our assignment have required for submitted.
Which assignment you are talking about
Professor Hossein Saiedian
Department of Electrical Engineering & Computer Science
School of Engineering • University of Kansas
One of the requirements of the graduate software engineering courses is that you conduct research and write a research paper on some aspects of software engineering. The paper may present original work, discuss a new technique, provide a survey and evaluation of recent work in a given area, or give a comprehensive and taxonomic tutorial information. The paper must emphasize concepts and the underlying principles and should provide authentic contribution to knowledge. If your paper does not represent original work, it should have educational value by presenting a fresh perspective or a synthesis of existing knowledge. The purpose of this document is to provide you with some guidelines. You are, however, encouraged to consult
additional resources that assist you in writing a professional technical paper.
The organization of this document is as follows. In Section 2, I’ll explain why it is important to write a research paper. Issues related to the paper topic are briefly discussed in Section 3. In
Section 4, issues related to the organization of your paper are discussed. Evaluation criteria are
given in Section 5. Sections 6 and 7 review formatting requirements and additional resources.
Section 8 presents an epilogue.
Why a Research Paper?
There are many reasons why you should enhance your skills in writing a research paper. The most important ones are as follows:
You should become familiar with the body of literature on “software engineering.” Through this process, you will become familiar with important computer science and software engineering literature, well-known authors and researchers, and the institutions where important research is taking place. Note that the emphasis here is on primary literature, i.e., reputable and original research publications. This definition excludes “review” and trade magazines. Examples of primary literature include: IEEE Software, IEEE Computer, ACM SIGSOFT Notes, Journal of Systems and Software, Communications of the ACM, ACM Transactions on Software Engineering and Methodologies, IEEE Transactions on Software Engineering, Software — Practice and Experience, Springer-Verlag series on Lecture Notes in Computer Science, and proceedings of conferences such as the International Conference on Software Engineering.
It is important that you learn how to find out what has been reported in the literature and how to actually obtain a research article. This includes taking advantages of local libraries, various on-line databases and the services of the Interlibrary Loan at the KU libraries.
Writing a dissertation is a must for Ph.D. students; a thesis option is becoming increasingly popular and valuable for Master’s students. Writing a research paper at this time provides you with the necessary background and experience that you will need to write a quality thesis or dissertation later.
By writing a research paper, you will develop an in-depth knowledge of a particular area in software engineering and will enhance your technical reading/writing abilities. It is important that you learn how to evaluate a body of literature and interpret it instead of just reporting what has been done.
It is also important that you learn how to set a research objective, define its scope, and to explicitly define its expected contributions. If you want your paper to be effective, you must have a well- and, clearly defined purpose; it is the purpose that holds together a piece of writing and gives it substance.
3. Research Topic
The topic of research paper is largely up to you. Make it as narrow as possible by focusing on a very specific issue. Tackling too broad a topic makes your task difficult and a cohesive, thorough paper almost impossible. To help ensure this and to assure that both the topic and the focus are appropriate, please turn in the following items:
Table 1: Due Dates
|Proposal and 10–15 relevant references||3rd week of the semester|
|Detailed outline of the paper||6th week of the semester|
|First draft of the paper||12th week of the semester|
|Final draft||Week before the finals|
Note that it is the contents that counts. Thus no page limit is set. However, a thorough examination of a topic will probably require around 3,500–4,500 words (or around 15-20 single
spaced pages with one inch margins) to adequately discuss an issue.(*1)
4. Paper Organization
You should choose a descriptive title for your paper. The paper should have an abstract followed by the body of the paper followed by an annotated bibliography. The body of the paper should be divided into appropriately numbered sections, sub-sections, sub-sub-sections, etc.,
each with descriptive titles. A brief description of the major sections of your paper appears in the following subsections. Specific formatting requirements are given in Section 6.
Descriptive Title. The title of your paper should be as informative as possible and should clearly identify both the general field of the paper and the particular branch of it under consideration.
Abstract. An abstract is a synthesis of your paper and should briefly describe its significance.
It should enable the readers to take in the nature and results of the paper quickly and decide whether they wish to read further. The size should be about half a page (single-spaced) and serve as a brief review of the paper’s contents and contributions. Make it clear and concise. Use full sentences and avoid references and technicalities. At the end of the abstract, you should
include 5–6 important keywords and/or phrases.
Introduction. The introductory section should provide a bridge from the abstract to the remaining discussion sections or the body of the paper. The first paragraph should be comprehensible to anyone interested in software engineering and should pinpoint the location of the subject matter. You should define/describe the questions and/or the topic that you will address. By defining and establishing the objectives of your paper in the introductory section, you clarify the goal and set the direction for the rest of the paper. At the end of this section, it is essential to indicate the scope of your paper, define the audience(*2) and describe the organization of your paper so that the readers know what to expect. The introduction should be between one to two pages.
1I recommend using a reasonably powerful editor and word-processor. In particular, I strongly recommend
2| It is a good idea to identify the audience of your paper. While evaluating your paper, I will assume the place of the intended audience to determine in what ways your paper is contributing to my knowledge.
Background/Review of the State of the Art. In the background sections that follow, you should provide an enlarged but focused description of pertinent literature organized clearly around the important questions and/or topics you posed in the introduction. The background information should be provided in enough detail to orient the reader who may not be a specialist in the subject under discussion and should establish connection with other results and studies. Make the background clear, crisp, and logically organized. Recall the following advice by Joseph Pulitzer, “Put it before them briefly so they will read it; clearly so they will appreciate it; picturesquely so they will remember it; and above all accurately so they will be guided by its
Research Question/Your Solution and Results. Present a precise statement of the problem or the question that you plan to address and discuss its significance. You do this by providing an analysis of the models and technologies you reviewed earlier, describing their shortcomings (if any) and how your work (solution) will complement them. Your description of results and evaluations must be well-documented. Make liberal use of tables, figures, and diagrams, and include literature references appropriately. Be concise
and informative. If you write concisely about any topic, you describe it in the fewest possible words but without sacrificing clarity. Do not confuse brevity with conciseness. Make sure there is smooth transition between the (sub-)sections.
Observations, Discussions, Validation This section should present and summarize the major points of your work and convince the reader that you have properly addressed or solved the problem introduced in Section 4. You should be candid in discussing failures as well as successful results. This and the earlier section should constitute the bulk of your term paper.
Conclusions. The conclusions section is placed at the end of the document, right before the bibliography. It concludes the paper by pointing out its major contributions and perhaps indicating interesting areas of research related to the paper’s topic that have not been addressed by you, but deserve future investigation.
References/Bibliography. The conclusions are followed by a list of references (or bibliography) items. Use the Harvard family of bibliographic styles (see the references at the end of this article). There are two primary forms of citation in the Harvard style dependent upon whether the reference is used as a noun or parenthetically. Furthermore, when there are more than
two authors, all authors are listed in the first citation. When you have multiple bibliography items for the same author in the same year, use alphabetic letters “a”, “b”, etc. to properly cite them. In subsequent citations use only the first author’s name followed by ‘et al.’ The following passage illustrates these points:
According to Ross, Goodenough & Irvin (1975), the essence of abstraction is to extract essential properties while ignoring inessential details. Others view abstraction as a process (Ghezzi, Jayazeri & Mandrioli 1998). For example, Ghezzi et al. (1998) state that “Abstraction is a process whereby we identify the important aspect of a phenomenon and ignore its details.” Abstraction is different from information hiding; in general, the purpose of information hiding is to make inaccessible the details that will not affect other parts of a system (Ross et al. 1975). Practically, every article that mentions information hiding traces its origin to (Parnas 1972). Budd (1997b) discusses both abstraction and information hiding in the context of object-oriented
programming. Some authors, e.g., Ghezzi et al. (1998), provide a more generalized view of Parnas’ view on information hiding while others’ are more specialized (Budd 1997a, Budd 1997b). In fact, Budd (1997a) provides specific examples in C++. The bibliography at the end of your paper should be as complete as possible. It is very likely that your references include journal articles, conference proceedings articles, books (or chapters in a book or in a collection), and technical reports. The following is a list of required3
items for each of such article:
• Journal Articles: author, title, journal, volume, number, year, pages [month].
• Books: author (or editor), title, publisher, year, edition, publisher address.
• Book Chapters: same as book and/or conference proceedings articles.
• Conference Proceedings: author, title, proceedings title, pages, year, publisher, [editor, month, place]
• Technical Reports: author, title, institution, year [number, address]
• Thesis/Dissertation: author, title, school, year, [address]
For other types of articles, please make a reasonable judgment as to what items must be included. Normally, author, title, year, and some information about the type of publication should be included. In addition to the URL address, you must include the corresponding author(s), title, and other pertaining information for all URL references. Save all your references
and be prepared to turn in any item if requested (*3).
5. Evaluation Criteria
5.1 Grading Criteria
Your paper will be graded according to the following criteria:
6. Specific Formatting Requirements
An appropriately chosen topic and its well treatment should result in a paper about 3,500-4,500 words. Note that it is the quality of the contents that counts, not the length. If your paper is slightly smaller or larger, it will be OK provided that its contents are acceptable. Please do not take advantage of line spacing, font size and margin size options to force a perceived smaller
or larger paper. It will not work!
Organization. Organize your paper in terms of sequentially numbered sections, subsections, and sub-subsections, each with an appropriate title. The paper organization may be as follows:(*4)
• Paper Title
• Your name and contact information
• Paper abstract
• Introduction (problem statement)
• Background sections (may include a discussion of existing work, literature survey, justification of your work)
• Sections presenting your work (may include your solution, results, evaluations, validation, observations, case studies, application of concepts, etc.)
• Appendices (if necessary, may include items such as a large chunk of code that is necessary to be a part of the paper but is inappropriate to be included in the paper body)
Font Size. Use 11-point or 12-point font size.
Line Spacing. You may prepare your paper in single or double space format. If you choose to prepare in double space format, be sure to single space the title, abstract, itemized and enumerated lists, tables, and the bibliography.
Paper Margins. Allow 1-inch margins on all four sides and justify text on both sides.
Tables and Figures. Number all tables, figures, and similar items and use these numbers to explicitly refer to such items. Include a descriptive caption for each table or figure (or similar items). Be sure to use a uniform/consistent approach for citing such items and for presenting their captions.
Please use this document as a model to organize your paper unless the “templates” you have found are more appropriate for your paper. Additional requirements may be given later.
7. Writing Resources
Zobel (1997) provides many tips on technical writing for computer science which I have found quite helpful and would recommend for further reading. An SEI technical-report by Levine, Pesante & Dunkle (1990) is directed specifically at software engineers, discusses the writing process in the context of software engineering, and suggests techniques for becoming an effective writer. A video version of this technical-report is also available. Please see me if you are interested. My “teaching” website provides links to the KU’s “Resources for Writers” and to other Internet sites that offer very useful advice on research and technical writing. See Appendix for the URL addresses.
When you read an article, in addition to learning its contents, pay close attention to the author’s writing style, sentence construction, referencing style, choice of words, etc. You will become a better writer by paying attention to how good authors write. Observe the mechanics of clear writing. Regardless of whom your audience is, you should use a specific, concrete, and precise language. Vary the length of sentences to maintain the readers’ interest. Make sure your transitions from one sentence to the next and from one paragraph to the next make the connections clear so that your reader can easily follow the flow of your ideas. Finally, pay attention to details; nothing offends a reader faster than incorrect spelling and/or a poorly
prepared document. If spelling is not one of your strong points, keep a dictionary. Watch for typos.
Writing a technical article involves more than just sitting down and writing, even if the subject is within your area of expertise. You must insist on conciseness, clarity, and accuracy and avoid pedantic, verbose, imprecise, and inaccurate materials. Furthermore, instead of simply regurgitating existing and known knowledge, present a synthesis from it.
Your term paper must be original, i.e., it should describe research work done by yourself. You must give appropriate acknowledgment and/or credit to other research work that you have used in preparing your paper. Therefore, it is important that you learn how to cite someone else’s work, when to quote, when and how much materials to include in indented quotations, etc.
Verbatim inclusion of other people’s writing in a paper, without acknowledging and crediting the source, is non-ethical and illegal (because it violates copyright protections). Please follow the link to “How to Quote (To Avoid Unintentional Plagiarism)” on my teaching website. The url is given in the Appendix.
Budd, T. (1997a), Data Structures in C++ Using the STL, Addison-Wesley.
Budd, T. (1997b), An Introduction to Object-Oriented Programming, 2nd edn, Addison-Wesley.
Ghezzi, C., Jayazeri, M. & Mandrioli, D. (1998), Fundamentals of Software Engineering, 2nd edn, Prentice-Hall.
Levine, L., Pesante, L. & Dunkle, S. (1990), Technical writing for software engineers, Technical
Report SEI-CM-23, Software Engineering Institute.
Parnas, D. L. (1972), ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM 5(12), 1053–1058.
Ross, D., Goodenough, J. & Irvin, C. (1975), ‘Software engineering process: Principles, and goals’, IEEE Computer 8(5), 17–27.
Zobel, J. (1997), Writing for Computer Science: The Art of Effective Communication, Springer.
Appendix: Resources for Technical Writing
The following websites offer valuable resources and advice on technical writing:(*5)
• How to quote (or how to avoid unintentional plagiarism):
• KU’s resources for writers:
• Advice on research and writing:
• Technical writing and research ethics: