# NTU MSc Dissertation NTU Shield **Student**: Donald Duck
**Supervisor**: Dr. Nachiket Kapre
**Date**: 22nd August 2013
Download the Markdown template [msc_dissertation.md](./msc_dissertation.md).
> wget https://nachiket.github.io/advice/msc_dissertation.md To compile on Mac OS X or Ubuntu Linux with [Pandoc](https://pandoc.org/) installed, use > pandoc msc_dissertation.md -o msc_dissertation.pdf
**Grading Policy**
| | | | |:--|:--|:--| |20% | Regular 1:1 meetings | The process of conducting yourself through the MSc is as important as the final product. You will be expected to attend all 1:1 weekly meetings. Exceptions only with MCs. | |10% | Draft plan | A good engineer knows how to provision the most important resource: **time**, for a project. I will expect at least a rough plan outline that we revise as we execute the project. | |20% | Regular 15-minute group presentations (once a month) | A good engineer is also a good oral communicator. I will expect short 15-minute presentations to my research group once a month. Ultimately, I want you to become a confident speaker and a great communicator. | |50% | Final report | Technical report writing is very different from writing an exam. In industry, you will be expected to be precise with your specifications and communications. At the same time, you need to tell a **good story**. You need to connect with your reader at several levels. |
# Advice - Use active voice. - e.g. We show how to speed up computations (**correct**) - e.g. It is shown that speedup can be achieved. (**wrong**) - Good engineering students should *quantify* all aspects of their design. Vague claims "this is good, this is bad" will not be appreciated. - Use examples to explain difficult concepts. Simply writing equations or program pseudo-code is *not* enough. Try to convey the intuition behind the problem you are solving. - Use Markdown and Pandoc on Ubuntu or macOS to generate your preliminary reports. Eventually you will have to switch to LaTeX. - State **novelty** of the MSc project. I expect MSc reports to be novel in some way. They cannot simply be engineering efforts. - Become familiar with **gnuplot** or other visualization tools to help you better support your plotting needs. I will *NOT* accept Excel-based plots. - Think about designing good experiments. It is not sufficient to merely get your idea working. Evaluation is not binary -- works versus does not work. In fact, there is a lot you can learn even if your ideas do not work. How well does your system perform? What are its operating limits/weaknesses? Can it be improved and by how much? - Tell a good story. Ultimately, we all like to listen to a carefully constructed narrative. Make it interesting for everyone.
The MSc dissertation should be modelled on a research paper with the following breakdown of sections. This is recommended for double-column, double-sided A4 pages with 10-point font. Read a few technical papers first to get a hang of the language/tone expected and the type of report you will be expected to write. # Abstract (1 page) - A crisp, quantitative claim describing what you have achieved (quantitative = numerical statement) - e.g. We can make SPICE run 10 times faster using cheap off-the-shelf hardware (**correct**) - e.g. SPICE runs faster when using our ideas (**wrong**) - Explain the idea behind your project effort. Why does your idea work (or not?). - Elaborate the idea with *insightful* comments about the instinct behind the idea. - If this is an unexpected result, say what the typical expectation is... - How does this advance the state-of-the-art in the field? # Introduction - Gentle introduction of the subject under discussion. Writing introductions is an art. Try to think of how a popular science article is written. It should almost be something that your mom can read and understand. - A nice iconic picture that captures your problem/system would be perfect here. This may or may not be possible in your project. This will help the reader associate your report with this first visual impression. - At the end, summarize a list of key claims/deliverables of the report. # Background (2 pages) - What new knowledge did you need to learn to implement your project? This should cover scientific or technical ideas rather than *personal experience*. - e.g. I had to learn Linux (**wrong**) - e.g. If a friend from a different specialization were to read your report, what key concepts from your area would they need to know? Identify those concepts and write self-contained, high-level summaries. (**correct**) # Literature review (1 page) - No scientific scholarly work is complete without context. It is important that you talk to your advisor to get a broader perspective of the area. Your work will sound a lot more intelligent when you show that you have made an effort to highlight the contrast between your report and other efforts. - A tabular taxonomy or classification of existing ideas can be helpful. This also shows that you are systematic and know how to visually place your work in the world. # Idea (3-4 pages) - This is all up to you. Good students distinguish themselves from others by using examples to walk a reader through the mechanics of the internals of the project. - Meaningless, laborious, complex details do not impress anyone. Think hard about what details to leave out. Just because you spent a lot of time being stuck at a particular step of the problem does not mean you have to devote a proportional amount of space in text. - Make it interesting to read. Examiners have to read dozens of reports. Cute analogies, pretty pictures, good examples will stand out and be remembered. Boring details and hard-to-understand descriptions will be forgotten. # Experiments (5-6 pages) - Most students ignore this component. They stop at the "it is working" phase. I really only start to evaluate the student project when I start seeing numbers and quantification of the project. - Design good experiments. Put on your scientist's hat and think about how you can show off your achievements. - Learn to use plotting and graphing tools. Use labels and text that are clearly visible. Examiners do not carry around magnifying glasses on a typical workday. - Provide a head-to-head comparison with a competing system if it exists. This will further reaffirm the quality and scholarly nature of your work. - Provide an in-depth discussion of the key ideas that emerge after looking at the data. # Conclusions (1 page) - Restate the quantitative claim from the abstract. Tell the examiner what you have already explained (repeat it for clarity). - DO NOT INTRODUCE A NEW IDEA IN THE CONCLUSIONS. All concepts should have been covered earlier. - Conclusions are only a place to collate the 'aha' moments you had when writing the report or conducting your experiments. # Planning (1 page) - How does your final execution compare to the actual initial plan sketch? - What new skills did you learn during the MSc project? Did you have to learn something that you never thought you would have to/be able to learn? - What was your working relationship with your advisor? Did you expect things to be different and in what way? # Future Work (1 page) - No project is complete without a path forward. Do not be afraid to think of the weaknesses of your project. - Think about what you did not have time to complete but your advisor wanted to see completed.
Updated: 22nd August 2013