Bachelor/Master Projects
The goal of semester projects is for students to learn more about the research process in our area and to contribute to the lab’s research by applying that process. This involves obtaining in-depth knowledge, trying out new ideas, and communicating results. You will be working on a topic related to what the lab is doing, so we will be there to help, and we will also expect you to produce interesting results that advance the corresponding projects.
A Master thesis project is more advanced: beyond learning new things, it must include a well defined component that tackles a new problem, one for which no accepted solution currently exists, but for which the student attempts to develop (and assess) a solution as part of the project. In the case of a project conducted within a company, this component must be applicable beyond the confines of the company – it must add to the knowledge base of the technical community. Whether or not a component meets the requirements of the section is determined by the supervising professor, with final authority resting with the section director and associate dean. A Masters thesis student must also demonstrate the ability to conduct independent work in research or advanced development.
What you can expect from us
It is your project and you own it start-to-finish. We will provide you with guidance and help you whenever you are stuck. If you need advice on how to proceed, if you are out of ideas, or if you are stuck on an implementation issue, contact your supervisor. However, you must have first tried to solve the problem yourself before reaching out for help. Do not be afraid to “bother” us – if we are too busy at the moment we will let you know and/or reply later.
We will also happily chat with you if you have ideas about the project, or questions about the general research area you are working in.
There is a delicate balance between asking your supervisor too often and too rarely. You should only ask after trying to solve your issue yourself, such as searching for solutions on the Web, trying out some ideas, and asking your friends and colleagues if you are working in a shared space. On the other hand, you should not spend too much time trying to solve a problem if you have no idea how to proceed, and your supervisor will often be able to quickly point you in the right direction thanks to experience. You must have the maturity to recognize when it would be more productive to ask someone else (e.g., if you have been stuck for several hours without progress). A good rule of thumb is to think as follows: “I encountered problem X. I tried approach A and approach B, but they didn’t work because … I now need help in order to …”
What we expect from you
We expect you to have some independence during your project, and we are trusting you with taking ownership and initiative. You should be the main driving force behind your project.
We are interested in your results, not in how long you spent in front of your computer. Learning to estimate how much time a task takes and to manage expectations is a fundamental part of any project.
We know that life does not always go as planned, so please tell us if you cannot work as much or as well as you would want to. We will work with you to find a solution, but we need to know that there is a problem. You will be our colleague during your project, so we expect you to let us know in advance if you will not be available, just as we will let you know if there is something on our side.
EPFL also imposes some requirements on you, such as semester deadlines or formatting requirements for thesis cover pages. Please read the EPFL rules for Bachelor projects, Master projects, and the EPFL guidelines on copyright and plagiarism. We expect you to proactively inform yourself about all these rules and to apply them judiciously; it is not our responsibility to ensure that you follow them. Of course, ask us if you need help.
In the case of a Master project conducted within the company, issues of confidentiality must be addressed before the proposal can be accepted. It is understood that the work done by the student will remain property of the company, but the supervisor will not sign any non-disclosure agreement, and the student and company supervisor are responsible for not sharing any confidential information with any member of DSLAB. Your Master thesis must be public; confidential MS theses, while not forbidden by EPFL, are not acceptable in IC.
Organization
You will typically have weekly meetings with your supervisor (except for projects in industry) to discuss what you’ve done in the past week, and what you’ll be doing in the upcoming week. This is also a good time to ask high-level questions and to propose any new ideas you have. Meeting earlier is also possible if you are stuck. This is similar to the sprint debriefs we teach in the Software Development Project course.
We ask you to keep track of your progress in a progress report shared with your supervisor, preferably in a Google Doc, in which you write a short paragraph summarizing what you did each week. To allow us time to prepare for the weekly meeting, please update the report at least 2 hours before the meeting. This is useful for both you and us: it allows you to remember what you’ve done, which is particularly useful when it feels like you have not gotten anything done even though you worked hard on leads that did not pan out, and it allows us to know what you’ve done, so that we can better guide you towards the overall goal. It’s a good idea to write down your progress and new ideas as they happen, instead of stressing out to write it just before the meeting.
At the beginning of your report will be a list of project goals you agree on with your supervisor. This list can evolve with time, but any changes must be agreed upon by both you and your supervisor.
Final report
Your project report/thesis is a description of the important parts of the project: its initial goals, its major steps, and its final results, including a discussion of lessons learned, alternatives identified in hindsight, and possible future steps. It should be a summary for members of the lab and future project students; target your report at the level of knowledgeable classmates, not expert researchers (unless your report turns into a research paper).
Structure your report in six parts: (1) an introduction to the problem, summarizing any necessary background material, (2) a description of your design, explaining how it helps solve the problem as well as any design choices you made, (3) a description of your implementation, in enough detail that one can understand the overall picture without having to read your source code, (4) an evaluation, including any benchmark results, (5) a discussion of the results, including interesting insights you gained, as well as the limitations of what you did and how the work could be extended or improved in the future, and (6) a list of the references you used in the rest of the report.
In the case of an industry project, it is understood that only part of the work conducted in the company can be viewed as research and development, so the thesis need not cover all of the work done for the company. Instead, the thesis focuses on the parts of that work that demonstrate what the student did to formulate the main problem, address it, develop solutions for it, and assess these solutions.
Your report should not exceed 10 double-column pages in 11-point font, unless you really believe the added length is worth it. Keep it as short as you believe is appropriate, do not pad with filler text to reach a target page count. We prefer reading a concise report with a high density of good insights and ideas than a long, watered down report that states obvious things.
Your supervisor can help you with the report, so feel free to send drafts for feedback, both at the beginning when you only have an overall structure and at the end when you are almost done.
Presentation
Depending on your project’s outcome and on the lab’s availability, we may ask you to present your project during one of our lab meetings. The goal is to give you an audience to discuss your results, and to share with the lab your results. We are especially interested in any unusual, unexpected, and interesting findings, even if they do not directly relate to the results.
Code
Your code should include a README file with (1) an overview of the code architecture, such as which modules do what and how the modules are tied together, (2) all instructions necessary to run your code, and (3) all instructions necessary to benchmark or otherwise evaluate your code. The audience for this file is any future lab member or project student who might need to reuse your code.
Your code should be correct and easy to understand, but it does not need to meet “production” requirements such as API documentation or fully automated installation instructions. It’s fine to merely link to your dependencies along with an explanation of how to install and configure them. We would rather you spend time getting interesting results than tediously documenting every little thing.
Grade
We grade projects based on your work during the semester, your results (code, interesting ideas, etc.) and your written report and/or presentation. Your ability to operate independently during the semester plays an important role in the evaluation, as does your time management. The more interesting ideas and results you come up with, the better your grade.
The approximate grading scheme for all projects/theses is as follows:
- 6.0 is for truly excellent work and results. For example, “A Formally Verified NAT Stack” was an evolution of a Master thesis done in the lab, and influenced the later “Verifying Software Network Functions With No Verification Expertise” paper published at SOSP, which is a top conference in computer systems.
- 5.5: very high quality; exceeds expectations
- 5.0: great work; meets expectations
- 4.5: OK with minor problems; partially meets expectations
- 4.0: meets basic quality requirements; clearly below expectations
- below 4.0: does not meet basic quality requirements
Quarter grades (e.g., 5.25) are also used.