What is the procedure to write a Project file?
Answers
Answered by
0
Format for Project Reports
The project reports should be like conference papers: concise and focussing on what you did.
Format: Use 1 inch margins (left and right), 1 inch margins (top and bottom), 11 point times font for the main text, and use 10 point courier font for computer code. Use your judgement for other situations (for example indented, italics, and 10 point courier font for quotations). Single space your text. Make the text fully-justified (where the letters are aligned on both the left and right). The text should be in 2-columns, with 3/8 of an inch of space between columns. Your paper should be 4 pages long. Having only 3 pages is fine, as long as the content is good. Anything 6 pages or longer will not be graded.
If you want to use LaTeX, here are two examples with the formatting already done. You can just remove the text that you do not need. You will also need either the ieee.clsclass file or the IEEEconf.cls class file. Just download both class files until you decide which one you like.
Example final report, journal style .tex fileand its output.Example final report, conference style .tex file and its output.
You are allowed to have appendices, as needed. Appendices are mainly for code or mathematical derivations. Appendices do not count in the page count. For example, if you have 4 pages of report, you may also turn in an appendix that is as long as you like. The appendix should be like a separate document, with your name(s) on it. Attach it physically to the report, e.g. with a binder clip.
Yes, your code should be in the appendix, monospaced, single column. You do not have to turn in all code used in your experiment; use your best judgement. You may want to include only relevent sections of code. For example, you should not include code that someone else wrote, unless you made major modifications. If your code is 100 pages, you should not print all of it. If your code is 6 pages, then you should print all of it.
If you include a work-log, you can put it in the appendix. Or you could incorporate it into one of the sections of the report, if it is appropriate.
The references must be in the same 2-column format as the rest of your paper.
For a conference paper, most people will read the abstract to see if they find it interesting enough to read the whole paper. This makes a lot of sense if you go to a conference in a topic that interests you, but find that there are 100+ other papers.
By the way, I recommend writing the abstract LAST, since it is easier this way.IntroductionWhy your topic is important (convince us!)Where is it used? ApplicationsWhat you will talk about/doOverview of the rest of your paper (section 2 covers...section 3 presents...)BackgroundAny relevant and specific infoe.g. hardware statistics, equipment used
What other people had to say on this topic(s)(be sure to cite your references, and quote as appropriate.
Each team member must submit an individual report. It is possible to refer to someone else's report, such as a team member. But you must document that report like you would any other source. You can quote from it, as long as you enclose it in double-quotes, and put the citation after it.
See the following guide to documenting your sources.
See the paper summary feedback for useful examples of what to do when writing a technical document.
Remember your audience - your paper should be understandable by any CS student (at your level) who has taken this class.
Things to include in the report:
PicturesYour observations and measurementsEquationsGraphsFiguresSimulation, model (E.g. our design took 200 cycles to do task #1. We ran it 10 times, and the time for each run is: 12, 15, 16, 14, 13, 15, .. Therefore, we expect the second task, which is twice as long, to take about 30 sec).Note: If you use color graphs, make sure you use a color printer when printing the report! I have seen several reports that say things like "the blue dots represent ..., while the red ones represent...", only to have the figure printed in grey-scale.
The project reports should be like conference papers: concise and focussing on what you did.
Format: Use 1 inch margins (left and right), 1 inch margins (top and bottom), 11 point times font for the main text, and use 10 point courier font for computer code. Use your judgement for other situations (for example indented, italics, and 10 point courier font for quotations). Single space your text. Make the text fully-justified (where the letters are aligned on both the left and right). The text should be in 2-columns, with 3/8 of an inch of space between columns. Your paper should be 4 pages long. Having only 3 pages is fine, as long as the content is good. Anything 6 pages or longer will not be graded.
If you want to use LaTeX, here are two examples with the formatting already done. You can just remove the text that you do not need. You will also need either the ieee.clsclass file or the IEEEconf.cls class file. Just download both class files until you decide which one you like.
Example final report, journal style .tex fileand its output.Example final report, conference style .tex file and its output.
You are allowed to have appendices, as needed. Appendices are mainly for code or mathematical derivations. Appendices do not count in the page count. For example, if you have 4 pages of report, you may also turn in an appendix that is as long as you like. The appendix should be like a separate document, with your name(s) on it. Attach it physically to the report, e.g. with a binder clip.
Yes, your code should be in the appendix, monospaced, single column. You do not have to turn in all code used in your experiment; use your best judgement. You may want to include only relevent sections of code. For example, you should not include code that someone else wrote, unless you made major modifications. If your code is 100 pages, you should not print all of it. If your code is 6 pages, then you should print all of it.
If you include a work-log, you can put it in the appendix. Or you could incorporate it into one of the sections of the report, if it is appropriate.
The references must be in the same 2-column format as the rest of your paper.
For a conference paper, most people will read the abstract to see if they find it interesting enough to read the whole paper. This makes a lot of sense if you go to a conference in a topic that interests you, but find that there are 100+ other papers.
By the way, I recommend writing the abstract LAST, since it is easier this way.IntroductionWhy your topic is important (convince us!)Where is it used? ApplicationsWhat you will talk about/doOverview of the rest of your paper (section 2 covers...section 3 presents...)BackgroundAny relevant and specific infoe.g. hardware statistics, equipment used
What other people had to say on this topic(s)(be sure to cite your references, and quote as appropriate.
Each team member must submit an individual report. It is possible to refer to someone else's report, such as a team member. But you must document that report like you would any other source. You can quote from it, as long as you enclose it in double-quotes, and put the citation after it.
See the following guide to documenting your sources.
See the paper summary feedback for useful examples of what to do when writing a technical document.
Remember your audience - your paper should be understandable by any CS student (at your level) who has taken this class.
Things to include in the report:
PicturesYour observations and measurementsEquationsGraphsFiguresSimulation, model (E.g. our design took 200 cycles to do task #1. We ran it 10 times, and the time for each run is: 12, 15, 16, 14, 13, 15, .. Therefore, we expect the second task, which is twice as long, to take about 30 sec).Note: If you use color graphs, make sure you use a color printer when printing the report! I have seen several reports that say things like "the blue dots represent ..., while the red ones represent...", only to have the figure printed in grey-scale.
Similar questions