Enter a detailed keyword. Ex: Syllabus of IGNOU Ist year BSc Computer Science course
Need help about a course?
Visit CollegeZones.com
| Need help about a course? |
| Home / Syllabus / Andhra University / PG Programs / M.Tech / Project Guidelines |
Ask a question Print this page |
|
M.TECH PROJECT GUIDE LINES
The purpose of this note is to describe how to organize the written Dissertation submitted as partial fulfillment of your M.Tech. Degree. The distinguishing mark of a dissertation is an original contribution to knowledge. The dissertation is a formal document whose sole purpose is to prove that you have made an original contribution to knowledge. Failure to prove that you have made such a contribution generally leads to failure. To this end, your dissertation must show two important things: 1) You have identified a worthwhile problem, which has not been previously solved. 2) You have answered the question. Your contribution to knowledge generally lies in your solution or answer. The sole purpose of the dissertation is to prove that you have made an original and useful contribution to knowledge. The examiners need answers to the following questions: * What is this student's research question? * Is it a good question? (has it been answered before? is It a useful question to work on?) * Did the student convince me that the question was adequately answered? * Has the student made an adequate contribution to knowledge? To prove the originality and value of your contribution, you must present a through review of the existing literature on the subject, and on closely related subjects. Then, by making direct reference to your literature review, you must demonstrate that your question (a) Has not been previously answered, and (b) Is worth answering Describing how you answered the question is usually easier to write about, since you have been intimately involved in the details over the course of your studies. A Generic Dissertation Skeleton 1. INTRODUCTION This is a general introduction to what the dissertation is all about - it is not just a description of the contents of each section. Briefly summarize the question (you will be stating the question in detail later), some of the reasons why it is a worthwhile question, and perhaps give an overview of your main results. This is a birds-eye view of the answers to the main questions answered in the dissertation (see above). 2. BACKGROUND INFORMATION A brief section giving background information may be necessary, especially if your work spans two or more traditional fields. That means your readers may not have any experience with some of the material needed to follow your dissertation, so you need to give it to them. A different title than that given above is usually better; e.g., "A Brief Review of Frammis Algebra." 3. REVIEW OF THE STATE OF THE ART Here you review the state of the art relevant to your dissertation. Again, a different title is probably appropriate; e.g., "State of the Art in Zylon Algorithms". The idea is to present (critical analysis a little bit later) the major ideas in the state of the art right up to, but not including, your own personal brilliant ideas. You organize this section by idea, and not by author or by publication. For example if there have been three important main approaches to Zylon Algorithms to date, you might organize subsections around these three approaches, if necessary: 3.1 Iterative Approximation of Zylons 3.2 Statistical Weighting of Zylons 3.3 Graph-theoretic Approaches to Zylon Manipulation 4. PROBLEM STATEMENT Engineering dissertation tend to refer to a problem to be solved. * A concise statement of the question that you dissertation tackles * Justification, by direct reference to section3, that your question is previously unanswered. * Discussion of why it is worthwhile to answer this question. Item 2 above is where you analyze information which you presented in Section 3. For example, may be your problem is to "develop a Zylon algorithm capable of handling very large scale problems in reasonable time" (you would further describe what you mean by "large scale" and "reasonable time" in the Problem statement). Now in your analysis of the art you would show how each class of current approaches fails (i.e. can handle only small problems, or takes too much time. In the last part of this section you would explain why haying a large scale fast Xylon algorithm is useful; e.g., by describing applications where it can be used. 5. DESCRIBING HOW YOU SOLVED THE PROBLEM This part of the dissertation is much more free-form. It may have one or several sections and subsections. But it all has only one purpose: to convince the examiners that you solved the problem that you set for yourself in Section 4. So show what you did that is relevant to solving the problem: if there were blind alleys and dead ends, do not include these. 6. CONCLUSIONS You generally cover three things in the Conclusions section, and each of these usually merits a separate subsection: a) Conclusions b) Summary of Contributions c) Future Research 7. REFERENCES The list of references is closely tied to the review of the state of the art given in section 3. Most examiners scan your list of references looking for the important for the important works in the field, so make sure they are listed and referred to in section 3. Truth be known, most examiners also look for their own publications if they are in the topic area of the dissertation, so list these too. Besides, reading your examiner's papers usually gives you a clue as to the type of questions they are likely to ask. All references given must be referred to in the main body of the dissertation. Note the difference from a Bibliography, which may include works that are not directly referenced in the dissertation. Organize the list of references either alphabetically by author surname (preferred), or by order of citation in the dissertation. 8. APPENDICES What goes in the appendices? Any material which impedes the smooth development of your presentation, but which is important to justify the results of a dissertation. Generally it is material that is of too nitty-gritty a level of detail for inclusion in the main body of the dissertation, but which should be available for perusal by the examiners to convince them sufficiently. Examples include program listings, immense tables of data, lengthy mathematical proofs or derivations, etc. A COMPUTER PROGRAMS AND OTHER PROTOTYPE The purpose of your dissertation is to clearly document an original contribution to knowledge. You may develop computer programs, prototypes, or other tools as a means of proving your points, but remember, the dissertation is not about the tool, it is about the contribution to knowledge. Tools such as Computer Programs are fine and useful products, but you can't get an advanced degree just for the tool. You must use the tool to demonstrate that you have made a an original contribution to knowledge; e.g., through its use, or ideas it embodies. HOW TO WRITE AN ABSTRACT ABSTRACT Because on-line search databases typically contain only abstracts, it is vital to write a complete but concise description of your work to entice potential readers into obtaining a-copy -of the full paper. This article describes how to write a good computer architecture abstract for both conference and Journal papers, Writers should follow a checklist consisting of motivation, problem statement, approach, results, and conclusions. Following this checklist should increase the chance of people taking the time to obtain and read your complete paper. INTRODUCTION Now that the use of on-line publication databases is prevalent, writing a really good abstract has become even more important than it was a decade ago. Abstracts have always served the function of "selling" your work. But now, instead of merely convincing the reader to keep reading the rest of the attached paper, an abstract. must convince the reader to leave the comfort of an office and article from a library or worse, go hunt down a copy of the obtain one after a long wait through inter-library loan). In a business context, art "executive summary" is often the only piece of a report read by the people who matter; and it should be similar in content if not tone to a journal paper abstract. CHECKLIST : PARTS OF AN ABSTRACT Despite the fact that an abstract is quite brief, it must do almost as much work as the multipage paper that follows It. In a computer architecture paper, this means that it should in most cases include the following sections. Each section is typically a single sentence, although there is room for creativity. In particular, the parts may, be merged or spread among a set of sentences. Use the following as a checklist for- your next abstract: * MOTIVATION Why do we are about the problem and the results? if the problem Isn't obviously "interesting" it might, be better to put motivation first; but if your work is Incremental progress on a problem that Is widely recognized as important, then it is probably better to put the problem statement first to Indicate which piece of the larger problem you are breaking off to work on. This section should include the importance of your work, the difficulty of the area, and the I impact it might have if successful. * PROBLEM STATEMENT What problem are you trying to solve? What is the scope of your work (a, generalized approach, or for a specific situation)? Be careful not to use too much jargon. in some cases It is appropriate to put the problem statement before the motivation, but usually this only works If most readers already understand why the problem is Important. * RESULTS What's answer? specifically, most good computer architecture papers conclude that something is so many percent faster, cheaper, smaller, or otherwise better that something else. Put the result there, In numbers. Avoid vague, handwaving results such as ".very", "small", or "significant". If you must be vague, you are only given license to do so when you can talk about orders-of-magnitude improvement. There is a tension here In that you should not provide numbers that can be easily misinterpreted, but on the other hand you don't have room for all the caveats. * CONCLUSIONS What are the implementations of your answer? Is it going to change the world (unlikely), be a significant "win", be a nice hack, or simply serve as a road sign indicating that the path is a waste of time (all of the previous results are useful). Are, your results general, potentially generalizable, or specific to a particular case? OTHER CONSIDERATIONS An abstract must be a fully self-contained, capsule description of the paper. It can't assume or attempt to provoke), the reader into flipping through looking for an explanation of what is meant by some vague statement. It must make sense all by itself. Some points to consider include: * Meet the word count limitation. If your abstract, runs too long, either it will be rejected or someone will take a chainsaw to it to get it down to size. Your purposes will be better served by doing the difficult task of cutting yourself, rather that leaving it to someone else who might, be more interested in meeting size restrictions than an representing your efforts in the best possible manner. An abstract word limit of 150 to 200 words is common. * Any major restrictions or limitations on the results should be stated, if only by using 'weasel-words' such as "might", "could", "may" and "seem". * Think of a half-dozen search phrases and keywords that people looking for your work might use. Be sure that those exact phrases appear in your abstract, so that they will turn up at the top of a search result listing. * Usually the context of a paper is set by the publication it appears in (for example, IEEE computer magazines about computer technology). But, if your paper appears in a some what un-traditional venue, be sure to include in the problem statement the domain or topic. area that it is really applicable to. * Some publications request 'keywords". These have two purposes. They are used to facilitate keyword index searches. which are greatly reduced in importance now that on-line abstract text searching is commonly used. However, they are also used to assign papers to review committees or editors, which car. be extremely importatant to your fate. So make sure that the keyword' s you pick make assigning your paper to a review category obvious (for example, if there is a list of conference topics. use your chosen topic area as one of the keyword tuples). CONCLUSION Writing an efficient abstract is hard work, but will repay you with increased Impact on the world by enticing people to read your publications. Make sure that all the components of a good abstract pre included in the one you write. FURTHER READING Mohaelson, Herbert. How to write & Publish Engineering Papers and Reports, Oryx Press, 1990 Chapter & discusses abstracts Cremmins, Edward, The art of abstracting 2nd Edition, info Resources Press, April 1996. This is an entire book about abstracting, written primarily for professional abstracts. FORMAT OF M.TECH DISSERTATION The dissertation should be in the following format. Otherwise, the submission is rejected. " Cover/Title Page " 1st Page = Cover page " Certificate (Dept.) " Company certificate if applicable " Acknowledgements " Abstract " Table of contents with page numbers " Rest of the Dissertation : follow the guidelines given " References REFERENCES EXAMPLE: 1. Dias, F.J.O., "Truth-table verification of an iterative logic array," IEEE Tans. On Computers, Vol. C-25, PP 605-613, June 1976 2. "Signature analysis," Hewlett-Packard Journal, Vol. 28, No. 9, May 1977 (1) (2) are to be shown in text. " Bibilography BIBILOGRAPHY EXAMPLE : 1. (Author) (Text Book) (Publisher), Year " Appendix |
Engineering Colleges in India
Get the most comprehensive list of Engineering Colleges in India
Engineering Admission Notifications
Recent Notifications for admissions to various Engineering Colleges in India
Business Schools - Engineering Colleges - Medical & Nursing Admissions - BEd in Distance mode - Journalism & Media Studies - IGNOU
Enter a detailed keyword. Ex: Syllabus of IGNOU Ist year BSc Computer Science course