Notes for Msc Students

Project Report

The report should be structured as follows.

Abstract

The abstract provides a succinct description of the work. It should briefly touch the following aspects:

• what is the problem
• why is it important
• limitations of state of the art
• key idea/insight of the proposal

Introduction

The introduction should be around 2/3 pages in length and should address the following aspects:

• context of the problem
• problem definition: what is the problem? Why is the problem important?
• why was the problem not solved before?
• what are the challenges? And limitations of the state of art?
• objectives of the thesis: what is going to be solved, what is going to be improved over the state of the art
• brief overview of the key idea/approach/solution/technique
• explain how the rest of the document is organized

Related Work and Background

This section presents the state of the art, showing that you are aware of the state of the art and properly understand other works. Just summarizing the papers/systems it not enough, a good related work presents the key ideas of the paper, and stresses its positive and negative aspects in a critical way. The limitations presented will serve as additional motivation for your work.

The related work should be structured with subsections that cluster the works along some sensible dimension that is important to your work: e.g.: centralized vs decentralized.

Discussion

It is important to end the related work with a discussion that summarizes the state-of-the-art in a critical way and further motivates your work. This should be synthesized in a table that highlights the several dimensions that are important to you work: what are the important properties/functionality/ideas. The final line of the table should be the system which you are proposing thus quickly highlighting the main differences between your work and the other ones.

Background

Often it is important to provide the reader with additional information on a certain topic so that s/he can understand your work. This could be either a subsection inside the Related Work or a Section on its own.

An easy way to distinguish between background and related work is to ask the following: am I just using this technique/paper/idea in my work or is my proposal competing/offering a different trade-off than it? If the former then the work goes into the background otherwise related work.

Architecture

This section describes your approach/proposal/system. It should cover the following aspects:

• reiterate the problem and objectives
• describe the system in a high-level top-down fashion. Describe the architecture, the components and how they are going to address the stated objectives
• a figure depicting your proposal is worth a thousand words
• if several alternatives are still on the table, discuss the advantages and short-comings of each and the planned steps to assess what is the best approach
• if relevant, discuss any technology-related aspects: programming language, frameworks, etc
• conclude with a discussion section highlighting the main features/novelty and how this will address the objectives

Evaluation

This section describes the evaluation plan. It should cover the following:

• what are the main questions the evaluation is going to answer, for instance: is the proposed system faster/more efficient/scalable/secure/etc. Once again this should be in line with the objectives
• what are the evaluation metrics? If relevant identify quantitative and qualitative metrics
• what is the workload that is going to be considered? Standard benchmark? Use case? etc
• what is the baseline, i.e. what is the solution going to be compared with

Each of the above points should be properly justified.

Work Plan

Brief description of the work plan, highlighting the main tasks and how they relate in time. You can use a Gantt chart or a simple table or textual description.

Future work is scheduled as follows:

• January - February: refine the architecture
• February - March: …

There is no point in having low-level granularity, nobody wants to know what you will be working on day 96 of the work plan (and you don’t know either)

Conclusion

This section concludes the document. It should summarize the work done, reiterate the problem, how the solution is going to address it and the expected challenges.

General Notes

• use proper citations, including a tilde (~) between the word and the \cite command to prevent unwanted line breaks. E.g.: John et al.~\cite{John:5} …
• make sure the bibliography if properly formatted, see these guidelines
• learn how to write a bad research paper
• Grammar mistakes are not acceptable, using the tools or your system or online tools (Grammarly, an LLM) helps produce error-free documents